clisp-devel — closed list for developers and testers

Re: new beta release

[Nemo <cy...@gm...>]

Greetings:

On 11/02/2018, Bruno Haible <br...@cl...> wrote:
> Hi all,
>
> clisp 2.49.90 is available at
>   https://haible.de/bruno/gnu/clisp-2.49.90.tar.bz2

This tarball builds cleanly under Solaris 10/Sparc as a 32-bit binary
with the following:

    CC=/opt/developerstudio12.5/bin/cc
    CXX=/opt/developerstudio12.5/bin/CC
    CC=cc CXX=CC ./configure cc12.5.bld

"uname -a": SunOS <name> 5.10 Generic_147147-26 sun4u sparc SUNW,Sun-Blade-2500

Previous problems arose from trying to build the 64-bit version.

"gmake check" reported:

    socket:    6 errors out of      92 tests
    strings:    1 error out of      409 tests

Being a complete newcomer to clisp, I have attached file error files.
Apologies if this not procedure.

Sincerely,
N.

Re: CLISP GSoC Project Ideas

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

Hi Charles,

I did not realize that you were writing to clisp-list, not clisp-devel.
I am replying there, so that Bruno will see it.
I hope he will volunteer to be the primary mentor.
I am certainly willing to help too, but Bruno's command of both C and
CLISP internals is unsurpassed.

Bruno, please respond!

Thanks.

> * Charles Zhang <xneybf@orexryrl.rqh> [2018-02-18 17:57:19 -0800]:
>
> Thanks for your encouraging response.
>
> After digging deeper into the CLISP internals (reading the byte-code
> specification), I've decided a do-able and interesting backend project
> would be to add native file compilation as described here:
> https://clisp.sourceforge.io/wanted.html
> My understanding is that this would allow the use of external debuggers
> like GDB on compiled code and forgo the need for a byte-code interpreter at
> execution time. In essence, this would be the ahead of time counterpart to
> the JIT compiler. I do not know which option (to C, LLVM, or GCC IR) would
> be the easiest to integrate into CLISP, although my intuition tells me that
> transpilation to C would be easiest. At this point, I am wondering if there
> is anyone available who is willing to mentor this project, so that I may
> write a more detailed proposal to be submitted for GSoC and receive general
> pointers.
>
> Charles
>
> On Fri, Feb 16, 2018 at 9:52 AM, Sam Steingold <sd...@gn...> wrote:
>
>> Hi Charles,
>>
>> > * Charles Zhang <xneybf@orexryrl.rqh> [2018-02-16 02:52:26 -0800]:
>> >
>> > I'd like to work on GNU CLISP for Google Summer of Code 2018.
>>
>> Welcome!
>>
>> > Specifically, I am interested in either implementing lock-free
>> > hash-tables or
>>
>> I think getting MT to work has the highest priority ATM.
>>
>> > working on the backend, e.g. adding either a bytecode to C transpiler,
>> > or using bytecode as an IR as a means to compile straight to native
>> > code, either AOT or adding onto the existing JITC work. Another
>> > possible idea I'm interested in would be to improve the byte-code
>> > compiler itself: adding various optimizations not already done
>>
>> One compiler improvement that has been on the TODO list as long as I
>> remember is
>>
>> Enhance the compiler so that it can inline local functions.
>>
>> (Using local function involves copying the closure object ATM, avoiding
>> that would be very nice).
>>
>> > or (more ambitiously) to perform better type inference. As far as
>> > I can tell, CLISP does not do as much type-informed optimizations as
>> > other Common Lisp implmentations.
>>
>> I don't think type-informed optimizations would be easy to do in CLISP.
>>
>> > I am familiar with the internals of SBCL and know the details of Lisp
>> > compilation fairly well, so compiler features rather than user-level
>> > additions like library bindings would be more interesting to work on.
>> > It would be great to hear thoughts from the CLISP maintainers on what
>> > seems like a feasible GSoC goal.
>>
>> The success of your project depends on your commitment, which depends on
>> your interest.
>> Please pick whatever excites you.
>>
>> Thanks.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1561
http://steingoldpsychology.com http://www.childpsy.net http://camera.org
http://islamexposedonline.com http://thereligionofpeace.com
Would you like a dozen wireless mice to feed the Python book you just bought?

Re: new beta release

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

Don Cohen wrote:
> BTW the nightly test of the other one ends up the same as it did
> the previous several nights, https not supported but all other tests
> pass, and ap5 builds.

That's good to know, especially as we are approaching the release. Thanks for
this continuous testing!

Bruno

Re: bug reporting

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

Hi Sam,

> the current list is:
> https://clisp.sourceforge.io/beta/impnotes/clisp.html#bugs
> 
> is this all we need?

Probably it could be streamlined by distinguishing build failures from
other bugs. For the other bugs, "clisp --version" will give us the
version, compiler flags, versions of dependencies already, so no need to
ask for it explicitly.

How about this?

"When submitting a bug report, please specify the following information:

  1. What is your platform (uname -a on a UNIX system)?
  2. Please supply the full output (copy and paste) of all the error messages
  3. Please provide step-by-step instructions on how to reproduce the problem.
  4. If you are reporting a build failure:
     - Compiler version? GNU libc version (on GNU/Linux)?
     - What is the version of each of the DEPENDENCIES?
     - Where did you get the CLISP sources? When? (Absolute dates, e.g., “2006-01-17”,
       are preferred over the relative ones, e.g., “2 days ago”. If you are using
       Mercurial, please supply the output of hg id).
     - Which configure command were you using, and what are the values of the
       environment variables CC, CFLAGS, CPPFLAGS, LDFLAGS, LD_LIBRARY_PATH?
     - Please attach all build logs.
  5. If you are reporting any other bug:
     - What is the output of clisp --version?
     - Where did you get the CLISP sources or binaries? When? (Absolute dates,
       e.g., “2006-01-17”, are preferred over the relative ones, e.g., “2 days ago”.
       If you are using Mercurial, please supply the output of hg id).
"

Bruno

Re: bug reporting

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

Bruno,

> * Sam Steingold <fq...@ta...t> [2018-02-13 13:18:50 -0500]:
>
> Please report each failure separately as described in
> https://clisp.sourceforge.io/clisp.html#bugs

the current list is:
https://clisp.sourceforge.io/beta/impnotes/clisp.html#bugs

is this all we need?

thanks.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1561
http://steingoldpsychology.com http://www.childpsy.net http://camera.org
http://americancensorship.org http://no2bds.org http://think-israel.org
Bus error -- please leave by the rear door.

Re: new beta release

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

Hi Nemo,

> I tried building this on Solaris 10/sparc with Studio 12.5, GCC 3.4.3,
> and GCC 5.2.0.  Each failed (in different places).

To make your report useful, please add - for each case separately -
  1. the versions of the dependency packages you used
     (see the file DEPENDENCIES),
  2. the commands you used to build it, including the
     values of CC, CFLAGS, CPPFLAGS etc that you had set in the
     environment,
  3. the build output (attach it in gzipped form if it is large).

Without such details, neither can you help us make a better release, nor
can we help you install clisp.

Bruno

Re: new beta release

[Nemo <cy...@gm...>]

Greetings:

On 11/02/2018, Bruno Haible <br...@cl...> wrote:
> Hi all,
>
> clisp 2.49.90 is available at
>   https://haible.de/bruno/gnu/clisp-2.49.90.tar.bz2
>
> I invite you all to poke around with it, and report problems, since I'd
> like to see a 2.50 release soon that is as robust as possible.

I tried building this on Solaris 10/sparc with Studio 12.5, GCC 3.4.3,
and GCC 5.2.0.  Each failed (in different places).  The last clisp I
built was 2.33.2 (with Studio 12.5 -- it still builds with two errors
strings and sockets).

Any advice for me?

Sincerely,
N.

Re: new beta release

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

Sam Steingold writes:
 > > * Don Cohen <qba...@vf...3-vap.pbz> [2018-02-12 02:31:16 +0000]:
 > >
 > > If you want me to test the other one, tell me how to do it.
 > > Something like hg clone somethingorother ?
 > 
 > https://stackoverflow.com/q/4345478/850781

so, following two links I find
hg update -r<REV>
And what value do I use for <REV> ?
And then what value do I use to get back?

BTW the nightly test of the other one ends up the same as it did
the previous several nights, https not supported but all other tests
pass, and ap5 builds.

Re: new beta release

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

> * Don Cohen <qba...@vf...3-vap.pbz> [2018-02-12 02:31:16 +0000]:
>
> If you want me to test the other one, tell me how to do it.
> Something like hg clone somethingorother ?

https://stackoverflow.com/q/4345478/850781

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1561
http://steingoldpsychology.com http://www.childpsy.net http://mideasttruth.com
https://jihadwatch.org http://thereligionofpeace.com http://iris.org.il
If money were measured in piles, I would have had a pit of it.

Re: new beta release

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

Bruno Haible writes:
 > Hi Don,
 > 
 > >  > clisp 2.49.90 is available at
 > >  >   https://haible.de/bruno/gnu/clisp-2.49.90.tar.bz2
 > > 
 > > Is this is different from the result of hg pull -u that I test nightly?
 > 
 > It is the same if and only if you pull from the 'clisp-2.50' branch.
 > 
 > If you are pulling from the default branch, it is close but not identical.

So I'll test the default branch tonight.
If you want me to test the other one, tell me how to do it.
Something like hg clone somethingorother ?
Then the usual configure cbcx
And then the additional test of building ap5.
I'd normally do it both with and without MT.

Re: new beta release

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

Hi Don,

>  > clisp 2.49.90 is available at
>  >   https://haible.de/bruno/gnu/clisp-2.49.90.tar.bz2
> 
> Is this is different from the result of hg pull -u that I test nightly?

It is the same if and only if you pull from the 'clisp-2.50' branch.

If you are pulling from the default branch, it is close but not identical.

Bruno

new beta release

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

Bruno Haible writes:
 > Hi all,
 > 
 > clisp 2.49.90 is available at
 >   https://haible.de/bruno/gnu/clisp-2.49.90.tar.bz2

Is this is different from the result of hg pull -u that I test nightly?
If it were the same it would be a lot easier for me to test.

new beta release

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

Hi all,

clisp 2.49.90 is available at
  https://haible.de/bruno/gnu/clisp-2.49.90.tar.bz2

I invite you all to poke around with it, and report problems, since I'd like
to see a 2.50 release soon that is as robust as possible.

Features of this beta release (please report issues about it):
  * Portability - see NEWS file
  * Many object representations are supported - please use the
    'multibuild-<platform>' target of Makefile.devel to test all of them.
  * FFI is supported on all platforms except HP-UX.

Not in the scope of this beta release (no need to report issues on these):
  * Native Windows ports (mingw and msvc).
  * Multithreading.

Bruno

Re: All smokes pass

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

Hi Reini,

> I forgot if sigsegv works on win64 already, I did
> the utils/libsigsegv-win64.patch 2017.

Interesting. Thanks for the pointer!

> ffcall needs utils/libffcall-1.13-20170225-funbegin.patch

I believe libffcall-2.0 should work better than any earlier libffcall version.
Please try that.

> > are showing positive effects even on the "mainstream" platforms?
> 
> Exactly.
> It still doesn't work on my debian-testing

As I'm close to make a prerelease, and have already tested many Debian
platforms, I would like to hear about the problems you encountered
there: platform? symptoms? how to reproduce?

> threads and jit have still a lot todo

Yes, my focus has not been on threads and jit so far. After the 2.50
release, my focus will be on Windows portability, the build system,
the warnings, https support. Won't get to multithreading in the next
3 months.

Bruno

Re: All smokes pass

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

On Thu, Feb 1, 2018 at 8:58 PM, Bruno Haible <br...@cl...> wrote:

> Hi Reini,
>
> > There’s the ci branch with the travis and appveyor smokes.
>
> You mean, the files .travis.yml and .appveyor.yml in
> https://github.com/rurban/clisp ?
>

The ci branch contains those two files, plus the patches and recipes for
smokes on those 3 platforms.

I forgot if sigsegv works on win64 already, I did
the utils/libsigsegv-win64.patch 2017.
ffcall needs utils/libffcall-1.13-20170225-funbegin.patch


>
> > For the first time since I started smoking clisp, all the linux and OS X
> tests passed by today.
>
> Do you mean, your work on .travis.yml and .appveyor.yml is completed?
>

No. Those branches were completed March 2017.
It could also be used to produce binary releases, as described in those
files.


>
> Or do you mean, the many bug fixes in the clisp repository, from the last
> year,
> are showing positive effects even on the "mainstream" platforms?
>

Exactly.
It still doesn't work on my debian-testing, but on a stock ubuntu as from
travis
it started now working.


>
> Or do you mean, avoidable test suite failures are now properly avoided by
> conditionalization?
>
> (Sorry for the questions; I couldn't parse the intent of your message.)
>
>
No, most of the test problems still need my patches, from the bugfixes
branch.
But at least core clisp passes its own testsuite on the major platforms.
I.e. the homegrown GC and module problems from last year.

threads and jit have still a lot todo, and the translation is only about
70% done.

-- 
Reini Urban

Re: All smokes pass

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

Hi Reini,

> There’s the ci branch with the travis and appveyor smokes.

You mean, the files .travis.yml and .appveyor.yml in
https://github.com/rurban/clisp ?

> For the first time since I started smoking clisp, all the linux and OS X tests passed by today.

Do you mean, your work on .travis.yml and .appveyor.yml is completed?

Or do you mean, the many bug fixes in the clisp repository, from the last year,
are showing positive effects even on the "mainstream" platforms?

Or do you mean, avoidable test suite failures are now properly avoided by
conditionalization?

(Sorry for the questions; I couldn't parse the intent of your message.)

Bruno

All smokes pass

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

For the first time since I started smoking clisp, all the linux and OS X tests passed by today.
https://travis-ci.org/rurban/clisp/builds

The windows build still errors at #include <w32shell.h>
https://ci.appveyor.com/project/rurban/clisp/history

There’s the ci branch with the travis and appveyor smokes.
Then my various bugfixes, and then the ongoing translations to english.

Reini Urban
ru...@cp...

Re: full-mod-check, socket tests

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

Hi Bruno,

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

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

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

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

Thanks.

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

Re: test suite driver enhancements

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

Hi Bruno,

In addition to Don's objections to new syntax (which I agree with and
opposed to), I have another objection:

> * Bruno Haible <oe...@py...t> [2018-01-28 11:24:02 +0100]:
>
> ...On AIX and HP-UX. Caused by the lack of support for /dev/fd/1....

the cause of the problem is "lack of support for /dev/fd/1" rather than
specific OS. we need to check for features, not OS.

iow, check whether "/dev/fd/1" is supported, not the name of the os.

we already have an "#if" nightmare in lispbibl.d, let us not duplicate
it in tests.

> 2) When a group of tests belongs together, and a test fails, skip the
> remaining tests of the same group.

why not move such tests into a separate file and run that file is the
feature is present?

iow,

(when (probe-namestring "/dev/fd/1")
  (push "mkst" *all-tests*))

> To solve problem 1), I propose to add - in tests.lisp - OS names to the
> *features* list. So that it becomes possible to write #+(or AIX HP-UX).
> Outside of the test suite, i.e. for user programs, there should be no
> distinction between Linux, AIX, HP-UX, etc.

oh no! please!

> To solve problem 2), I propose a syntax with braces:
> {
> FORM1
> EXPECTED-RESULT1
> FORM2
> EXPECTED-RESULT2
> ...
> }
>
> To solve problem 3), I propose a syntax like this:
> $+CONDITION
> FORM
> EXPECTED-RESULT

I would much rather stick with the Lisp syntax.

Thanks.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1561
http://steingoldpsychology.com http://www.childpsy.net http://camera.org
https://ffii.org http://americancensorship.org https://jihadwatch.org
I don't want to be young again, I just don't want to get any older.

Re: screen -> module

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

Hi Bruno,

> * Bruno Haible <oe...@py...t> [2018-01-27 11:25:39 +0100]:
>
> Moving the sockets to a separate module is very low priority (no
> benefit I can see).

Increased modularity should make code easier to maintain for us and
contribute for others.
You argued for making dirkey a module decades ago for the same reason.


-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1561
http://steingoldpsychology.com http://www.childpsy.net http://mideasttruth.com
http://no2bds.org https://ffii.org http://jij.org http://memri.org
MS: Brain off-line, please wait.

Re: full-mod-check, socket tests

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

Hi Sam,

> >> I will enable the modules tests in configure.
> >
> > Please enable only base-mod-check for the moment.
> 
> base-mod-check goes to step5 and full-mod-check to step6,
> summarized at the end.

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

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

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

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

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

Bruno

test suite driver enhancements

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

 > 1) A couple of tests should be skipped (or with an acceptable failure) on
 > specific platforms. Example:

The https test evidently should be skipped on all platforms so far.

It would be nice to at least collect a list of the tests skipped so
at the end you can see which ones were skipped, perhaps report the 
number skipped along with the number passed and failed.

 > 2) When a group of tests belongs together, and a test fails, skip
 >    the remaining tests of the same group.

So when one fails you set some variable that causes others to be skipped.
You could, of course, consider the entire group to be a single test.
And then if it fails, have a way to view it as a sequence of separate
tests.

 > 3) When a test is skipped, we need to write the condition twice:
 >    #+condition form #+condition result

First, #+ syntax is bad for collecting a list of skipped tests.
Second, I don't yet see why you dislike deftest forms.
I'd expect a deftest form to contain a condition as one of its arguments.

 >  This means, minimal clutter. Ideally, no need to write 'deftest' forms,
 >  'assert' statements etc.

(deftest condition form result)
seems less clutter than 
#+condition form #+condition result

 >   This means, use SETQ/DEFVAR, not LET/LET*, to create temporary objects
 >   that the rest of the test references.

This seems a fairly minor consideration.
We face the same problems for debugging normal code all the time.

 > What I do not want is a test suite style like these:
...
 > In other words, I see the test suite files as *data* (to be
 > interpreted by the test suite driver), not as a Lisp program.

I don't understand why you dislike the sample forms or why they are
not data to be interpreted just as much as what you propose below.

 > To solve problem 1), I propose to add - in tests.lisp - OS names to the
 > *features* list. So that it becomes possible to write #+(or AIX HP-UX).
 > Outside of the test suite, i.e. for user programs, there should be no
 > distinction between Linux, AIX, HP-UX, etc.

(See complaints about #+ above.)
If you avoid #+ then it doesn't really matter whether you store such
data in *features* or some other global variables.

 > To solve problem 2), I propose a syntax with braces:
 > { FORM1 EXPECTED-RESULT1 FORM2 EXPECTED-RESULT2 ... }

Why do you want to leave lisp syntax?  This only makes it harder for
someone to use the test source file.  One should be able to easily 
write code that just reads all the forms from the file without having 
to deal with new syntax.
I don't see how this can be better than something like
(as-one-test FORM1 EXPECTED-RESULT1 FORM2 EXPECTED-RESULT2 ... )
And better than that, I think, would be
(as-one-test (deftest ...)(deftest ...) ...)

 > To solve problem 3), I propose a syntax like this:
 > $+CONDITION FORM EXPECTED-RESULT

Again it seems that leaving lisp syntax is only making trouble
I don't see how this is any better than
(deftest CONDITION FORM EXPECTED-RESULT)


It seems to me that you can view deftest and as-one-test forms
either as lisp programs (if you define them as macros and then load
the file) or as data if you write a program that reads all the forms
in the file and then interprets them in some way other than simple
eval.  Defining the macros seems to me the easiest way of just running 
the tests, but (1) there are other things you might do, like just 
count the tests, and (2) even for running the tests you probably want
to do things like reporting the number of passes, failures, skips.
In fact different uses of the same test suite might be conveniently
implemented by using different definitions of those same macros.

test suite driver enhancements

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

Hi,

When looking at the "make check" results on the various platforms, I'm seeing
room for improvement:

1) A couple of tests should be skipped (or with an acceptable failure) on
specific platforms. Example:

------------------------------------------------------------------------------------------------------
Form: (LET ((*REOPEN-OPEN-FILE* NIL)) (WITH-OPEN-FILE (COPY S :DIRECTION :OUTPUT) (STREAMP COPY)))
CORRECT: T
CLISP  : ERROR
OPEN: Filename for #1=#<OUTPUT UNBUFFERED FILE-STREAM CHARACTER> is unknown

OUT:
"[SIMPLE-FILE-ERROR]: OPEN: Filename for #1=#<OUTPUT UNBUFFERED FILE-STREAM CHARACTER> is unknown

"
------------------------------------------------------------------------------------------------------
On AIX and HP-UX. Caused by the lack of support for /dev/fd/1.

2) When a group of tests belongs together, and a test fails, skip the remaining tests
   of the same group.

3) When a test is skipped, we need to write the condition twice:
   #+condition form #+condition result

However, keep in mind the important design goals of the test suite driver:

  ============================================================================
  * It must be easy to add a new test.
    This means, minimal clutter. Ideally, no need to write 'deftest' forms,
    'assert' statements etc.

  * When a test fails, it must be easy to execute it in single-step mode.
    Where "single-step mode" means to copy entire lines of test into the Lisp
    REPL.
    This means, use SETQ/DEFVAR, not LET/LET*, to create temporary objects
    that the rest of the test references.
  ============================================================================

What I do not want is a test suite style like these:

[From ansi-tests:]
(deftest rename-file.1
  (let ((pn1 #p"file-to-be-renamed.txt")
        (pn2 #p"file-that-was-renamed.txt"))
    (delete-all-versions pn1)
    (delete-all-versions pn2)
    (with-open-file (s pn1 :direction :output) (format s "Whatever~%"))
    (let ((results (multiple-value-list (rename-file pn1 pn2))))
      (destructuring-bind (defaulted-new-name old-truename new-truename)
          results
          (values
           (=t (length results) 3)
           (probe-file pn1)
           (notnot (probe-file pn2))
           (list (notnot (pathnamep defaulted-new-name))
                 (notnot (pathnamep old-truename))
                 (notnot (pathnamep new-truename))
                 (typep old-truename 'logical-pathname)
                 (typep new-truename 'logical-pathname))
           (notnot (probe-file defaulted-new-name))
           (probe-file old-truename)
           (notnot (probe-file new-truename))))))
  t nil t (t t t nil nil) t nil t)

[From sacla-tests]
(let ((ba (make-array '(1 2 3 4 5) :element-type 'bit)))
  (dotimes (i (* 1 2 3 4 5))
    (setf (sbit ba
                (floor i (* 1 2 3 4 5))
                (floor (mod i (* 2 3 4 5)) (* 3 4 5))
                (floor (mod i (* 3 4 5)) (* 4 5))
                (floor (mod i (* 4 5)) 5)
                (mod i 5))
          (if (evenp i) 0 1)))
  (dotimes (i (* 1 2 3 4 5) t)
    (unless (eql (row-major-aref ba i) (if (evenp i) 0 1))
      (return nil))))

[From sbcl tests:]
(let ((fun (compile nil '(lambda () (make-instance 'class-with-special-ssvuc-2
                                     :some-slot 1)))))
  (assert (= *special-ssvuc-counter-2* 0))
  (funcall fun)
  (assert (= *special-ssvuc-counter-2* 0))
  (defmethod (setf slot-value-using-class) :before
      (new-value class (instance class-with-special-ssvuc-2) slotd)
    (incf *special-ssvuc-counter-2*))
  (funcall fun)
  (assert (= *special-ssvuc-counter-2* 1)))

In other words, I see the test suite files as *data* (to be interpreted by the
test suite driver), not as a Lisp program.


To solve problem 1), I propose to add - in tests.lisp - OS names to the
*features* list. So that it becomes possible to write #+(or AIX HP-UX).
Outside of the test suite, i.e. for user programs, there should be no
distinction between Linux, AIX, HP-UX, etc.

To solve problem 2), I propose a syntax with braces:
{
FORM1
EXPECTED-RESULT1
FORM2
EXPECTED-RESULT2
...
}

To solve problem 3), I propose a syntax like this:
$+CONDITION
FORM
EXPECTED-RESULT

Comments?

Bruno

Re: DBus module foreign function warnings

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

On Fri, Jan 26, 2018 at 8:39 AM, Sam Steingold <sd...@gn...> wrote:
> Are you actually using this module for something or is it just a
> maintenance exercise?

Just a maintenance exercise.  When I build packages for Fedora, I look
for warnings, because they often indicate that either I am doing
something wrong, or something is amiss with the package itself.

> Fixed, thanks.

Thank you!  Regards,
-- 
Jerry James
http://www.jamezone.org/

Re: [clisp:clisp] New commit [b83c12] by Sam Steingold

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

Hi Sam,

> src/pathname.d (my_realpath): Cosmetic change to avoid gcc warning
> 
> "suggest a space before ';' or explicit braces around empty body in 'while' statement".
> 
> By Sam Steingold on 01/22/2018 16:17
> [**View Changes**](https://sourceforge.net/p/clisp/clisp/ci/b83c1201abb01c8dab13de6e3bb70bff35682243/)

This part:

@@ -186,14 +186,13 @@
                     if (mypath_ptr < mypath_limit) { *mypath_ptr++ = '/'; } /* first, append a '/' */
                     /* then the rest: */
                     while ((mypath_ptr <= mypath_limit)
-                           && (*mypath_ptr = *from_ptr++))
-                      { mypath_ptr++; }
+                           && (*mypath_ptr++ = *from_ptr++)) ;
                     *mypath_ptr = 0; /* and conclude wit 0 */
                   }
                   /* this replaces resp. completes the path: */

Is not right. The value of mypath_ptr after the loop matters. Your patch
has the effect of terminating mypath with 2 NUL bytes instead of 1 NUL byte.
Thus causing a buffer overrun.

Bruno