simple distributed objects have been here a while
on
Phoenix 0.3 Is Out
·
· Score: 2
NeXTSTEP has awesome distributed object support that lives on in OS X. Distributed objects in objective C using the foundation framework (which I believe is implemented in gnustep as well) is incredibly simple, yet still plenty flexible. Whether you're talking across threads, processes, or the Internet, sending messages (i.e. making method calls) on distributed objects is almost indistinguishable from sending messages to other objects. In fact, a method was added to NSObject to tell you whether or not the object you're working with is being accessed as a distributed object.
Java RMI isn't too bad, but anyone who implements (or even works on) any type of distributed object system without doing distributed object work in the NeXT foundation kit is at a disadvantage, in my opinion.
It also sounds like "hard link" is the same as Unix "hard link" which are actually a big mistake in Unix design and are pretty useless. Also the documentation indicates that this exists only in NT 5.0 and later.
*shrug* I find that having multiple hard links to a file is extremely useful. I guess it depends on your application.
I also thought that it was pointless to create a native application using java, but then, out of necessity, that's exactly what my first OS X application ended up being.
I have a web-based app that I wanted to create a non-web GUI for (involved various file uploads and stuff that could more easily be handled via a native GUI). The server supports XML-RPC, but at the time, I didn't have an XML-RPC framework I could use from Objective C. However, I did have a fully functional commandline app that did it that I'd written in java.
So, I just fired up project builder, told it I was writing a java cocoa app, and spent a while getting the UI the way I wanted it, then just plugged in a couple methods to the controller to call the existing code.
Because this was my first OS X application, it was a learning experience as far as picking up the cocoa concepts and stuff, but it only took a day of me being home sick (and I felt pretty crappy, so I wasn't working all that fast).
The time I spent learning cocoa concepts was not wasted at all. I figured out how to build frameworks and get them into my application, so I had the stuff I needed to go full objective C. I *copied* the UI I'd already made into a new project, and pasted a lot of the code straight from the java app to the objective C app (mostly controller stuff). Of course, I had to convert the java cocoa calls to objc, but for the most part, that was it.
Moral of the story: If you intend to write a native OS X app, and you don't have all the parts you need in objc, but you do have most of it in java, do it in java! It was a good proof-of-concept anyway.:)
Tell that to the voters of Florida who were prevented from submitting a vote that was counted.
The current system does not work as well as a system that could have problems introduced in CPU microcode. Software and hardware systems can be tested to keep people confident that, given a set of input will produce an expected set of output consistently. If the thing stays as simple as entering an ID and clicking a bunch of boxes, it's pretty easy to test all of the possible cases and run that test suite every single day (hour, etc...).
I live in Santa Clara and get my power from Silicon Valley Power. I don't think it's fair to say ``just like everbody else'' when everybody else was paying $400/mo electricity bills last year with very low load, I was paying closer to $50 with a data center in my garage.
I don't know as much about them as the parent of this thread, but they sure seemed to be doing something differently than the rest of the valley.
While I don't have enough comments to justify a properly structured reply, I would like to comment on two of them.
regarding video: BNC is *easy*. Slip it in, lock it, done. I've had plenty of VGA ports I couldn't get plugged in properly.
regarding internal drive power: I've had plenty of these that I couldn't unplug without a great deal of effort, and I had one just a couple of days ago fall apart when I was trying to unplug it.
doesn't make it cumbersome. You can't find the terminal? Bring up a finder window. Click on the applications button at the top. Find the Utilities folder (should be somewhere near the bottom, you can always resort the window). Now, find the terminal icon in this window. Drag the icon onto the dock. At this point, it'll always be there for you, one click away. Repeat for any other app you intend to use frequently. If you find that you aren't using one of these apps frequently, drag it off the dock and watch it go *poof*.
Of course, I run XDarwin in fullscreen mode, and xterms are a matter of me pressing ``x'' on the background. cmd-opt-a takes me back to Aqua where I have my web browser and whatever else I don't run under X.
If the screen's to small, get a bigger one, or another one (my powerbook will drive a second head at 2048x1536, although I haven't pulled out the 18" LCD since I bought it).
What you need to realize, though, is that your Linux box isn't as capable. My wife runs KDE on her iBook (under OS X). She also runs iMovie for simple NLE, and processes some of her video with quicktime (as do I, but I'm a twm guy, myself). While gphoto is somewhat nice, it's not iPhoto. I haven't used a lot of gui MP3 players, but iTunes will play mp3s that mpg123 will not, and it makes mastering CDs easy (although the shell scripts on my FreeBSD box were usually easy enough).
There have been a few problems, sure (OpenOffice spreadsheets won't let me add numeric values for whatever reason, so we're stuck with koffice in the meantime), but overall, it's been everything I've been getting out of other systems, plus tons of OS X and OS 9 software (stupid handspring doesn't support OS X yet, so I have to use OS 9 software, which works flawlessly).
Well, sorry, but it is worthy. It's not a "full" database like you'd like for your work, but it's more than enough for a huge number of problems.
mySQL is the right tool for *far* fewer jobs than those to which most people believe it applies. Many people end up writing code to deal with various aspects of data management that the database is supposed to take care of because they don't know that the database is supposed to take care of the data.
If you only know mySQL, you will attempt to solve your problem within the limitations of the tool. The problem is that many things can't be done in multithreaded or worse, multi-process application code to ensure integrity. If the DB won't do it, and it doesn't support transactions, then you've just gotta hope people don't ever use your application in a way that will make your data invalid.
I just don't get the appeal of mySQL. The last time I tried it, it seemed more difficult to use than postgres, and it supports a subset of the functionality. I have not done a project that doesn't require at least some basic database feature that mySQL doesn't have in years. Sure, I suppose I could've written code to emulate some of those parts of the database, but certainly not all. For the parts I could emulate, the application would most certainly run more slowly (multiple queries to emulate a subquery or what I do in a stored procedure), and the ones I couldn't would just have to be left out, which would make the applications more buggy (lack of transaction support on applications that run on multiple front-ends would simply cause the apps to fail).
Anyway, basic point is that if you don't understand your problem and/or the tools that are out there to help you solve it, you will solve it incorrectly. It may seem like it's working, but those types of implementations fail really quickly when they go multi-user.
Yeah, looks like he did it using PowerPoint, too. So?
Maybe the point is worth more than the medium here. Maybe by the time he's ready to do another one of these, you will have written him tools better suited to his message.
In the meantime, the message is valuable. If you don't like the format, use an open source converter to make it a format you like more. When you're done, listen to it, and learn from it.
8) No, not on your life. You can take my primitives from my cold dead body. If you want to suggest that primative should not be used in most production applications that's fine, but their is a time and a place for priatives that are very important. Suggesting that we get rid of primatives severly hurts your credability.
There's no reason to tie such things together. Primitives are a design flaw in the java language (not the VM). There is no reason to have a distinction between the primitive int and the Integer object. A reasonable compiler should be able to see how the variable is being used and do the right thing. See Eiffel. In Eiffel, everything is an object, yet performance is amazing.
Keep in mind that an interface is just an abstract class with the additional requirement that there can be no non-abstract methods in the interface. This is the point at which it becomes unreasonable. It leads to lots of implementations of the exact same functionality (imagine how many implementations of getString() in JDBC ResultSet classes do the exact same thing).
So, there are two needs for Interfaces. Java deals with one of them, while leaving code reusability kind of out to dry.
Operator overloading is certainly not a bad thing. Evidence of this is in the String + operator in java.
you can control whether or not it is read or read/write by a hardware toggle. ... Read only access means that noone can swap your private key for another private key, or delete your keys, or...
Dude, your secret is out! Now that They know about the switch, your secrets are no longer safe.
Perhaps if you are looking for perl programmers who will need to be doing a lot of textual processing, but that's definitely not the case in other areas.
I prefer to work with people who don't do a lot of regex, because they're less likely to use them for everything. I haven't worked on a large project that used regular expressions in years. I feel pretty good about that.
Sure, I've used them in a couple small scripts for parsing text, but if you see the majority of programming requiring regex, you definitely need to put your hammer down and pick up a Makita.
One has a feeling that regexp engines are just becoming programming languages in and of themselves - the only difference being that the 'program' consists of a string of cryptic single character commands, and the input is limited to a single string.
You forgot to mention that it also does what you're trying to accomplish as a side-effect of what you actually told it to do.
That's the thing that bothers me the most. The examples people are giving here are symptoms of the real problem. If you want to know if this piece of data you're looking at is a number, use a programming language that supports numbers and see if you can make a number out of it, then use the number.
Want to know if your input contains ``nasty characters?'' Wrong, you don't. You want to know if it's what you are expecting. At best, you want to know if it contains only characters you have authorized in a proper sequence that makes sense. You can sometimes do this with a regex, but not treating your data as strings in the first place gets rid of most of the desires to do textual processing on it. It makes your application development easier, more correct, and easier to read. It also makes it less likely to need to be modified down the road when you realize you overlooked unicode conversions, null characters, or other things that cause security holes.
Geez, what is it with people and complicating simple tasks with regex? How about:
ls/bin/??/usr/bin/??
Which is roughly the equivalent of doing:
echo/bin/??/usr/bin/??
if your shell has a built-in echo and you want to avoid forking of another process. That seems a lot more intuitive of a way to look for a command with two mystery characters. Or just one mystery character:
Don't expect it to ever work nearly as well as anything running on Apple hardware, though. One of the main reasons OS X works so well is that they're not trying to support every computer ever made.
Awesome software - take a look
on
Am I Hot or Not
·
· Score: 1
I've got a stack that I wrote and have been using for a few years without a problem...well, until 0325 this morning when a battery in one of my thermometer servers caused the machine to fail. It does a lot of cool stuff, including some cool multicast action for plug-n-play data collection and stuff. You can see some good examples here:
I've got about 3600 images in mine and the advanced search can do the same types of things you're looking to do. Without an account, you won't see most of the pictures in my album, but you can get the idea.
Additionally, I did a search filter system last night that allows me to (for example) show me no more than one picture taken on any given month, selected randomly. Makes it useful to show progression.
My photos are in postgres via photoservlet, my mail is in my IMAP server, and my source code is in CVS. These things are all very easy to find right now. I don't use Office, so I don't have that problem, but stuff I do in LaTeX is in CVS.
My web stuff is in AFS, and available through my web server. Much of that is in CVS (not enough, really), but at least I've got AFS doing nightly snapshots for me.:)
Cyrus rejected my zlib patches for their IMAP server because, ``disk is cheap.'' I've been using my zlib patch everywhere I use cyrus and it's saved me tons of disk space (it's been so long since I've done a conversion, I don't remember details, but I know it's more than 50% on average).
Cyrus is one of the better systems out there, IMO. Individual files take up a lot of inodes, sure, but the ``database'' files counter the performance lost to having to open all those files when you don't need them.
Before that, I concatenated gzip files in mbox format. Modifying anything that can read mbox to read gzip files can't be terribly hard, but I assure you, the benefit is huge.
Solaris'/proc is just like/proc has been on many systems. It's a filesystem designed to show you process information. Linux's/proc has always been an irritating thing for me. On Solaris, NetBSD, IRIX, etc... I can cd into/proc and see processes. That's all that's there, as one would expect by a filesystem named *procfs* and documented as ``process information pseudo-filesystem.''
NetBSD has kernfs which, while it doesn't have all of the info found in Linux's/proc it's *separate*.
For example, I often want to do something over a all processes in a Solaris machine (check for fd leaks or whatever). I do it by cding into/proc and doing ``for i in *'' usually. I suppose I could assume that anything that starts with a number is a PID or whatever, but I just don't believe it makes sense to mix all that crap together, and then claim that Linux's is ``better'' than all the rest because they put a lot of incompatible crap in it.
Slashdot Mirror
NeXTSTEP has awesome distributed object support that lives on in OS X. Distributed objects in objective C using the foundation framework (which I believe is implemented in gnustep as well) is incredibly simple, yet still plenty flexible. Whether you're talking across threads, processes, or the Internet, sending messages (i.e. making method calls) on distributed objects is almost indistinguishable from sending messages to other objects. In fact, a method was added to NSObject to tell you whether or not the object you're working with is being accessed as a distributed object.
Java RMI isn't too bad, but anyone who implements (or even works on) any type of distributed object system without doing distributed object work in the NeXT foundation kit is at a disadvantage, in my opinion.
It also sounds like "hard link" is the same as Unix "hard link" which are actually a big mistake in Unix design and are pretty useless. Also the documentation indicates that this exists only in NT 5.0 and later.
*shrug* I find that having multiple hard links to a file is extremely useful. I guess it depends on your application.
I also thought that it was pointless to create a native application using java, but then, out of necessity, that's exactly what my first OS X application ended up being.
:)
I have a web-based app that I wanted to create a non-web GUI for (involved various file uploads and stuff that could more easily be handled via a native GUI). The server supports XML-RPC, but at the time, I didn't have an XML-RPC framework I could use from Objective C. However, I did have a fully functional commandline app that did it that I'd written in java.
So, I just fired up project builder, told it I was writing a java cocoa app, and spent a while getting the UI the way I wanted it, then just plugged in a couple methods to the controller to call the existing code.
Because this was my first OS X application, it was a learning experience as far as picking up the cocoa concepts and stuff, but it only took a day of me being home sick (and I felt pretty crappy, so I wasn't working all that fast).
The time I spent learning cocoa concepts was not wasted at all. I figured out how to build frameworks and get them into my application, so I had the stuff I needed to go full objective C. I *copied* the UI I'd already made into a new project, and pasted a lot of the code straight from the java app to the objective C app (mostly controller stuff). Of course, I had to convert the java cocoa calls to objc, but for the most part, that was it.
Moral of the story: If you intend to write a native OS X app, and you don't have all the parts you need in objc, but you do have most of it in java, do it in java! It was a good proof-of-concept anyway.
Tell that to the voters of Florida who were prevented from submitting a vote that was counted.
The current system does not work as well as a system that could have problems introduced in CPU microcode. Software and hardware systems can be tested to keep people confident that, given a set of input will produce an expected set of output consistently. If the thing stays as simple as entering an ID and clicking a bunch of boxes, it's pretty easy to test all of the possible cases and run that test suite every single day (hour, etc...).
I live in Santa Clara and get my power from Silicon Valley Power. I don't think it's fair to say ``just like everbody else'' when everybody else was paying $400/mo electricity bills last year with very low load, I was paying closer to $50 with a data center in my garage.
I don't know as much about them as the parent of this thread, but they sure seemed to be doing something differently than the rest of the valley.
While I don't have enough comments to justify a properly structured reply, I would like to comment on two of them.
regarding video: BNC is *easy*. Slip it in, lock it, done. I've had plenty of VGA ports I couldn't get plugged in properly.
regarding internal drive power: I've had plenty of these that I couldn't unplug without a great deal of effort, and I had one just a couple of days ago fall apart when I was trying to unplug it.
doesn't make it cumbersome. You can't find the terminal? Bring up a finder window. Click on the applications button at the top. Find the Utilities folder (should be somewhere near the bottom, you can always resort the window). Now, find the terminal icon in this window. Drag the icon onto the dock. At this point, it'll always be there for you, one click away. Repeat for any other app you intend to use frequently. If you find that you aren't using one of these apps frequently, drag it off the dock and watch it go *poof*.
Of course, I run XDarwin in fullscreen mode, and xterms are a matter of me pressing ``x'' on the background. cmd-opt-a takes me back to Aqua where I have my web browser and whatever else I don't run under X.
If the screen's to small, get a bigger one, or another one (my powerbook will drive a second head at 2048x1536, although I haven't pulled out the 18" LCD since I bought it).
What you need to realize, though, is that your Linux box isn't as capable. My wife runs KDE on her iBook (under OS X). She also runs iMovie for simple NLE, and processes some of her video with quicktime (as do I, but I'm a twm guy, myself). While gphoto is somewhat nice, it's not iPhoto. I haven't used a lot of gui MP3 players, but iTunes will play mp3s that mpg123 will not, and it makes mastering CDs easy (although the shell scripts on my FreeBSD box were usually easy enough).
There have been a few problems, sure (OpenOffice spreadsheets won't let me add numeric values for whatever reason, so we're stuck with koffice in the meantime), but overall, it's been everything I've been getting out of other systems, plus tons of OS X and OS 9 software (stupid handspring doesn't support OS X yet, so I have to use OS 9 software, which works flawlessly).
mySQL is the right tool for *far* fewer jobs than those to which most people believe it applies. Many people end up writing code to deal with various aspects of data management that the database is supposed to take care of because they don't know that the database is supposed to take care of the data.
If you only know mySQL, you will attempt to solve your problem within the limitations of the tool. The problem is that many things can't be done in multithreaded or worse, multi-process application code to ensure integrity. If the DB won't do it, and it doesn't support transactions, then you've just gotta hope people don't ever use your application in a way that will make your data invalid.
I just don't get the appeal of mySQL. The last time I tried it, it seemed more difficult to use than postgres, and it supports a subset of the functionality. I have not done a project that doesn't require at least some basic database feature that mySQL doesn't have in years. Sure, I suppose I could've written code to emulate some of those parts of the database, but certainly not all. For the parts I could emulate, the application would most certainly run more slowly (multiple queries to emulate a subquery or what I do in a stored procedure), and the ones I couldn't would just have to be left out, which would make the applications more buggy (lack of transaction support on applications that run on multiple front-ends would simply cause the apps to fail).
Anyway, basic point is that if you don't understand your problem and/or the tools that are out there to help you solve it, you will solve it incorrectly. It may seem like it's working, but those types of implementations fail really quickly when they go multi-user.
Yeah, looks like he did it using PowerPoint, too. So?
Maybe the point is worth more than the medium here. Maybe by the time he's ready to do another one of these, you will have written him tools better suited to his message.
In the meantime, the message is valuable. If you don't like the format, use an open source converter to make it a format you like more. When you're done, listen to it, and learn from it.
I don't know, I'm more afraid of Britney Spears than Osama bin Laden at this point (speaking as a parent).
There's no reason to tie such things together. Primitives are a design flaw in the java language (not the VM). There is no reason to have a distinction between the primitive int and the Integer object. A reasonable compiler should be able to see how the variable is being used and do the right thing. See Eiffel. In Eiffel, everything is an object, yet performance is amazing.
Keep in mind that an interface is just an abstract class with the additional requirement that there can be no non-abstract methods in the interface. This is the point at which it becomes unreasonable. It leads to lots of implementations of the exact same functionality (imagine how many implementations of getString() in JDBC ResultSet classes do the exact same thing).
So, there are two needs for Interfaces. Java deals with one of them, while leaving code reusability kind of out to dry.
Operator overloading is certainly not a bad thing. Evidence of this is in the String + operator in java.
Read only access means that noone can swap your private key for another private key, or delete your keys, or
Dude, your secret is out! Now that They know about the switch, your secrets are no longer safe.
Perhaps if you are looking for perl programmers who will need to be doing a lot of textual processing, but that's definitely not the case in other areas.
I prefer to work with people who don't do a lot of regex, because they're less likely to use them for everything. I haven't worked on a large project that used regular expressions in years. I feel pretty good about that.
Sure, I've used them in a couple small scripts for parsing text, but if you see the majority of programming requiring regex, you definitely need to put your hammer down and pick up a Makita.
You forgot to mention that it also does what you're trying to accomplish as a side-effect of what you actually told it to do.
That's the thing that bothers me the most. The examples people are giving here are symptoms of the real problem. If you want to know if this piece of data you're looking at is a number, use a programming language that supports numbers and see if you can make a number out of it, then use the number.
Want to know if your input contains ``nasty characters?'' Wrong, you don't. You want to know if it's what you are expecting. At best, you want to know if it contains only characters you have authorized in a proper sequence that makes sense. You can sometimes do this with a regex, but not treating your data as strings in the first place gets rid of most of the desires to do textual processing on it. It makes your application development easier, more correct, and easier to read. It also makes it less likely to need to be modified down the road when you realize you overlooked unicode conversions, null characters, or other things that cause security holes.
Geez, what is it with people and complicating simple tasks with regex? How about:
/bin/?? /usr/bin/??
/bin/?? /usr/bin/??
/bin/l? /usr/bin/l?
ls
Which is roughly the equivalent of doing:
echo
if your shell has a built-in echo and you want to avoid forking of another process. That seems a lot more intuitive of a way to look for a command with two mystery characters. Or just one mystery character:
ls
etc...
tkp4 is a very good clone of the Windows p4 gui.
:)
http://web.cuug.ab.ca/~macdonal/tkp4/
I open it up now and then when I can't translate a concept from CVS in my head.
publicsource.apple.com
Don't expect it to ever work nearly as well as anything running on Apple hardware, though. One of the main reasons OS X works so well is that they're not trying to support every computer ever made.
I've got a stack that I wrote and have been using for a few years without a problem...well, until 0325 this morning when a battery in one of my thermometer servers caused the machine to fail. It does a lot of cool stuff, including some cool multicast action for plug-n-play data collection and stuff. You can see some good examples here:
. xtp
http://bleu.west.spy.net/~dustin/projects/ibutton
photoservlet.sf.net
I've got about 3600 images in mine and the advanced search can do the same types of things you're looking to do. Without an account, you won't see most of the pictures in my album, but you can get the idea.
Additionally, I did a search filter system last night that allows me to (for example) show me no more than one picture taken on any given month, selected randomly. Makes it useful to show progression.
My photos are in postgres via photoservlet, my mail is in my IMAP server, and my source code is in CVS. These things are all very easy to find right now. I don't use Office, so I don't have that problem, but stuff I do in LaTeX is in CVS.
:)
My web stuff is in AFS, and available through my web server. Much of that is in CVS (not enough, really), but at least I've got AFS doing nightly snapshots for me.
While there are similarities, note that cyrus also keeps a couple of files per folder to enhance the performance.
Cyrus rejected my zlib patches for their IMAP server because, ``disk is cheap.'' I've been using my zlib patch everywhere I use cyrus and it's saved me tons of disk space (it's been so long since I've done a conversion, I don't remember details, but I know it's more than 50% on average).
Cyrus is one of the better systems out there, IMO. Individual files take up a lot of inodes, sure, but the ``database'' files counter the performance lost to having to open all those files when you don't need them.
Before that, I concatenated gzip files in mbox format. Modifying anything that can read mbox to read gzip files can't be terribly hard, but I assure you, the benefit is huge.
Solaris' /proc is just like /proc has been on many systems. It's a filesystem designed to show you process information. Linux's /proc has always been an irritating thing for me. On Solaris, NetBSD, IRIX, etc... I can cd into /proc and see processes. That's all that's there, as one would expect by a filesystem named *procfs* and documented as ``process information pseudo-filesystem.''
/proc it's *separate*.
/proc and doing ``for i in *'' usually. I suppose I could assume that anything that starts with a number is a PID or whatever, but I just don't believe it makes sense to mix all that crap together, and then claim that Linux's is ``better'' than all the rest because they put a lot of incompatible crap in it.
NetBSD has kernfs which, while it doesn't have all of the info found in Linux's
For example, I often want to do something over a all processes in a Solaris machine (check for fd leaks or whatever). I do it by cding into
I create complex pdfs in LaTeX and I don't remember the file format changing as long as I've been using it.