clisp-devel — closed list for developers and testers

Re: Trouble building 2.49.60 beta on Fedora - s390x

[Bruno H. <br...@cl...>]

Jerry James wrote:
> Is s390x unsupported for now?

I am testing a patch for s390x support. But my build machine is quite slow [1],
therefore this testing takes 24 hours.

Bruno

[1] http://git.savannah.gnu.org/gitweb/?p=libffcall.git;a=blob_plain;f=porting-tools/emulation/qemu-s390x.txt

Re: Trouble building 2.49.60 beta on Fedora - arm64

[Jerry J. <log...@gm...>]

On Sun, Aug 20, 2017 at 3:55 PM, Bruno Haible <br...@cl...> wrote:
>> For arm64 support, please use the attached patch.
>
> Oops, small mistake. Please use this one instead.

Again, thank you for the quick response.  I will try a build with
these patches in the next 24 hours and let you know how it goes.
Regards,
-- 
Jerry James
http://www.jamezone.org/

Re: Trouble building 2.49.60 beta on Fedora - powerpc64

[Jerry J. <log...@gm...>]

On Sun, Aug 20, 2017 at 4:02 PM, Bruno Haible <br...@cl...> wrote:
> For powerpc64 and powerpc64le, please use the attached patch.

Wonderful!  Thank you so much for the quick response.  Is s390x
unsupported for now?  If so, I can exclude it from making clisp
builds.

I will give this patch a try soon, probably tomorrow night.

Regards,
-- 
Jerry James
http://www.jamezone.org/

Re: Trouble building 2.49.60 beta on Fedora - gdbm

[Jerry J. <log...@gm...>]

Hi Bruno,

On Sat, Aug 19, 2017 at 11:22 PM, Bruno Haible <br...@cl...> wrote:
> Thanks for the report. I'll use this patch (in order to continue supporting
> gdbm 1.8.3).

That looks great, but I don't see anything accounting for the
UNKNOWN-UPDATE to UNKNOWN-ERROR name change.  I'm not sure which
version of gdbm made that change, but I can look into it if you need
me to do so.

Regards,
-- 
Jerry James
http://www.jamezone.org/

Re: Trouble building 2.49.60 beta on Fedora - powerpc64

[Bruno H. <br...@cl...>]

Jerry James wrote:
> the s390x, ppc64 and ppc64le builds all fail with this message:
> 
> ../src/lispbibl.d:2987:2: error: #error CLISP has not been ported to
> this platform - oint_type_len undefined
>  #error CLISP has not been ported to this platform - oint_type_len undefined

For powerpc64 and powerpc64le, please use the attached patch.

Bruno

Re: Trouble building 2.49.60 beta on Fedora - arm64

[Bruno H. <br...@cl...>]

> For arm64 support, please use the attached patch.

Oops, small mistake. Please use this one instead.

Bruno

Re: Trouble building 2.49.60 beta on Fedora - arm64

[Bruno H. <br...@cl...>]

Hi Jerry,

> Also, the aarch64 build fails like this:
> 
> ;; Compiling file /builddir/build/BUILD/clisp-2.49.60/modules/asdf/asdf.lisp ...
> *** - handle_fault error2 ! address = 0x2e0800084480 not in
> [0x2e0000000000,0x2e0000066778) !
> SIGSEGV cannot be cured. Fault address = 0x2e0800084480.
> GC count: 14
> Space collected by GC: 12036056
> Run time: 0 457240
> Real time: 0 476000
> GC time: 0 38463
> Permanently allocated: 165368 bytes.
> Currently in use: 4392320 bytes.
> Free space: 299880 bytes.
> make[1]: Leaving directory '/builddir/build/BUILD/clisp-2.49.60/build/asdf'
> make: Leaving directory '/builddir/build/BUILD/clisp-2.49.60/build'
> make[1]: *** [Makefile:22: asdf.fas] Segmentation fault (core dumped)
> make[1]: *** Deleting file 'asdf.fas'
> make: *** [Makefile:2334: asdf] Error 2
> 
> Do you have any idea what might cause that?

For arm64 support, please use the attached patch.

Bruno

Re: Trouble building 2.49.60 beta on Fedora - gdbm

[Bruno H. <br...@cl...>]

Hello Jerry,

Thanks for the detailed reports!

I'll reply for each of the issues separately.

> Finally, I needed the
> attached patch to build successfully with gdbm 1.13.

Thanks for the report. I'll use this patch (in order to continue supporting
gdbm 1.8.3).

Bruno


diff -r 5b5ef50761bd modules/gdbm/gdbm.c
--- a/modules/gdbm/gdbm.c	Sun Jun 25 11:46:27 2017 +0200
+++ b/modules/gdbm/gdbm.c	Sun Aug 20 07:08:22 2017 +0200
@@ -66,7 +66,7 @@
            READER-CANT-REORGANIZE UNKNOWN-UPDATE ITEM-NOT-FOUND              \
            REORGANIZE-FAILED CANNOT-REPLACE ILLEGAL-DATA OPT-ALREADY-SET     \
            OPT-ILLEGAL)
-static _Noreturn void error_gdbm (char *fatal_message) {
+static _Noreturn void error_gdbm (const char *fatal_message) {
   end_blocking_system_call(); /* in case we are called from _gdbm_fatal() */
   pushSTACK(`GDBM::GDBM-ERROR`);
   pushSTACK(`:MESSAGE`);
@@ -124,10 +124,16 @@
 
 static object open_gdbm (object path, int bsize, int rw, int mode) {
   GDBM_FILE gdbm;
+  /* gdbm versions < 1.9 had a broken prototype of gdbm_open() in gdbm.h. */
+  #if !defined(GDBM_OPENMASK) && defined(__cplusplus)
   with_string_0(path, GLO(pathname_encoding), name, {
-      SYSCALL(gdbm = gdbm_open(name, bsize, rw, mode,
-                               (void (*)(void))error_gdbm));
-    });
+    SYSCALL(gdbm = gdbm_open(name, bsize, rw, mode, (void (*) (void)) error_gdbm));
+  });
+  #else
+  with_string_0(path, GLO(pathname_encoding), name, {
+    SYSCALL(gdbm = gdbm_open(name, bsize, rw, mode, error_gdbm));
+  });
+  #endif
   if (gdbm == NULL) error_gdbm(NULL);
   return allocate_fpointer(gdbm);
 }

Trouble building 2.49.60 beta on Fedora

[Jerry J. <log...@gm...>]

Greetings,

I updated the Fedora ffcall package to the 1.13 release awhile ago.
Recently I attempted to update clisp to the 2.49.60 beta release as
well, but I'm having some trouble with it.  The x86 builds, both
32-bit and 64-bit, are fine, as is the 32-bit ARM build.  However, the
s390x, ppc64 and ppc64le builds all fail with this message:

../src/lispbibl.d:2987:2: error: #error CLISP has not been ported to
this platform - oint_type_len undefined
 #error CLISP has not been ported to this platform - oint_type_len undefined

Are additional configure flags of some kind needed when building for
those platforms?

Also, the aarch64 build fails like this:

;; Compiling file /builddir/build/BUILD/clisp-2.49.60/modules/asdf/asdf.lisp ...
*** - handle_fault error2 ! address = 0x2e0800084480 not in
[0x2e0000000000,0x2e0000066778) !
SIGSEGV cannot be cured. Fault address = 0x2e0800084480.
GC count: 14
Space collected by GC: 12036056
Run time: 0 457240
Real time: 0 476000
GC time: 0 38463
Permanently allocated: 165368 bytes.
Currently in use: 4392320 bytes.
Free space: 299880 bytes.
make[1]: Leaving directory '/builddir/build/BUILD/clisp-2.49.60/build/asdf'
make: Leaving directory '/builddir/build/BUILD/clisp-2.49.60/build'
make[1]: *** [Makefile:22: asdf.fas] Segmentation fault (core dumped)
make[1]: *** Deleting file 'asdf.fas'
make: *** [Makefile:2334: asdf] Error 2

Do you have any idea what might cause that?  Finally, I needed the
attached patch to build successfully with gdbm 1.13.

Regards,
-- 
Jerry James
http://www.jamezone.org/

Re: output from hg pull -u

[<don...@is...>]

Bruno Haible writes:
 > Don Cohen wrote:
 > > pulling from http://hg.code.sf.net/p/clisp/clisp
 > > searching for changes
 > > adding changesets
 > > adding manifests
 > > adding file changes
 > > added 1 changesets with 4 changes to 4 files
 > > abort: outstanding merge conflicts
 > 
 > Have you checked the various status commands?

No, I didn't even know about them.
However, when I now do
 $ hg pull -u
 pulling from http://hg.code.sf.net/p/clisp/clisp
 searching for changes
 no changes found
So I expect all is well and all these other commands won't
tell me anything more about what was wrong.

Re: output from hg pull -u

[Bruno H. <br...@cl...>]

Don Cohen wrote:
> pulling from http://hg.code.sf.net/p/clisp/clisp
> searching for changes
> adding changesets
> adding manifests
> adding file changes
> added 1 changesets with 4 changes to 4 files
> abort: outstanding merge conflicts

Have you checked the various status commands?

  $ hg status
  $ hg summary --remote

  $ hg out

  $ hg in

  $ hg branches

  $ hg heads

hg doesn't display this status at every command, but you need to be aware
of this context.

Or maybe someone has pushed a commit, edited it, and pushed again. If you were
unlucky enough to pull the intermediate commit, you need to drop it first:

  $ hg strip REVISION-(N-1)
  See https://www.mercurial-scm.org/wiki/StripExtension

Bruno

output from hg pull -u

[<don...@is...>]

pulling from http://hg.code.sf.net/p/clisp/clisp
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 4 changes to 4 files
abort: outstanding merge conflicts

I take the last line to mean that some action is required
by someone who can write the repository.

Re: clisp might crash later!

[Bruno H. <br...@cl...>]

Hi Jörg,

> Moreover, if we increase the RLIMIT_STACK, the initial heap-stack
> distance also increases and we still cannot reach the stack with the
> heap. However, if we set the RLIMIT_STACK to RLIM_INFINITY (4GB on i386)
> then the kernel switches from the default top-down mmap() layout to a
> legacy bottom-up mmap() layout, and:
> 
> - the initial heap-stack distance is approximately 2GB, because the
>   start of the heap (the initial brk()) is randomized above the address
>   0x40000000, and the end of the stack is randomized below the address
>   0xC0000000; [...]"

Thanks. This is relevant info!

> Does a given compiled CLISP binary accommodate both layouts?

Not yet. I'll make sure that it does.

Bruno

Re: clisp might crash later!

[<Joe...@t-...>]

Hi,

Bruno wrote:
>  - not defining SINGLEMAP_MEMORY on Linux,
>  - instead use TRIVIALMAP_MEMORY (otherwise we lose the generational GC) with a
>    range that is determined through some improved heuristics.

Did you read the recent LWN articles about stack clash? I learned there that the
memory map depends on the stack size: whether it's unlimited or not. How does
CLISP get along with that behavior (that depends on run-time environment only)?

https://lwn.net/Articles/725832/
https://lwn.net/Articles/726580/
https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt

"If we set the RLIMIT_STACK to 136MB (MIN_GAP, arch/x86/mm/mmap.c) then
the initial heap-stack distance is minimal (randomized in a [96MB,137MB]
range) [...]

Moreover, if we increase the RLIMIT_STACK, the initial heap-stack
distance also increases and we still cannot reach the stack with the
heap. However, if we set the RLIMIT_STACK to RLIM_INFINITY (4GB on i386)
then the kernel switches from the default top-down mmap() layout to a
legacy bottom-up mmap() layout, and:

- the initial heap-stack distance is approximately 2GB, because the
  start of the heap (the initial brk()) is randomized above the address
  0x40000000, and the end of the stack is randomized below the address
  0xC0000000; [...]"

Does a given compiled CLISP binary accommodate both layouts?

Regards,
	Jörg

Re: clisp might crash later!

[Bruno H. <br...@cl...>]

Hi Sam,

> What am I supposed to do when I see this:
> 
> Warning: reserving address range 0x2a0000000000...0x2affffffffff that contains memory mappings. clisp might crash later!
> Memory dump:

1. Report it here, for me to investigate. -> Thanks!
2. This seems to be a Linux kernel, which uses only a limited portion of the said
   address range. => No worry.
   Whereas on OpenBSD, the memory mappings are statistically distributed across
   the address range. In this case, NO_ADDRESS_SPACE_ASSUMPTIONS must be set
   (already done in lispbibl.d for OpenBSD).

When I'm back to clisp development (currently I'm preparing libffcall 2.0), I plan
to solve this issue by
  - not defining SINGLEMAP_MEMORY on Linux,
  - instead use TRIVIALMAP_MEMORY (otherwise we lose the generational GC) with a
    range that is determined through some improved heuristics.

Bruno

crash in mop.tst

[Bruno H. <br...@cl...>]

Sam wrote:
> PS. Do you think you might find time for
> https://sourceforge.net/p/clisp/bugs/703/ in the near future?

If you can reproduce it with build-porting64-gcc-portability, I'll
jump on it immediately.

If not, it will have to wait. My plan is to investigate the problems
introduced by the various optimizations (that are turned off in
--enable-portability builds) one by one:
  -DNO_ASM -DNO_ARI_ASM -DNO_SP_ASM
  -DNO_FAST_DISPATCH
  -DNO_FAST_FLOAT -DNO_FAST_DOUBLE
  -DNO_ALLOCA
  -DNO_ADDRESS_SPACE_ASSUMPTIONS
  -DNO_GENERATIONAL_GC
If the problem is not reproducible with these -DNO* options, an
important data point would be: what is the maximum set of such options
that makes the problem disappear?

Bruno

Re: Processing of Defining Macros

[Bruno H. <br...@cl...>]

Hi Sam,

> > I don't know how to modify the CLOS so that it considers two separate
> > worlds of classes: the compilation environment and the evaluation
> > environment.
> 
> You can have a "delenda" list during file compilation (bound in a
> compilation unit), add to it all the definitions created while compiling
> and then kill everything on the list at the end of the compilation unit.

This approach will not behave well in the (quite common) case that the
user
  1. creates a file foo.lisp that defines a class X.
  2. loads the file
  3. modifies the file foo.lisp with incompatible changes
  4. loads the file again, which fails due to mistakes in the file.
Then he will have lost the definition of class X in memory,
and the one in the file is non-functional. Not very desirable.

I think the only reasonable approach is to store class definitions of
the compilation environment in a different place than the class definitions
of the evaluation environment. But things get tricky because parts of the
classes are common, and you have methods such as CLASS-DIRECT-SUBCLASSES.

Bruno

Re: what is XCL?

[Bruno H. <br...@cl...>]

Hi Sam,

> CLISP test suite mentions XCL a lot.
> Moreover, it contains 3 files (readtable, tread, tprint) which are
> _only_ used with XCL.
> Comments seem to indicate that XCL might be a German implementation from
> the 1980-ies.

Yes, the clisp/tests/README gives credit to its authors.

Some of the bibliography at https://www.informatik.uni-kiel.de/~wg/New/MoreTechReports.html
is probably related.

It is not the same as http://www.cliki.net/XCL .

> Do we need it?

You can surely remove the #+XCL result cases.

Before removing the files readtable.tst tread.tst tprint.tst, I would first try
to adapt them to clisp and sbcl (unless the ansi-tests or sacla-tests already
contain comprehensive tests of these areas). Remember, the goal is to uncover
bugs.

Bruno

Re: Processing of Defining Macros

[Sam S. <sd...@gn...>]

Hi Bruno,

> * Bruno Haible <oe...@py...t> [2017-08-03 23:51:09 +0200]:
>
> I don't know how to modify the CLOS so that it considers two separate
> worlds of classes: the compilation environment and the evaluation
> environment.

You can have a "delenda" list during file compilation (bound in a
compilation unit), add to it all the definitions created while compiling
and then kill everything on the list at the end of the compilation unit.

Something like `rm(ls())` in R, see
<https://stackoverflow.com/a/14580551/850781>.

PS. Do you think you might find time for
https://sourceforge.net/p/clisp/bugs/703/ in the near future?

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net http://www.memritv.org
http://thereligionofpeace.com http://think-israel.org http://memri.org
It's not just a language, it's an adventure.  Common Lisp.

what is XCL?

[Sam S. <sd...@gn...>]

Hi Bruno,
CLISP test suite mentions XCL a lot.
Moreover, it contains 3 files (readtable, tread, tprint) which are
_only_ used with XCL.
Comments seem to indicate that XCL might be a German implementation from
the 1980-ies.

Could you please shed some light on this?
Do we need it?

Thanks.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net http://www.memritv.org
http://think-israel.org http://no2bds.org http://mideasttruth.com
Feynman: 'Philosophy of science is as useful to scientists as ornithology is to birds'

Re: clisp might crash later!

[Sam S. <sd...@gn...>]

... on gcc20 the map is somewhat different:


--8<---------------cut here---------------start------------->8---
Warning: reserving address range 0x2a0000000000...0x2affffffffff that contains memory mappings. clisp might crash later!
Memory dump:
  0x400000 - 0x8b5fff
  0xab5000 - 0xad9fff
  0xada000 - 0xb09fff
  0x1315000 - 0x1336fff
  0x2ac6be624000 - 0x2ac6be643fff
  0x2ac6be644000 - 0x2ac6be645fff
  0x2ac6be843000 - 0x2ac6be843fff
  0x2ac6be844000 - 0x2ac6be844fff
  0x2ac6be845000 - 0x2ac6be845fff
  0x2ac6be846000 - 0x2ac6be866fff
  0x2ac6be867000 - 0x2ac6bea65fff
  0x2ac6bea66000 - 0x2ac6bea66fff
  0x2ac6bea67000 - 0x2ac6bea67fff
  0x2ac6bea68000 - 0x2ac6bea8cfff
  0x2ac6bea8d000 - 0x2ac6bec8bfff
  0x2ac6bec8c000 - 0x2ac6bec8ffff
  0x2ac6bec90000 - 0x2ac6bec90fff
  0x2ac6bec91000 - 0x2ac6bec91fff
  0x2ac6bec92000 - 0x2ac6bec93fff
  0x2ac6bec94000 - 0x2ac6bee93fff
  0x2ac6bee94000 - 0x2ac6bee94fff
  0x2ac6bee95000 - 0x2ac6bee95fff
  0x2ac6bee96000 - 0x2ac6bef7dfff
  0x2ac6bef7e000 - 0x2ac6bf17dfff
  0x2ac6bf17e000 - 0x2ac6bf185fff
  0x2ac6bf186000 - 0x2ac6bf187fff
  0x2ac6bf188000 - 0x2ac6bf19cfff
  0x2ac6bf19d000 - 0x2ac6bf21dfff
  0x2ac6bf21e000 - 0x2ac6bf41cfff
  0x2ac6bf41d000 - 0x2ac6bf41dfff
  0x2ac6bf41e000 - 0x2ac6bf41efff
  0x2ac6bf41f000 - 0x2ac6bf41ffff
  0x2ac6bf420000 - 0x2ac6bf5a3fff
  0x2ac6bf5a4000 - 0x2ac6bf7a2fff
  0x2ac6bf7a3000 - 0x2ac6bf7a6fff
  0x2ac6bf7a7000 - 0x2ac6bf7a7fff
  0x2ac6bf7a8000 - 0x2ac6bf7acfff
  0x2ac6bf7ad000 - 0x2ac6bf7c1fff
  0x2ac6bf7c2000 - 0x2ac6bf9c1fff
  0x2ac6bf9c2000 - 0x2ac6bf9c2fff
  0x2ac6bf9c3000 - 0x2ac6bf9c6fff
  0x2ac6bf9c7000 - 0x2ac6c6393fff
  0x2ac6c6394000 - 0x2ac6c63b9fff
  0x2ac6c63ba000 - 0x2ac6c63c0fff
  0x2ac6c63c1000 - 0x2ac6c63c1fff
  0x2ac6c63c2000 - 0x2ac6c63c2fff
  0x2ac6c63c3000 - 0x2ac6c63c3fff
  0x2ac6c63c4000 - 0x2ac6c65c4fff
  0x2ac6c65c5000 - 0x2ac6c65c7fff
  0x2ac6c65c8000 - 0x2ac6c65c9fff
  0x2ac6c65ca000 - 0x2ac6c67c8fff
  0x2ac6c67c9000 - 0x2ac6c67c9fff
  0x2ac6c67ca000 - 0x2ac6c67cafff
  0x7fffbaac2000 - 0x7fffbaae3fff
  0x7fffbab72000 - 0x7fffbab72fff
  0xffffffffff600000 - 0xffffffffff600fff
STACK size: 262078 [0x300001ffe00 0x30000000010]
--8<---------------cut here---------------end--------------->8---



-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net http://www.memritv.org
http://americancensorship.org http://think-israel.org http://no2bds.org
Me, sarcastic?! Yeah, right...

Re: Processing of Defining Macros

[Bruno H. <br...@cl...>]

Hi Sam,

> http://clhs.lisp.se/Body/03_bcaa.htm:
> >> It is not specified whether definitions made available in the
> >> compilation environment are available in the evaluation environment, nor
> >> is it specified whether they are available in subsequent compilation
> >> units or subsequent invocations of the compiler.

This part of CLHS - the specification of side effects of COMPILE-FILE -
was probably the area where the standardization had the most positive
effect. Before this standardization, the instructions to compile a
given package depended a lot on the particular CL implementation.
Afterwards, package authors learned where to put EVAL-WHEN wrappers
around selected top-level forms.

The standards committee considered that separating the compile-time
environment from the evaluation environment was a good thing, but
left a considerable amount of leeway to the implementations, if they
wanted to not break existing code.

> Some macros form Figure 3-8 leak into the evaluation environment and
> some do not.
> 
> Specifically, declaim, defvar, defconstant, defparameter do NOT.
> defmacro, defclass, defstruct, defpackage DO.

Yes, this is how it behaves in clisp. Let's compare clisp with sbcl.
I compiled this file:
================== compile with compile-file ===================
(declaim (special foo1))
(defvar foo2 10)
(defconstant foo3 11)
(defparameter foo4 12)
(defmacro foo5 () '(list 73 55))
(defclass foo6 () ())
(defstruct foo7 ())
(defpackage foo8)
================================================================
Results:
  * Regarding DEFVAR, DEFPARAMETER: clisp and sbcl behave the same,
    no side effects on the evaluation environment.
  * Regarding DEFMACRO, DEFPACKAGE: clisp and sbcl behave the same,
    the definitions are made available in the evaluation environment.
  * Regarding DECLAIM, DEFCONSTANT: clisp provides better separation:
    no side effects in clisp, whereas definitions are available in the
    evaluation environment for sbcl.
  * Regarding DEFCLASS: sbcl provides better separation.
    The class definition is available in the evaluation environment for clisp.
  * Regarding DEFSTRUCT: sbcl provides slightly better separation.
    The class definition is available in the evaluation environment for clisp.
    In sbcl, the class definition is available, but the accessors are not,
    so that (find-class 'foo7) returns true but (make-instance 'foo7)
    nevertheless fails.

> This kinda makes sense - except for declaim which I think should be in
> the second list.

No. Ideally none of the defining macros should have an effect on the
evaluation environment. It makes no sense to make DECLAIM behave worse
in clisp, now that over 25 years so many packages have been made to work
with clisp.

Taking this argument the other way: It would be possible to make
DEFCLASS behave better in clisp, namely as good as sbcl does - now that
over 15 years so many packages have been made to work with sbcl.
It's "only" an implementation issue: I don't know how to modify the CLOS
so that it considers two separate worlds of classes: the compilation
environment and the evaluation environment.

> On the second thought, I think this is not quite right.
> Compiling a file should have an effect of loading its lib file.

No, ideally compiling a file would leave no traces at all in the
clisp process that ran the COMPILE-FILE.

> E.g., in a single session, using an example from
> http://clisp.org/impnotes/require.html,
> 
> (compile-file "foo")
> 
> will _not_ define variables defined in "foo", but
> 
> (compile-file "bar")
> 
> will load "foo.lib" (because of `(require "foo")` in "bar.lisp") and
> thus will define the variables.

Yes, but it should load "foo.lib" when stumbling across (require "foo")
in bar.lisp. It should not rely on the traces in memory, left by the previous
COMPILE-FILE command. That is the precise raison d'être for the .lib files.

I don't know how other implementations handle this issue when they produce
just one file as the result of COMPILE-FILE. I invented the .lib files
precisely so that
  (compile-file "bar")
could work
  - without requiring prior (compile-file "foo") nor (load "foo") in the same
    session,
  - without implicitly loading all the definitions of "foo" (thus leaving way
    too many side effects in the compilation environment).

Bruno

clisp might crash later!

[Sam S. <sd...@gn...>]

Bruno,

What am I supposed to do when I see this:

--8<---------------cut here---------------start------------->8---
Warning: reserving address range 0x2a0000000000...0x2affffffffff that contains memory mappings. clisp might crash later!
Memory dump:
  0x400000 - 0x8aefff
  0xaae000 - 0xacefff
  0xacf000 - 0xb20fff
  0x2aaaaaaab000 - 0x2aaaaaac8fff
  0x2aaaaaac9000 - 0x2aaaaaac9fff
  0x2aaaaaaca000 - 0x2aaaaaacbfff
  0x2aaaaaacc000 - 0x2aaaaac40fff
  0x2aaaaacc8000 - 0x2aaaaacc8fff
  0x2aaaaacc9000 - 0x2aaaaacc9fff
  0x2aaaaacca000 - 0x2aaaaaccafff
  0x2aaaaaccb000 - 0x2aaaaad0cfff
  0x2aaaaad0d000 - 0x2aaaaaf0bfff
  0x2aaaaaf0c000 - 0x2aaaaaf10fff
  0x2aaaaaf11000 - 0x2aaaaaf12fff
  0x2aaaaaf13000 - 0x2aaaab112fff
  0x2aaaab113000 - 0x2aaaab113fff
  0x2aaaab114000 - 0x2aaaab114fff
  0x2aaaab115000 - 0x2aaaab115fff
  0x2aaaab116000 - 0x2aaaab20bfff
  0x2aaaab20c000 - 0x2aaaab40bfff
  0x2aaaab40c000 - 0x2aaaab412fff
  0x2aaaab413000 - 0x2aaaab414fff
  0x2aaaab415000 - 0x2aaaab429fff
  0x2aaaab42a000 - 0x2aaaab4a9fff
  0x2aaaab4aa000 - 0x2aaaab6a9fff
  0x2aaaab6aa000 - 0x2aaaab6aafff
  0x2aaaab6ab000 - 0x2aaaab6abfff
  0x2aaaab6ac000 - 0x2aaaab804fff
  0x2aaaab805000 - 0x2aaaaba03fff
  0x2aaaaba04000 - 0x2aaaaba07fff
  0x2aaaaba08000 - 0x2aaaaba08fff
  0x2aaaaba09000 - 0x2aaaaba0efff
  0x2aaaaba0f000 - 0x2aaaaba24fff
  0x2aaaaba25000 - 0x2aaaabc23fff
  0x2aaaabc24000 - 0x2aaaabc24fff
  0x2aaaabc25000 - 0x2aaaabce8fff
  0x2aaaabce9000 - 0x2aaaabcedfff
  0x7ffffffe9000 - 0x7fffffffefff
  0xffffffffff600000 - 0xffffffffff600fff
STACK size: 98238 [0x300000bfe00 0x30000000010]
--8<---------------cut here---------------end--------------->8---

CLISP does not "crash later".
This is on gcc10 and gcc20 (https://cfarm.tetaneutral.net/machines/list/).

Thanks.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net https://ffii.org
http://honestreporting.com http://thereligionofpeace.com http://no2bds.org
XFM: Exit file manager? [Continue] [Cancel] [Abort]

Re: (format ... "~A" (apply #'format nil errorstring arguments))

[Bruno H. <br...@cl...>]

Hi Sam,

> In clos-method2.lisp and many other places you have this pattern:
> 
> --8<---------------cut here---------------start------------->8---
> (defmacro program-error-reporter (caller)
>   `#'(lambda (form detail errorstring &rest arguments)
>        (apply #'sys::lambda-list-error form detail
>               "~S: ~A" ,caller (apply #'format nil errorstring arguments))))
> --8<---------------cut here---------------end--------------->8---
> 
> Why not
> 
> --8<---------------cut here---------------start------------->8---
> (defmacro program-error-reporter (caller)
>   `#'(lambda (form detail errorstring &rest arguments)
>        (apply #'sys::lambda-list-error form detail
>               "~S: ~?" ,caller errorstring arguments)))
> --8<---------------cut here---------------end--------------->8---

Both are equivalent. I find the first one easier to understand,
because ~S, ~A, and APPLY are very familiar to everyone, whereas I wouldn't
remember how ~? works exactly - there are two cases - without looking up
CLHS 22.3.7.6.

The other possible explanation is that FORMATTER of ~? was not completely
implemented when I wrote clos-method2.lisp, and I dared to use ~? only after
it was efficient enough.

Bruno

(format ... "~A" (apply #'format nil errorstring arguments))

[Sam S. <sd...@gn...>]

Bruno,

In clos-method2.lisp and many other places you have this pattern:

--8<---------------cut here---------------start------------->8---
(defmacro program-error-reporter (caller)
  `#'(lambda (form detail errorstring &rest arguments)
       (apply #'sys::lambda-list-error form detail
              "~S: ~A" ,caller (apply #'format nil errorstring arguments))))
--8<---------------cut here---------------end--------------->8---

Why not

--8<---------------cut here---------------start------------->8---
(defmacro program-error-reporter (caller)
  `#'(lambda (form detail errorstring &rest arguments)
       (apply #'sys::lambda-list-error form detail
              "~S: ~?" ,caller errorstring arguments)))
--8<---------------cut here---------------end--------------->8---

The only place where the second pattern is used is invalid-method-error
and method-combination-error in close-methcomb2.

Thanks.

--
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net http://think-israel.org
http://no2bds.org http://jij.org http://honestreporting.com
You won't get smarter by calling me a fool.