On Fri, 22 Jul 2005 18:06:01 +0100, [EMAIL PROTECTED] wrote (in message <[EMAIL PROTECTED]>):
> 2. As OS X transitions to 64-bitness, Apple advises developers of graphical > applications to consider various communication schemes for 32-bit based GUI > components and 64-bit engines, such as message passing using UNIX domain > sockets. Most (all?) of the demos use tcl/tk and I'm wondering about the > efficacy of using Mozart sockets to exchange data between mozart-based > computation engines and GUI modules written in Java or other languages. Any > thoughts on this? > Hmm I thought X11 was a wire protocol - perhaps Apple should consider adopting it. I seem to have no trouble using an X11 gui on a 32 bit workstation whilst the "client" happily chugs away in 64 bit land down in the cool room sending the odd packet or two to the X server now and then. As I recall most X servers support UDP, unix sockets and some of them shared memory as client/server transports. It's just a case of using X libraries to do one's graphics and then running the client code wherever - of course you'll need to running an X server somewhere - (this is possible even on OS/X) (see fink etc.) After all tcl/tk uses X - and what could be more portable than that? GTK+ is currently the way to go on widget sets and that's been done for Oz already. One of the problems/strengths with X though is that it is a low level graphics protocol that does not control look and feel - other than defining certain rectangular screen areas (which some might argue is not truly low level) - this means that the client is responsible for everything that appears in a window and the handling of window events. The client side libraries thus control the behaviour and appearance of the app. Window managers can control the decoration and behaviour of windows - but these are just X apps themselves. X is analogous to postscript/pdf it that it defines a language or protocol encapsulations that enable one to draw things (and deliver event messages). I don't notice Apple saying we should consider re-designing our read only (PDF) graphics - since they have adopted a well known protocol for that already. (This is how Mathematica does all graphics display) Maybe apple should consider putting their considerable graphics/UI expertise into an X server/wm and a GTK plug compatible widget set that really rocked. > > FYI: > http://developer.apple.com/macosx/64bit.html > Plus ca change... BTW I love my Mac - but since the mactel announcement I am looking at opteron as a workhorse - PPC is dead - I have scrapped all plans to develop high performance scientific apps for Altivec or PPC. Apple has no choice but to go with x86 but it is now firmly in the consumer products market. Why would I buy an Apple box that I cannot see (i.e. in a dark cold room) when I can run a highy pared and optimized gentoo linux kernel on a 4x Opteron to do the data crunching? Altivec and G5 made some sense to me in the machine room but not mactel. What we really need to leverage from Java land is the massive utility code base and consequent connectivity to every stack/api known to man. I work in C/C++ for all my critical code and do my integration at this level - sharing application data in a common bus (purpose built for the kind of data I work with) - based on shared memory (posix shm seems not to work on darwin as far as I can tell so currently SysV). I connect Oz, C apps, Mathematica (currently with Java and R in progress) and exchange data on a high speed large scale store(s) - I get the best of all possible worlds - gui in all of the above - constraints - linear algebra - graph therory - stats. All of the above come with terrific distributed computing capabilities (especially OZ) so we can farm out work. I'm in computational heaven - but the most fundamental base is GNU and gcc - without which none of the above would exist. Back to basics, thats my philospophy. Don't expect the IT industry to shine a light on the path (science and academia provides illumination and the motivations are entirely of a different kind) look to application; the technology is already available. Really. > Thanks, > Tony Cheers, Simon _________________________________________________________________________________ mozart-users mailing list [email protected] http://www.mozart-oz.org/mailman/listinfo/mozart-users
