clisp-devel — closed list for developers and testers

Re: Build problem

[m_maass <m_...@we...>]

Dear all,

i have the same problem as Blake (12.3.2017),  with gcc and clang after
make check.

*** - handle_fault error2 ! address = 0xb00000050b9 not in
[0xb0000000000,0xb0000001098) !
SIGSEGV cannot be cured. Fault address = 0xb00000050b9.
GC count: 645
Space collected by GC: 942622064
Run time: 22 232000
Real time: 23 875937
GC time: 3 356000
Permanently allocated: 158648 bytes.
Currently in use: 6726592 bytes.
Free space: 1305988 bytes.
Makefile:25: die Regel für Ziel „tests“ scheiterte
make[1]: *** [tests] Speicherzugriffsfehler

Can someone give a hint?

Thanks

Re: readlink bug?

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

Hi Sam,

> basically, linklen == result, but linkbuf is incomplete, and, moreover,
> is terminated with a newline(!) and a NULL (against the spec).

So, we again need special-case code, like the one you removed on 2011-06-01
(commit 0c6f53e756e4) ?

Bruno

Re: readlink bug?

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

oops, C-c too fast.

basically, linklen == result, but linkbuf is incomplete, and, moreover,
is terminated with a newline(!) and a NULL (against the spec).

> * Sam Steingold <fq...@ta...t> [2017-03-14 20:12:45 -0400]:
>
> I observe the following behavior:
>
> $ ls -l /proc/1627/fd/
> total 0
> 0 lrwx------ 1 sds sds 64 Mar 14 19:34 0 -> /dev/pts/23
> 0 l-wx------ 1 sds sds 64 Mar 14 19:34 1 -> /home/sds/src/clisp/current/build-porting64-gcc-standard_heapcodes/z
> 0 l-wx------ 1 sds sds 64 Mar 14 19:34 2 -> /home/sds/src/clisp/current/build-porting64-gcc-standard_heapcodes/z
> 0 lr-x------ 1 sds sds 64 Mar 14 19:34 3 -> /home/sds/src/clisp/current/build-porting64-gcc-standard_heapcodes/lisp.run*
> 0 l-wx------ 1 sds sds 64 Mar 14 19:34 4 -> /home/sds/src/clisp/current/build-porting64-gcc-standard_heapcodes/z
> 0 l-wx------ 1 sds sds 64 Mar 14 19:34 5 -> /home/sds/src/clisp/current/build-porting64-gcc-standard_heapcodes/z
>
> after
>
> GC_SAFE_SYSTEM_CALL(result = readlink(namestring_asciz,linkbuf,linklen));
>
> (gdb) p linkbuf
> $5 = "/home/sds/src/clisp/current/build-porting64-gcc-standard_heapcod\n"
> (gdb) p namestring_asciz
> $6 = 0x7fffffff7ff0 "/proc/1627/fd/1"
> (gdb) p fs->fs_stat
> $7 = {st_dev = 4, st_ino = 5336534, st_nlink = 1, st_mode = 41152,
> st_uid = 1001, st_gid = 1001, __pad0 = 0, st_rdev = 0, st_size = 64,
> st_blksize = 1024, st_blocks = 0, st_atim = {tv_sec = 1489534480,
> tv_nsec = 542647557}, st_mtim = {tv_sec = 1489534480, tv_nsec =
> 542647557}, st_ctim = {tv_sec = 1489534480, tv_nsec = 542647557},
> __glibc_reserved = {0, 0, 0}}

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 16.10 (yakkety) X 11.0.11804000
http://www.childpsy.net/ http://iris.org.il http://jihadwatch.org
http://palestinefacts.org http://ffii.org http://memri.org
Sometimes "pain in the ass" and "headache" are synonyms.

readlink bug?

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

Hi Bruno,

I observe the following behavior:

--8<---------------cut here---------------start------------->8---
$ ls -l /proc/1627/fd/
total 0
0 lrwx------ 1 sds sds 64 Mar 14 19:34 0 -> /dev/pts/23
0 l-wx------ 1 sds sds 64 Mar 14 19:34 1 -> /home/sds/src/clisp/current/build-porting64-gcc-standard_heapcodes/z
0 l-wx------ 1 sds sds 64 Mar 14 19:34 2 -> /home/sds/src/clisp/current/build-porting64-gcc-standard_heapcodes/z
0 lr-x------ 1 sds sds 64 Mar 14 19:34 3 -> /home/sds/src/clisp/current/build-porting64-gcc-standard_heapcodes/lisp.run*
0 l-wx------ 1 sds sds 64 Mar 14 19:34 4 -> /home/sds/src/clisp/current/build-porting64-gcc-standard_heapcodes/z
0 l-wx------ 1 sds sds 64 Mar 14 19:34 5 -> /home/sds/src/clisp/current/build-porting64-gcc-standard_heapcodes/z
--8<---------------cut here---------------end--------------->8---

after

GC_SAFE_SYSTEM_CALL(result = readlink(namestring_asciz,linkbuf,linklen));

(gdb) p linkbuf
$5 = "/home/sds/src/clisp/current/build-porting64-gcc-standard_heapcod\n"
(gdb) p namestring_asciz
$6 = 0x7fffffff7ff0 "/proc/1627/fd/1"
(gdb) p fs->fs_stat
$7 = {st_dev = 4, st_ino = 5336534, st_nlink = 1, st_mode = 41152, st_uid = 1001, st_gid = 1001, __pad0 = 0, st_rdev = 0, st_size = 64, st_blksize = 1024, st_blocks = 0, st_atim = {tv_sec = 1489534480, tv_nsec = 542647557}, st_mtim = {tv_sec = 1489534480, tv_nsec = 542647557}, st_ctim = {tv_sec = 1489534480, tv_nsec = 542647557}, __glibc_reserved = {0, 0, 0}}



-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 16.10 (yakkety) X 11.0.11804000
http://www.childpsy.net/ http://jihadwatch.org http://truepeace.org
http://honestreporting.com http://dhimmi.org http://mideasttruth.com
No snowflake in an avalanche is responsible for anything.

Re: shrink-wrapped distribution

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

Hi Jörg,

> Maybe we could differentiate user expectations by target platform?
> - MS-Windows: single file mostly welcome (think "portable executable (PE)"). 
> Self-extracting and executing archives are common.

OTOH, nowadays the "File Explorer" can unzip .zip files right away, I think.
Right?

> - trad. UNIX: ... 
> (I remember other tricks, like a file beginning as a tiny shell script,
>  then exit, followed by binary stuff).

A shell script is also what GNU 'shar' produces.

In KDE, when you click on a .zip file in dolphin, it opens 'ark', which
allows the user to extract the zip into a target directory, without any use
of command-line.

But when I click on a .sh file in dolphin, it opens it in an editor by default.
It also offers the option to execute it in a terminal emulator, but this does
not work (and avoiding the command-line was one of the purposes of the exercise).

> - MacOSX: People are used to foo.app for GUI apps.
> Some know that they can invoke apps on the CLI via e.g. /Applications/VLC.app/Contents/MacOS/VLC
> I have no idea whether a CLISP.app structure would make sense for a program that
> only lives on the command line

Can you find out?

Bruno

Re: make check-exec-image failure

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

Hi Sam,

> > Our time is better invested in working on '(make-distribution)'
> > than on '(saveinitmem :executable t)'.
> 
> Yep, I imagine a bunch of make-distrib-<platform>.lisp files,
> and something like this in init.lisp:
> 
> #+win32 (load "make-distrib-win32")
> #+macos (load "make-distrib-macos")
> ...
> #-(or win32 macos ...)
> (defun make-distrib (name)
>   (saveinitmem name :executable t))
> 
> 
> :-)

Yes, this is fine with me. If you have a feature that works reliably on some
platforms, you can use it on these platforms, and find other ways to achieve
the same high-level goal on the other platforms.

Bruno

Re: make check-exec-image failure

[Karsten P. <Kar...@gm...>]

On 13.03.17 01:12, Bruno Haible wrote:
> But what I need is that "make check" does not abort prematurely, because
> a "make check" failure means - to everyone - "the package is broken, you
> should better not proceed with 'make install'".

While the issue with check-exec-image is being discussed (and the 
discussion is outside of my skillset) can't you do something like the 
following in src/makemake.in

   # don’t run check-exec-image on Darwin
   # CHECK_DEPS="check-recompile check-fresh-line check-script 
check-exec-image check-tests"
   case "$host_os"  in
     darwin* )
        CHECK_DEPS="check-recompile check-fresh-line check-script 
check-tests"
       ;;
     * )
         CHECK_DEPS="check-recompile check-fresh-line check-script 
check-exec-image check-tests"
       ;;
   esac

Works at least for me, don't know how others check result

Karsten

Re: make check-exec-image failure

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

Hi Bruno,

> * Bruno Haible <oe...@py...t> [2017-03-13 20:30:47 +0100]:
>
>> > <<There is now a general move away from "pack everything into one file"
>> >   to "create separate file for different purposes"...>>
>> ...
>> This is not true for someone like me who threw together a quick hack to
>> be run by my wife. It is much easier for me to email her an executable
>> image which she will copy to her desktop and click to run than create a
>> tgz which she has to unpack, install &c &c.
>> 
>> The only alternative to `(saveinitmem :executable t)` is
>> `(make-distribution)` which will create an executable installer.
>
> Our time is better invested in working on '(make-distribution)'
> than on '(saveinitmem :executable t)'.

Yep, I imagine a bunch of make-distrib-<platform>.lisp files,
and something like this in init.lisp:

#+win32 (load "make-distrib-win32")
#+macos (load "make-distrib-macos")
...
#-(or win32 macos ...)
(defun make-distrib (name)
  (saveinitmem name :executable t))


:-)


-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net http://iris.org.il
http://camera.org http://www.dhimmitude.org http://jij.org
Modern man is the missing link between apes and human beings.

Re: make check-exec-image failure

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

Hi Sam,

> > <<There is now a general move away from "pack everything into one file"
> >   to "create separate file for different purposes"...>>
> ...
> This is not true for someone like me who threw together a quick hack to
> be run by my wife. It is much easier for me to email her an executable
> image which she will copy to her desktop and click to run than create a
> tgz which she has to unpack, install &c &c.
> 
> The only alternative to `(saveinitmem :executable t)` is
> `(make-distribution)` which will create an executable installer.

Our time is better invested in working on '(make-distribution)'
than on '(saveinitmem :executable t)'.

Bruno

Re: gcc warnings

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

Hi Sam,

> My general attitude to compiler warnings is that each such warning is a bug.
> Either it is a bug in the code being compiled, or it is a bug in the compiler.

No. Different projects need to enable different sets of warnings. That's why
the warnings have names, so that we can selectively enable or selectively
disable them.

Look again at these examples:
nw="$nw -Wsystem-headers"       # Don't let system headers trigger warnings
nw="$nw -Wundef"                # All compiler preprocessors support #if UNDEF
nw="$nw -Wtraditional"          # All compilers nowadays support ANSI C

Bruno

Re: make check-exec-image failure

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

Hi,

>But what I need is that "make check" does not abort prematurely, because a "make check" failure
>means - to everyone - "the package is broken, you should better not proceed with 'make install'".
I've always wondered whether distros use "make check" before releasing a package.
I have some doubts though, because I remember reading bugs that one would think impossible
had people used make check as a prerequisite.
Of course, make check probably works only on the target platform, not the cross-compiler build farm?

IMHO "make check" is important, because it ensures that basic CLISP functions work,
including GC and sockets (even some FFI tests).


I find a maintainer's attitude reasonable: Each and every warning is puzzling and costs
time ("is it or not the sign of a problem?"). As such, supplying options to force the
desired semantics, such as -fwrapv -fno-strict-aliasing and *not* silencing warnings
(assuming -fwrapv will silence those related to overflows) is an approach that should
satisfy both maintainers, developers as well as users occasionally compiling code. The
compile log will contain few warnings *and* the program will not crash from GCC
"optimizations" in obscure (rarely used) areas of the code.

Forcing the desired semantics should also have the additional benefit of allowing GCC's
highest optimization levels (-O3 to -O6), but that's another story.


>So, when users ask for a "single executable" option, tell them that this option would buy them nothing.

Maybe we could differentiate user expectations by target platform?
- MS-Windows: single file mostly welcome (think "portable executable (PE)"). 
Self-extracting and executing archives are common.

- trad. UNIX: used to packages and support files in /lib /usr /etc
Yet Sam put in effort to support that too, several years ago...
(I remember other tricks, like a file beginning as a tiny shell script,
 then exit, followed by binary stuff).

A single file is nice because sometimes you lose track of what .mem belongs to what lisp.run.

- MacOSX: People are used to foo.app for GUI apps.
Some know that they can invoke apps on the CLI via e.g. /Applications/VLC.app/Contents/MacOS/VLC
I have no idea whether a CLISP.app structure would make sense for a program that
only lives on the command line, i.e. whether an .app is expected to follow some
protocol, such as opening an event loop and responding to a WM startup notification message?

My expectation: When starting CLISP.app, (Saveinitmem ... :executable t) would
create another .app, somewhere else.

Another approach (involving several files): I've often created clickable files named
*.desktop (on Linux) and *.command (OSX) that start a terminal and a program therein.
The icon file is separate (.desktop) or in the resource fork (.command).
That's all I need, but others did not seem impressed by my approach ;-)

Regards,
	Jörg

Re: make check-exec-image failure

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

Hi Bruno,

> * Bruno Haible <oe...@py...t> [2017-03-13 09:41:35 +0100]:
>
>> > So, when users ask for a "single executable" option, tell them that this
>> > option would buy them nothing.
>> 
> <<There is now a general move away from "pack everything into one file"
>   to "create separate file for different purposes"...>>

This is true for skilled vendors distributing well-polished packages to
many users.

This is not true for someone like me who threw together a quick hack to
be run by my wife. It is much easier for me to email her an executable
image which she will copy to her desktop and click to run than create a
tgz which she has to unpack, install &c &c.

The only alternative to `(saveinitmem :executable t)` is
`(make-distribution)` which will create an executable installer.

Until we have it, we should support executable images.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net https://ffii.org
http://no2bds.org http://camera.org http://mideasttruth.com http://iris.org.il
Can I do it in Lisp, or would you rather wait an extra couple of months?

Re: gcc warnings

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

Hi Bruno,

My general attitude to compiler warnings is that each such warning is a bug.
Either it is a bug in the code being compiled, or it is a bug in the compiler.
Thus disabling a warning is merely closing one's eyes.
It can be a stop-gap (let's disable warning A while we are working on
warning B), but never permanent.
I know you disagree, and I doubt that I will convince you or vv.
Thanks for dealing with the issue.


> * Bruno Haible <oe...@py...t> [2017-03-13 09:47:49 +0100]:
>
> Hi Sam,
>
>> The same story with ignoring GCC warnings today - I don't understand the
>> subject and I am leaving it to you
>
> I will deal with these GCC warnings. But to keep the story short:
>
>   1) It is better to start with all warnings and disable the warnings
>      on case-by-case basis, than to start with no warnings and enable them
>      selectively. Reason: GCC keeps adding new, useful warnings for a number
>      of years already. [1]
>
>   2) clang has become a compiler to care about as well, and clang has also
>      a number of useful (and a small number of not useful) warnings.
>
> Bruno
>
> [1] https://www.gnu.org/software/gnulib/manual/html_node/manywarnings.html

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net http://camera.org
http://iris.org.il http://mideasttruth.com http://islamexposedonline.com
Stupidity, like virtue, is its own reward.

Re: gcc warnings

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

Hi Sam,

> The same story with ignoring GCC warnings today - I don't understand the
> subject and I am leaving it to you

I will deal with these GCC warnings. But to keep the story short:

  1) It is better to start with all warnings and disable the warnings
     on case-by-case basis, than to start with no warnings and enable them
     selectively. Reason: GCC keeps adding new, useful warnings for a number
     of years already. [1]

  2) clang has become a compiler to care about as well, and clang has also
     a number of useful (and a small number of not useful) warnings.

Bruno

[1] https://www.gnu.org/software/gnulib/manual/html_node/manywarnings.html

Re: make check-exec-image failure

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

Hi Sam,

> > So, when users ask for a "single executable" option, tell them that this
> > option would buy them nothing.
> 
> I see your point, but I find it unconvincing.
> ...
> However, it boils down to "the whole world is wrong, I am right".

It's not "the whole world". Read again my argument
<<There is now a general move away from "pack everything into one file"
  to "create separate file for different purposes"...>>

Bruno

Re: Comment on proprietary advertising (Re: clisp max heap size on 64 bit machines)

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

Hi Bruno,

> * Bruno Haible <oe...@py...t> [2017-03-13 00:38:21 +0100]:
>
> I find the mailing list archives OK. Their main plus is that they provide
> permanent URLs that still work 10 years later. What I miss most is a view
> of threads that cross the month limit, like gmane used to have.

precisely.
the arbitrary separation of archives by month is absurd.

> The bug tracker is good for me. Once you've learned how to customize
> it, it helps you to focus on certain kinds of bugs, depending on your
> current priorities.

I find the universality of the bug id namespace (i.e., bug number
determines the project) to be absurd.

> But as Daniel said: in the current phase of good work on the code, any
> change in the infrastructure (code repo, mailing list, bug tracker)
> would be annoying.

agreed.

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 16.10 (yakkety) X 11.0.11804000
http://www.childpsy.net/ http://camera.org http://memri.org http://iris.org.il
http://openvotingconsortium.org http://ffii.org http://truepeace.org
Why use Windows, when there are Doors?

Re: make check-exec-image failure

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

Hi Bruno,

> * Bruno Haible <oe...@py...t> [2017-03-13 01:12:19 +0100]:
>
> So, when users ask for a "single executable" option, tell them that this
> option would buy them nothing.

I see your point, but I find it unconvincing.

It sounds like "I cannot give you what you came to expect from C, so I
will try to convince you that you should not ask for it in the first
place".

You are a smart guy and you can build a convincing sounding argument.

However, it boils down to "the whole world is wrong, I am right".
The same story was with FP contagion 20 years ago - I understand the
subject and I implemented what the world thinks is right.
The same story with ignoring GCC warnings today - I don't understand the
subject and I am leaving it to you (the problem is that if you step
away again, CLISP will be dead in the water because finding someone
shares your views would be impossible.)


-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 16.10 (yakkety) X 11.0.11804000
http://www.childpsy.net/ http://islamexposedonline.com http://camera.org
http://openvotingconsortium.org http://www.memritv.org http://ffii.org
Money does not "play a role", it writes the scenario.

Re: next nightly build problem

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

Hi Daniel,

> Adding this because it might be related: on NetBSD I disabled
> TRIVIALMAP_MEMORY and SINGLEMAP_MEMORY because our fixed address (0x40...0)
> is not mappable there.
> 
> This was done with commit 1c61a0 [1]

While this was good to get clisp running on NetBSD at all, one can go one step
further and re-enable TRIVIALMAP_MEMORY or SINGLEMAP_MEMORY with the
appropriate address range.

For SINGLEMAP_MEMORY this was relatively easy, done through an autoconf test
("checking for highest bit number which can be included in mmaped addresses",
from m4/mmap.m4).

For TRIVIALMAP_MEMORY it is harder. For now I've specified the address range
explicitly. But it should be possible to determine it automatically,
depending on CODE_ADDRESS_RANGE, MALLOC_ADDRESS_RANGE, SHLIB_ADDRESS_RANGE,
STACK_ADDRESS_RANGE, and garcol_bit_o...

Bruno

clisp-cvs Digest, Vol 75, Issue 3

[<cli...@li...>]

Send clisp-cvs mailing list submissions to
	cli...@li...

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/clisp-cvs
or, via email, send a message with subject or body 'help' to
	cli...@li...

You can reach the person managing the list at
	cli...@li...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of clisp-cvs digest..."


CLISP CVS commits for today

Today's Topics:

   1. clisp: Warn before doing mmap calls that might crash clisp.
      (cli...@li...)
   2. clisp: Warn before reserving an address range that might
      crash c... (cli...@li...)
   3. clisp: ansi-cl-bib: remove path from the webstore link
      (cli...@li...)
   4. clisp: Add -Wno-shift-negative-value to XCFLAGS.
      (cli...@li...)
   5. clisp: Disable address range warning on Mac OS X.
      (cli...@li...)
   6. clisp: maint: Modernize multibuild-linux-x86 target.
      (cli...@li...)
   7. clisp: Rename STANDARD_HEAPCODES to ONE_FREE_BIT_HEAPCODES.
      (cli...@li...)
   8. clisp: Rename LINUX_NOEXEC_HEAPCODES to
      KERNELVOID32_HEAPCODES. (cli...@li...)
   9. clisp: New heapcodes scheme KERNELVOID32B_HEAPCODES.
      (cli...@li...)
  10. clisp: Fix build failure on OpenBSD 6 (regression from
      2017-03-10). (cli...@li...)
  11. clisp: Avoid unwanted optimizations on signed integer types
      by gcc. (cli...@li...)
  12. clisp: When warning about the address range, dump the process
      me... (cli...@li...)
  13. clisp: Add support for generational GC on OpenBSD/x86.
      (cli...@li...)
  14. clisp: Don't attempt to use SINGLEMAP_MEMORY on
      OpenBSD/x86_64. (cli...@li...)
  15. clisp: Fix build failure on x86 platforms with clang, e.g.
      FreeB... (cli...@li...)
  16. clisp: Add support for TRIVIALMAP_MEMORY configuration on
      FreeBS... (cli...@li...)


----------------------------------------------------------------------

Message: 1
Date: Fri, 10 Mar 2017 18:46:46 +0000
From: cli...@li...
Subject: clisp: Warn before doing mmap calls that might crash clisp.
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/445f13d82fc0
changeset: 15795:445f13d82fc0f9917476916e6cf0c75ae792e5f8
user:      Bruno Haible <br...@cl...>
date:      2017-03-10 15:06:43 +0100
description:
Warn before doing mmap calls that might crash clisp.

diffstat:

 src/ChangeLog    |  11 ++++++++
 src/config.h.in  |   3 ++
 src/configure    |  14 +++++++++-
 src/configure.in |   1 +
 src/spvw_mmap.d  |  72 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 99 insertions(+), 2 deletions(-)



------------------------------

Message: 2
Date: Fri, 10 Mar 2017 18:46:48 +0000
From: cli...@li...
Subject: clisp: Warn before reserving an address range that might
	crash c...
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/aa379ae79196
changeset: 15796:aa379ae79196000bc05b17056f49f80ffa1f9951
user:      Bruno Haible <br...@cl...>
date:      2017-03-10 19:45:48 +0100
description:
Warn before reserving an address range that might crash clisp.

diffstat:

 Makefile.devel            |    3 +-
 src/ChangeLog             |   13 +
 src/aclocal.m4            |   13 +-
 src/config.h.in           |    3 +
 src/configure             |   70 ++++-
 src/gllib/Makefile.am     |   10 +-
 src/gllib/Makefile.in     |   13 +-
 src/gllib/glthread/lock.c |    2 +-
 src/gllib/glthread/lock.h |    2 +-
 src/gllib/vma-iter.c      |  636 ++++++++++++++++++++++++++++++++++++++++++++++
 src/gllib/vma-iter.h      |   64 ++++
 src/glm4/gnulib-cache.m4  |    3 +-
 src/glm4/gnulib-common.m4 |    6 +-
 src/glm4/gnulib-comp.m4   |    5 +
 src/glm4/lib-prefix.m4    |    2 +-
 src/spvw_mmap.d           |   74 +++++-
 16 files changed, 899 insertions(+), 20 deletions(-)



------------------------------

Message: 3
Date: Fri, 10 Mar 2017 19:49:19 +0000
From: cli...@li...
Subject: clisp: ansi-cl-bib: remove path from the webstore link
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/d98f5b570808
changeset: 15797:d98f5b57080851983216fec73262cffce2bc6136
user:      Sam Steingold <sd...@po...>
date:      2017-03-10 14:04:24 -0500
description:
ansi-cl-bib: remove path from the webstore link

diffstat:

 doc/cl-ent.xml |  4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)



------------------------------

Message: 4
Date: Fri, 10 Mar 2017 19:49:21 +0000
From: cli...@li...
Subject: clisp: Add -Wno-shift-negative-value to XCFLAGS.
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/7cc29a3c6c41
changeset: 15798:7cc29a3c6c41ff681388264fd5d5fe75fa23e2cb
user:      Sam Steingold <sd...@po...>
date:      2017-03-10 14:49:14 -0500
description:
Add -Wno-shift-negative-value to XCFLAGS.

* src/makemake.in (XCFLAGS) [GCC & !CROSS]: Add -Wno-shift-negative-value.
Note that gcc accepts -Wno-<whatever>, so no version check is needed.

diffstat:

 src/ChangeLog   |  10 ++++++++--
 src/makemake.in |  15 ++++++---------
 2 files changed, 14 insertions(+), 11 deletions(-)



------------------------------

Message: 5
Date: Fri, 10 Mar 2017 23:17:32 +0000
From: cli...@li...
Subject: clisp: Disable address range warning on Mac OS X.
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/2f070ef362ee
changeset: 15799:2f070ef362ee397695d3b29ecb4143bff8b64c0d
user:      Bruno Haible <br...@cl...>
date:      2017-03-11 00:13:07 +0100
description:
Disable address range warning on Mac OS X.

diffstat:

 src/ChangeLog   |  10 ++++++++--
 src/spvw_mmap.d |   5 +++--
 2 files changed, 11 insertions(+), 4 deletions(-)



------------------------------

Message: 6
Date: Sat, 11 Mar 2017 14:23:19 +0000
From: cli...@li...
Subject: clisp: maint: Modernize multibuild-linux-x86 target.
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/64668b594ab5
changeset: 15800:64668b594ab5bbb924f1ffda8b17df6bc1b6259f
user:      Bruno Haible <br...@cl...>
date:      2017-03-11 09:10:21 +0100
description:
maint: Modernize multibuild-linux-x86 target.

diffstat:

 Makefile.devel |  85 ++++++++++++++++-----------------------------------------
 src/ChangeLog  |   7 ++++
 2 files changed, 31 insertions(+), 61 deletions(-)



------------------------------

Message: 7
Date: Sat, 11 Mar 2017 14:23:20 +0000
From: cli...@li...
Subject: clisp: Rename STANDARD_HEAPCODES to ONE_FREE_BIT_HEAPCODES.
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/808a71f4b682
changeset: 15801:808a71f4b682d06a0ceabe097b0a1908a2feb0b8
user:      Bruno Haible <br...@cl...>
date:      2017-03-11 09:38:48 +0100
description:
Rename STANDARD_HEAPCODES to ONE_FREE_BIT_HEAPCODES.

diffstat:

 Makefile.devel        |  56 +++++++++++++++++++++++++-------------------------
 src/ChangeLog         |  15 +++++++++++++
 src/built.d           |   4 +-
 src/lightning.c       |   2 +-
 src/lispbibl.d        |  42 +++++++++++++++++++-------------------
 src/makemake.in       |   2 +-
 src/spvw.d            |   2 +-
 src/spvw_garcol.d     |   4 +-
 src/spvw_garcol_old.d |   4 +-
 src/spvw_gcmark.d     |   8 +++---
 10 files changed, 77 insertions(+), 62 deletions(-)



------------------------------

Message: 8
Date: Sat, 11 Mar 2017 14:23:22 +0000
From: cli...@li...
Subject: clisp: Rename LINUX_NOEXEC_HEAPCODES to
	KERNELVOID32_HEAPCODES.
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/fe0cadbf43ea
changeset: 15802:fe0cadbf43ea197437d72ec0f7e0beaaf9954648
user:      Bruno Haible <br...@cl...>
date:      2017-03-11 10:03:30 +0100
description:
Rename LINUX_NOEXEC_HEAPCODES to KERNELVOID32_HEAPCODES.

diffstat:

 Makefile.devel     |  42 +++++++++++++-------------
 src/ChangeLog      |  15 +++++++++
 src/built.d        |   4 +-
 src/constsym.d     |   2 +-
 src/io.d           |   2 +-
 src/lightning.c    |   2 +-
 src/lispbibl.d     |  83 ++++++++++++++++++++++++++++++-----------------------
 src/spvw.d         |   4 +-
 src/spvw_gcmark.d  |   2 +-
 src/spvw_memfile.d |   6 +-
 10 files changed, 94 insertions(+), 68 deletions(-)



------------------------------

Message: 9
Date: Sat, 11 Mar 2017 14:23:23 +0000
From: cli...@li...
Subject: clisp: New heapcodes scheme KERNELVOID32B_HEAPCODES.
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/3521c49e4168
changeset: 15803:3521c49e416873c4a188def67e7b3b4a7b4f2cb9
user:      Bruno Haible <br...@cl...>
date:      2017-03-11 10:21:49 +0100
description:
New heapcodes scheme KERNELVOID32B_HEAPCODES.

diffstat:

 src/ChangeLog  |   8 +++++++
 src/lispbibl.d |  59 ++++++++++++++++++++++++++++++++++++++++++++++-----------
 src/spvw.d     |  10 +++++++-
 3 files changed, 63 insertions(+), 14 deletions(-)



------------------------------

Message: 10
Date: Sat, 11 Mar 2017 14:23:25 +0000
From: cli...@li...
Subject: clisp: Fix build failure on OpenBSD 6 (regression from
	2017-03-10).
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/719734fca92c
changeset: 15804:719734fca92cf686bf286f4f38cd78d7ad722ce7
user:      Bruno Haible <br...@cl...>
date:      2017-03-11 11:15:49 +0100
description:
Fix build failure on OpenBSD 6 (regression from 2017-03-10).

diffstat:

 src/ChangeLog   |   5 +++++
 src/makemake.in |  32 +++++++++++++++++++++++---------
 2 files changed, 28 insertions(+), 9 deletions(-)



------------------------------

Message: 11
Date: Sat, 11 Mar 2017 14:23:26 +0000
From: cli...@li...
Subject: clisp: Avoid unwanted optimizations on signed integer types
	by gcc.
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/59ddc790b018
changeset: 15805:59ddc790b018fdcb8eb0d71087c9d4a67aefdeaf
user:      Bruno Haible <br...@cl...>
date:      2017-03-11 11:37:01 +0100
description:
Avoid unwanted optimizations on signed integer types by gcc.

diffstat:

 src/ChangeLog   |   5 +++++
 src/makemake.in |  15 ++++++++++++++-
 2 files changed, 19 insertions(+), 1 deletions(-)



------------------------------

Message: 12
Date: Sat, 11 Mar 2017 16:29:16 +0000
From: cli...@li...
Subject: clisp: When warning about the address range, dump the process
	me...
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/d6906bd85f95
changeset: 15806:d6906bd85f950da88d22432c231b7b72cb99e5af
user:      Bruno Haible <br...@cl...>
date:      2017-03-11 17:18:34 +0100
description:
When warning about the address range, dump the process memory map.

diffstat:

 src/ChangeLog   |   7 +++++++
 src/spvw_mmap.d |  17 +++++++++++++++++
 2 files changed, 24 insertions(+), 0 deletions(-)



------------------------------

Message: 13
Date: Sat, 11 Mar 2017 16:29:18 +0000
From: cli...@li...
Subject: clisp: Add support for generational GC on OpenBSD/x86.
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/a2f1ed6a1df9
changeset: 15807:a2f1ed6a1df9e371fa9a42e6e417ab739a9dd3bd
user:      Bruno Haible <br...@cl...>
date:      2017-03-11 17:22:38 +0100
description:
Add support for generational GC on OpenBSD/x86.

diffstat:

 src/ChangeLog  |   8 ++++++++
 src/lispbibl.d |  20 +++++++++++++++++---
 src/spvw.d     |   3 +++
 3 files changed, 28 insertions(+), 3 deletions(-)



------------------------------

Message: 14
Date: Sat, 11 Mar 2017 16:29:19 +0000
From: cli...@li...
Subject: clisp: Don't attempt to use SINGLEMAP_MEMORY on
	OpenBSD/x86_64.
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/15c1e0995b17
changeset: 15808:15c1e0995b17ba76a5570978601dac434ed615b4
user:      Bruno Haible <br...@cl...>
date:      2017-03-11 17:27:27 +0100
description:
Don't attempt to use SINGLEMAP_MEMORY on OpenBSD/x86_64.

diffstat:

 src/ChangeLog  |   6 ++++++
 src/lispbibl.d |  13 ++++++++++---
 2 files changed, 16 insertions(+), 3 deletions(-)



------------------------------

Message: 15
Date: Mon, 13 Mar 2017 00:43:31 +0000
From: cli...@li...
Subject: clisp: Fix build failure on x86 platforms with clang, e.g.
	FreeB...
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/ec1a521ae05d
changeset: 15809:ec1a521ae05d56d9951743ddb9c0b33d4b334597
user:      Bruno Haible <br...@cl...>
date:      2017-03-12 10:18:12 +0100
description:
Fix build failure on x86 platforms with clang, e.g. FreeBSD/x86.

diffstat:

 src/ChangeLog   |  6 ++++++
 src/makemake.in |  2 +-
 2 files changed, 7 insertions(+), 1 deletions(-)



------------------------------

Message: 16
Date: Mon, 13 Mar 2017 00:43:32 +0000
From: cli...@li...
Subject: clisp: Add support for TRIVIALMAP_MEMORY configuration on
	FreeBS...
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/69c18b3afcda
changeset: 15810:69c18b3afcdaa6e5042d1e0c4bc12495c87a6041
user:      Bruno Haible <br...@cl...>
date:      2017-03-12 10:58:34 +0100
description:
Add support for TRIVIALMAP_MEMORY configuration on FreeBSD/x86_64.

diffstat:

 src/ChangeLog |  5 +++++
 src/spvw.d    |  3 +++
 2 files changed, 8 insertions(+), 0 deletions(-)



------------------------------

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford

------------------------------

_______________________________________________
clisp-cvs mailing list
cli...@li...
https://lists.sourceforge.net/lists/listinfo/clisp-cvs


End of clisp-cvs Digest, Vol 75, Issue 3
****************************************

Re: make check-exec-image failure

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

Hi Sam,

> > There is now a general move away from "pack everything into one file"
> > to "create separate file for different purposes".
> 
> Users, nevertheless, do ask for a "single executable" option.
> 
> CLISP, being a developer's tool - as opposed to a user's tool, needs, in
> addition to "vendor model" you describe: a team of seasoned
> professionals building distributions to be used by many people, a
> "custom exec" model, when a lisp hacker throws together a quick solution
> and gives is to his 1 or 2 ad hoc users.
> 
> E.g., I want to run something on a box in which I cannot install anything.
> An executable image - as opposed to two files (runtime + image) - is
> easier to distribute.

This is not a sound argument. When a file is transferred to a machine,
whether by ftp, scp, the browser, or whatever, it is by default not executable.
This is means, it needs some "post-install" command to really make it
usable. Whether this command is a "chmod a+x" or "tar xfz" or "unzip -x",
does not make a big difference in practice.

Additionally, most users want to transfer binaries in a compressed way,
to save bandwidth.

Now, when you accept "tar xfz" or "unzip -x" as a post-install command,
there is no reason to insist on just 1 file.

So, when users ask for a "single executable" option, tell them that this
option would buy them nothing.

> > No. (savemem ... :executable t) is based on
> > spvw_memfile.d:savemem_with_runtime, which consists in *appending*
> > a memory image to an *executable file*.
> 
> I know, I wrote it.

The only way of generating an executable that does not cause portability
problems - and thus endless maintenance hassles - is through the compiler
($CC), that invokes the linker, or through the linker directly ($LD).

> > I certainly won't spend time digging in the internals of the Mach-O
> > object format in order to find out how to port this to Mac.
> 
> this is a regression on _all_ platforms.

No, it's not a regression if we tell people that a certain feature cannot
work on specific platforms, such as Mac OS X and MirBSD.

If you want the complete list of platforms where it works vs. does not work,
I can determine this list for you over time by running "make check-exec-image"
as part of my testing in the next few weeks.

But what I need is that "make check" does not abort prematurely, because
a "make check" failure means - to everyone - "the package is broken, you
should better not proceed with 'make install'".

Bruno

Re: Comment on proprietary advertising (Re: clisp max heap size on 64 bit machines)

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

Hi Sam,

There are more alternatives to sourceforge: not only savannah.gnu.org
but also gitlab.com or common-lisp.net. I haven't evaluated the
merits of each, though.

> Moreover, my experience is that FSF services are unreliable.

This was the case around 2009 or so, but since 2011 or so I have rarely
had issues with the GNU infrastructure. On rare occasions, the mailing
lists delayed mails by 1 day. That's the only problem I can remember.

Yes, planet.gnu.org is often inaccessible, but AFAIH it's being run by
a volunteer, not by the GNU sysadmins.

> Moreover, while mailing list archives may be good, the bug tracker
> sucks.

I find the mailing list archives OK. Their main plus is that they provide
permanent URLs that still work 10 years later. What I miss most is a view
of threads that cross the month limit, like gmane used to have.

The bug tracker is good for me. Once you've learned how to customize
it, it helps you to focus on certain kinds of bugs, depending on your
current priorities.

> Bruno, is the gnulib mailing list hosted by FSF?
> Are you happy with them?

Yes and yes.

But as Daniel said: in the current phase of good work on the code, any
change in the infrastructure (code repo, mailing list, bug tracker)
would be annoying.

Bruno

Re: Comment on proprietary advertising (Re: clisp max heap size on 64 bit machines)

[Daniel J. <dan...@gm...>]

As much as I dislike some of the services "here" at SourceForge (mailing
archives, "forking") I think it would be a bad idea to change anything
about the hosting situation now. There is thankfully a lot more of activity
on both mailing lists as well as lots of new commits. Changes to the
hosting situation will bring some broken links, confusion and unexpected
work. This distracts from useful work on and discussion about CLISP itself.

Sam Steingold <sd...@gn...> schrieb am So., 12. März 2017, 19:44:

> Hi Jean,
>
> > * Jean Louis <ohtf@tah.fhccbeg> [2017-03-10 23:07:05 +0300]:
> >
> >> > Not related to the CLISP question, I am somewhat surprised that
> >> > excellent piece of software such as GNU CLISP, is hosted on
> >> > Sourceforge, with this direct advertising to proprietary software.
> >>
> >> Small price to pay for the service they have provided us for 15+
> >> years.
> >
> > Does freedom have price?
> >
> > GNU software should promote the 4 freedoms and GPL licensing, and it
> > shall avoid the promotion of proprietary software.
>
> I do not share these extreme views.
>
> Moreover, my experience is that FSF services are unreliable.
>
> Moreover, while mailing list archives may be good, the bug tracker
> sucks.
>
> Bruno, is the gnulib mailing list hosted by FSF?
> Are you happy with them?
>
> Thanks.
>
> --
> Sam Steingold (http://sds.podval.org/) on Ubuntu 16.10 (yakkety) X
> 11.0.11804000
> http://www.childpsy.net/ http://memri.org http://www.dhimmitude.org
> http://dhimmi.org http://truepeace.org http://honestreporting.com
> If you're being passed on the right, you're in the wrong lane.
>
>
> ------------------------------------------------------------------------------
> Announcing the Oxford Dictionaries API! The API offers world-renowned
> dictionary content that is easy and intuitive to access. Sign up for an
> account today to start using our lexical data to power your apps and
> projects. Get started today and enter our developer competition.
> http://sdm.link/oxford
> _______________________________________________
> clisp-devel mailing list
> cli...@li...
> https://lists.sourceforge.net/lists/listinfo/clisp-devel
>

Re: Comment on proprietary advertising (Re: clisp max heap size on 64 bit machines)

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

Hi Jean,

> * Jean Louis <ohtf@tah.fhccbeg> [2017-03-10 23:07:05 +0300]:
>
>> > Not related to the CLISP question, I am somewhat surprised that
>> > excellent piece of software such as GNU CLISP, is hosted on
>> > Sourceforge, with this direct advertising to proprietary software.
>> 
>> Small price to pay for the service they have provided us for 15+
>> years.
>
> Does freedom have price?
>
> GNU software should promote the 4 freedoms and GPL licensing, and it
> shall avoid the promotion of proprietary software.

I do not share these extreme views.

Moreover, my experience is that FSF services are unreliable.

Moreover, while mailing list archives may be good, the bug tracker
sucks.

Bruno, is the gnulib mailing list hosted by FSF?
Are you happy with them?

Thanks.

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 16.10 (yakkety) X 11.0.11804000
http://www.childpsy.net/ http://memri.org http://www.dhimmitude.org
http://dhimmi.org http://truepeace.org http://honestreporting.com
If you're being passed on the right, you're in the wrong lane.

Re: TEST_NT hack and OpenBSD

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

Hi Bruno,

> * Bruno Haible <oe...@py...t> [2017-03-11 02:44:54 +0100]:
>
> 1) 'test file1 -nt -file2' is not standardized by POSIX [1], therefore better
>    not rely on it.

this is a common korn shell extension.

> 2) I don't see anything that uses it.

without it module recompile requires `rm -rf` of the module dir, see
makemake.in:

--8<---------------cut here---------------start------------->8---
  if [ "@TEST_NT@" = no ]; then # re-making a module requires rm -rf module
    newer(){ echo 'test -f $$m/'$1' -a '"'!'"' -f $@/'$2; }
  else # re-making a module just works
    newer(){ echo 'test -f $$m/'$1' -a $$m/'$1' -nt $@/'$2; }
  fi
--8<---------------cut here---------------end--------------->8---


-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 16.10 (yakkety) X 11.0.11804000
http://www.childpsy.net/ http://palestinefacts.org http://jihadwatch.org
http://openvotingconsortium.org http://truepeace.org http://www.memritv.org
Save the whales, feed the hungry, free the mallocs.

Re: Build problem

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

Thanks!  But what about the make check error.  Is that normal?

On Sun, Mar 12, 2017 at 12:17 PM, Sam Steingold <sd...@gn...> wrote:

> > * Blake McBride <oy...@zp...zr> [2017-03-11 18:48:03 -0600]:
> >
> > Thanks.  The winning sequence, when the status of the repo is unclear is:
> >
> > hg pull
> > hg update
> > ./configure
>
> I suggest that you always pass a build directory to configure:
>
> ./configure build-no-options
>
> this way you do `rm -rf build-no-options` instead of `make distclean`.
>
> --
> Sam Steingold (http://sds.podval.org/) on Ubuntu 16.10 (yakkety) X
> 11.0.11804000
> http://www.childpsy.net/ http://www.dhimmitude.org http://iris.org.il
> http://ffii.org http://palestinefacts.org http://americancensorship.org
> Growing Old is Inevitable; Growing Up is Optional.
>