On Sat, 23 Jul 2005 14:59:07 +0100, Marc-Antoine Parent wrote (in message <[EMAIL PROTECTED]>):
>> 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. >> > > On the 64 bit front: I am quite convinced that the coupling between > Oz and interface is largely loose enough to allow a 64bit Oz engine. > Certainly this is the case with the Tk interface, which on the Mac > does _not_ use X11, but a Tk-Aqua binding. The GTK interface uses a > X11-based Tk however. The dichotomy is annoying, but I think that X11 > should be avoided on the mac whenever possible, to avoid the > cognitive clash of a very different feel with the basic interface; I > just wish there were also a functional GTK-native port on the mac > (there were two projects, and both seem stalled.) > That was a lucky! - it often makes sense to use something fairly high level like tcl/tk since one can rely on others doing a native port. If oz had used a direct interface to GTK/X then we'd be pretty sad in Mac land right now. How much effort is involved in porting an X11 program to Cocoa/Aqua? I should look at the port of emacs. Since I used to hang around in emacs/X at one time (I coded my first stuff in X10.4!) > >> One of the problems/strengths with X though is that it is a low level >> graphics protocol that does not control look and feel - >> > ... > >> 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). >> > ... > >> 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. >> > > Won't happen... X11 is too low level, precisely. They are pushing > Aqua L&F, which requires the high level of graphic APIs provided by > the Quartz engine (Compositing etc.) X11 limitations make this quite > impossible. What could happen is that Apple could take over native > Aqua bindings for GTK through Cocoa. That would be just brilliant. > But a lot of libraries that use GTK often feel free to talk to the > underlying X11 API whenever convenient, and a GTK-Aqua binding would > not allow that. So it is not clear how many projects such a port > would really benefit. > That's a real problem - and very frustrating. The impedance mismatch between X and any of the APIs is probably too great to make any sense to provide an adaptation. There's no good answer to this. What's the story on windows - the win api seems to be low level engough to provide a reasonalbe X11 server. Still X11 is low level and it shows. > >> Altivec and G5 made some sense to me in the machine room but not >> mactel. >> > > No kidding. But incidentally, Altivec had zero impact on Oz > performance. So Intel is actually a gain there. And Opteron is great > for FP, but Oz is mostly pointer arithmetic, so Intel might not fare > too badly. Of course, we will all miss Altivec for Mathematica. > Yes indeed I am hoping to pick up a (cheap!) end of line dual g5 fully stocked with memory and disk with one of those nice cinema displays... so I can run Mathematica on one and oz on the other speaking to each other through shared memory 8-) 64 bit is a bit of a double edged sword in my case - compactness is as important as speed - I use 32 bit ints and floats in my representations and I need to fit millions of data in memory - moving to 64 bit naievely means a doubling of memory requirement with no real gain - unless i can pack cleverly into a 64 bit word and do multiple operations in one fetch - might work as a sort of narrow vector if I can figure it out. I was going to do this in altivec (and use the lapack) - but I'm really still working on the load and store parts and using mathematica for prototyping algorithms right now. la comes when I've done the hard work of figuring out an approach. Having said all that the raw performance of those opterons is fantastic - even mapping the segment was "faster in the fingers" and I had to up the problem size an order of magnitiude to get reasonable samples for benchmarking... on a 1.6 Ghz opteron I got a four times speedup compared with a 1G desktop - it's that 800Mhz memory bus that does the job. So 800 / 333 = 4 (nice numbers AMD!) One thing I noticed during my benchmark tests (inlined integer loads and stores - sequential access to memory) is that on my powerbook -fast -mcpu=G4 was not as good as -O3 (gcc 3.3). Didn't have time recently to get to the bottom of that but I only found out by accident. Just shows that for specialised work it's worth a bit of experimentation. > >> 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 know it is there, and used to pass the tests in the Oz config. > Can I ask what problems you ran into? I've attached a small test program which I used (the code is not mine and I didn't verify it on linux) when deciding what to do - I wanted to use posix since I will want to port to win32 (and possibly file mapped memory) - I didn't spend any time on finding out what was wrong with this - but I got a SysV IPC version up and running straight away so I went with it. I need to revisit this as I say - so if you can get any traction i'd be grateful - I did log a bug with Apple but haven't had a response. I may well have missed something. The program build and runs ok but I get an error attaching to the segment and thats the end of it really. I was more confident with sysV ipc which works fine - modulo tweaking some parameters at boot time: default maxsizes are a bit on the low side. It is likely to be a darwinism rather than OS/X if anything. > > Marc-Antoine > > Cheers, Simon
posixsm.c
Description: Binary data
_________________________________________________________________________________ mozart-users mailing list [email protected] http://www.mozart-oz.org/mailman/listinfo/mozart-users
