Re: [Gcl-devel] Re: gcl_signal - PS

[Camm Maguire]

Greetings!

OK, Michael, I'd like to merge in your work during this next week.
I've printed out the patch, and it is quite long.  It would be
helpful, but is not essential, to have it broken out into logical
chunks.  

I anticipate that some modifications might be necessary or at least
desirable.   I intend to launch a discussion of a 2.7.0 roadmap soon
which should hopefully clarify these matters.  Much depends on where
we envisage gcl being used in the future.  But some of my initial
thoughts are:

1) We desperately need a well-defined modular approach to avoid a
   'kitchen sink' product.  There are some who want full ansi to get
   at the clocc libraries and write web applications, there are some
   who want a lean and very efficient core to support large and
   complex applications, there may even be some who want to use gcl as
   a scripting language.  compiled scripting might be a good slogan
   for lisp :-).  Of course our present memory footprint is much
   larger than either bash or perl.  So what this means is that we
   should separate additional functions into logical units of one file
   a piece, and decide when to load the module, or whether it should
   be autoloaded.

2) It is easy to write code quickly in lisp -- that is one if its
   strong points.  But it is also easy to write slow code in lisp.  We
   should let the user write all the inefficient code they want, but
   the core library functions of gcl proper should be as efficient as
   reasonably  possible.  We don't have to make a career out of this,
   but it is likely that some modifications will be desirable when
   importing code from elsewhere, e.g. ecl.  In short, two rules of
   thumb -- 1) avoid unnecessary allocations, 2) declare variables,
   especially fixnum, :dynamic-extent, and object.

3) This one I'm not sure about, but there are certain advantages to
   adding new functions in lisp as opposed to C.  At some distant
   point, we might even consider replacing some C functions with
   lisp.  It is essential in such a move to determine that the
   compiled lisp code is just as fast as the C code, and hopefully no
   larger.  The primary advantages are in lisp level debugging, which
   I hope to write about in a separate post.  I'm just raising the
   issue here so we think about it.

Take care,

Michael Koehne <address@hidden> writes:

> Moin Mike & Camm,
> 
> > The easiest way would just be to get it into CVS quickly.  
> 
>   but this might break windows systems - my idea - you could do a :
>     cvs update -r HEAD
>   copy this directory to a ../2nd-gcl/ place, download
>     www.copyleft.de/lisp/gcl-04180.patch
>     www.copyleft.de/lisp/configure-04181
>   and do a
>     patch -p0 < gcl-04180.patch
>   this patch should apply clean (i hope). Copy this directory to
>   a ../3rd-gcl/ place and do a normal :
>     autoconf ( to create a ./configure from configure.in
>              - please to Camm - delete ./configure - this file should be
>              in any tar or source distribution, but not in CVS
>   ./configure
>            - use the www.copyleft.de/lisp/configure-04181,
>              if you dont have autoconf - or do the autoconf step
>              on your BSD VIA system.
>              ftp upload gave : No PORT command issued first !-)
>               
>   make
>   make install
>   make -C ansi-tests/
> 
>   my questions:
>   - does the patch break the compiler under windows ?
>   - does a *si:pathname-resolve* include :device ?
>   - do pathnames like #p"c:/My Documents/Mike/foo.lisp" work ?
>   - does (truename  #p"c:/My Documents/Mike/foo.lisp") work ?
>     - truename changed, that it has to signal an error, if the
>       pathname does'nt exist - this will break the compiler, if
>       truename does'nt work under windows !
>   - does (directory #p"c:/My Documents/*/f*.l*") work ?
>   - does (user-homedir-pathname) work ? This MUST check for some
>     windows registry files, as its sometimes #P"C:/My Documents/",
>     but may be #P"C:/Eigene Dateien/" in our country !
>   - does the ansi tests show something around 1000 errors ?
>     - place the ansi-tests/test.out file on your server, so
>       I could compare the results.
>   last not least:
>   - take a look at http://www.copyleft.de/lisp/gcl-ansi-pathnames.html
>     Example sys-translations.lisp and provide something meaningfull
>     for windows. The map-windows-searchlist would be a bit more
>     complicatated, than just scanning for #\; instead of #\:, as it
>     also has to map #:\\ into #:/ also.
>   - copy this new sys-translations.lisp into you
>     local/lib/gcl-2.7.0/lsp/ directory, to check 
>       (load-logical-pathname-translations "sys")
>       (truename #p"path:your favourite.exe") 
> 
>   do a
>      diff -p ../2nd-gcl/dir/file.ext ./dir/file.ext >> gcl-mike.patch
>   for every file.ext, you needed to change, and report where the patch
>   broke. We might need to do this a 2nd cyle, with the next version of
>   the patch. Of course 04180 is just a snapshot (and not the best at
>   all, as pprint-dispatcher is only implemented half ;) and I'm sure
>   that I did not only buried some bugs, but also created a lot of new
>   features, who might have some bugs as followers. So here are 3 ssh
>   public keys, and I could use one of them, if you tell Camm that its
>   ok that I can really checkin the patch. Camm might also need an FAX
>   where I agree that my patch is under GNU LGPL - RMS wanted that ages ago
>   - and he is true with his paperwork, if I remind the chap*.texi files.
> 
> ssh-dss 
> AAAAB3NzaC1kc3MAAACBANAUZtVDn/2Hu3nKD6f2Wcn5G/tdLv/kiYwJDB/BFDjtAfogCbz4ryQ8912NjG38EaGStB9dZJ7hu1gWXgPS8py0kFfenO4firmNEwBen7brxzIpwWPXVMphzj+BFD0SQ5B4gyon0CUyPg816N+PT6I2tgBxNrz7tzIPL5S6iVqZAAAAFQCmHrwmlUXCvYN7pTUGBcKOEMqzBwAAAIA8070Y4bnjLlyuXk3DD/lSuBtMl9CS3xGDVV7EAgK3WP23YVxgR85JKnqee3wzZi8prROs0aKUOoaT3ByV8T1+FHv6UINfFhrRtgH4oXedAX220mf8K6LQNCpZ3CSwzaXDu0dSqmRqUtnqlf8sJsikVMdMCsXrZ+WVfsgfN3C8ZwAAAIEAz7rYZ0rR0VyGr3hfwy+fqNAlAgRrKnkx2gOp8lMkehTm5rN+ZXH16HYBGG4ZQpIKoE2ZqOgO6awIrevwTegFFwTPGYVDzJE/cuK2hBPniftEexJFE5k1WWpSl+CQYcAZ44Nafe/Rw/d/Hys6hQxFWuuUbV1qL1b9m8wvREsuji0=
>  address@hidden
> ssh-rsa 
> AAAAB3NzaC1yc2EAAAABIwAAAIEAnvP9ECe6fcSqHLDBnj4JkqSJGs7/Z9Xllb+iWDG3n1Ihv3TAkacykAh++8gHX2xei88Ca33cFbiUVb/YtLsFQIILhzKQLjvNSJ9nGqP5wa9bwXuIk4UvXIRSAuBYOrguvCD7RVya8ocBjZ5ZLkG7LuTENOo4w2HGeOTpKShlUCc=
>  address@hidden
> 1024 35 
> 135505064468468409205214231766343660356562980116161229013003700476136757947625776173297369162441179249432089542168963515532467920732938540197654909030552268555518006482346070429471503609756477165805403996442793895360701396552313793383100861702594808774473872421227847317155146096650158759179328632381753812747
>  address@hidden
> 
> Bye Michael
> -- 
>   mailto:address@hidden             UNA:+.? 'CED+2+:::Linux:2.4.22'UNZ+1'
>   http://www.xml-edifact.org/           CETERUM CENSEO WINDOWS ESSE DELENDAM
> 
> 
> 

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