Hi Camm.
EXCUSES 'Twas a long weekend here and I made full use of it for non-programming purposes. It looks from the CVS log and the Axiom/GCL 2.6.7 related email that there's a lot to catch up with. Random thoughts follow. 2.6.7PRE I just checked that 2.6.7pre builds on Windows. Will likewise test Maxima etc as the week progresses. What I need is some Lisp test code and simple instructions to check whatever network functionality you've added which you hope will work straight off under Windows. Please also tell me your time frame for getting 2.6.7 finalised and I'll try without promises to address GCL-TK within those limits. SIGNALS AND WINDOWS Are you implying (in some other email over the past few days) that SIGUSR1 is used in the handshaking between the TK server and GCL? I take it SIGUSR1 is a user definable signal? The signal question you raise there is a can of worms partly because I'm not au fait with their use, but also in the sense that although GCL already has a mechanism for attempting to emulate the receipt within GCL of fake signals passed by another process (or from withing GCL), that mechanism requires the other process (or GCL) to implement it's own special code to actually send the fake signal in the first place. That system (shared memory) is used by XMaxima to fake up SIGKILL. Once you have reached this stage you have to ask yourself whether it would have been better to just use a Windows mechanism in the first place. The other signals you mention are completely different in terms of the relevant Windows system functionality if such even exists (I'm thinking here of the profiling, memory fault handling and sigio). FORK() VS THREADS If you go too far in the emulation direction, you also then have to ask yourself whether you shouldn't be using Cygwin in the first place, particularly with respect to fork(). When last I heard (several years ago) Cygwin fork() had problems with sockets after the clone is done. (GRASS used this mechanism for it's display server on Unix and Cygwin and never really resolved the issues. My memory is that the MLton compiler gave up on Cygwin fork() just a few months ago.) Lets face it, forked socket servers are one of the main reasons people fork() in the first place. Furthermore, Cygwin fork() is not efficient in terms of either space or time. If you choose to use Cygwin you then close the circle and have an application which is problematic to distribute and support which means you might as well tell your users to use Linux (I admire Linux/*BSD/Cygwin and even X by the way, don't get me wrong). Ultimately, threads are the way to go in respect of this kind of functionality on Windows but of course, we have to find the time and know-how. GUI BACKENDS Time and know-how again whatever the path - I originally chose JAPI precisely because I could implement a GUI library in a couple of hours; hopefully GCL-TK can be salvaged on Windows in a similarly short time frame. Other compiler projects I am aware of farm library work (especially large open ended GUI library projects such as GTK, OpenGL, WXWidgets bindings) out to helpers. The GCL project is short staffed as it is, with you (Camm) the only seriously committed developer we have. Cheers Mike Thomas. _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer
