clisp-devel — closed list for developers and testers

Re: windows build

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

Hi Reini,

> * Reini Urban <ervav.heona@tznvy.pbz> [2017-03-19 10:42:37 +0100]:
>
> ...(Windows)...

Could you please try my patch
https://sourceforge.net/p/clisp/patches/_discuss/thread/58fe6204/2688/attachment/no_dynamic_modules_cygwin.patch
(see https://sourceforge.net/p/clisp/patches/46/ for context)?

Thanks!

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net http://www.memritv.org
http://islamexposedonline.com https://jihadwatch.org http://jij.org
If a cat tells you that you lost your mind, then it is so.

Re: Getting rid of varbrace

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

Hi Bruno,

> * Sam Steingold <fq...@ta...t> [2017-03-21 09:19:08 -0400]:
>
> Given that we have almost 12k "var" instances:
>
> $ grep '^ *var ' *.d | wc -l
>    11760
>
> we need either a comment or a thorough purge.
> I favor the latter because I want the CLISP sources to _look_ like
> regular C.
>
> Note that the purge can be done with a perl one-liner.

Here is the sed(1) one-liner (tested on zthread.d and unixaux.d):

--8<---------------cut here---------------start------------->8---
sed -i "" -e 's/^\( *\)var /\1/' *.d
--8<---------------cut here---------------end--------------->8---

Are we using any non-C99 compilers?

Thanks.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net http://jij.org
http://americancensorship.org http://camera.org https://ffii.org
DRM "access management" == prison "freedom management".

Re: Getting rid of varbrace

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

Daniel,

I will leave installing the patch to Bruno because this is a portability
issue.
However, I have some comments inline below.

> * Daniel Jour <qnavry.bregjvt@tznvy.pbz> [2017-03-21 01:01:13 +0000]:
>
> - Contain no comment what the #define var does and why its there.

Not good.
Given that we have almost 12k "var" instances:

--8<---------------cut here---------------start------------->8---
$ grep '^ *var ' *.d | wc -l
   11760
--8<---------------cut here---------------end--------------->8---

we need either a comment or a thorough purge.
I favor the latter because I want the CLISP sources to _look_ like
regular C.

Note that the purge can be done with a perl one-liner.

> - Don't mention any change in the change log.

Bruno will be irate :-)

> - Remove an (hopefully!) unused variable. This should probably be a
> separate commit.

Absolutely. Please either make a separate patch or tell me where the
unused var is.

> - Manually add a pairs of braces at two places; I couldn't figure out what
> exactly the code there does, so I went the safe route.

Why did you need the braces at all?

> Most of the compilation errors complained about having only a declaration
> following an (goto) label. I solved this by adding a semicolon behind each
> such label ("label:" becomse "label:;").

No, please add braces instead.

> Is this a viable approach at getting rid of varbrace soon? If so then
> I can "polish" those patches further.

I will let Bruno decide on this.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net http://www.memritv.org
http://memri.org http://honestreporting.com http://think-israel.org
Don't take life too seriously, you'll never get out of it alive!

Getting rid of varbrace

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

The following two patches remove varbrace from the build and fix some
compilation errors due to that removal. My configuration built with those
two patches works fine (according to make check).

I didn't do an exhaustive test of different configurations, so this
definitively needs more testing. Also the patches:

- Contain no comment what the #define var does and why its there.
- Don't mention any change in the change log.
- Remove an (hopefully!) unused variable. This should probably be a
separate commit.
- Manually add a pairs of braces at two places; I couldn't figure out what
exactly the code there does, so I went the safe route.
- Don't remove the varbrace util yet; it's just not built / used.

Most of the compilation errors complained about having only a declaration
following an (goto) label. I solved this by adding a semicolon behind each
such label ("label:" becomse "label:;").

Is this a viable approach at getting rid of varbrace soon? If so then I can
"polish" those patches further.

Re: GSoC: Selection of project ideas and proposals

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

> * Compro Prasad <pbzcebcenfnq@tznvy.pbz> [2017-03-21 02:25:23 +0500]:
>
> I would love to work on the 1st idea(on thread-safe hash tables
> implementation) on the page http://clisp.org/wanted.html . I have a basic
> concept in this(multithreading and hash tables) subject both practically
> and theoretically. But I haven't worked on both at the same time so it
> would be a pretty good task. Looks like it will take around 2 months or so.

Good!

> [MT builds ran flawlessly with a running ./lisp.run executable but running
> ./clisp segfaults]

I thought MT does not work for you because it does not create lispinit.mem.
Right?

> Will I have to work on all/most of the feature implementations given
> on http://clisp.org/wanted.html ?

no, thread-safe hash tables is plenty.
gnome-config is fine also.
basically, you should write several proposals and discuss them here, and
we will see which one looks most realistic and fun.

> I have the basic layout of the proposal from
> https://www.gnu.org/software/soc-projects/guidelines.html . Is it good
> enough or there are some edits that you would suggest?

This is fine.


-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net
http://honestreporting.com http://no2bds.org http://mideasttruth.com
Things that cannot be programmed in assembler have to be soldered.

Re: [PATCH 2/2] silence comment5 warnings

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

Hi Bruno,

> * Bruno Haible <oe...@py...t> [2017-03-21 00:27:16 +0100]:
>
> Sam wrote:
>> I would rather eliminate comment5 altogether, rather than mutilate the
>> code to pacify it.
>
> Eliminating comment5 would not help here, since the warning comes from
> 'varbrace', and comment5's processing does not modify the lines that
> trigger the warning.

varbrace is not needed either. C99, IIRC, supports arbitrary placement
of declarations.

We need to drop comment5 and varbrace and rename all *.d files to *.c.
Then gctrigger should convert them to *.m.c and cc should compile *.m.c
to *.o.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net https://ffii.org
http://mideasttruth.com https://jihadwatch.org http://www.dhimmitude.org
main(a){printf(a,34,a="main(a){printf(a,34,a=%c%s%c,34);}",34);}

Re: HAVE_LONG_LONG_INT

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

Bruno wrote:
> I disagree. This would break the ability to compile with MSVC.  Last
> time I checked (Visual Studio 2015), it did not have 'long long',
> only __int64. Has this changed in Visual Studio 2017?

Are you sure? I don't have access to any version of MSVC right now,
but according to their own documentation[1], (unsigned) long long should
be there even in MSVC 2010?

But are we ever really using "long long"? A quick grep on all files in
the repo shows only a single usage of "long long" (actually "unsigned
long long"):

./src/spvw_sigsegv.d:29:  fprintf(stderr," %llu",(unsigned long
long)tm.gcfreed);

Other than that it's only typedefs (which could be changed to __int64
for MSVC) and code for the detection (whether there is long long
support or not).


[1] https://msdn.microsoft.com/de-de/library/s3f49ktz(v=vs.100).aspx

Re: HAVE_LONG_LONG_INT

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

Hi Daniel,

> We have a lot of code that is only included if HAVE_LONG_LONG_INT is
> defined. Now, C99 requires that type (long long int as well as
> unsigned long long int, both with 64 bits - excluding padding bits of
> course).
> 
> Thus I think we should get rid of those conditionals depending on
> HAVE_LONG_LONG_INT.

I disagree. This would break the ability to compile with MSVC.
Last time I checked (Visual Studio 2015), it did not have 'long long',
only __int64. Has this changed in Visual Studio 2017?

Bruno

Re: [PATCH 2/2] silence comment5 warnings

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

Bruno wrote:
> Done by modifying varbrace.c.

Wouldn't it be better to finally get rid of varbrace? I have not
tested it, but a single

#define var

in lispbibl.d should do it until all those "var" pseudo-keywords are
removed, no?

HAVE_LONG_LONG_INT

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

We have a lot of code that is only included if HAVE_LONG_LONG_INT is
defined. Now, C99 requires that type (long long int as well as
unsigned long long int, both with 64 bits - excluding padding bits of
course).

Thus I think we should get rid of those conditionals depending on
HAVE_LONG_LONG_INT.

Because that affects a lot of code, the best approach is probably to
only gradually remove occurrences of such conditionals (as opposed to
a massive change).

Ideas / Thoughts?

Re: [PATCH 2/2] silence comment5 warnings

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

Hello Reini,

I don't agree with this patch. The code that caused the warning messages
is valid C. This, for example, is a valid C program:

==========================================================================
#include <stdio.h>

#define hello "hello world" /* some nice
                               greeting */
int main () {
  printf (hello "\n");
}
==========================================================================

Or even this:
==========================================================================
#include <stdio.h>

#define hello "hello world" /\
* some nice
                               greeting *\
/
int main () {
  printf (hello "\n");
}
==========================================================================

I prefer much to fix the tools so that they understand the C syntax that
we use, rather than to add a constraint that we would have to remember
in future developments.

Done by modifying varbrace.c.

Sam wrote:
> I would rather eliminate comment5 altogether, rather than mutilate the
> code to pacify it.

Eliminating comment5 would not help here, since the warning comes from
'varbrace', and comment5's processing does not modify the lines that
trigger the warning.

Bruno

Re: More translations upcoming, git, ci

[Reini U. <rei...@gm...>]

> On Mar 20, 2017, at 4:45 PM, Sam Steingold <sd...@gn...> wrote:
> 
> Hi Reini, and welcome back!
> 
>> * Reini Urban <ervav.heona@tznvy.pbz> [2017-03-19 10:42:37 +0100]:
>> 
>> 1. I added a github mirror from the hg repo, with bi-hourly updates.
>> https://github.com/rurban/clisp/
> 
> Did you import the whole mercurial history into git?

Yes, there’s a nice bridge by Felipe Contreras,
https://github.com/felipec/git-remote-hg/blob/master/git-remote-hg
for read+write.

I even imported the old bad commits with missing names and emails.
I tried to fix them, but then the importer could not identify the old ones anymore, as the hashes changed.
So I went with all the original commits.

I don’t import the already closed branches, only the open ones.

Re: [PATCH 2/2] silence comment5 warnings

[Reini U. <rei...@gm...>]

> On Mar 20, 2017, at 4:58 PM, Sam Steingold <sd...@gn...> wrote:
> 
>> * Reini Urban <ervav.heona@tznvy.pbz> [2017-03-20 08:02:59 +0100]:
>> 
>> Like "End of comment outside comment in line"
>> caused by multi-line comments not detected as such with #define.
> 
> I would rather eliminate comment5 altogether, rather than mutilate the
> code to pacify it.
> 
> IOW, whenever you translate a file, please convert comments to C, and
> then we will dump comment5.

Agreed, much better. Almost done with all in my translate branch.
When I finished the last 2 files, I’ll rename them all to .c and remove comment5.

Re: GSoC: Selection of project ideas and proposals

[Reini U. <rei...@gm...>]

> On Mar 20, 2017, at 9:55 PM, Compro Prasad <com...@gm...> wrote:
> 
> I would love to work on the 1st idea(on thread-safe hash tables implementation) on the page http://clisp.org/wanted.html . I have a basic concept in this(multithreading and hash tables) subject both practically and theoretically. But I haven't worked on both at the same time so it would be a pretty good task. Looks like it will take around 2 months or so. [MT builds ran flawlessly with a running ./lisp.run executable but running ./clisp segfaults]

Which kind of hash table do you have in mind?
The best are usually preshing’s concurrent leapfrog http://preshing.com/20160314/leapfrog-probing/
or concurrent hopscotch.

Biggest problem besides weak hashes and the GC 
will be probing for the atomic intrinsics, and use slow locking or timestamps if not available.

Reini Urban
ru...@cp...

Re: make check-exec-image failure

[Ken B. <kb...@co...>]

Hi Sam,

On 3/20/2017 11:35 AM, Sam Steingold wrote:
> Ken, does it fail with the hg tip?

Yes.  I just built clisp from Bruno's tarball 
(https://haible.de/bruno/gnu/clisp-2.49.50.tar.bz2), and here's what 
happens when I try to save an executable in the build directory:

$ ./clisp -norc -q -x '(progn (ext:saveinitmem "test.exe" :init-function 
(function exit) :EXECUTABLE t))'
;; Wrote the memory image into test.exe (13,849,465 bytes)
Bytes permanently allocated:            160,328
Bytes currently in use:               3,602,952
Bytes available until next GC:           66,168
3602952 ;
66168 ;
160328 ;
2 ;
26120 ;
15000

$ ./test.exe
Segmentation fault (core dumped)

I suspect that the problem has something to do with my patches to make 
dynamic modules work, but I don't know for sure.

Ken

GSoC: Selection of project ideas and proposals

[Compro P. <com...@gm...>]

I would love to work on the 1st idea(on thread-safe hash tables
implementation) on the page http://clisp.org/wanted.html . I have a basic
concept in this(multithreading and hash tables) subject both practically
and theoretically. But I haven't worked on both at the same time so it
would be a pretty good task. Looks like it will take around 2 months or so.
[MT builds ran flawlessly with a running ./lisp.run executable but running
./clisp segfaults]

Will I have to work on all/most of the feature implementations given on
http://clisp.org/wanted.html ?
If yes then I would love to work on the 3rd mentioned feature too. Its kind
of easy to implement according to me. But portability might be a thing
which I am not familiar with so much. This might be done within a span of
2-3 weeks at max.
Along with them I could also help with GUI(8th feature) but presently I
have no background in assembly stuff in this area if required else it would
be a great implementation too.
Since, I am a bleeding edge GNOME user, the 10th feature(gnome-config) is
equally attractive but the problem is that I haven't done nor written
anything more than normal GUI applications in C. I have no idea of its
implementation so I take it could be done within a month.

Given I have decent algorithmic skills, a great learner and experimenter of
programs available how much time will each feature I mentioned take
irrespective of the time I mentioned?

I have the basic layout of the proposal from
https://www.gnu.org/software/soc-projects/guidelines.html . Is it good
enough or there are some edits that you would suggest?

My GitHub URL: https://github.com/Compro-Prasad


Regards,
Abhishek(Compro) Prasad

Re: TEST_NT hack and OpenBSD

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

> *  <Wbret-Plevy.Ubruyr@g-flfgrzf.pbz> [2017-03-20 13:58:30 +0000]:
>
> Is there really a need to add 1000 lines of code to the repository and
> several new tests and gnulib modules *just for the utilities*, not
> even the actual program, just to compare dates?

hear!

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net http://no2bds.org
http://www.dhimmitude.org http://iris.org.il http://camera.org
A computer scientist is someone who fixes things that aren't broken.

Re: Test error for sockets.tst in current beta version (newly introduced)

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

Hi Karsten,

> * Karsten Poeck <Xnefgra.Cbrpx@tznvy.pbz> [2017-03-20 15:29:15 +0100]:
>
> (SOCKET-CONNECT (SOCKET-SERVER-PORT *SERVER*) "localhost" :TIMEOUT 0)
> [OS-ERROR]: OS-ERROR(6): Device not configured

The problem is the failure of the

    ioctl(fd,FIONBIO,&non_blocking_io)

call in socket.d:connect_via_ip() (line 830).

(I think that function is additionally broken on that line because it
does not close fd before returning INVALID_HANDLE).

The solution is to use the newer interface (fcntl+O_NONBLOCK) as is done
in unix.d and documented in

http://www.kegel.com/dkftpbench/nonblocking.html
http://pubs.opengroup.org/onlinepubs/9699919799/functions/fcntl.html
http://stackoverflow.com/q/1150635/850781

Problems:

1. win32: *NO_BLOCK* macros are not defined (I guess the current code
can be reused).  Can someone with access to win32 find out whether
FIONBIO is defined there?

2. NO_BLOCK_DECL includes a function call. I think it can be safely moved
to START_NO_BLOCK.

At any rate, I pushed a patch which fixes the problem for me.

Thanks for the report.

--
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net http://memri.org
https://ffii.org http://think-israel.org https://jihadwatch.org
People hear what they want to hear and discard the rest.

Re: making clisp build more robust

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

Hi Bruno,

> * Bruno Haible <oe...@py...t> [2017-03-19 11:25:45 +0100]:
>
> 6. There are now 'multibuild-*' targets in Makefile.devel. But it's
> only in combination with continuous integration that they provide
> their full benefits.

You use --with-debug only for build-porting*-gcc-debug_gcsafety.
I suggest that you either add --with-debug to build-porting*-gcc-safety3
or add a separate target.

The reason I don't want to do it myself is that we gotta have a non-C++
debug target, and I want to use whatever you are using.

Thanks

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net http://www.dhimmitude.org
http://no2bds.org http://islamexposedonline.com https://jihadwatch.org
Liberty is measured in meters: how far one can travel without showing an ID.

Re: [PATCH 2/2] silence comment5 warnings

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

> * Reini Urban <ervav.heona@tznvy.pbz> [2017-03-20 08:02:59 +0100]:
>
> Like "End of comment outside comment in line"
> caused by multi-line comments not detected as such with #define.

I would rather eliminate comment5 altogether, rather than mutilate the
code to pacify it.

IOW, whenever you translate a file, please convert comments to C, and
then we will dump comment5.

Thanks!

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net https://ffii.org
https://jihadwatch.org http://honestreporting.com http://memri.org
A language that does not change the way you think is not worth learning.

Re: More translations upcoming, git, ci

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

Hi Reini, and welcome back!

> * Reini Urban <ervav.heona@tznvy.pbz> [2017-03-19 10:42:37 +0100]:
>
> 1. I added a github mirror from the hg repo, with bi-hourly updates.
> https://github.com/rurban/clisp/

Did you import the whole mercurial history into git?

Thanks

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net http://iris.org.il
http://thereligionofpeace.com http://americancensorship.org http://camera.org
Live Lisp and prosper.

Re: make check-exec-image failure

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

Bruno,

> * Bruno Haible <oe...@py...t> [2017-03-19 03:00:59 +0100]:
>
>> This is wrong.
>> exec images work on all platforms.
>
> "make check-exec-image" fails at least on OpenBSD/i386, OpenBSD/x86_64, and
> MirBSD.

With my latest patch too?!

> And probably on Cygwin as well, otherwise Ken Brown would not have added
> this patch to the Cygwin port of clisp:
>
> # HG changeset patch
> # User Ken Brown <kb...@co...>
> # Date 1429042817 14400
> #      Tue Apr 14 16:20:17 2015 -0400
> # Node ID 5383b0dea9eef525202949979d621e9f84a91fec
> # Parent  abc756d38a96bd7959869ca47d66590df7c19baf
> Don't allow saving executable memory images on Cygwin
>
> diff -r abc756d38a96 -r 5383b0dea9ee src/savemem.lisp
> --- a/src/savemem.lisp	Sat Mar 14 14:45:32 2015 -0400
> +++ b/src/savemem.lisp	Tue Apr 14 16:20:17 2015 -0400
> @@ -38,6 +38,9 @@
>                      ((:script *script*) (null init-function))
>                      keep-global-handlers (start-package *package*)
>                      (locked-packages *system-package-list*) executable)
> +  (if executable
> +      (error
> +       "Sorry, this build does not support saving executable memory images"))
>    (let* ((old-driver *driver*) old-global-handlers file-size
>           (*package* (sys::%find-package start-package))
>           (active-restarts *active-restarts*)

Ken, does it fail with the hg tip?

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net http://www.dhimmitude.org
http://no2bds.org https://jihadwatch.org http://iris.org.il
There are many reasons not to use Lisp - but no good ones.

Test error for sockets.tst in current beta version (newly introduced)

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

Error during make check in socket.tst

 From the terminal:
(DEFPARAMETER *SERVER* (SHOW (SOCKET-SERVER)))
#<SOCKET-SERVER 0.0.0.0:56229>
EQL-OK: *SERVER*
(MULTIPLE-VALUE-LIST (SOCKET-STATUS *SERVER* 0))
EQUAL-OK: (NIL 0)
(DEFPARAMETER *SOCKET-1* (SHOW (SOCKET-CONNECT (SOCKET-SERVER-PORT 
*SERVER*) "localhost" :TIMEOUT 0)))
[OS-ERROR]: OS-ERROR(6): Device not configured
ERROR!! ERROR should be *SOCKET-1* !
(DEFPARAMETER *STATUS-ARG* (LIST (LIST *SERVER*) (LIST *SOCKET-1* :IO)))
[SIMPLE-UNBOUND-VARIABLE]: LET: variable *SOCKET-1* has no value

ERROR!! ERROR should be *STATUS-ARG* !
(EQ (SOCKET-STATUS *STATUS-ARG* 0) *STATUS-ARG*)
[SIMPLE-UNBOUND-VARIABLE]: EVAL: variable *STATUS-ARG* has no value

ERROR!! ERROR should be T !
(CDR (ASSOC *SERVER* *STATUS-ARG*))
[SIMPLE-UNBOUND-VARIABLE]: EVAL: variable *STATUS-ARG* has no value

ERROR!! ERROR should be T !
(CDDR (ASSOC *SOCKET-1* *STATUS-ARG*))
[SIMPLE-UNBOUND-VARIABLE]: EVAL: variable *SOCKET-1* has no value

ERROR!! ERROR should be :OUTPUT !
(DEFPARAMETER *SOCKET-2* (SHOW (SOCKET-ACCEPT *SERVER*)))


and hangs here.


karstenoecksMBP:tests karstenpoeck$ more socket.erg

Form: (DEFPARAMETER *SOCKET-1* (SHOW (SOCKET-CONNECT (SOCKET-SERVER-PORT 
*SERVER*) "localhost" :TIMEOUT 0)))
CORRECT: *SOCKET-1*
CLISP  : ERROR
OS-ERROR(6): Device not configured
OUT:
"[OS-ERROR]: OS-ERROR(6): Device not configured
"

revision 15861 == newwest from hg

Clean build in new directory
./configure --with-libsigsegv-prefix=/usr/local/ 
--with-libreadline-prefix=/usr/local/opt/readline/ 
--with-libiconv-prefix=/Users/karstenpoeck/clisphg/tools/libiconv-1.14/ 
--with-libffcall-prefix=/usr/local/ --cbc 20170320


karstenoecksMBP:20170320 karstenpoeck$ ./lisp.run -M lispinit.mem -B . 
--version
GNU CLISP 2.49.50+ (2017-03-30) (built 3699001648) (memory 3699001922)
Software: GNU C 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1)
gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wreturn-type 
-Wmissing-declarations -Wimplicit -Wno-sign-compare 
-Wno-format-nonliteral -Wno-shift-negative-value -O -fwrapv 
-fno-strict-aliasing -DUNIX_BINARY_DISTRIB -DENABLE_UNICODE 
-DDYNAMIC_FFI -DDYNAMIC_MODULES -DNO_GETTEXT  libgnu.a 
-L/usr/local/opt/readline//lib -lreadline -lncurses 
/usr/local//lib/libavcall.a /usr/local//lib/libcallback.a 
/usr/local//lib/libsigsegv.a -lc  -L/usr/X11/lib
SAFETY=0 TYPECODES WIDE_HARD GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED 
TRIVIALMAP_MEMORY
libsigsegv 2.11
libreadline 7.0
libffcall 1.13
Features: (LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL 
INTERPRETER LOGICAL-PATHNAMES SOCKETS GENERIC-STREAMS SCREEN FFI UNICODE 
BASE-CHAR=CHARACTER WORD-SIZE=64 UNIX MACOS)
C Modules: (clisp)
Installation directory: /Users/karstenpoeck/lisp/compiler/clisphg/20170320/
User language: ENGLISH
Machine: X86_64 (X86_64) karstenoecksmbp.fritz.box [192.168.178.41]

Darwin karstenoecksMBP.fritz.box 16.4.0 Darwin Kernel Version 16.4.0: 
Thu Dec 22 22:53:21 PST 2016; root:xnu-3789.41.3~3/RELEASE_X86_64 x86_64
karstenoecksMBP:clisphg karstenpoeck$

I have build nearly daily with hg tip 2 weeks, error did not happen in 
last 12 versions.

Last version where make check works for me (built on 2017-03-18 with 
threads, on 2017-03-16 w/o threads:

karstenoecksMBP:clisphg karstenpoeck$ clisp --version
GNU CLISP 2.49+ (2010-07-17) (built 3698688410) (memory 3698690328)
Software: GNU C 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1)
gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wreturn-type 
-Wmissing-declarations -Wimplicit -Wno-sign-compare 
-Wno-format-nonliteral -Wno-shift-negative-value -O -fwrapv 
-fno-strict-aliasing -DUNIX_BINARY_DISTRIB -DENABLE_UNICODE 
-DDYNAMIC_FFI -DDYNAMIC_MODULES -DNO_GETTEXT  libgnu.a 
-L/usr/local/opt/readline//lib -lreadline -lncurses 
/usr/local//lib/libavcall.a /usr/local//lib/libcallback.a 
/usr/local//lib/libsigsegv.a -lc  -L/usr/X11/lib
SAFETY=0 TYPECODES WIDE_HARD GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED 
TRIVIALMAP_MEMORY
libsigsegv 2.11
libreadline 7.0
libffcall 1.13
Features: (READLINE REGEXP WILDCARD SYSCALLS I18N LOOP COMPILER CLOS MOP 
CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER LOGICAL-PATHNAMES SOCKETS 
GENERIC-STREAMS SCREEN FFI UNICODE BASE-CHAR=CHARACTER WORD-SIZE=64 UNIX 
MACOS)
C Modules: (clisp i18n syscalls regexp readline)
Installation directory: /usr/local/lib/clisp-2.49+/
User language: ENGLISH
Machine: X86_64 (X86_64) karstenoecksmbp.fritz.box [192.168.178.41]

Re: TEST_NT hack and OpenBSD

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

Hi,

>     newer(){ echo 'test -f $$m/'$1' -a $$m/'$1' -nt $@/'$2; }
>I've now replaced this use of an unportable shell primitive with a small auxiliary program.

Recently I saw a use of 'find' to compare dates of 2 files!

Alas, I have no idea how portable find's -maxdepth 0 option is
$ find foo -maxdepth 0 -newer bar -ls
So maybe an old-fashioned prune is the better option?
$ find foo -prune -newer bar -ls

Linux and OSX document maxdepth. However, the section on standards conformance in
a Linux manpage mentions -prune, not -maxdepth. This HP-UX manpage does not document -maxdepth
http://nixdoc.net/man-pages/HP-UX/find.1.html

Is there really a need to add 1000 lines of code to the repository and several new tests and gnulib modules *just for the utilities*, not even the actual program, just to compare dates?

Here's what looks like logic that should work across 40 years of UNIXisms

newer(){ [ -f "$1" ] && ([ ! -e "$2" ] || test -n "`find "$1" -prune -newer "$2"`"); }

Regards,
	Jörg

Re: [PATCH 1/2] More parallel make -j4 fixes for txt

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

Hi Reini,

>     README, README.de, README.es, clisp.c, ... all clash
>     with parallel builds using the same intermediate
>     txt binaries and txt.c sources.
>     Rename them.
> 
>     Use a $(( $i + 1 )) shell function, which should be portable across
>     all shells.
>     See https://github.com/rurban/clisp/issues/1

Thanks, I applied this with modifications:
  1. No, $(( $i + 1 )) is not portable shell syntax. The portable shell
     syntax is `expr $i + 1`.
     For portable shell syntax, always reference the chapter
     "Portable Shell Programming" [1].
  2. Here too, I like a more descriptive name: 'gen-foo.c', not 'txt4.c'.
     (The original code did not do this, because it was bound to Windows 8+3
     file name limitations, and 'gen-README.de.c' was an invalid file name
     in that environment.)

Bruno

[1] https://www.gnu.org/software/autoconf/manual/autoconf.html#Portable-Shell