clisp-devel

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/

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

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: 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: 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...>]

> * 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

[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

[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

[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

[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

[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

[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

[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

[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: hg pull, hg update

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

> Looks like I managed mess up "hg up".

The distinction between "hg pull && hg update" and "hg pull --update" [1]
is something that I find very confusing in 'hg'. So, in order to never
use "hg pull" alone, I'm using this script in my $PATH:

================================== hg ==================================
#!/bin/sh
# "hg pull" without --update is always a mistake.
HG=/usr/bin/hg
if test $# = 1 -a "x$1" = xpull; then 
  exec ${HG} pull --update
else
  exec ${HG} "$@"
fi
========================================================================

Hope this helps.

Bruno

[1] https://stackoverflow.com/questions/15241394/mercurial-command-to-combine-hg-pull-hg-up

Re: hg pull, hg update

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

> * Bruno Haible <oe...@py...t> [2018-01-23 08:24:02 +0100]:
>
>> Looks like I managed mess up "hg up".
>
> The distinction between "hg pull && hg update" and "hg pull --update"
> is something that I find very confusing in 'hg'.

I use rebase: in ~/.hgrc:

--8<---------------cut here---------------start------------->8---
[extensions]
hgext.rebase =

[defaults]
pull = --rebase
--8<---------------cut here---------------end--------------->8---



-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1561
http://steingoldpsychology.com http://www.childpsy.net http://camera.org
https://ffii.org http://memri.org http://www.dhimmitude.org
History doesn't repeat itself, but historians do repeat each other.

Re: supporting older compilers

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

Hi Bruno,

> * Bruno Haible <oe...@py...t> [2018-01-22 18:44:51 +0100]:
>
> My g++ version is 5.4. And yours?

lispbibl mentions
"gcc-2.8.1 on hppa and egcs-1.0.3a on i386..."
"gcc-2.7.2 has a bug..."

What is the minimal compiler version CLISP supports?

thanks.
-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1561
http://steingoldpsychology.com http://www.childpsy.net
http://www.dhimmitude.org http://mideasttruth.com http://iris.org.il
XML is like violence. If it doesn't solve the problem, use more.

Re: supporting older compilers

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

Hi Sam,

> lispbibl mentions
> "gcc-2.8.1 on hppa and egcs-1.0.3a on i386..."
> "gcc-2.7.2 has a bug..."
> 
> What is the minimal compiler version CLISP supports?

Usually I'd say 2.95.2 is the theoretical minimum. There are still
a couple of machines around with only a gcc 3.3 or 3.4.6.

A few groups (Haiku, OS/2 porters) used to stick with old compilers for a
lnng time.
- On Haiku, gcc 2.95.3 is the default, but people can also use a gcc-5.4 port [1].
- On OS/2, there is a gcc 7.2 meanwhile. [2]

These mentions of old compilers in lispbibl.d don't really cost many
lines of code. But it seems safe to remove support for versions < 2.95.2.

Bruno

[1] https://lists.gnu.org/archive/html/bug-gnulib/2017-08/msg00177.html
[2] http://os2ports.smedley.id.au/index.php?page=copy-of-gcc-v6.x

Re: supporting older compilers

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

Hi Bruno,

> * Bruno Haible <oe...@py...t> [2018-01-23 22:43:58 +0100]:
>
> These mentions of old compilers in lispbibl.d don't really cost many
> lines of code.

The issue is a clear picture - what we are supporting (and why).

> But it seems safe to remove support for versions < 2.95.2.

Please do!

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1561
http://steingoldpsychology.com http://www.childpsy.net http://memri.org
http://iris.org.il https://jihadwatch.org http://camera.org
If I had a $ for every time I was rejected, I would no longer be rejected.

Re: Pari module build failure

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

Hi Jerry and Sam,

> > ;; 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 should be fixed now. Thanks a lot for the report!

Bruno

Re: Pari module build failure

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

On Tue, Jan 23, 2018 at 2:55 PM, Bruno Haible <br...@cl...> wrote:
> This should be fixed now. Thanks a lot for the report!

Excellent!  Thanks for the quick fix.  I don't have time tonight, but
will try to build again tomorrow and see how it goes.  Regards,
-- 
Jerry James
http://www.jamezone.org/

Re: Pari module build failure

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

On Tue, Jan 23, 2018 at 10:01 PM, Jerry James <log...@gm...> wrote:
> Excellent!  Thanks for the quick fix.  I don't have time tonight, but
> will try to build again tomorrow and see how it goes.  Regards,

Sorry for the delay.  The problem is indeed fixed.  Thanks again.  Regards,
-- 
Jerry James
http://www.jamezone.org/

Re: full-mod-check, socket tests

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

Hi Sam,

> >> 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.

This is a good move forward, because it will let us see bugs in the modules
more quickly.

However, the rawsock tests on Solaris 10 hang quite often (with more than 50%
probability, and both on sparc and x86). While test failures are acceptable,
a hang is a show-stopper because it blocks the
"make -f Makefile.devel multibuild-..." based testing.

I am therefore forced to disable the full-mod-check for the moment.
(I'm leaving in the --with-module=rawsock option in Makefile.devel, so that
we can at least check whether the rawsock module compiles correctly.)

Now, you can spend time fixing the rawsock module to at least not hang.
Then we can reenable step6 quickly.

Or you can spend time fixing the many test failures of the built-in sockets
which are seen on all non-Linux platforms (see attachment; similar failures
also on Mac OS X and AIX). I would consider this higher priority, because
the built-in sockets are the primary socket API in clisp.

Bruno

Re: full-mod-check, socket tests

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

Hi Bruno,

> * Bruno Haible <oe...@py...t> [2018-01-29 00:45:31 +0100]:
>
> Or you can spend time fixing the many test failures of the built-in
> sockets which are seen on all non-Linux platforms (see attachment;
> similar failures also on Mac OS X and AIX). I would consider this
> higher priority, because the built-in sockets are the primary socket
> API in clisp.

Could you please supply *features* for each socket.erg file?

Additionally, please run socket.tst with the base linkset which makes
symbolic errnos available - there should be no errors.

I wonder whether we should actually move socket.tst to modules/syscalls
to avoid the need to check for numeric errnos altogether.

Thanks.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1561
http://steingoldpsychology.com http://www.childpsy.net http://camera.org
http://jij.org http://no2bds.org https://jihadwatch.org http://memri.org
If you do not move, you will not feel the shackles.