Subject: new version now at Karlsruhe

From: Marcus Daniels <[email-masked]>
Date: Sat, 12 Aug 1995 22:49:51 GMT

12 August 1995
============

User visible changes
--------------------

* CLISP now supports the GNU gettext package.  Non-gettext internationalization
  support still available with "--disable-nls".  

* Self referencing symbolic links were not always avoided during 
  directory searches.  Thanks to Dan Stanger for pointing this out.

* Fixed a bug in XGCD which caused the results to be wrong with a small
  probability, for example in the case (XGCD 77874422 32223899).
  Thanks to Bruno Haible and Michael Stoll.

* Top level configure accepts absolute build directory.

* Top level configure now passes on --exec-prefix, --prefix, and --srcdir 
  to makemake.

Portability
-----------

* Runs on Solaris 2.4 with SUNWspro (3.0.1).  Thanks to Bruno Haible.

* Runs on Solaris 2.4/sun4m with GCC (2.6.3).

* Repair of memmove-related build problem on SunOS/Solaris.
  Thanks to Bruno Haible.

* Fixed a bug in mips/avcall.

* arimips.s now assembled with -KPIC to avoid problems during incremental
  linking of lisp.o.

At:
ma2s2.mathematik.uni-karlsruhe.de

In:
/pub/lisp/clisp/source
  clispsrc-newreadline.tar.z
  clispsrc-queens.tar.z
  clispsrc-readline.tar.z
  clispsrc-regexp.tar.z
  clispsrc-stdwin.tar.z
  clispsrc-wildcard.tar.z
  clispsrc.tar.z

Binaries (minimal distribution -- about 1.8 meg each).

and In:
/pub/lisp/clisp/binaries
  linux
  sun4-sunos4   (4m)
  sun4-sunos5.4 (4m)
  sgi-irix53
  
These files, and further work, will fade in and out of:

  http://sayre.sysc.pdx.edu:8001/clisp

---

From: Joachim Schrod <[email-masked]>
Date: Mon, 14 Aug 1995 20:29:34 +0200 (MESZ)

> 12 August 1995

Might this directory be renamed to linux-elf/ to make the contents
more clearer? Many Linux users haven't switched to ELF yet, as there
are no wide-spread ELF-based distributions.

>   http://sayre.sysc.pdx.edu:8001/clisp

Do you also have anonymous ftp access? Last week, I tried five times
to fetch it; the connection always broke down. ftp is better suited to
run it automated at night.

And I've got another wish: May anybody who has the most current
version running, please try

	clisp -i export-compile
	clisp -i export

on the following two files

---------------- export.lsp ----------------------------
(defpackage GI)

(export 'gi::name 'gi)

(defun gi:name ()
  (print "Some obscure function."))
---------------- export-compile.lsp --------------------
(defpackage GI)

(export 'gi::name 'gi)

(compile-file "export")

(quit)
---------------- snip snap -----------------------------

I've made an RS/6000 version of 1995-06-23 and would upload it to
Karlsruhe if the above error is still in the new revision... :-)

Concerning the above error: As you might imagine, this is not the real
code, but a very stripped down version of stuff that is usually buried
in some levels of macro definitions. (It's from an SGML style sheet
language where element definitions are transformed into class
definitions that are interned in a special package.)
    I think the code of export might need a special treatment for the
exported identifiers, it must not use their current symbol name.

Btw, does anybody know of a more elegant work-around than
    (export (intern "NAME" 'gi) 'gi)
?

Cheers,
	Joachim

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod			Email: [email-masked]
Computer Science Department
Technical University of Darmstadt, Germany

---

From: Marcus Daniels <[email-masked]>
Date: Mon, 14 Aug 1995 17:18:14 GMT

>>>>> "Joachim" == Joachim Schrod <[email-masked]> writes:

me> Binaries (minimal distribution -- about 1.8 meg each).
me> 
me> and In: /pub/lisp/clisp/binaries linux

Joachim> Might this directory be renamed to linux-elf/ to make the
Joachim> contents more clearer? Many Linux users haven't switched to
Joachim> ELF yet, as there are no wide-spread ELF-based distributions.

Good idea.  I've changed "linux" to "linux-elf".

me> These files, and further work, will fade in and out of:
me> 
me> http://sayre.sysc.pdx.edu:8001/clisp

Joachim> Do you also have anonymous ftp access? Last week, I tried
Joachim> five times to fetch it; the connection always broke down. ftp
Joachim> is better suited to run it automated at night.

Sorry, except for ma2s2, I do not have anon ftp.  Until I get a CVS
server setup, I can put stable-alpha code on ma2s2.

Joachim> And I've got another wish: May anybody who has the most
Joachim> current version running, please try

[deleted]

Joachim> I've made an RS/6000 version of 1995-06-23 and would upload
Joachim> it to Karlsruhe if the above error is still in the new
Joachim> revision... :-)

The problem is still in the new version.  I'm testing a fix now.

Either way, I'm sure there are people who would want "CLISP classic".
The RS/6000 binaries are very welcome.

---

From: Marcus Daniels <[email-masked]>
Date: Tue, 15 Aug 1995 02:26:40 GMT

>>>>> "Joachim" == Joachim Schrod <[email-masked]> writes:

Joachim> Btw, does anybody know of a more elegant work-around than
Joachim> (export (intern "NAME" 'gi) 'gi) ?

Hmm..  How about this?  

*** clisp-1995-08-12/src/io.d	Wed Aug  9 17:22:16 1995
--- clisp-1995-08-14/src/io.d	Mon Aug 14 15:13:48 1995
***************
*** 6033,6039 ****
                  { pushSTACK(home); # Home-Package retten
                    pr_symbol_part(stream_,ThePackage(home)->pack_name); # Packagenamen ausgeben
                    home = popSTACK(); # Home-Package zurück
!                   if (externalp(STACK_0,home)) # Symbol extern in seiner Home-Package?
                      goto one_marker; # ja -> 1 Packagemarker
                    write_schar(stream_,':'); # sonst 2 Packagemarker
                    one_marker:
--- 6033,6043 ----
                  { pushSTACK(home); # Home-Package retten
                    pr_symbol_part(stream_,ThePackage(home)->pack_name); # Packagenamen ausgeben
                    home = popSTACK(); # Home-Package zurück
!                   # Symbol extern in seiner Home-Package?
!                   # Print `::' when compiling, so as to avoid previous
!                   # runtime exports resulting in external symbol names 
!                   # in the .fas that aren't in fact external.
!                   if (externalp(STACK_0,home) && !test_value(S(compiling)))
                      goto one_marker; # ja -> 1 Packagemarker
                    write_schar(stream_,':'); # sonst 2 Packagemarker
                    one_marker:

---

From: [email-masked] (Bruno Haible)
Date: Wed, 16 Aug 95 21:06:17 +0200

>     (export (intern "NAME" 'gi) 'gi)

The DEFPACKAGE macro is meant to solve all those problems that arise
from putting single EXPORT etc. forms into source files. You have no
problem if you put the export clause into the DEFPACKAGE form.
The only ugliness is that you writes string containing the symbol names
in upper case.

---------------- export.lsp ----------------------------
(defpackage "GI" (:export "NAME"))
 
(defun gi:name ()
---------------- export-compile.lsp --------------------
(defpackage "GI" (:export "NAME"))
 
(compile-file "export")
 
(quit)
---------------- snip snap -----------------------------

      Bruno

---

From: Joachim Schrod <[email-masked]>
Date: Wed, 16 Aug 1995 22:08:21 +0200 (MESZ)

> The only ugliness is that you writes string containing the symbol names

As these forms are actually macro expansions, there is no ugliness as
long as it works. Well, one might argue that the whole macro where I
construct class definitions, method definitions, property lists,
etc., from one macro is butt-ugly, but that's another point. :-)

Thanks for this hint,

	Joachim

---

From: Marcus Daniels <[email-masked]>
Date: Wed, 16 Aug 1995 18:07:30 GMT

>>>>> "Joachim" == Joachim Schrod <[email-masked]> writes:

Joachim> As these forms are actually macro expansions, there is no
Joachim> ugliness as long as it works. Well, one might argue that the
Joachim> whole macro where I construct class definitions, method
Joachim> definitions, property lists, etc., from one macro is
Joachim> butt-ugly, but that's another point. :-)

Well, the earlier patch was a questionable tradeoff, not a fix.  I
should not put it in CLISP.  If you really need this capability, I can
put in an undocumented "compiler mode" variable, so that you won't be
forced to recompile CLISP just to make your program work.  I could see
how adapting your sources to DEFPACKAGE might not be feasible.

If anyone can think of a foolproof solution, please send me patches!

---

From: Joachim Schrod <[email-masked]>
Date: Wed, 16 Aug 1995 22:58:17 +0200 (MESZ)

Marcus wrote:
> 
> If you really need this capability, I can

You don't need to go into trouble for it. The DEFPACKAGE solution is
quite OK for me. Other Lisps might have problems with the EXPORT
construct as well, so I'll go for that (supposedly save) solution.

My system is structured enough to confine such constructs to a few
well-isolated places. I.e., it's easy to change. :-)

	Joachim