Re: [Axiom-developer] (Possible) reasons Axiom didn't appeal to SoC coders...

[C Y]

--- Bill Page <address@hidden> wrote:

> If by "parent program" you mean "sman" and "session"? Since these are
> C programs there is no good reason not be able to compile them under
> either cygwin or MSYS/MinGW (native windows). The trick is to get the
> right support for sockets.  On the other hand, 'hyperdoc' and
> 'graphics' both require X-windows. This is something that (as far
> as I know) is only available under cygwin. 

There are X servers for Windows other than cygwin but I believe they
are all commercial - nor do I know if we could successfully work with
them.  The correct approach here is to work with some cross platform
toolkit and avoid the need for an X server, but that will take time
:-(.  Socket support on Windows should be possible - IIRC Maxima makes
use of this.

> > I see no fundamental reason why both process should not be threads
> > in the same problem and therefore bypass the socket stuff.  From my
> > perspective, that is just another over-engineering aspect of Axiom.

It helps in at least one respect - threads in lisp are not universal
between implementations and platforms, and if thread support is not
robust depending on it is a bit risky.  Sockets are at least universal
and flexible.  My understanding was GCL does not currently support
threads - has this changed?  What about on Windows and Linux?  How
about Solaris and MacOSX?  SBCL has threads on Linux and I think they
are either close or there on Windows (with what level of robustness I
don't know.)  CMUCL has threads on x86, but I'm not sure about other
platforms.  Other lisps I don't know - IIRC Clisp does not have
threads.  If we decide to go only with SBCL we might be able to use
threads only but sockets should work virtually anywhere.

Also, what about situations where (for example) someone wants to run
the Axiom kernel on a dedicated machine and the interface on another
machine?  Sockets are ideal for this sort of situation.

> > Notice that if you use sockets, the the anti-virus firewall will
> > consider Axiom as a program that wants access to network and it
> > might be blocked; then the anti-virus will ask you whether you
> > want to grant access or not.  That is silly. 

Yes, XMaxima and possible WxMaxima have that problem on Windows. 
Normally it is dealt with once and then works fine from there on.  I
agree it is annoying but I'm not convinced that issue in and of itself
it is sufficient reason to abandon sockets.  Or perhaps there is some
other inter-process communication mechanism we could take advantage of
that doesn't involve sockets and their firewall issues (does
Mathematica's MathLink have firewall problems?  I don't know.)
 
> That is correct however historically Axiom was designed at a time
> when there was not thread suppor under unix (or what ever Axiom was 
> built on at that time) and it was still considered "pretty neat" to 
> get this stuff working via sockets. So I would call it legacy rather 
> than over engineering. 

Thread support is still spotty between implementations and platforms. 
I would say use it if available, but don't depend on it as a do-or-die
feature.  Couldn't we do something like:

Start Axiom GUI ->  If threads, start new thread with kernel
                    If no threads, start new process with kernel

Cheers,
CY


 
____________________________________________________________________________________
Sucker-punch spam with award-winning protection. 
Try the free Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/features_spam.html