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

[Bill Page]

Quoting Gabriel Dos Reis <address@hidden>:

> ... 
> C Y wrote:
> |
> | One question - as I understand it, AXIOMsys works on Windows but the
> | parent program axiom does not.  Would a HyperDoc for Windows also
> | require a new communications mechanism?  Doing this straight from lisp
> | (ala hunchentoot or something similar) would be my preference, but
> | again it's probably not simple. 

Currently AXIOMsys can only be built using gcl on windows. The only
available version of gcl for windows is built as a native windows application
using MSYS/MinGW. There is an experimental version of Axiom built
with SBCL for Windows by Gregory Vanuxem but as far as I know it
does not include socket support. For that matter, neither does the
gcl version of Axiom for windows. Axiom has it's own routines written
in C that provide the socket interface and so far this has not been
incorporated into the version of Axiom for Windows. 

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. 

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

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. 

Regards,
Bill Page.