clisp-devel — closed list for developers and testers

Re: Pari module build failure

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

Hi Bruno,

> * Bruno Haible <oe...@py...t> [2018-01-22 23:48:36 +0100]:
>
>> 1. mark tip as bad: ...
>
> Thanks a lot for the recipe!

You are very welcome!

>> The first bad revision is:
>> changeset:   16442:a3806e5f96d1
>> user:        Bruno Haible <br...@cl...>
>> date:        Mon Jan 15 00:24:23 2018 +0100
>> summary:     Enable most optimizations on Mac OS X/x86_64.
>
> Oh really?! It looked like, from looking at the build-*/cbcstep3.log files,
> that these optimizations are safe.

Note that the error is not macosx-specific, it is observed at least on
linux too.

>> I will enable the modules tests in configure.
>
> Please enable only base-mod-check for the moment.

base-mod-check goes to step5 and full-mod-check to step6,
summarized at the end.

Thanks.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1561
http://steingoldpsychology.com http://www.childpsy.net
http://iris.org.il http://no2bds.org https://jihadwatch.org http://camera.org
The software said it requires Windows 3.1 or better, so I installed Linux.

Re: Pari module build failure

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

> * Bruno Haible <oe...@py...t> [2018-01-22 23:27:38 +0100]:
>
> Sam wrote:
>> >> >> debug_gcsafety builds work:
>> >> >>
>> >> >>   linux-x86_64       (*)
>
> Works for me on this machine as well:

"Oh, this is embarrassing" (Schwarzenegger to Stallone in Expendables).

Looks like I managed mess up "hg up".

Sorry.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1561
http://steingoldpsychology.com http://www.childpsy.net http://iris.org.il
http://americancensorship.org https://jihadwatch.org
The force of gravity doubles when acting on a body on a couch.

Re: Pari module build failure

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

Hi Sam,

> 1. mark tip as bad: ...

Thanks a lot for the recipe!

> 4. get this after 6 iterations:
> 
> The first bad revision is:
> changeset:   16442:a3806e5f96d1
> user:        Bruno Haible <br...@cl...>
> date:        Mon Jan 15 00:24:23 2018 +0100
> summary:     Enable most optimizations on Mac OS X/x86_64.

Oh really?! It looked like, from looking at the build-*/cbcstep3.log files,
that these optimizations are safe.

> Lesson learned: one cannot be really sure about an optimization without
> testing modules too.

Ack.

> I will enable the modules tests in configure.

Please enable only base-mod-check for the moment.

Reason: Distros will usually enable some more modules than the 4 BASE_MODULES.
But the other modules after often not up-to-date, and I wouldn't want that
the packagers of clisp think that clisp by itself does not pass its testsuite.

Or if you really want to enable full-mod-check, please do so in a different step
(cbcstep5.log), so that's easy to distinguish these test failures from those
in clisp proper.

Bruno

Re: Pari module build failure

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

Sam wrote:
> >> >> debug_gcsafety builds work:
> >> >>
> >> >>   linux-x86_64       (*)
> >> >
> >> > nope: boot builds, base fails:
> >> >
> >> > /home/sds/src/clisp/current/modules/regexp/regexi.c: In function
> >> > 'Values C_subr_regexp_regexp_exec()':
> >> > /home/sds/src/clisp/current/modules/regexp/regexi.c:120: error:
> >> > invalid conversion from 'char*' to 'const uintB*'
> >> 
> >> IOW, patch e28a1c6d0963 did not fix the problem.
> >
> > Works for me: I just did a "make -f Makefile.devel
> > build-porting64-gcc-debug_gcsafety", and it succeeded.
> > My g++ version is 5.4. And yours?
> 
> $ ssh gcc12 gcc --version
> gcc (Debian 4.3.2-1.1) 4.3.2

Works for me on this machine as well:

On gcc12.fsffrance.org, using a clisp HEAD from today,
"make -f Makefile.devel build-porting64-gcc-debug_gcsafety" produces
a build where cbcstep2.log succeeded.

Bruno

Re: Pari module build failure

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

> * Bruno Haible <oe...@py...t> [2018-01-22 18:52:45 +0100]:
>
> Sam Steingold wrote:
>> This is a relatively recent regression, "hg bisect" should be able to
>> pinpoint the commit that broke it.
>
> How do you use 'hg bisect' in practice? I've never used it. When a build
> takes betwen 15 min and 2 h, I'd like to be sure I use the right commands
> before starting a multi-hour build sequence.

1. mark tip as bad:

$ hg bisect -b

2. checkout an old version and test it

$ hg checkout 16250
$ cd build-g-nodynmod/ && make clean base && ./clisp -q -norc -x '(regexp:regexp-compile "abc")' && cd ..
...
#<FOREIGN-POINTER #x00007F8BBDE00000> ;; <--- success!!
$ hg bisect -g
Testing changeset 16394:f359be5a1874 (120 changesets remaining, ~6 tests)
138 files updated, 0 files merged, 5 files removed, 0 files unresolved

3. repeat this:

$ cd build-g-nodynmod/ && rm -rf syscalls && time make clean base && ./clisp -q -norc -x '(regexp:regexp-compile "abc")' && cd .. && hg bisect -g

and do

$ cd .. ; hg bisect -b

on failure  (*** - FINALIZE: #<ADDRESS #x0000000101EFC918> is not a function)

4. get this after 6 iterations:

The first bad revision is:
changeset:   16442:a3806e5f96d1
user:        Bruno Haible <br...@cl...>
date:        Mon Jan 15 00:24:23 2018 +0100
summary:     Enable most optimizations on Mac OS X/x86_64.


This could be automated more but it was not worth the effort.

Lesson learned: one cannot be really sure about an optimization without
testing modules too.
I will enable the modules tests in configure.

Thanks.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1561
http://steingoldpsychology.com http://www.childpsy.net https://jihadwatch.org
http://honestreporting.com http://www.dhimmitude.org http://think-israel.org
Time would have been the best Teacher, if it did not kill all its students.

Re: Pari module build failure

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

> * Bruno Haible <oe...@py...t> [2018-01-22 18:52:45 +0100]:
>
> Sam Steingold wrote:
>> This is a relatively recent regression, "hg bisect" should be able to
>> pinpoint the commit that broke it.
>
> How do you use 'hg bisect' in practice? I've never used it. When a build
> takes betwen 15 min and 2 h, I'd like to be sure I use the right commands
> before starting a multi-hour build sequence.

    > This command helps to find changesets which introduce problems.
    > To use, mark the earliest changeset you know exhibits the problem
    > as bad, then mark the latest changeset which is free from the
    > problem as good. Bisect will update your working directory to a
    > revision for testing. Once you have performed tests, mark the
    > working directory as bad or good and bisect will either update to
    > another candidate changeset or announce that it has found the bad
    > revision.

iow, you do "hg bisect -b tip" and "hg bisect -g ????" and then "hg
bisect" and "make base && ./clisp -q -norc -x '(regexp:regexp-compile
"abc")'".
it can be automated but probably not worth it.

>> > ;; Loading file /builddir/build/BUILD/clisp-2.49.60/build/pari/desc2lisp.fas ...
>> > *** - EXT:FINALIZE: #<address #x0000000000859E30> is not a function
>> > make[1]: *** [Makefile:35: pari.c] Error 1
>> >
>> > What does that mean?
>> 
>> This stems from
>> 
>> --8<---------------cut here---------------start------------->8---
>> > (regexp:regexp-compile "abc")
>> *** - FINALIZE: #<ADDRESS #x0000000107B75918> is not a function
>> --8<---------------cut here---------------end--------------->8---
>
> Maybe in this case you can compile clisp with "-ggdb -O0" and get a
> stack trace with gdb?

--8<---------------cut here---------------start------------->8---
[1]> (regexp:regexp-compile "abc")

Breakpoint 12, prepare_error (errortype=type_error, errorstring=0x653f14 "~S: ~S is not a function", start_driver_p=false) at ../src/error.d:379
379	  begin_error(); /* start error message */
(gdb) where
#0  prepare_error (errortype=type_error, errorstring=0x653f14 "~S: ~S is not a function", start_driver_p=false) at ../src/error.d:379
#1  0x000000000056e62b in check_value (errortype=type_error, errorstring=0x653f14 "~S: ~S is not a function") at ../src/error.d:427
#2  0x0000000000572df0 in check_function_replacement (obj={one_o = 9519792}) at ../src/error.d:1486
#3  0x000000000046d4a1 in check_function (obj={one_o = 9519792}) at ../src/lispbibl.d:17605
#4  0x000000000046d437 in coerce_function (obj={one_o = 9519792}) at ../src/eval.d:2370
#5  0x000000000053bc16 in C_finalize () at ../src/record.d:882
#6  0x0000000000479ba7 in funcall_subr (fun={one_o = 549755849448}, args_on_stack=2) at ../src/eval.d:5259
#7  0x0000000000478b47 in funcall (fun={one_o = 549755849448}, args_on_stack=2) at ../src/eval.d:4892
#8  0x00000000004254d4 in C_subr_regexp_regexp_compile () at /home/sds/src/clisp/current/modules/regexp/regexi.c:52
#9  0x0000000000472ba2 in eval_subr (fun={one_o = 549755876552}) at ../src/eval.d:3630
#10 0x000000000047067c in eval1 (form={one_o = 4398047665440}) at ../src/eval.d:3121
#11 0x0000000000470111 in eval (form={one_o = 4398047665440}) at ../src/eval.d:3003
#12 0x0000000000567d7c in C_read_eval_print () at ../src/debug.d:409
#13 0x0000000000479ba7 in funcall_subr (fun={one_o = 549755823296}, args_on_stack=2) at ../src/eval.d:5259
#14 0x0000000000478bd3 in funcall (fun={one_o = 2199023267312}, args_on_stack=2) at ../src/eval.d:4899
#15 0x000000000047ebfe in interpret_bytecode_ (closure={one_o = 4947802702208}, codeptr=0x9800003b248, byteptr=0x9800003b28f "\037(\a") at ../src/eval.d:6831
#16 0x000000000047ae3d in funcall_closure (closure={one_o = 4947802702208}, args_on_stack=0) at ../src/eval.d:5662
#17 0x0000000000478b76 in funcall (fun={one_o = 4947802702208}, args_on_stack=0) at ../src/eval.d:4894
#18 0x00000000004909bc in C_driver () at ../src/control.d:2008
#19 0x000000000047ede0 in interpret_bytecode_ (closure={one_o = 4947802608256}, codeptr=0x9800003b218, byteptr=0x9800003b245 "\031\003") at ../src/eval.d:6837
#20 0x000000000047ae3d in funcall_closure (closure={one_o = 4947802608256}, args_on_stack=0) at ../src/eval.d:5662
#21 0x0000000000478b76 in funcall (fun={one_o = 4947802608256}, args_on_stack=0) at ../src/eval.d:4894
#22 0x000000000047fb4a in interpret_bytecode_ (closure={one_o = 4947802678584}, codeptr=0x9800003bb38, byteptr=0x9800003bb84 "\031\001\230\016\033l") at ../src/eval.d:6886
#23 0x000000000047ae3d in funcall_closure (closure={one_o = 4947802678584}, args_on_stack=0) at ../src/eval.d:5662
#24 0x0000000000478b76 in funcall (fun={one_o = 4947802678584}, args_on_stack=0) at ../src/eval.d:4894
#25 0x000000000047fb4a in interpret_bytecode_ (closure={one_o = 4947802678768}, codeptr=0x9800003bb38, byteptr=0x9800003bb84 "\031\001\230\016\033l") at ../src/eval.d:6886
#26 0x000000000047ae3d in funcall_closure (closure={one_o = 4947802678768}, args_on_stack=0) at ../src/eval.d:5662
#27 0x0000000000478b76 in funcall (fun={one_o = 4947802678768}, args_on_stack=0) at ../src/eval.d:4894
#28 0x000000000047fb4a in interpret_bytecode_ (closure={one_o = 4947802702024}, codeptr=0x9800003bb38, byteptr=0x9800003bb84 "\031\001\230\016\033l") at ../src/eval.d:6886
#29 0x000000000047ae3d in funcall_closure (closure={one_o = 4947802702024}, args_on_stack=0) at ../src/eval.d:5662
#30 0x0000000000478b76 in funcall (fun={one_o = 4947802702024}, args_on_stack=0) at ../src/eval.d:4894
#31 0x0000000000568267 in driver () at ../src/debug.d:478
#32 0x000000000045e2a1 in main_actions (p=0x944520) at ../src/spvw.d:3938
#33 0x000000000045a53c in main (argc=11, argv=0x7fffffffe0b8) at ../src/spvw.d:4200
(gdb) 
(gdb) br C_finalize
[1]> (regexp:regexp-compile "abc")

Breakpoint 18, C_finalize () at ../src/record.d:882
882	  STACK_1 = coerce_function(STACK_1);
(gdb) xout STACK[-1]
#<UNBOUND>{one_o = 1924162125823}
(gdb) xout STACK[-2]
#<huh?! address=0x9142b0>{one_o = 9519792}
(gdb) xout STACK[-3]
#<FOREIGN-POINTER 0x963b90>{one_o = 6597069897576}
--8<---------------cut here---------------end--------------->8---

I think the problem is somehow with the ``...`` notation in modprep.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1561
http://steingoldpsychology.com http://www.childpsy.net http://honestreporting.com
http://think-israel.org http://americancensorship.org https://jihadwatch.org
A philosophical argument is won by the first to pull the trigger.

Re: Pari module build failure

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

Hi Bruno,

> * Bruno Haible <oe...@py...t> [2018-01-22 18:44:51 +0100]:
>
>> >> debug_gcsafety builds work:
>> >>
>> >>   linux-x86_64       (*)
>> >
>> > nope: boot builds, base fails:
>> >
>> > /home/sds/src/clisp/current/modules/regexp/regexi.c: In function
>> > 'Values C_subr_regexp_regexp_exec()':
>> > /home/sds/src/clisp/current/modules/regexp/regexi.c:120: error:
>> > invalid conversion from 'char*' to 'const uintB*'
>> 
>> IOW, patch e28a1c6d0963 did not fix the problem.
>
> Works for me: I just did a "make -f Makefile.devel
> build-porting64-gcc-debug_gcsafety", and it succeeded.
> My g++ version is 5.4. And yours?

$ ssh gcc12 gcc --version
gcc (Debian 4.3.2-1.1) 4.3.2



-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1561
http://steingoldpsychology.com http://www.childpsy.net http://jij.org
http://mideasttruth.com http://memri.org http://iris.org.il
In every non-trivial program there is at least one bug.

Re: Pari module build failure

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

Sam Steingold wrote:
> This is a relatively recent regression, "hg bisect" should be able to
> pinpoint the commit that broke it.

How do you use 'hg bisect' in practice? I've never used it. When a build
takes betwen 15 min and 2 h, I'd like to be sure I use the right commands
before starting a multi-hour build sequence.

> > ;; Loading file /builddir/build/BUILD/clisp-2.49.60/build/pari/desc2lisp.fas ...
> > *** - EXT:FINALIZE: #<address #x0000000000859E30> is not a function
> > make[1]: *** [Makefile:35: pari.c] Error 1
> >
> > What does that mean?
> 
> This stems from
> 
> --8<---------------cut here---------------start------------->8---
> > (regexp:regexp-compile "abc")
> *** - FINALIZE: #<ADDRESS #x0000000107B75918> is not a function
> --8<---------------cut here---------------end--------------->8---

Maybe in this case you can compile clisp with "-ggdb -O0" and get a
stack trace with gdb?

Bruno

Re: Pari module build failure

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

Hi Sam,

> >> debug_gcsafety builds work:
> >>
> >>   linux-x86_64       (*)
> >
> > nope: boot builds, base fails:
> >
> > /home/sds/src/clisp/current/modules/regexp/regexi.c: In function 'Values C_subr_regexp_regexp_exec()':
> > /home/sds/src/clisp/current/modules/regexp/regexi.c:120: error: invalid conversion from 'char*' to 'const uintB*'
> 
> IOW, patch e28a1c6d0963 did not fix the problem.

Works for me: I just did a "make -f Makefile.devel build-porting64-gcc-debug_gcsafety",
and it succeeded. My g++ version is 5.4. And yours?

Bruno

Re: Pari module build failure

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

> * Jerry James <ybtnawreel@tznvy.pbz> [2018-01-20 18:42:47 -0700]:
>
> Attempting a build of today's mercurial head (6c8234f1b27c) on an
> x86_64 machine running Fedora Rawhide, with pari 2.9.4:
>
> ;; Loading file /builddir/build/BUILD/clisp-2.49.60/build/pari/desc2lisp.fas ...
> *** - EXT:FINALIZE: #<address #x0000000000859E30> is not a function
> make[1]: *** [Makefile:35: pari.c] Error 1
>
> What does that mean?

This stems from

--8<---------------cut here---------------start------------->8---
> (regexp:regexp-compile "abc")
*** - FINALIZE: #<ADDRESS #x0000000107B75918> is not a function
--8<---------------cut here---------------end--------------->8---

This is a relatively recent regression, "hg bisect" should be able to
pinpoint the commit that broke it.

Could you please do it?

Thanks!

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1561
http://steingoldpsychology.com http://www.childpsy.net https://jihadwatch.org
http://www.memritv.org http://iris.org.il http://americancensorship.org
Any fool can squander everything once. Doing it more than once requires genius.

Re: Pari module build failure

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

> * Sam Steingold <fq...@ta...t> [2018-01-22 11:16:57 -0500]:
>
>> debug_gcsafety builds work:
>>
>>   linux-x86_64       (*)
>
> nope: boot builds, base fails:
>
> /home/sds/src/clisp/current/modules/regexp/regexi.c: In function 'Values C_subr_regexp_regexp_exec()':
> /home/sds/src/clisp/current/modules/regexp/regexi.c:120: error: invalid conversion from 'char*' to 'const uintB*'
> /home/sds/src/clisp/current/modules/regexp/regexi.c:120: error: invalid conversion from 'char*' to 'const uintB*'
> /home/sds/src/clisp/current/modules/regexp/regexi.c:120: error: invalid conversion from 'char*' to 'const uintB*'
> /home/sds/src/clisp/current/modules/regexp/regexi.c:120: error: invalid conversion from 'char*' to 'const uintB*'
> make[1]: *** [regexi.o] Error 1
> make[1]: Leaving directory `/home/sds/src/clisp/current/build-porting64-gcc-debug_gcsafety/regexp'
> make: *** [regexp] Error 2

IOW, patch e28a1c6d0963 did not fix the problem.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1561
http://steingoldpsychology.com http://www.childpsy.net http://no2bds.org
http://camera.org http://honestreporting.com http://mideasttruth.com
Why do we want intelligent terminals when there are so many stupid users?

Re: Pari module build failure

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

Hi Bruno,

> * Bruno Haible <oe...@py...t> [2018-01-22 16:27:53 +0100]:
>
>> gcsafety builds seem to be broken on all platforms available to me.
>
> The Makefile.devel now contains a list of platforms on which the
> debug_gcsafety builds work:
>
>   linux-x86_64       (*)

nope: boot builds, base fails:

--8<---------------cut here---------------start------------->8---
/home/sds/src/clisp/current/modules/regexp/regexi.c: In function 'Values C_subr_regexp_regexp_exec()':
/home/sds/src/clisp/current/modules/regexp/regexi.c:120: error: invalid conversion from 'char*' to 'const uintB*'
/home/sds/src/clisp/current/modules/regexp/regexi.c:120: error: invalid conversion from 'char*' to 'const uintB*'
/home/sds/src/clisp/current/modules/regexp/regexi.c:120: error: invalid conversion from 'char*' to 'const uintB*'
/home/sds/src/clisp/current/modules/regexp/regexi.c:120: error: invalid conversion from 'char*' to 'const uintB*'
make[1]: *** [regexi.o] Error 1
make[1]: Leaving directory `/home/sds/src/clisp/current/build-porting64-gcc-debug_gcsafety/regexp'
make: *** [regexp] Error 2
--8<---------------cut here---------------end--------------->8---

>   macosx-i386

nope: https://sourceforge.net/p/clisp/bugs/710/
boot builds, base fails.

Thanks.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1561
http://steingoldpsychology.com http://www.childpsy.net
http://www.dhimmitude.org https://ffii.org http://no2bds.org
20% of people do 80% of work; also 80% of people think they are in those 20%.

Re: [clisp:clisp] 2 new commits to clisp

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

Sam Steingold wrote:
> > * CLISP - an ANSI Common Lisp Mercurial repository <ab...@py...g> [2018-01-20 08:21:03 +0000]:
> >
> > ## Branch: default  
> >
> > syscalls: Make this module work with DYNAMIC_MODULES.
> >
> > By Bruno Haible on 01/20/2018 08:19
> > [**View
> > Changes**](https://sourceforge.net/p/clisp/clisp/ci/f7c179f9907ab70c389b0ff245fe4cd0f22b801d/)
> 
> Why?! What's the point?

As explained in <https://sourceforge.net/p/clisp/bugs/725/>, I got an error when
running 'clisp-link run' with a couple of modules.

> syscalls is a base module and is _always_ built statically and linked
> into the base link set.

I could also have used 'clisp-link run boot syscalls rawsock'.

And we should be able to move some modules from BASE_MODULES to MODULES
when we like.

> it should never be compiled dynamically.

No. The lesson learned should be:
  ** Never use $(CC) on a source file without $(CPPFLAGS). **
  ** Never use $(CC) without $(CFLAGS), even when linking. **

> also, are you sure that volatile is equivalent to -O0 for all compilers?

Yes. The effects of 'volatile' are not formally standardized, but for
decades, they have the informal meaning of "don't optimize these memory
accesses".

Bruno

Re: Pari module build failure

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

Hi Sam,

> gcsafety builds seem to be broken on all platforms available to me.

The Makefile.devel now contains a list of platforms on which the
debug_gcsafety builds work:

  linux-x86_64       (*)
  linux-x86_64-32
  linux-i386
  linux-arm64        (*)
  linux-ia64
  linux-mips-32      (*)
  linux-mips-n32     (*)
  linux-mips-64      (*)
  linux-powerpc64    (*)
  linux-powerpc64le  (*)
  linux-sparc64      (*)
  linux-arm          (*)
  linux-hppa
  linux-m68k
  linux-powerpc      (*)
  linux-s390
  linux-sparc        (*)
  hurd-i386
  freebsd-gnu-x86_64
  freebsd-arm64
  netbsd-x86_64
  netbsd-i386
  netbsd-sparc
  macosx-i386
  macosx-powerpc
  aix-powerpc-32-gcc (*)
  aix-powerpc-64-gcc (*)

Those marked with (*) are available on the GCC compilefarm.

Bruno

Re: [clisp:clisp] 2 new commits to clisp

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

> * CLISP - an ANSI Common Lisp Mercurial repository <ab...@py...g> [2018-01-20 08:21:03 +0000]:
>
> ## Branch: default  
>
> syscalls: Make this module work with DYNAMIC_MODULES.
>
> By Bruno Haible on 01/20/2018 08:19
> [**View
> Changes**](https://sourceforge.net/p/clisp/clisp/ci/f7c179f9907ab70c389b0ff245fe4cd0f22b801d/)

Why?! What's the point?

syscalls is a base module and is _always_ built statically and linked
into the base link set. it should never be compiled dynamically.

also, are you sure that volatile is equivalent to -O0 for all compilers?

thanks.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1561
http://steingoldpsychology.com http://www.childpsy.net http://memri.org
http://think-israel.org http://honestreporting.com
XFM: Exit file manager? [Continue] [Cancel] [Abort]

Re: Pari module build failure

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

> * Jerry James <ybtnawreel@tznvy.pbz> [2018-01-20 18:42:47 -0700]:
>
> Attempting a build of today's mercurial head (6c8234f1b27c) on an
> x86_64 machine running Fedora Rawhide, with pari 2.9.4:
>
> ;; Loading file /builddir/build/BUILD/clisp-2.49.60/build/pari/desc2lisp.fas ...
> *** - EXT:FINALIZE: #<address #x0000000000859E30> is not a function
> make[1]: *** [Makefile:35: pari.c] Error 1
>
> What does that mean?

I have seen this too, linux only.
I have no idea what this might possibly mean (the pari module does not
use finalize).
This might be a GC-safety bug leading to memory corruption, but I
gcsafety builds seem to be broken on all platforms available to me.

Bruno, can you say something?

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1561
http://steingoldpsychology.com http://www.childpsy.net http://memri.org
https://jihadwatch.org http://no2bds.org http://honestreporting.com
non-smoking section in a restaurant == non-peeing section in a swimming pool

Make check failure

[Blake M. <bl...@mc...>]

Hi,

make check passed a week ago but is failing now (64 bit LinuxMint 17.1):

[...]
Welcome to GNU CLISP 2.49.60+ (2017-06-25) <http://clisp.org/>

Copyright (c) Bruno Haible, Michael Stoll 1992-1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2018

Type :h and hit Enter for context help.

;; connecting to
"http://clisp.org/beta/impnotes/id-href.map"...connected...HTTP/1.1
301 Moved Permanently --> "
https://clisp.sourceforge.io/beta/impnotes/id-href.map"
;; connecting to "http://clisp.orghttps://
clisp.sourceforge.io/beta/impnotes/id-href.map"...
*** - PARSE-INTEGER: substring "" does not have integer syntax at position 0

Bye.
make: *** [check-doc] Error 1

Pari module build failure

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

Attempting a build of today's mercurial head (6c8234f1b27c) on an
x86_64 machine running Fedora Rawhide, with pari 2.9.4:

;; Loading file /builddir/build/BUILD/clisp-2.49.60/build/pari/desc2lisp.fas ...
*** - EXT:FINALIZE: #<address #x0000000000859E30> is not a function
make[1]: *** [Makefile:35: pari.c] Error 1

What does that mean?
-- 
Jerry James
http://www.jamezone.org/

New Spanish PO file for 'clisp' (version 2.49.60)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'clisp' has been submitted
by the Spanish team of translators.  The file is available at:

    http://translationproject.org/latest/clisp/es.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/clisp/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/clisp.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

nightly builds

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

Sam asked nightly builders to make check,extracheck,mod-check.
So every day you want me to see the following?

[tail of check output]

;; connecting to "http://clisp.org/beta/impnotes/id-href.map"...connected...HTTP/1.1 301 Moved Permanently --> "https://clisp.sourceforge.io/beta/impnotes/id-href.map"
;; connecting to "http://clisp.orghttps://clisp.sourceforge.io/beta/impnotes/id-href.map"...
*** - PARSE-INTEGER: substring "" does not have integer syntax at position 0

Bye.
Makefile:2247: recipe for target 'check-doc' failed
make: *** [check-doc] Error 1



[tail of extracheck output -- what's this supposed to tell me?]

STACK size: 98238 [0x180000bfe00 0x18000000010]
if ./image; then exit 1; fi
STACK size: 98238 [0x180000bfe00 0x18000000010]
*** - myerror
ls -l lisp.run lispinit.mem image image.mem
-rwxr-xr-x. 1 don don 9894688 Jan 15 04:22 image
-rw-r--r--. 1 don don 3357472 Jan 15 04:22 image.mem
-rw-r--r--. 1 don don 3361472 Jan 15 03:22 lispinit.mem
-rwxr-xr-x. 1 don don 6532392 Jan 15 03:21 lisp.run
rm -f image image.mem



[tail of mod-check output - want more detail or you already know 
about all of this?]

EQL-OK: 5
RUN-TEST: finished #P"/home/don/hg/clisp/modules/readline/test.tst" (0 errors out of 37 tests)
finished   4 files:             298 errors out of     632 tests
  1             i18n/test.tst:    0 errors out of      11 tests
  2         syscalls/test.tst:    3 errors out of     264 tests
  3           regexp/test.tst:  295 errors out of     320 tests
  4         readline/test.tst:    0 errors out of      37 tests
Bye.
Makefile:2403: recipe for target 'base-mod-check' failed
make: *** [base-mod-check] Error 1

Re: make check fails

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

Don Cohen wrote:
>   $  cat /home/don/hg/clisp/build-dir/tests/*.erg
>   Form: (HANDLER-CASE (LETF ((*CURRENT-LANGUAGE* 'FRENCH)) (LIST (STRING= "À bientôt!" (SYSTEM::TEXT "Bye.")) (STRING= *CURRENT-LANGUAGE* "FRANÇAIS"))) (ERROR (E) (PRINC-ERROR E) '(T T)))
>   CORRECT: (T T)
>   CLISP  : (NIL T)
>   Differ at position 0: T vs NIL
>   CORRECT: (T T)
>   CLISP  : (NIL T)

Fixed now. The cause was that the French translation has changed.

> Under make check, I think all of this I've reported before.

A reminder does not hurt :)

Bruno

Re: make check fails

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

Hi Sam,

> Darwin Kernel Version 17.3.0
> ./configure --with-debug --without-dynamic-modules build-g-nodynmod
> Form: (HANDLER-CASE (LET ((X 1)) (LOCALLY (DECLARE (SYSTEM::IMPLEMENTATION-DEPENDENT X)) X)) (WARNING (W) (PRINC-TO-STRING W)))

Indeed, I could reproduce this in GENERIC64C_HEAPCODES model and
KERNELVOID32_HEAPCODES model. It's fixed now.

Bruno

Re: (sxhash (make-instance 'ext:standard-stablehash)) => 3614431684

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

Sam wrote:

> --8<---------------cut here---------------start------------->8---
> > (sxhash (make-instance 'ext:standard-stablehash))
> 3614431684
> > (sxhash (make-instance 'ext:standard-stablehash))
> 3614431684
> > (sxhash (make-instance 'ext:structure-stablehash))
> 83368493
> > (sxhash (make-instance 'ext:structure-stablehash))
> 83368493
> --8<---------------cut here---------------end--------------->8---
> 
> However, it seems like it _could_ do better.

Done: Implemented.

Thanks for the suggestion (and to Pascal for the help in reading the standard).

Bruno

Re: (sxhash (make-instance 'ext:standard-stablehash)) => 3614431684

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

Hello Pascal,

> > Yes, it is conceivable that SXHASH looks into instances of
> > STANDARD-OBJECT or STRUCTURE-OBJECT, with a limited depth.
> 
> I don’t agree.

Indeed, it seems I misread the spec [1] today (and read it correctly
when I implemented SXHASH).

> Furthermore, it means that the SXHASH shouldn’t change when you mutate the slots of the object!

Indeed, that is implied by clause 3.

> IMO, SXHASH for object shall depend only on the identity of the object.

Yes, and by clause 2, applied to a cons such as
  (#<STANDARD-OBJECT #x000333F08090>)
, the value that we compute in sxhash_atom must also not depend on the address
of the STANDARD-OBJECT or STRUCTURE-OBJECT in memory.

But the function sxhash, used outside of hashcode_tree recursion, could
use the address of the object. Clause 2 does not apply to instances of
STANDARD-OBJECT or STRUCTURE-OBJECT.

Thanks for having corrected me!

Bruno

[1] http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/fun_sxhash.html

Re: (sxhash (make-instance 'ext:standard-stablehash)) => 3614431684

[Pascal B. <pj...@in...>]

> On 12 Jan 2018, at 21:29, Bruno Haible <br...@cl...> wrote:
> 
> Hi Sam,
> 
>> I understand that SXHASH is not guaranteed to be different for different
>> instances:
>> 
>> --8<---------------cut here---------------start------------->8---
>>> (sxhash (make-instance 'ext:standard-stablehash))
>> 3614431684
>>> (sxhash (make-instance 'ext:standard-stablehash))
>> 3614431684
>>> (sxhash (make-instance 'ext:structure-stablehash))
>> 83368493
>>> (sxhash (make-instance 'ext:structure-stablehash))
>> 83368493
>> --8<---------------cut here---------------end--------------->8---
>> 
>> However, it seems like it _could_ do better.
> 
> Yes, it is conceivable that SXHASH looks into instances of
> STANDARD-OBJECT or STRUCTURE-OBJECT, with a limited depth.

I don’t agree.

The specification says that:
(equal x y) implies (= (sxhash x) (sxhash y))
But equal for instances means eq.

That is, there is an expectation that SXHASH works only on the identity of the object, not on its slots.
Furthermore, it means that the SXHASH shouldn’t change when you mutate the slots of the object!

IMO, SXHASH for object shall depend only on the identity of the object.

(This would also be consistent with the hash function used in HASH-TABLEs.)

-- 
__Pascal J. Bourguignon__