clisp-devel — closed list for developers and testers

Re: status update

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

Ok, here comes the final GSoC status report. Unfortunately, I did not
reach the goal of working (building and passing tests) code on the
major platforms.

I made changes to

 * switch the build system to use the autotools. This is not
   complete. The runtime and memory image get build, as well as the
   clisp "-K dispatcher" executable (all on linux). There's still a
   lot of configuration happening inside the source code (which should
   be done by configure), and not all the required configure tests are
   run (testing for termios, for example). More importantly clisp-link
   is missing support for dynamic module generation and is not yet
   used, thus no acutal linking sets are produced (no base,
   full). Also clisp.h is not yet generated.

 * update the gnulib code used by the runtime. This is halfway done,
   depends mostly on solving the configuration related issues above.

 * update the modules to use up to date gnulib code. This is done for
   rawsock and regexp. They also work with "pre-autotools clisp" and
   also on windows, thus these changes could be used on top of the
   current repo state.

 * update the asdf module. This is done.

 * add a new libmagic module. This is mostly done, but only exports a
   limited subset of the available functions.

 * add new gnulib modules to extend the features of rawsock on windows. I
   had to throw away a lot of code here, the WinAPI is not always
   doing what its documentation claims to do.


To continue the switch to autotools needs to be completed. This means
going through the code, determining what configurations are done
(mostly in lispbibl.d, but also other files and the src/m4 directory)
and add them in as appropriate.


Not reaching the goal of a new release is a big disappointment for me,
but I guess the delay due to my illness was just to much to be able to
complete all the work that needed to be done.


I had a lot of fun working on CLISP, and intend to do so in the
future. Thank you all a lot for your help throughout this summer! :)

(On top of all I'm fighting with an unstable internet connection atm,
I put up the autotools work hopefully in some hours)

Re: status update

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

> * Daniel Jour <qnavry.bregjvt@tznvy.pbz> [2016-08-16 02:39:14 +0200]:
>
>> Are you prepared to make a release?
>
> Almost, but not yet. Unfortunately.
>

Time is up (pretty much).

Where do we stand now?

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1404
http://www.childpsy.net/ http://openvotingconsortium.org http://truepeace.org
http://dhimmi.org http://islamexposedonline.com http://thereligionofpeace.com
Save time: send elected officials to jail directly, bypassing the office.

Re: status update

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

> Are you prepared to make a release?

Almost, but not yet. Unfortunately.

I really hope to get my work releaseable within the next (few)
days. I'm making good progress, but the delay from the midterm and
more seriously from the time when I was ill are definitely an issue.

Ahead of me is still some "configuration/detection" that happens
outside of autoconf (mostly in lispbibl.d) as well as the integration
of some gnulib modules (I "started" without any gnulib module, and
added them back as necessary, removing the then superfluous platform
dependent code from CLISP's source files).

What's - at least related to the autotools - still very hacky / not
reliably working is clisp-link.

clisp-cvs Digest, Vol 72, Issue 1

[<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: * modules/clx/new-clx/demos/clx-demos.lisp: require
      CLX (cli...@li...)
   2. clisp: (faq-help): mention StackOverflow
      (cli...@li...)
   3. clisp: Avoid startup errors when the user has weird ~/.clisp
      (cli...@li...)
   4. clisp: * modules/asdf/asdf.lisp: upgrade to 2.33
      (cli...@li...)
   5. clisp: * src/m4/termcap.m4 (CL_TERMCAP): also look for
      tgetent i... (cli...@li...)
   6. clisp: remove obsolete code
      (cli...@li...)
   7. clisp: Fix bug#668 posix:file-state always return NIL for
      :rdev (cli...@li...)
   8. clisp: minor fixes in sorttest.lisp
      (cli...@li...)
   9. clisp: update SF tracker links
      (cli...@li...)
  10. clisp: convert tracker references to the new format
      (cli...@li...)
  11. clisp: fix compilation of bindings/glibc
      (cli...@li...)
  12. clisp: (clisp-repo-p): update for the new HG root (SF
      infrastruc... (cli...@li...)
  13. clisp: fix build of the asdf module
      (cli...@li...)
  14. clisp: system::simple-os-error --> ext:os-error to finish the
      20... (cli...@li...)
  15. clisp: src/package.d (intern): cerror_package_locked can
      trigger GC (cli...@li...)
  16. clisp: clisp.podval.org --> clisp.org/beta
      (cli...@li...)


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

Message: 1
Date: Fri, 08 Feb 2013 19:30:14 +0000
From: cli...@li...
Subject: clisp: * modules/clx/new-clx/demos/clx-demos.lisp: require
	CLX
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/6c160a19948d
changeset: 15605:6c160a19948d9ffd929afbea5b392866e15c990b
user:      Sam Steingold <sd...@po...>
date:      2013-02-08 14:29:52 -0500
description:
* modules/clx/new-clx/demos/clx-demos.lisp: require CLX

diffstat:

 modules/clx/new-clx/demos/README         |  2 +-
 modules/clx/new-clx/demos/clx-demos.lisp |  4 +++-
 src/ChangeLog                            |  4 ++++
 3 files changed, 8 insertions(+), 2 deletions(-)



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

Message: 2
Date: Sun, 14 Apr 2013 21:59:20 +0000
From: cli...@li...
Subject: clisp: (faq-help): mention StackOverflow
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/9070e09f4ab9
changeset: 15606:9070e09f4ab98ebd5a94a06002507a022120c896
user:      Sam Steingold <sd...@po...>
date:      2013-04-14 17:45:21 -0400
description:
(faq-help): mention StackOverflow

diffstat:

 doc/faq.xml |  6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)



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

Message: 3
Date: Sun, 14 Apr 2013 21:59:22 +0000
From: cli...@li...
Subject: clisp: Avoid startup errors when the user has weird ~/.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/527b7fdc5332
changeset: 15607:527b7fdc5332962c897227a557391a89b05df225
user:      Sam Steingold <sd...@po...>
date:      2013-04-14 17:56:08 -0400
description:
Avoid startup errors when the user has weird ~/.clisp
* pathname.d, subr.d (PROBE-PATHNAME): accept &key (:error t)
* spvw.d (main_actions): pass :ERROR NIL to PROBE-PATHNAME

diffstat:

 doc/impbody.xml |   8 +++++---
 src/ChangeLog   |   6 ++++++
 src/pathname.d  |  11 ++++++++---
 src/spvw.d      |   3 ++-
 src/subr.d      |   2 +-
 5 files changed, 22 insertions(+), 8 deletions(-)



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

Message: 4
Date: Sun, 14 Apr 2013 21:59:23 +0000
From: cli...@li...
Subject: clisp: * modules/asdf/asdf.lisp: upgrade to 2.33
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/97c19a70b668
changeset: 15608:97c19a70b668d87c169342db3eb9dd557e22fefd
user:      Sam Steingold <sd...@po...>
date:      2013-04-14 17:59:02 -0400
description:
* modules/asdf/asdf.lisp: upgrade to 2.33

diffstat:

 modules/asdf/asdf.lisp |  12991 ++++++++++++++++++++++++++++++++++------------
 src/ChangeLog          |      4 +
 2 files changed, 9507 insertions(+), 3488 deletions(-)



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

Message: 5
Date: Sun, 11 May 2014 06:03:37 +0000
From: cli...@li...
Subject: clisp: * src/m4/termcap.m4 (CL_TERMCAP): also look for
	tgetent i...
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/0334c6afdcc8
changeset: 15609:0334c6afdcc82a822a7816deed1f63deed1535fa
user:      Sam Steingold <sd...@po...>
date:      2014-05-11 01:59:38 -0400
description:
* src/m4/termcap.m4 (CL_TERMCAP): also look for tgetent in tinfo;

fixes bug#665 as suggested by Jason Miller <jas...@us...>

diffstat:

 src/ChangeLog     |  5 +++++
 src/m4/termcap.m4 |  4 ++--
 2 files changed, 7 insertions(+), 2 deletions(-)



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

Message: 6
Date: Sun, 11 May 2014 06:03:39 +0000
From: cli...@li...
Subject: clisp: remove obsolete code
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/cd4c963a9505
changeset: 15610:cd4c963a9505fe53d47de2f9753fa1f7c2be63a2
user:      Sam Steingold <sd...@po...>
date:      2014-05-11 02:03:09 -0400
description:
remove obsolete code

diffstat:

 emacs/d-mode.el |  12 +++---------
 1 files changed, 3 insertions(+), 9 deletions(-)



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

Message: 7
Date: Wed, 22 Oct 2014 16:04:22 +0000
From: cli...@li...
Subject: clisp: Fix bug#668 posix:file-state always return NIL for
	:rdev
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/5c63938ef493
changeset: 15611:5c63938ef493e06b089fd6868293f39496413b78
user:      Sam Steingold <sd...@po...>
date:      2014-10-22 12:04:12 -0400
description:
Fix bug#668 posix:file-state always return NIL for :rdev

* modules/syscalls/configure.in: check for struct stat members

diffstat:

 modules/syscalls/configure.in |  5 ++++-
 src/ChangeLog                 |  5 +++++
 2 files changed, 9 insertions(+), 1 deletions(-)



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

Message: 8
Date: Sun, 31 May 2015 04:56:54 +0000
From: cli...@li...
Subject: clisp: minor fixes in sorttest.lisp
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/d3f6e80fb705
changeset: 15612:d3f6e80fb70517240edc5e079b2e96811112e22c
user:      Sam Steingold <sd...@po...>
date:      2015-05-31 00:56:01 -0400
description:
minor fixes in sorttest.lisp

diffstat:

 doc/impext.xml |  6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)



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

Message: 9
Date: Mon, 08 Aug 2016 23:30:44 +0000
From: cli...@li...
Subject: clisp: update SF tracker links
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/164fc33f70e5
changeset: 15613:164fc33f70e5fc39a2691f14e135fdfe5564a794
user:      Sam Steingold <sd...@po...>
date:      2016-08-08 19:30:32 -0400
description:
update SF tracker links

diffstat:

 doc/common.xsl |  4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)



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

Message: 10
Date: Wed, 10 Aug 2016 21:49:53 +0000
From: cli...@li...
Subject: clisp: convert tracker references to the new format
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/04ced6d61510
changeset: 15614:04ced6d61510294320ac60b296ca81a65caca566
user:      Sam Steingold <sd...@po...>
date:      2016-08-10 17:42:26 -0400
description:
convert tracker references to the new format

diffstat:

 Makefile.devel               |    2 +-
 doc/Makefile                 |    2 +-
 doc/clisp.xml.in             |    2 +-
 doc/faq.xml                  |   10 +-
 emacs/misc.el                |   67 ++++-
 modules/clx/new-clx/clx.f    |    4 +-
 modules/clx/new-clx/test.tst |   10 +-
 modules/regexp/test.tst      |    2 +-
 modules/syscalls/calls.c     |    4 +-
 modules/syscalls/posix.lisp  |    4 +-
 src/ChangeLog                |  665 +++++++++++++++++++++---------------------
 src/NEWS                     |  246 +++++++--------
 src/TODO                     |   22 +-
 src/clisp-link.in            |    3 +-
 src/clos-class3.lisp         |    2 +-
 src/clos-genfun3.lisp        |    2 +-
 src/compiler.lisp            |    3 +-
 src/eval.d                   |    2 +-
 src/intread.d                |    3 +-
 src/lispbibl.d               |   17 +-
 src/makemake.in              |    4 +-
 src/pathname.d               |    2 +-
 src/reploop.lisp             |    4 +-
 src/savemem.lisp             |    2 +-
 src/socket.d                 |    2 +-
 src/stream.d                 |    2 +-
 tests/ChangeLog              |  140 ++++----
 tests/clos.tst               |    8 +-
 tests/conditions.tst         |    8 +-
 tests/encoding.tst           |    8 +-
 tests/eval20.tst             |    2 +-
 tests/excepsit.tst           |    6 +-
 tests/ext-clisp.tst          |    2 +-
 tests/ffi.tst                |    4 +-
 tests/format.tst             |    8 +-
 tests/hash-classes.lisp      |    2 +-
 tests/iofkts.tst             |   20 +-
 tests/lambda.tst             |    2 +-
 tests/listeners.lisp         |    2 +-
 tests/loop.tst               |   12 +-
 tests/macro8.tst             |   54 +-
 tests/mop.tst                |    8 +-
 tests/number2.tst            |   14 +-
 tests/pack11.tst             |    2 +-
 tests/path.tst               |   10 +-
 tests/restarts.tst           |    2 +-
 tests/setf.tst               |    6 +-
 tests/socket.tst             |    8 +-
 tests/steele7.tst            |    2 +-
 tests/streams.tst            |   16 +-
 tests/streamslong.tst        |    6 +-
 tests/symbols.tst            |    2 +-
 tests/type.tst               |    2 +-
 utils/modprep.lisp           |    2 +-
 54 files changed, 754 insertions(+), 692 deletions(-)



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

Message: 11
Date: Thu, 11 Aug 2016 19:21:44 +0000
From: cli...@li...
Subject: clisp: fix compilation of bindings/glibc
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/699e5648fc96
changeset: 15615:699e5648fc961ed32ed2886692b4a508e807af3d
user:      Sam Steingold <sd...@po...>
date:      2016-08-11 15:04:05 -0400
description:
fix compilation of bindings/glibc

* modules/bindings/glibc/linux.lisp: avoid
error: "Never use <bits/ipctypes.h> directly; include <sys/ipc.h> instead."
by including <sys/ipc.h> instead of <bits/ipctypes.h>

diffstat:

 modules/bindings/glibc/linux.lisp |  2 +-
 src/ChangeLog                     |  6 ++++++
 2 files changed, 7 insertions(+), 1 deletions(-)



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

Message: 12
Date: Thu, 11 Aug 2016 19:21:45 +0000
From: cli...@li...
Subject: clisp: (clisp-repo-p): update for the new HG root (SF
	infrastruc...
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/22befbd39746
changeset: 15616:22befbd39746e693422a59e1223a3b22ae923f02
user:      Sam Steingold <sd...@po...>
date:      2016-08-11 15:04:33 -0400
description:
(clisp-repo-p): update for the new HG root (SF infrastructure change)

diffstat:

 emacs/misc.el |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)



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

Message: 13
Date: Thu, 11 Aug 2016 19:21:46 +0000
From: cli...@li...
Subject: clisp: fix build of the asdf module
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/52549db66080
changeset: 15617:52549db660801e4f01c8a564335b9a646ea9e603
user:      Sam Steingold <sd...@po...>
date:      2016-08-11 15:17:58 -0400
description:
fix build of the asdf module

* src/makemake.in (make_modules): create separate targets for base and
full modules because the former are compiled using the boot
linking set, while the latter (e.g., asdf) require the base linking set

diffstat:

 src/ChangeLog   |   6 ++++
 src/makemake.in |  70 ++++++++++++++++++++++++++++++--------------------------
 2 files changed, 44 insertions(+), 32 deletions(-)



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

Message: 14
Date: Fri, 12 Aug 2016 22:41:07 +0000
From: cli...@li...
Subject: clisp: system::simple-os-error --> ext:os-error to finish the
	20...
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/8b07139562f3
changeset: 15618:8b07139562f334f21fde8869c3869c8ac309bc40
user:      Sam Steingold <sd...@po...>
date:      2016-08-11 18:45:24 -0400
description:
system::simple-os-error --> ext:os-error to finish the 2011-08-19 patch eafb54143f18 (use OS facilities to print os-error)

diffstat:

 modules/syscalls/test.tst |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)



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

Message: 15
Date: Fri, 12 Aug 2016 22:41:08 +0000
From: cli...@li...
Subject: clisp: src/package.d (intern): cerror_package_locked can
	trigger GC
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/2b77edee4b07
changeset: 15619:2b77edee4b07f4883bafcd706bb94d137868a7d8
user:      Sam Steingold <sd...@po...>
date:      2016-08-11 18:53:11 -0400
description:
src/package.d (intern): cerror_package_locked can trigger GC

diffstat:

 src/ChangeLog    |  4 ++++
 src/package.d    |  2 +-
 tests/pack11.tst |  7 +++++++
 3 files changed, 12 insertions(+), 1 deletions(-)



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

Message: 16
Date: Fri, 12 Aug 2016 22:41:10 +0000
From: cli...@li...
Subject: clisp: clisp.podval.org --> clisp.org/beta
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/fe10e785a294
changeset: 15620:fe10e785a2941ec2899913091f57d7bca9a87f97
user:      Sam Steingold <sd...@po...>
date:      2016-08-11 20:24:08 -0400
description:
clisp.podval.org --> clisp.org/beta

diffstat:

 Makefile.devel  |  2 +-
 doc/faq.xml     |  2 +-
 src/makemake.in |  3 +--
 src/spvw.d      |  2 +-
 4 files changed, 4 insertions(+), 5 deletions(-)



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

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev

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

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


End of clisp-cvs Digest, Vol 72, Issue 1
****************************************

Re: status update

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

> * Daniel Jour <qnavry.bregjvt@tznvy.pbz> [2016-07-04 14:08:17 +0200]:
>
> Sam wrote:
>> Congratulations, you pass the midterm evaluation.
>
> Thank you :)

You are welcome.

Next Monday, August 15, the final evaluation starts.

Are you prepared to make a release?

Thanks.

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 16.04 (xenial) X 11.0.11803000
http://www.childpsy.net/ http://americancensorship.org
http://think-israel.org http://truepeace.org http://memri.org
Only adults have difficulty with child-proof caps.

Re: WIDE_AUXI

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

Daniel, Sam,

> > *) Is WIDE_AUXI still in use / of interest? It was introduced
> >  2002-12-04 by Bruno, but as far as I can tell won't get used unless
> >  explicitly requested during configure via setting -D WIDE_AUXI in
> >  CFLAGS.
> 
> I have no idea why Bruno introduced it (we already have WIDE_SOFT).

I think it had two purposes:
  - It was an experiment, to help developing the WIDE_SOFT memory model.
    For example, if a gcc bug or GC bug was hampering WIDE_SOFT, to
    see whether it occurred also with the (less demanding) WIDE_AUXI.
  - It has immediate (= not heap-allocated) single-floats, so it could
    be useful for numerical programs that use single-floats on 32-bit
    platforms.
    But such numerical programs more often use double-floats, and
    nowadays 64-bit platforms are the norm.

> Unless he explains, I think we can discard it.

Yes you can discard it.

Bruno

Re: status update

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

Hi,

> * Daniel Jour <qnavry.bregjvt@tznvy.pbz> [2016-08-08 02:30:01 +0200]:
>
> *) Is WIDE_AUXI still in use / of interest? It was introduced
>  2002-12-04 by Bruno, but as far as I can tell won't get used unless
>  explicitly requested during configure via setting -D WIDE_AUXI in
>  CFLAGS.

I have no idea why Bruno introduced it (we already have WIDE_SOFT).
Unless he explains, I think we can discard it.

> *) Bug report numbers. At various places in the code there are bug
>  report numbers (like 710737, lispbibl.d, "Global register
>  declarations"). I guess these numbers are from an abandoned bug
>  tracker? Is there a backup of these bug reports somewhere? (I'm
>  mostly just curious, there's no real need for these reports atm.)

These numbers refer to the old SF bug tracker.
See emacs/misc.el:clisp-bug-reference-url-format for a hint on how to
convert those numbers to the new ones.

> *) intparam.h, floatparam.h: Instead of creating these headers during
> the build, I just wrote them using standard (C99) features (for
> example FLT_MANT_DIG from float.h).

Whatever you find easy to maintain.

> This makes cross-building much easier (did it even work before?).

I am sure it did :-)

> One thing that surprised me was that intparam.h contains endianness
> defines for each of short, int, long and long long. Since all these
> defines get "merged" into a single BIG_ENDIAN_P define, I guess
> systems with different endianness for different sized integer types
> are no longer supported? (Did we actually support such systems, like
> the PDP-11, at some point?)

You would be surprised by the zoo of systems once supported by CLISP.

> *) Not GSoC related: If I understood this correctly, the math code
>  backing CLISPs number system has at some point been extracted as a
>  library, CLN (http://www.ginac.de/CLN/). Would it make sense to
>  "throw out" our math code and to use that library instead? Looking at
>  its code it has probably seen massive rewrites: It's now written in
>  C++. It seems to be actively maintained and suitable for an ANSI CL
>  number system.

It might.

Note that all these issues should be postponed until AFTER you make the
release.
The ONLY focus of the release is making it work on all 3 major platforms
OOTB.



-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 16.04 (xenial) X 11.0.11803000
http://www.childpsy.net/ http://camera.org http://memri.org
http://openvotingconsortium.org http://thereligionofpeace.com
Sufficiently advanced stupidity is indistinguishable from malice.

Re: status update

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

Hi,

> Thanks Daniel, get well soon!

Thank you, it's getting better, I hope to be back to full health soon.

Quick questions:

*) Is WIDE_AUXI still in use / of interest? It was introduced
 2002-12-04 by Bruno, but as far as I can tell won't get used unless
 explicitly requested during configure via setting -D WIDE_AUXI in
 CFLAGS.

*) Bug report numbers. At various places in the code there are bug
 report numbers (like 710737, lispbibl.d, "Global register
 declarations"). I guess these numbers are from an abandoned bug
 tracker? Is there a backup of these bug reports somewhere? (I'm
 mostly just curious, there's no real need for these reports atm.)

*) intparam.h, floatparam.h: Instead of creating these headers during
 the build, I just wrote them using standard (C99) features (for
 example FLT_MANT_DIG from float.h). This makes cross-building much
 easier (did it even work before?). One thing that surprised me was
 that intparam.h contains endianness defines for each of short, int,
 long and long long. Since all these defines get "merged" into a
 single BIG_ENDIAN_P define, I guess systems with different endianness
 for different sized integer types are no longer supported? (Did we actually
 support such systems, like the PDP-11, at some point?)

*) Not GSoC related: If I understood this correctly, the math code
 backing CLISPs number system has at some point been extracted as a
 library, CLN (http://www.ginac.de/CLN/). Would it make sense to
 "throw out" our math code and to use that library instead? Looking at
 its code it has probably seen massive rewrites: It's now written in
 C++. It seems to be actively maintained and suitable for an ANSI CL
 number system.

Best,
Daniel

Re: status update

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

Thanks Daniel, get well soon!

On Wed, Aug 3, 2016 at 7:03 PM, Daniel Jour <dan...@gm...> wrote:
> Hi Sam,
>
>> It has been almost a month(!) without any updates.
>
> I'm very sorry for not contacting you earlier: I'm having health
> issues since about 3 weeks (not minor, but hopefully and probably not
> major issues). This significantly limited the amount of work I was
> able to do, and - although it gets better - still forces me to take
> little steps.
>
>
>> Are you still working on CLISP?
>
> Yes. Though due to the above I'm only slowly making progress :( I'm
> still working on switching the configuration to an autotools based
> system, as well as porting network related code to Windows. I've also
> updated gnulib code (for all of CLISP): This is not yet building, but
> already showed me which parts of CLISP will need to be adjusted. (I
> know where the incompabilities are and how to fix most of them, but
> did not yet fix them.)
>
>
> Since I now receive (better than before) medical treatment I really
> hope for a fast recovery. I'll know more tomorrow.
>
>
> Best,
> Daniel



-- 
Sam Steingold <http://sds.podval.org> <http://www.childpsy.net/>

Re: status update

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

Hi Sam,

> It has been almost a month(!) without any updates.

I'm very sorry for not contacting you earlier: I'm having health
issues since about 3 weeks (not minor, but hopefully and probably not
major issues). This significantly limited the amount of work I was
able to do, and - although it gets better - still forces me to take
little steps.


> Are you still working on CLISP?

Yes. Though due to the above I'm only slowly making progress :( I'm
still working on switching the configuration to an autotools based
system, as well as porting network related code to Windows. I've also
updated gnulib code (for all of CLISP): This is not yet building, but
already showed me which parts of CLISP will need to be adjusted. (I
know where the incompabilities are and how to fix most of them, but
did not yet fix them.)


Since I now receive (better than before) medical treatment I really
hope for a fast recovery. I'll know more tomorrow.


Best,
Daniel

Re: status update

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

Hi Daniel,

> * Daniel Jour <qnavry.bregjvt@tznvy.pbz> [2016-07-04 14:08:17 +0200]:
> Sam wrote:
>
>> Please keep sending updates a couple of times a week.
>
> Please excuse that it's already a week since my last mail. I tried to
> only send an update when some subtaks is finished, but I'll switch to
> keeping you better informed about what I'm doing (even if it's not yet
> finished).

It has been almost a month(!) without any updates.
Are you still working on CLISP?
Thanks

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 16.04 (xenial) X 11.0.11803000
http://www.childpsy.net/ http://www.memritv.org http://openvotingconsortium.org
http://think-israel.org http://www.dhimmitude.org http://iris.org.il
My name is Deja Vu. Have we met before?

Re: status update

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

Sam wrote:
> Congratulations, you pass the midterm evaluation.

Thank you :)


> Now, please note that you really are behind the schedule.  You need
> to polish your fixes to rawsock, get your new modules accepted to
> gnulib, finish converting clisp to use autotools throughout, and
> make a release.

I'm currently working on getting the new modules ready for submission
to gnulib. The m4/autoconf code is the hardest part here (I haven't
written that much of m4 before).

More specifically, I:

* wrote an ifaddrs.h module for gnulib

* wrote an getifaddrs module (implementing functions from above
 header) for gnulib, initially using WSAIoctl, just to learn that this
 happily returns an empty list of interfaces without any indication of
 failure most of the time, so I rewrote it to use GetAdaptersAddresses
 instead.

* am writing a gnulib module to implement if_nameindex (and related
  functions) on mingw/Windows.

It also took me some time to understand why AC_SEARCH_LIBS isn't
working with Windows dlls/libs: The "stdcall" calling convention
decorates (function) symbols with the number of bytes used by the
arguments on the stack; but the autoconf macro generates an
declaration (with cdecl calling convention) like

char some_function();

so the test always fails with a linker error.


> (note that your tar ball is missing version number :-)

You mean because it still reads "2.49+" and not yet 2.5?


> Please keep sending updates a couple of times a week.

Please excuse that it's already a week since my last mail. I tried to
only send an update when some subtaks is finished, but I'll switch to
keeping you better informed about what I'm doing (even if it's not yet
finished).

Re: testing a new Clisp Windows installer

[Wolfgang D. <wol...@da...>]

On 2016-06-29 13:14, Joe...@t-... wrote:
> This is not the correct reason. CLISP uses FP instructions
> [...]
> I believe CLISP predates the GMP library. IIRC, Bruno extracted the
> bignum and perhaps FP code out of CLISP to produce some math library,
> but I think that library is not GMP but has another name (CLN?).

Thanks for the answers, I updated
http://maxima.sourceforge.net/lisp.html today, so that the info about
Clisp is (hopefully) correct.

There is a discussion, that a new Maxima version will be released soon
and I usually build a (CLISP (and SBCL) based) Windows installer - how
far is a new Windows build /release for CLISP? It was build now as part
of a GSOC project, right?

Best regards, Wolfgang

Re: testing a new Clisp Windows installer

[Raymond T. <toy...@gm...>]

>>>>> "Wolfgang" == Wolfgang Dautermann <wol...@da...> writes:

    Wolfgang> On 2016-06-29 21:20, Pascal J. Bourguignon wrote:
    >> See Joerg's answers.

    Wolfgang> Yes, thank you. I can change the text. Would the following be okay - and
    Wolfgang> correct?

    Wolfgang> -----------------------------------------------------------------
    Wolfgang> Clisp
    Wolfgang> -----
    Wolfgang> Clisp includes GNU readline support, so Maxima has advanced command-line
    Wolfgang> editing facilities when built with it.

Readline is optional; I sometimes forget to enable it and compile
clisp to include such support. (Or because I don't have the right
libraries already installed or whatever.)

    Wolfgang> Clisp is compiled to bytecodes, so Maxima running on Clisp is
    Wolfgang> substantially slower than on Lisps compiled to machine instructions.

My personal opinion: I wouldn't make such a blanket statement; it
really depends on what you're doing.  Number crunching is slow, yes,
but I suspect clisp on symbolic stuff is pretty good.  (The testsuite
does a lot of numerics so it's not a great test.)  For bignum work,
clisp is as fast as or faster than other lisps that compile to native
code.

--
Ray

Re: testing a new Clisp Windows installer

[Wolfgang D. <wol...@da...>]

On 2016-06-29 21:20, Pascal J. Bourguignon wrote:
> See Joerg's answers.

Yes, thank you. I can change the text. Would the following be okay - and
correct?

-----------------------------------------------------------------
Clisp
-----
Clisp includes GNU readline support, so Maxima has advanced command-line
editing facilities when built with it.

Clisp is compiled to bytecodes, so Maxima running on Clisp is
substantially slower than on Lisps compiled to machine instructions.
On the other hand, Clisp contains code from CLN (link to
http://www.ginac.de/CLN/), a library for efficient computations with all
kinds of numbers in arbitrary precision.

Clisp is very portable, there are Clisp implementations for many
platforms including MS Windows and Unix-like systems.
------------------------------------------------------------------

> Does maxima use long-float and if yes, does it use (setf
> ext:long-float-digits) to set the wanted precision (possibly big)?

I do not know very much about Maxima's internals, sorry.

> If it only uses single-float and double-float, then it's done in 
> hardware.

One can use double precision and arbitrary precision floats:

(%i1) sqrt(2),numer; /* compute sqrt(2) numerically as double */
(%o1)                          1.414213562373095
(%i2) fpprec:60$     /* set the precision for bloats to 60 digits */
(%i3) bfloat(sqrt(2)); /* compute sqrt(2) as a bigfloat (bfloat) */
(%o3)   1.41421356237309504880168872420969807856967187537694807317668b0

I assume, that the first may be done in hardware. But as Jörg pointed
out, the bytecode of calculating large expressions may be slow.

Thanks for all the answers and very fine, that Clisp development is
going on.

Best regards, Wolfgang

(Is there a way, that Clisp may produce machine code instead of
bytecode, to speed it up? There seem to be the possibility to use a
just-in-time-compiler (lightning) - does that work? If so, perhaps one
of the next releases may have enabled it by default?)

Re: testing a new Clisp Windows installer

[Raymond T. <toy...@gm...>]

>>>>> "Pascal" == Pascal J Bourguignon <pj...@in...> writes:

    Pascal> Wolfgang Dautermann <wol...@da...> writes:

[snip]

    Pascal> Does maxima use long-float and if yes, does it use
    Pascal> (setf ext:long-float-digits) to set the wanted precision (possibly big)?

Maxima can use long-floats (and double-doubles), but I don't think
anyone actually builds maxima to use that ability.  I'm pretty sure
none of the installers enable it and wouldn't be surprised if that
code no longer works.

--
Ray

Re: testing a new Clisp Windows installer

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

Wolfgang Dautermann <wol...@da...> writes:

> Hi all,
> I would also be interested in testing a new Clisp Windows (pre)release.
>
> I am a member of the Maxima-Team (Maxima is a CAS written in Common
> Lisp) and my main contribution is, that I create (crosscompiled)
> Windows-Installers for Maxima (for the 'crosscompiliation' for Lisp
> based programs I use Wine, which works well).
>
> I did start with Clisp as supported Lisp, now I also support SBCL. Clisp
> is slower, but - in my opinon - more hassle-free, it is still the
> default Lisp in my installers.
>
> So I am *certainly* interested in testing a new Clisp release for
> Windows - if it does work with my crosscompilation procedure. (If
> possible, both a 32 and a 64 bit version). [For the creation of my
> installer just a ZIP-File is easy to use, that was one of the reasons, I
> did start with Clisp (the other reason was, that it worked well with Wine)].
>
>
> Some more questions:
> Clisp is much slower than other Lisp implementations. On the Maxima
> website http://maxima.sourceforge.net/lisp.html
> there are some notes about the reasons (I am not sure, if they are correct):
>
> "Clisp is compiled to bytecodes, so Maxima running on Clisp is
> substantially slower than on Lisps compiled to machine instructions.
> Clisp computes floating-point operations in software, so floating-point
> operations in Clisp are much slower than in Lisp implementations that
> use hardware instructions for floating-point operations. On the other
> hand, Clisp makes use of the GMP library for arbitrary-precision integer
> computations."
>
> (a) Is "computes floating-point operations in software" correct?
> Nowadays? Can one disable that? I assume most processors can do it in
> hardware now.
> (b) "Clisp makes use of the GMP library" - how can one enable it? I
> compiled Clisp now from Daniels sourcecode, but libgmp seems not be used
> (checked using 'ldd'). And there is no configure-option '--use-libgmp'
> or something similar.

See Joerg's answers.

However, clisp has long-float numbers that can have arbitrary
precision, and therefore are implemented in software.

Does maxima use long-float and if yes, does it use
(setf ext:long-float-digits) to set the wanted precision (possibly big)?

If it only uses single-float and double-float, then it's done in
hardware.

There are also short-float numbers; I don't know how they're
implemented.  Probably they use single-float hardware and truncate the
mantissa on storage.


-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: testing a new Clisp Windows installer

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

Hi,

Wolfgang Dautermann queried:

>(a) Is "computes floating-point operations in software" correct?
>Nowadays? Can one disable that? I assume most processors can do it in
>hardware now.

This is not the correct reason. CLISP uses FP instructions (of course it depends
on the compiler switches, but I think the soft-float 68000 Amiga-CLISP version
was the only one where FP was not used at all.)

HOWEVER, Compiling (+ fp1 (* fp2 fp3)) in CLISP produces byte codes for + and *.
Interpreting these *and* drilling down the huge CL number hierarchy to dispatch to
the right addition and multiplication code is MUCH MUCH more overhead than
processing 2 assembly instructions "FMUL fp3, fp2 ->fp0, FADD fp0, fp1 -> fp0" -
which after type checks, is what Lisp compilers to native code produce and run...

>(b) "Clisp makes use of the GMP library" - how can one enable it? I
>compiled Clisp now from Daniels sourcecode, but libgmp seems not be used
>(checked using 'ldd'). And there is no configure-option '--use-libgmp'
>or something similar.

I believe CLISP predates the GMP library. IIRC, Bruno extracted the bignum and
perhaps FP code out of CLISP to produce some math library, but I think that
library is not GMP but has another name (CLN?).
Somebody with better memory, please jump in!

CLISP has always had and used its own math routines. Long ago, they were better
than many other packages, however in 20 years, a lot of effort went into GMP and
other math packages as well, to make them very reliable too.

Regards,
 Jörg höhle

testing a new Clisp Windows installer

[Wolfgang D. <wol...@da...>]

Hi all,
I would also be interested in testing a new Clisp Windows (pre)release.

I am a member of the Maxima-Team (Maxima is a CAS written in Common
Lisp) and my main contribution is, that I create (crosscompiled)
Windows-Installers for Maxima (for the 'crosscompiliation' for Lisp
based programs I use Wine, which works well).

I did start with Clisp as supported Lisp, now I also support SBCL. Clisp
is slower, but - in my opinon - more hassle-free, it is still the
default Lisp in my installers.

So I am *certainly* interested in testing a new Clisp release for
Windows - if it does work with my crosscompilation procedure. (If
possible, both a 32 and a 64 bit version). [For the creation of my
installer just a ZIP-File is easy to use, that was one of the reasons, I
did start with Clisp (the other reason was, that it worked well with Wine)].


Some more questions:
Clisp is much slower than other Lisp implementations. On the Maxima
website http://maxima.sourceforge.net/lisp.html
there are some notes about the reasons (I am not sure, if they are correct):

"Clisp is compiled to bytecodes, so Maxima running on Clisp is
substantially slower than on Lisps compiled to machine instructions.
Clisp computes floating-point operations in software, so floating-point
operations in Clisp are much slower than in Lisp implementations that
use hardware instructions for floating-point operations. On the other
hand, Clisp makes use of the GMP library for arbitrary-precision integer
computations."

(a) Is "computes floating-point operations in software" correct?
Nowadays? Can one disable that? I assume most processors can do it in
hardware now.
(b) "Clisp makes use of the GMP library" - how can one enable it? I
compiled Clisp now from Daniels sourcecode, but libgmp seems not be used
(checked using 'ldd'). And there is no configure-option '--use-libgmp'
or something similar.

Best regards, Wolfgang

status update

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

Hi,

I can test on MS-Windows 7 too (and would be happy to try out a recent clisp), but not before the 11th of July...

Keep up the good work,
	Jörg Höhle

Re: status update

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

Daniel Jour <dan...@gm...> writes:

> Regarding the independent confirmation: I'm a bit afraid that due to
> the lack of remaining time this could be an issue (I don't know how
> many are actively following this conversation). Is another GSoC
> student independent enough? (I was thinking about asking for help on
> the summer of code mailing list .. in order to have someone download
> the source tarbal, build it and send the confirmation to clisp-list.)

I can boot a MS-Windows-7 computer here, so when you have a binary ready
post its URL and I'll try it out on Friday night or Sunday.

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: status update

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

Hi Daniel,

Congratulations, you pass the midterm evaluation.

Now, please note that you really are behind the schedule.
You need to polish your fixes to rawsock, get your new modules
accepted to gnulib, finish converting clisp to use autotools
throughout, and make a release.
(note that your tar ball is missing version number :-)

Please keep sending updates a couple of times a week.

Good luck and thanks!

On Mon, Jun 27, 2016 at 6:06 AM, Daniel Jour <dan...@gm...> wrote:
> Oh my, I've been working on fixing something that's just not fixable
> for the last day (reverse DNS lookup ... doesn't work on my test
> windows machine, not even with nslookup.exe).
>
> Source tarbal:
> https://drive.google.com/file/d/0B303fG5hcio_bzR4SWszcnRoTWM/view?usp=sharing
>
>
>> By that time I need to have an independent confirmation that you
>> built clisp on windows with working rawsock module (that was the
>> condition for the midterm "pass" from the get go).  Please make sure
>> that I do get the confirmation by then.  Sorry if that sounds harsh,
>> but rules are rules.
>
> No problem. I'm a week behind schedule, and there's absolutely nothing
> that you could've done / helped me with to prevent that.
>
> CLISP with rawsock builds on windows, but it's not yet able to pass
> all tests. The core tests hangs when trying to let another CLISP
> instance send data via sockets to itself, but as far as I can see this
> is an issue with the invocation of that second instance.
>
> I removed the reverse DNS lookup from the rawsock tests, that way I
> got the number of errors down to 13. These seem mostly to come from
> the code that is sitting in syscalls module and core CLISP. On another
> windows test machine rawsock tests give a stack overflow when testing
> rawsock errors (the test that starts with "(block foo"), I don't know
> why yet.
>
> Regarding the independent confirmation: I'm a bit afraid that due to
> the lack of remaining time this could be an issue (I don't know how
> many are actively following this conversation). Is another GSoC
> student independent enough? (I was thinking about asking for help on
> the summer of code mailing list .. in order to have someone download
> the source tarbal, build it and send the confirmation to clisp-list.)
>
>
>> what are the changes you had to make to get it working?  it's
>> important that the changes "scale", i.e., a gnulib update does not
>> entail much work.
>
> The changes to rawsock? Not that much, actually. I switched its build
> system to one built with autotools, mostly in order to give it an
> gnulib checkout of its own. I'm writing some gnulib modules to patch
> functionality missing on windows (ifaddrs.h functions atm) so that the
> code in rawsock can be completelty platform independent.
>
> If by "scale" you mean that they can be built upon: Updating gnulib (when,
> for example there's an update in a used module) means running
>
> gnulib-tool --update
>
> in modules/rawsock, followed by
>
> autoreconf --force --install
>
> This is the exact procedure I'm following whenever I've made a change
> to one of the used modules.
>
> Though, atm the code is messy: I copied some parts from core CLISP and
> the syscalls module, although I don't use it. The reason is that both
> core CLISP as well as syscalls are still using the old, not yet
> updated gnulib code. Updating that failed due to the build system not
> being able to "rebuild" itself (the configures target in
> Makefile.devel fails).
>
> Looking at how much time I wasted struggling with the build system I'd
> like to replace it with an "standard" autotools one. I already started
> work on that, it shouldn't be much of an issue.
>
> I'd like to start a discussion about the modules and their
> organization in general, but I'll write that in a separate message
> soon.



-- 
Sam Steingold <http://sds.podval.org> <http://www.childpsy.net/>

Re: status update

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

Oh my, I've been working on fixing something that's just not fixable
for the last day (reverse DNS lookup ... doesn't work on my test
windows machine, not even with nslookup.exe).

Source tarbal:
https://drive.google.com/file/d/0B303fG5hcio_bzR4SWszcnRoTWM/view?usp=sharing


> By that time I need to have an independent confirmation that you
> built clisp on windows with working rawsock module (that was the
> condition for the midterm "pass" from the get go).  Please make sure
> that I do get the confirmation by then.  Sorry if that sounds harsh,
> but rules are rules.

No problem. I'm a week behind schedule, and there's absolutely nothing
that you could've done / helped me with to prevent that.

CLISP with rawsock builds on windows, but it's not yet able to pass
all tests. The core tests hangs when trying to let another CLISP
instance send data via sockets to itself, but as far as I can see this
is an issue with the invocation of that second instance.

I removed the reverse DNS lookup from the rawsock tests, that way I
got the number of errors down to 13. These seem mostly to come from
the code that is sitting in syscalls module and core CLISP. On another
windows test machine rawsock tests give a stack overflow when testing
rawsock errors (the test that starts with "(block foo"), I don't know
why yet.

Regarding the independent confirmation: I'm a bit afraid that due to
the lack of remaining time this could be an issue (I don't know how
many are actively following this conversation). Is another GSoC
student independent enough? (I was thinking about asking for help on
the summer of code mailing list .. in order to have someone download
the source tarbal, build it and send the confirmation to clisp-list.)


> what are the changes you had to make to get it working?  it's
> important that the changes "scale", i.e., a gnulib update does not
> entail much work.

The changes to rawsock? Not that much, actually. I switched its build
system to one built with autotools, mostly in order to give it an
gnulib checkout of its own. I'm writing some gnulib modules to patch
functionality missing on windows (ifaddrs.h functions atm) so that the
code in rawsock can be completelty platform independent.

If by "scale" you mean that they can be built upon: Updating gnulib (when,
for example there's an update in a used module) means running

gnulib-tool --update

in modules/rawsock, followed by

autoreconf --force --install

This is the exact procedure I'm following whenever I've made a change
to one of the used modules.

Though, atm the code is messy: I copied some parts from core CLISP and
the syscalls module, although I don't use it. The reason is that both
core CLISP as well as syscalls are still using the old, not yet
updated gnulib code. Updating that failed due to the build system not
being able to "rebuild" itself (the configures target in
Makefile.devel fails).

Looking at how much time I wasted struggling with the build system I'd
like to replace it with an "standard" autotools one. I already started
work on that, it shouldn't be much of an issue.

I'd like to start a discussion about the modules and their
organization in general, but I'll write that in a separate message
soon.

Re: status update

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

Daniel,

>> The deadline to complete your midterm evaluation is Monday, June 27th at 19:00 UTC

By that time I need to have an independent confirmation that you built
clisp on windows with working rawsock module (that was the condition
for the midterm "pass" from the get go).
Please make sure that I do get the confirmation by then.
Sorry if that sounds harsh, but rules are rules.

On Sat, Jun 25, 2016 at 10:19 AM, Daniel Jour <dan...@gm...> wrote:
>> what is your status?
>
> I was struggling with the build system, but I think I got it fixed
> now. Changes to the actual code seem (so far) to work flawlessly.  I
> had a bit less time available the last week, which is why I'm a bit
> behind schedule.

what are the changes you had to make to get it working?
it's important that the changes "scale", i.e., a gnulib update does
not entail much work.

>> did you manage to build clisp with rawsock on windows?
>
> Not yet (completely), but I think I'll be able to in about 24 hours.
>
>> if yes, please build a binary distribution ("make -f Makefile.devel
>> distrib") and make the binary available for download.
>
> I do that as soon as it builds and passes the tests, which will be
> hopefully very soon.

Thanks!

-- 
Sam Steingold <http://sds.podval.org> <http://www.childpsy.net/>

Re: status update

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

> what is your status?

I was struggling with the build system, but I think I got it fixed
now. Changes to the actual code seem (so far) to work flawlessly.  I
had a bit less time available the last week, which is why I'm a bit
behind schedule.

> did you manage to build clisp with rawsock on windows?

Not yet (completely), but I think I'll be able to in about 24 hours.

> if yes, please build a binary distribution ("make -f Makefile.devel
> distrib") and make the binary available for download.

I do that as soon as it builds and passes the tests, which will be
hopefully very soon.