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

[Camm Maguire]

Greetings!

"Mike Thomas" <address@hidden> writes:

> 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.
> 

No problem!  Life takes precedence!

> 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.
> 

Really just the little server code Bill is playing with.  Please let
me know if your results ever differ from his.  Should not break in
ANSI.  It would also be nice to confirm that the new :daemon keyword
to socket does nothing on Windows.  Lastly, perhaps try reading and
writing a client socket, i.e. with :host instead of :server set in
#'socket.

> 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.
> 

Thank you so much!  I think it looks like a good short term option on
axiom.  No extreme rush, but I was hoping this weekend.  An assessment
of the time requirements for gcl-tk and any technical obstacles also
most welcome.


> 
> 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?
> 

Yes.  Currently ifdefed out of gcltkaux for mingw -- the cause of the
errors I'm assuming.  Please note that you can set (debugging t) in
package 'tk and get lots of diagnostics.  Shelter's info page is
pretty good here.

> I take it SIGUSR1 is a user definable signal?

Yes.

> 
> 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).

OK I see it now.  Am a little confused how the receiving process gets
interrupted when another writes to shared memory  -- is this a windows
thing, or is there a periodic check on the shared mem contents
somewhere?  I think we need the former.

Thankfully, all our signal needs except for the maxima one you refer
to above are within GCL shipped programs, hence under our control. 

At some point, the 'windows mechanism' you refer to might be better,
but for now, and since we already have a template with SIGKILL, I
suggest we just extend it for SIGUSR1 in gcl-tk/tkMain.c and the
like.  Perhaps you might explain it to me if time permits.  The other
signals might be nice, but I don't know of any pressing need for them
on Windows, at least not that anyone has expressed.

> 
> 
> 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).

I'm hoping we don't have to go to cygwin, though the option might be
nice, only if someone else steps up to do the lion's share of work.
We're not that far away on mingw, I think, thanks to your outstanding
efforts.  Working mind share is the most valuable commodity here.  We
have three short term options

1) No socket multiutasking on windows, -- need to hear from axiom how
   onerous this would be

2) run-process the commands to an entirely separate AXIOMsys  (easiest
   and most serviceable, I'd think) Or even (system ...)

3) multiplex stin with select, which should be portable.

> 
> 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.
> 

Yep to both.  Maybe someone explains in detail reentrancy to me
someday, as I've never found the need for threads, with such a great
tool like fork.

> 
> 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.
> 

Agreed.  It would be great to farm out completely here, but there are
not enough users.  Thankfully it looks as though we have two working
options (presuming windows gcl-tk), so we can table the rest
indefinitely until more resources arise, if ever.

Take care,

> Cheers
> 
> Mike Thomas.
> 
> 
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah