CY wrote: > --- Bill Page <[EMAIL PROTECTED]> wrote: > > > On May 21, 2007 10:55 PM Waldek Hebisch wrote: > > > ... > > > currently for clisp I need cl-fad library, which I consider > > > problematic. Namely, cl-fad does not work with gcl, so for > > > gcl we need separate code. > > > > In general Camm Maguire (the primary developer go GCL) has > > expressed strong interest in improving GCL's support for > > ANSI common Lisp. If solving the problems of cl-fad on GCL > > would further this goal, I expect that we could count on > > his help (time available of course not withstanding). > > I think we need to worry first about ANSI Lisp support and second about > continuing to work on GCL. GCL is targeting ANSI, so eventually it > should be a moot point anyway, and in the meantime I would suggest we > target the final platform rather than worry about working on > intermediate or outdated Lisp environments. >
1) I need GCL support for regression testing. 2) I hope that Aldor lesson should be clear: avoid waiting on third party, this may take long time. In GCL case we may count on goodwill of Camm, but still I do not think taht we should cut off our life support and hope that it will be restored on time. 3) ATM core of Axiom is written in a very small subset of Lisp, sitting in the intersection of Cltl and Ansi. We need conditionals for things going beyond Ansi or Ansi violations. Directly here GCL is just one more implementation. Indirectly, we can not use some Ansi features. IMHO _that_ can wait for Ansi GCL. Back to cl-fad: its use of packages is incompatible with Cltl. If IIRC Ansi GCL misses one or two odd functions. But beyond that we would have to add to cl-fad a bunch of conditionals to cover GCL case. That is, we would have to use forked version of cl-fad. > > > We need only few functions from cl-fad, to work around clisp > > > weirdness (clisp makes strong distinction between paths to > > > files and paths to directories and refuses to perform file > > > operations on directories). So my current plan is to eliminate > > > use of cl-fad and provide the needed functions directly. > > > > Using a "standard" common lisp package seems preferrable to me > > even if has more functionaly than is currently required. > > I would tend to agree. As we expand Axiom's capabilities we may find > ourselves needing more of the functionality of these libraries. > cl-fad really provides very little functionality: the only nifty feature is ability to recursively walk directory tree. > > > Related problem is performing operations on directories -- > > > to gain portability between Unix and Windows I tried to use > > > Lisp code. But each Lisp is doing them differently (and > > > apparently some operations sometimes are missing). So I got > > > a maze of conditionals over Lisp implementations. Looking at > > > resulting code I feel that it is better to call operationg > > > system utilities and have just use conditionals to choose > > > between Unix and Windows versions of file utilities. > > > > I hope you mean calling the operating system routines directly > > (e.g. SI:: in GCL) and not resorting to spawning a new process > > to run shell commands (e.g. as is done one in Axiom's OBEY). > I mean spawning processes. I know that Windows does not like this, but is it really that bad? As alternative I consider rolling our own C library -- it seems that _no_ Lisp implementation give direct access to system calls. <rant> People frequently wonder why Perl is more popular than Lisp. Already 15 years ago Perl allowed you to call the 'syscall' system call -- which means that if Perl missed some OS function (it supported a _lot_ of them out of the box) one could roll Perl code to work around the problem. </rant> > Waldek, could you release the conditionalized Lisp code in question > even if we decide not to use it? It would make an EXCELLENT argument > and case study for making some of these interfaces more uniform between > implementations. > > > > Concerning sockets, we need Unix domain sockets and select. > > > It seems that clisp provide both, but to get Unix domain > > > sockets one needs version including rawsock module, which > > > is not included in default clisp configuration. > > > > > > sbcl offers sb-bsd-sockets which seem to have basic > > > functions, but I do not see select. > > > > > > gcl documentation suggest that Unix domain sockets are > > > unsupported. Also, I see no traces of select. > > > > > > There is "portable" cl-sockets library but the manual says > > > it supports Allegro CL, sbcl and cmucl. The manual does not > > > say anything about Unix domain sockets or select. The manual > > > says that cl-sockets requires UFFI, so presumably cl-sockets > > > works on top of "portable" C library. > > Does http://common-lisp.net/project/usocket/ address this problem at > all? I don't expect any of these solutions will support GCL at this > time, but hopefully that will come. > I did not investigate deeply, but the web page does not mention Unix domain sockects or select... They clearly say that UDP is is not ready, and mention a lot of little details about things alredy done, so they probably even have no plans for Unix domain. > P.S. - Waldek, is there a trick to building with sbcl? I get > make[2]: *** No rule to make target `sbcl', needed by `do_it.sbcl'. > Stop. > Sorry if I'm missing something obvious. > configure --with-lisp=/full/path/to/sbcl Current SVN should not require this. There is good chance that sbcl from current SVN will bootstrap algebra, but I still have to commit many fixes. -- Waldek Hebisch [EMAIL PROTECTED] _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer
