RE: [Axiom-developer] RE: [Gcl-devel] Re: axiom porting

[Mike Thomas]

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.