Apple's ProjectBuilder as a Java IDE
on
Java IDEs?
·
· Score: 1
Anybody try this ?
At least Sun dbx support in Emacs is pretty code
on
Java IDEs?
·
· Score: 1
You don't have to resort to dbx commands to set breakpoints and the like. You can pull down a menu item while point is sitting at the desired breakpoint.
IDEs are better for saving state about all aspects of the project (especially debugging, window arrangement, and so on) but Emacs can be cajoled into doing all sorts of things for you.
Re:Java is not C, it can be more like Smalltalk.
on
Java IDEs?
·
· Score: 1
I agree that the debugger is the best tool for debugging. But "printfs" have their place too, in very specific situations. One approach is to keep them in the code permanently as log statements on sufficiently high "debug level" settings, just in case you've got the kind of error that passes through a bottlneck and is easily described with printfs.
Garbage collection helps but doesn't solve all the problems. For example, some code needs to behave well in the presence of exceptions even if it doesn't handle them. Take this Java example:
NuclearReactor aReactor = null;
boolean aNormalShutdown = false;
try {
aReactor = new WaterCooledReactor("seabrook");
aReactor.start();
aReactor.monitor();// hang around until it stops
aNormalShutdown = true;
}
finally {
if (null != aReactor) { aReactor.shutdown(aNormalShutdown); }
}
Yes, I could write a finalizer that shuts down the reactor but this is something I want to happen right away !
By the way, my number one problem with C++ error handling is the lack of a finally feature. If you want a block of code to be aware of exceptions while not actually trapping them, you have two choices:
Catch all exceptions, then rethrow. The problems with this approach is that any C++ value (including numbers and any kind of pointer) can be an exception, and even among C++ classes there is no guaranteed base exception class
Embody the action to be protected in an object; its constructor performs setup, while the destructor (which will always be executed as the stack unwinds) does the cleanup. This is actually a very nice design pattern, but a lot of people can't wrap their heads around it, and it's kind of verbose for one-off situations.
Once nice thing about Microsoft C++ is that machine-level exceptions (like bad memory accesses) can be turned into C++ exceptions and thus handled like any other library exceptions. Older versions of Sun C++ don't seem to be able to do this. What about GCC ?
... but only if your programming language is capable on enforcing them. Most OSS projects use C so programmers have to check pointers - at least in the debug builds of libraries.
Bingo ! Having exceptions in a language really forces the issue of error handling. It was kind of shock for me, somebody who does commercial software, to see how OSS software is done in plain old C. I have been pretty insulated from that, having used mostly C++, Java, and Common Lisp, all of which support and use exceptions. Returned status codes and null pointers are just too easy to ignore. The other problem with C (if not Basic or Perl) is that early returns that you might want to make in error situations become tricky because you might have to let go of things that that you allocated earlier in the function.
I am working on a project now that does involve wrapping an old C library, and every single use of the old API is wrapped in a macro that will throw an exception on a bad return.
unfortunately philips and sony also own the major record companies.
Philips sold Polygram to Universal/Vivendi/Seagrams about two years ago. It's probably one reason why Philips makes MP3-file compatible CD players and Sony doesn't.
There's also one that's less obvious: CIDR. It works very well but has the already-discussed problem that it's hard to your subnet number(s) if you change ISPs.
Yes, Apple did demo Mentat's IPV6 support in Open Transport for MacOS Classic a while ago, but never shipped it.
From what I understand, Darwin includes (or can include) the KAME networking code that it inherits from FreeBSD, but it is not turned on. Maybe for OS X.1 though...
Also, every SSH program I've used in windows takes in the whole password before sending it along.
But what if you're typing a password for su or sudo ? At that point you would be transmitting tinygrams since ssh doesn't know that what's being transmitted is a password.
There are two ways to store type information in a file that are like more sophisticated versions of file(1):
If the data is XML-formatted, you could
look for something like a DTD or schema reference.
In OLE-land, a DocFile is structured as a container of typed files, recursively. The type of the top-level container can be considered the type of the file. DocFiles themselves start (or end) with a distinctive signature.
You can still use Mac OS X in "the old Mac style" in terms of not paying attention to extensions, but it's sad to see the backwardness of the rest of the world finally taking its toll. Perhaps it is time for a standards group to come up with some minimal metadata interchange ideas and apply them to data transfer protocols. It's pretty obvious that MIME would be one of the building blocks.
And, on the broader subject of metadata,
I think that at least two of the native Lisp Machine file systems (one of which was written by RMS) allowed for user-defined metadata in the form of a property-list, so you could store any property on a file as long as the data that was PRINTed could be READ back in.
Joe Mac User makes an HTML document referencing a bunch of JPEG and Flash images. The JPEG and Flash files don't have extensions in their names. He sends his HTML directory to his Windows-loving friend.
Yes, this collection of files will break a non-Mac-based HTTP server because they send file types based on extensions in the name. But strictly speaking the way particular HTTP servers work is an implementation detail and not a requirement of how the web is supposed to work.
Mac Classic-based HTTP servers will translate from type codes (not extensions) to MIME types so when this bundle of files is served, any web browser on any platform will work with it, since it is not supposed to extract type information from URLs anyway.
Does anybody know if Apple's mod_hfs does the same thing for Apache ?
Re:I took one of the banners and made it 10x small
on
Stopping The 56K Hate
·
· Score: 1
This probably one thing is overlooked in the bandwidth discussion -- newer technology such as stylesheets and the PNG format can improve performance on modems. Even Macromedia Flash (or SVG) can give you nice graphics at sizes that are smaller than equivalent GIFs or JPEGs.
-- it's not really because of Windows the OS, but because Microsoft has been building on COM for about seven years, and lot of programmers have been writing COM components for that long. Any self-describing COM component that doesn't have to run in GUI context is a candidate for easy exposure as a SOAP component. And the new.NET features make writing components even easier -- IDL becomes less of an issue. (I've done COM work with C++ and Java, and found IDL to be a good way to rigorously define a component interface, but I can see why it's a pain too.)
Of course, having nice tools help, but tools are helpless if there is no consistent architecture underneath. The reason why Java is the best bet for an alternative to Microsoft's web services is that Sun bothered to define architectures like Java Beans. Same thing goes for Open Scripting Architecture and perhaps the AppKit stuff from Apple.
One of the strengths of open source is that people build what they can use, they don't waste their time trying to figure out what someone else might have a use for, maybe.
The open source movement has no interest in creating markets, they have an interest in creating software that allows people to do the stuff they want or need to do.
Interesting, which means this strength is also
a weakness. Since most open source effort indeed
concentrates on existing development needs and
reimplementation of commodity protocols and
Windows features, there is little brainpower
left for thinking about, designing, implementing, and refining new concepts.
A lot of readers here scoff at web services, and some ways it's nothing more than a more flexible version of RPC for the Internet. But companies that follow the closed source model expand what people think of as useful in software against such skeptics. The skeptics can say they don't need GUIs, component object models, rich data formats like styled text or video, and so on, but in the end the best concepts will win out and then finally the open source front might notice that they have yet another kind of facility to reimplement.
My personal view is that web services based on SOAP will indeed succeed where DCOM and CORBA versions of the "object web" have failed. You don't have to beleive that but I think the best argument is that we already have web services and that there is a lot of value in being in the group that codifes them -- that is, who define how they are described and accessed.
...well, it says it will be available for Mac and Linux soon. I interviewed with them a long time ago (when they were just starting out) and I was puzzled about the reliance of client-side code to do all the work (after all, the Web is very friendly to server-side solutions). Curl might be compelling and worth the cost of learning yet another language/runtime in certain situations, but I am somewhat disappointed that there is no mention of smart server-side solutions.
In particular, if you could develop a web site in a nice, unified, portable system like Curl, maybe you have have a development system or compiler that could intelligently divide the work on the client or server based on the static things like the nature of the pages, and perhaps dynamic things like the bandwidth of the connection or the load on the server. In contrast, Curl as currently specified is just a better client-side technology, and a heavyweight and nonstandard one at that.
I agree, not merging needed changes back into the real source, even if they are "just" for makefiles (!), is asking for big trouble. Most of the time, those kinds of changes can be effected through the configure scripts.
I guese the essencce of problem with gnucash is that wants some.so's with are are at least planned to be compatible with existing versions, so in theory, if they were all working, nothing would break. But if they really are not ready, they've got to be put in a place that's private to gnucash for the time being...
Is there any Unixoid solution to the problem of recompiling and reinstalling things from source when the correct version is already installed ? For example, the ports system on FreeBSD (which I think is basically pretty cool) can't seem to figure out that you've already a X library from XFree86 4.x is already installed, so it helpfully goes off and download (to build) XFree86 3.x because somebody didn't upgrade a port description. Why can't it look inside the library/executable or a database and check the implementation number against what it requires, and try to build a new version of a dependency only if it doesn't mean the requirements ? You can't just go by the file date !
Seem to me that you need a VERSIONINFO-like tag inside Unix modules (and perhaps static libraries, unless the library format can) so that unrelated facilities like the OS installer, package installers, and dependency-driven builders can all avoid stomping on the new versions of things.
Slashdot Mirror
Great ! I assume you used the Unix download...
Anybody try this ?
You don't have to resort to dbx commands to set breakpoints and the like. You can pull down a menu item while point is sitting at the desired breakpoint.
IDEs are better for saving state about all aspects of the project (especially debugging, window arrangement, and so on) but Emacs can be cajoled into doing all sorts of things for you.
I agree that the debugger is the best tool for debugging. But "printfs" have their place too, in very specific situations. One approach is to keep them in the code permanently as log statements on sufficiently high "debug level" settings, just in case you've got the kind of error that passes through a bottlneck and is easily described with printfs.
By the way, my number one problem with C++ error handling is the lack of a finally feature. If you want a block of code to be aware of exceptions while not actually trapping them, you have two choices:
Once nice thing about Microsoft C++ is that machine-level exceptions (like bad memory accesses) can be turned into C++ exceptions and thus handled like any other library exceptions. Older versions of Sun C++ don't seem to be able to do this. What about GCC ?
Bingo ! Having exceptions in a language really forces the issue of error handling. It was kind of shock for me, somebody who does commercial software, to see how OSS software is done in plain old C. I have been pretty insulated from that, having used mostly C++, Java, and Common Lisp, all of which support and use exceptions. Returned status codes and null pointers are just too easy to ignore. The other problem with C (if not Basic or Perl) is that early returns that you might want to make in error situations become tricky because you might have to let go of things that that you allocated earlier in the function.
I am working on a project now that does involve wrapping an old C library, and every single use of the old API is wrapped in a macro that will throw an exception on a bad return.
Philips sold Polygram to Universal/Vivendi/Seagrams about two years ago. It's probably one reason why Philips makes MP3-file compatible CD players and Sony doesn't.
Are there any software DVD-Audio players ?
There's also one that's less obvious: CIDR. It works very well but has the already-discussed problem that it's hard to your subnet number(s) if you change ISPs.
Yes, Apple did demo Mentat's IPV6 support in Open Transport for MacOS Classic a while ago, but never shipped it.
From what I understand, Darwin includes (or can include) the KAME networking code that it inherits from FreeBSD, but it is not turned on. Maybe for OS X.1 though...
-
If the data is XML-formatted, you could
look for something like a DTD or schema reference.
-
In OLE-land, a DocFile is structured as a container of typed files, recursively. The type of the top-level container can be considered the type of the file. DocFiles themselves start (or end) with a distinctive signature.
You can still use Mac OS X in "the old Mac style" in terms of not paying attention to extensions, but it's sad to see the backwardness of the rest of the world finally taking its toll. Perhaps it is time for a standards group to come up with some minimal metadata interchange ideas and apply them to data transfer protocols. It's pretty obvious that MIME would be one of the building blocks.And, on the broader subject of metadata, I think that at least two of the native Lisp Machine file systems (one of which was written by RMS) allowed for user-defined metadata in the form of a property-list, so you could store any property on a file as long as the data that was PRINTed could be READ back in.
Mac Classic-based HTTP servers will translate from type codes (not extensions) to MIME types so when this bundle of files is served, any web browser on any platform will work with it, since it is not supposed to extract type information from URLs anyway.
Does anybody know if Apple's mod_hfs does the same thing for Apache ?
This probably one thing is overlooked in the bandwidth discussion -- newer technology such as stylesheets and the PNG format can improve performance on modems. Even Macromedia Flash (or SVG) can give you nice graphics at sizes that are smaller than equivalent GIFs or JPEGs.
Of course, having nice tools help, but tools are helpless if there is no consistent architecture underneath. The reason why Java is the best bet for an alternative to Microsoft's web services is that Sun bothered to define architectures like Java Beans. Same thing goes for Open Scripting Architecture and perhaps the AppKit stuff from Apple.
A lot of readers here scoff at web services, and some ways it's nothing more than a more flexible version of RPC for the Internet. But companies that follow the closed source model expand what people think of as useful in software against such skeptics. The skeptics can say they don't need GUIs, component object models, rich data formats like styled text or video, and so on, but in the end the best concepts will win out and then finally the open source front might notice that they have yet another kind of facility to reimplement.
My personal view is that web services based on SOAP will indeed succeed where DCOM and CORBA versions of the "object web" have failed. You don't have to beleive that but I think the best argument is that we already have web services and that there is a lot of value in being in the group that codifes them -- that is, who define how they are described and accessed.
In particular, if you could develop a web site in a nice, unified, portable system like Curl, maybe you have have a development system or compiler that could intelligently divide the work on the client or server based on the static things like the nature of the pages, and perhaps dynamic things like the bandwidth of the connection or the load on the server. In contrast, Curl as currently specified is just a better client-side technology, and a heavyweight and nonstandard one at that.
And if you don't abuse an Apple laptop, they last even longer. My kid's pediatrics office is still using Duos and 1xx series Powerbooks.
anybody got a screen shot ?
I agree, not merging needed changes back into the real source, even if they are "just" for makefiles (!), is asking for big trouble. Most of the time, those kinds of changes can be effected through the configure scripts.
I guese the essencce of problem with gnucash is that wants some .so's with are are at least planned to be compatible with existing versions, so in theory, if they were all working, nothing would break. But if they really are not ready, they've got to be put in a place that's private to gnucash for the time being...
Seem to me that you need a VERSIONINFO-like tag inside Unix modules (and perhaps static libraries, unless the library format can) so that unrelated facilities like the OS installer, package installers, and dependency-driven builders can all avoid stomping on the new versions of things.