Re: [Gcl-devel] *features*

[Michael Koehne]

Moin Camm & Paul,

> When I started work on GCL, I was very careful to only make steps I
> was sure would not break whatever was working at that point.  There is
> a lot of code out there with various #+, and gcl has a long history.

  a can of worms - my gecko also had his share from a box of crickets
  yesterday night - we like bugs, as long as we can snatch them.

> It is clear these items need cleaning up, including recasting as
> keywords.  I don't think it is a good idea to remove the kcl and akcl
> symbols, as I know a lot of code uses these, and we are, to my
> knowledge, fully backward compatible, which is a good thing, IMHO.  

  ECL droped claiming to be KCL in *features*. I did'nt drop the kcl and
  akcl symbols in my patch. I made them keywords - even if gcl is not
  "fully backward compatible".
  
  I just improved the workaround at pcl/makefile, to use a keyword and not
  an ordinary symbol. This workaround prevented PCL to use the kcl-patches,
  which would fail as GCL does'nt have a system::*akcl-version* variable.

  I had a long night hunting down the reason why -compile did'nt work
  in ./saved_clcs_gcl - Other messages like, ' Initializing pcl_pkg.o
  Error: Can't open file "pcl_pkg.data" ' had been even more missleading
  to me. It finaly turned out that a #+linux is no longer true on modern
  linux in gcl_cmpmain.

> All of this should wait for 2.7.x.

  of course - patch is against 2.7.0 cvs of tonight.

  I run the ansi-test suite on both the cvs and my patched version,
  and the showed the same number of violations. So I think I snatched
  all bugs I released, when opening the can of worms.

  I would like you to test Maxima and Axiom against this patch. So it
  might even apply to Debian's GCL 2.6.2 (because claiming to be BSD368
  on MC68020, if you are running Debian on Intel, just to justify its
  own make burden, sucks ;) before Sarge becomes burried.

> --without-tcl is a good idea, for 2.7.x of course :-).

> The way to handle the Debian package IMHO is to split the tkl.o module
> and the gcltksrv helper into a separate package which contains all the
> tcl/tk dependency.

  I think its unlikely to have GCL/CLC in Sarge ;( but I would like
  a more modular GCL after Sarge became stable. With unbundled gui's
  to apt-get on demand - so I think that a --without-tcl does'nt
  need a backport to gcl 2.6.2 ;)

> When this Debian package split is made, it will be about a two week
> pause before packages can be uploaded again, as it will require manual
> intervention by the archive maintainers.  So better get the final
> structure right at that point.

  I have the feeling, that Sarge will become stable real soon.

> > ps: I'll detect DEBIAN by the existance of /var/lib/dpkg/available.

  so far - linux distribution detection is not yet implemented.

> I think from the above that the only question of compilance here is
> that we're not using the explicit package prefix, e.g. lisp::.... But
> we might as well make them working keywords if we want to make a
> change like this anyway. 

  i saw many references to LISP::BSD386, mainly unexport statements.
  Making them keywords at least did'nt break any additional test in
  Paul's ansi test suite.

> Thanks for this.  Will chase this down in 2.7.x.  Please don't let me
> forget.

  patch attached ...

Bye Michael
-- 
  mailto:address@hidden             UNA:+.? 'CED+2+:::Linux:2.4.22'UNZ+1'
  http://www.xml-edifact.org/           CETERUM CENSEO WINDOWS ESSE DELENDAM

gcl-cvs-patch-features
Description: Text document