clisp-devel — closed list for developers and testers

Re: clisp - general interest in code cleanup

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

Hi Sam,

2016-03-21 23:46 GMT+01:00 Sam Steingold <sd...@gn...>:
>
> Hi Daniel,
>
> > * Daniel Jour <qnavry.bregjvt@tznvy.pbz> [2016-03-21 15:07:02 +0000]:
> >
> > the CLISP project seems to be "not that active", judging from the
mailing
> > list / bug tracker / repository activities. The latest release is 6
years
> > old.
>
> Alas, this is, indeed, the case.
>
> > Looking at the code base, I think this low activity stems at least in
part
> > from the IMO relatively bad condition it is in. Most of it seems to be
> > quite old, there are (now talking of the C parts) parts that invoke
> > undefined behavior (general pointer comparisons, integer overflows, out
of
> > bounds indexing) and some other odd things (the whole additional
> > preprocessing, pre C99 code, indexing from 1 instead of 0, apparently no
> > internal interfaces / abstraction, probably more).
> >
> > I'd like to change that. In order to do so I'd like to "modernize" the
code
> > base, starting with the C code. That means among other things
converting to
> > standard compliant code (C99 probably), splitting code into smaller
units,
> > establishing internal interfaces.
> >
> > Before putting (a lot) more work into this I'd like to know whether
> > a) there's is a general interest to make such - probably huge - changes
to
> > the code base, and whether
>
> Yes, there is at least some interest in modernizing CLISP code base.
> Note, however, that this is a fairly large task, and you are not the
> first one to volunteer to do this (previous attempts failed because
> people bit more than they could chew).
> This is why I am wary of this being the first CLISP project you attempt.

That's great. I agree, modernizing the complete code base is a task that's
too huge to attempt as a first CLISP project. What I hoped for was that it's
ok if, picking a random example, readtable related code got extracted from
src/io.d, i.e. it's ok when runtime code is refactored to some degree.

> > b) this could be seen as a project (with further details I'd work out
> > then) suitable for GSoC.
>
> Let us start small - or, at least, smaller.
>
> Specifically, make a release.

Sounds good.

> This will require you to learn the current CLISP infrastructure which
> will be absolutely critical when you move on to the next step of
> cleaning up the code.
> This will also allow us, the CLISP maintainers, to pass on our expertise
> to you and to monitor and mentor your progress.
> It is also a finite task with a clear and visible deliverable.

I think I have already a rough understanding of the infrastructure, in the
sense of "where is what" and how it fits together. (Apart from a lot of
code I read the complete implementation notes and was searching
through the clisp-devel list for info).
Though there's still a lot I don't understand :)

> Currently, CLISP hg tip is in a bad state: an import of gnulib packages
> resulted in a code base which probably works only on Linux.
>
> Specifically, what you would need to do is
>
> 1. update all gnulib imports

To what extend is CLISP using gnulib atm? I've found the
gnulib-imported target in Makefile.devel (as well as related stuff), but am
unsure how far the actual src/* files make use of it. As far as I can tell
only
src/lispbibl.d, src/_clisp.c and src/glmalloc.c seem to use it (only taking
the
runtime into approach, not any modules).

I didn't know about the patches section of sf.net until Ken Brown brought
it up (https://sf.net/p/clisp/mailman/message/34957653/).

> 2. fix gnulib/Windows interaction (gnulib assumes FD to be an int,
>    Windows uses Handles)

Can you provide a bit more background on that? Is this related to
http://lists.gnu.org/archive/html/bug-gnulib/2016-03/msg00033.html and
thus a general gnulib issue? Or does this only affect CLISP?

> 3. make sure that CLISP builds and passes self-tests on as many
>    platforms as possible, but at least
>    A. Linux (fedora, ubuntu &c)
>    B. Windows (whatever the most common version is now, with and without
>       cygwin)
>    C. Mac OS X
>    D. *BSD (FreeBSD, OpenBSD, NetBSD)

I should be able to get access to all of these:
I'm working on a Linux machine, NixOS distribution (if it compiles here
it'll
probably compile one every Linux, given correct dependencies) and have
access to Debian machines at my university. I have NetBSD and FreeBSD
qemu images available, and can probably get access to both Windows VMs
as well as "real machines" through my university. I can probably also get
access to Mac computers (there's a lab / pool at the university).

How "extensive" are these self-tests?

> 4. Make an official source and binary release.
>
> I think the above is a good GSoC project.

I guess I should get a proposal ready ASAP then.

> Bruno, WDYT?
>
> > I'm asking these - probably too detailed - questions on this list here
> > instead of on one of the CLISP mailing lists because they seem, as
already
> > pointed out, to be dead. I was unsure about whether to CC one of the
> > maintainers, because it's discouraged in some communities, and so I
didn't.
> > I didn't CC one of the maintainers because such CCing is discouraged in
> > some communities. What's the "correct" way to get in contact here? And:
Are
> > there any possible mentors for the CLISP project?
>
> Yes, I am prepared to mentor you.
> I hope that if you will show some progress, Bruno will chip in too.

Thank you a lot. I'll give my best to get a suitable proposal ready
until the deadline.

Daniel

> > Finally, a very brief info about me: My name is Daniel Jour nee Oertwig,
> > I'm currently pursuing my computer science master's degree at University
> > Wuerzburg, Germany.
> > I'm a self taught programmer, started learning about 14 years ago and
have
> > been doing all kinds of different things, like some hobby OS kernels,
> > programming language ideas, an orbit trajectory calculation tool (I did
my
> > bachelor's degree in aerospace computer science :) ), C++ code
> > transformation tools and a lot more. Thus I've been exposed to a lot of
> > technologies, but I'm most proficient with C, C++ and (Common) Lisp and
> > operating system concepts.
> > I've been working as a teaching assistant for my university's operating
> > systems course, teaching mostly stuff related to multithreading
(examples
> > in Java) and GNU/Linux usage. I'm an active user on stackoverflow.
> > I'm 24 years old, married, two kids (and I should note that my family
takes
> > precedence over anything else, thus I'm probably an a bit "riskier"
> > potential GSoC student)
> >
> > Best regards,
> > Daniel Jour
>
> --
> Sam Steingold (http://sds.podval.org/) on Ubuntu 15.10 (wily) X
11.0.11702000
> http://www.childpsy.net/ http://think-israel.org http://iris.org.il
> http://palestinefacts.org http://americancensorship.org http://dhimmi.org
> My plan for 'after work' is to retire.

Re: Please give me some advice and guidance for clisp proposal for GSoC

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

On 3/22/2016 4:00 PM, Sam Steingold wrote:
> Hi,
> You can start with checking out the CLISP source tree and building CLISP
> from sources.
> Good luck!
>

And please note that there are quite a few patches at 
https://sourceforge.net/p/clisp/patches/ that haven't been applied.  In 
particular, I submitted patches that enable building the hg tip on 
Cygwin (with support for dynamic modules).

Ken

Re: Please give me some advice and guidance for clisp proposal for GSoC

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

Hi,
You can start with checking out the CLISP source tree and building CLISP
from sources.
Good luck!
-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 15.10 (wily) X 11.0.11702000
http://www.childpsy.net/ http://honestreporting.com
http://americancensorship.org http://mideasttruth.com http://www.dhimmitude.org
Booze is the answer. I can't remember the question.

Re: Please give me some advice and guidance for clisp proposal for GSoC

[Wataru N. <sti...@gm...>]

Hi,

Thank you for your reply.

Unfortunately, I canceled my enrollment.
So I was disqualified from GSoC and am going to studying for the next
entrance exam.
In this proposal, I become more and more interested in CLISP.
Thus I would love to contribute for CLISP with or without GSoC.

2016-03-22 7:51 GMT+09:00 Sam Steingold <sd...@gn...>:

> Hi Wataru,
>
> Nice to hear from you.
> Note that Daniel Jour also expressed interest in CLISP + GSoC, so here
> is what I wrote to him:
>
> You could make a release.
> This will require you to learn the current CLISP infrastructure which
> will be absolutely critical when you move on to the next step of
> cleaning up the code.
> This will also allow us, the CLISP maintainers, to pass on our expertise
> to you and to monitor and mentor your progress.
> It is also a finite task with a clear and visible deliverable.
>
> Currently, CLISP hg tip is in a bad state: an import of gnulib packages
> resulted in a code base which probably works only on Linux.
>
> Specifically, what you would need to do is
>
> 1. update all gnulib imports
>
> 2. fix gnulib/Windows interaction (gnulib assumes FD to be an int,
>    Windows uses Handles)
>
> 3. make sure that CLISP builds and passes self-tests on as many
>    platforms as possible, but at least
>    A. Linux (fedora, ubuntu &c)
>    B. Windows (whatever the most common version is now, with and without
>       cygwin)
>    C. Mac OS X
>    D. *BSD (FreeBSD, OpenBSD, NetBSD)
>
> 4. Make an official source and binary release.
>
> I think the above is a good GSoC project.
>
>
> > * Wataru Nakaishi <fgvorne.yvfc@tznvy.pbz> [2016-03-17 23:35:23 +0900]:
> >
> > Hello sir,
> >
> > I am Wataru NAKANISHI, planning to enroll the university in Japan as of
> 21
> > March 2016.
> > I have been using Common Lisp daily, and been interested in contributing
> > for some lisp project.
> > Then when I had come to know the participation of CLISP in GSoC, I wanted
> > keenly to contribute for CLISP.
> >
> > I usually use Arch Linux, and sometimes use Windows 10. So I can work for
> > the tasks of both OSs.
> > The task which I'm the most interested in is developing thread-safe hash
> > tables, but I have almost no experiences about multi-threading.
> > At any cost, I would love to work for CLISP even if I should do other
> tasks.
> >
> > Please give me some advice.
> >
> > Thanks.
> > Wataru
>
> --
> Sam Steingold (http://sds.podval.org/) on Ubuntu 15.10 (wily) X
> 11.0.11702000
> http://www.childpsy.net/ http://dhimmi.org http://ffii.org
> http://openvotingconsortium.org http://camera.org http://think-israel.org
> My other CAR is a CDR.
>

Re: Please give me some advice and guidance for clisp proposal for GSoC

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

Hi Wataru,

Nice to hear from you.
Note that Daniel Jour also expressed interest in CLISP + GSoC, so here
is what I wrote to him:

You could make a release.
This will require you to learn the current CLISP infrastructure which
will be absolutely critical when you move on to the next step of
cleaning up the code.
This will also allow us, the CLISP maintainers, to pass on our expertise
to you and to monitor and mentor your progress.
It is also a finite task with a clear and visible deliverable.

Currently, CLISP hg tip is in a bad state: an import of gnulib packages
resulted in a code base which probably works only on Linux.

Specifically, what you would need to do is

1. update all gnulib imports

2. fix gnulib/Windows interaction (gnulib assumes FD to be an int,
   Windows uses Handles)

3. make sure that CLISP builds and passes self-tests on as many
   platforms as possible, but at least
   A. Linux (fedora, ubuntu &c)
   B. Windows (whatever the most common version is now, with and without
      cygwin)
   C. Mac OS X
   D. *BSD (FreeBSD, OpenBSD, NetBSD)

4. Make an official source and binary release.

I think the above is a good GSoC project.


> * Wataru Nakaishi <fgvorne.yvfc@tznvy.pbz> [2016-03-17 23:35:23 +0900]:
>
> Hello sir,
>
> I am Wataru NAKANISHI, planning to enroll the university in Japan as of 21
> March 2016.
> I have been using Common Lisp daily, and been interested in contributing
> for some lisp project.
> Then when I had come to know the participation of CLISP in GSoC, I wanted
> keenly to contribute for CLISP.
>
> I usually use Arch Linux, and sometimes use Windows 10. So I can work for
> the tasks of both OSs.
> The task which I'm the most interested in is developing thread-safe hash
> tables, but I have almost no experiences about multi-threading.
> At any cost, I would love to work for CLISP even if I should do other tasks.
>
> Please give me some advice.
>
> Thanks.
> Wataru

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 15.10 (wily) X 11.0.11702000
http://www.childpsy.net/ http://dhimmi.org http://ffii.org
http://openvotingconsortium.org http://camera.org http://think-israel.org
My other CAR is a CDR.

Re: clisp - general interest in code cleanup

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

Hi Daniel,

> * Daniel Jour <qnavry.bregjvt@tznvy.pbz> [2016-03-21 15:07:02 +0000]:
>
> the CLISP project seems to be "not that active", judging from the mailing
> list / bug tracker / repository activities. The latest release is 6 years
> old.

Alas, this is, indeed, the case.

> Looking at the code base, I think this low activity stems at least in part
> from the IMO relatively bad condition it is in. Most of it seems to be
> quite old, there are (now talking of the C parts) parts that invoke
> undefined behavior (general pointer comparisons, integer overflows, out of
> bounds indexing) and some other odd things (the whole additional
> preprocessing, pre C99 code, indexing from 1 instead of 0, apparently no
> internal interfaces / abstraction, probably more).
>
> I'd like to change that. In order to do so I'd like to "modernize" the code
> base, starting with the C code. That means among other things converting to
> standard compliant code (C99 probably), splitting code into smaller units,
> establishing internal interfaces.
>
> Before putting (a lot) more work into this I'd like to know whether
> a) there's is a general interest to make such - probably huge - changes to
> the code base, and whether

Yes, there is at least some interest in modernizing CLISP code base.
Note, however, that this is a fairly large task, and you are not the
first one to volunteer to do this (previous attempts failed because
people bit more than they could chew).
This is why I am wary of this being the first CLISP project you attempt.

> b) this could be seen as a project (with further details I'd work out
> then) suitable for GSoC.

Let us start small - or, at least, smaller.

Specifically, make a release.
This will require you to learn the current CLISP infrastructure which
will be absolutely critical when you move on to the next step of
cleaning up the code.
This will also allow us, the CLISP maintainers, to pass on our expertise
to you and to monitor and mentor your progress.
It is also a finite task with a clear and visible deliverable.

Currently, CLISP hg tip is in a bad state: an import of gnulib packages
resulted in a code base which probably works only on Linux.

Specifically, what you would need to do is

1. update all gnulib imports

2. fix gnulib/Windows interaction (gnulib assumes FD to be an int,
   Windows uses Handles)

3. make sure that CLISP builds and passes self-tests on as many
   platforms as possible, but at least
   A. Linux (fedora, ubuntu &c)
   B. Windows (whatever the most common version is now, with and without
      cygwin)
   C. Mac OS X
   D. *BSD (FreeBSD, OpenBSD, NetBSD)

4. Make an official source and binary release.

I think the above is a good GSoC project.

Bruno, WDYT?

> I'm asking these - probably too detailed - questions on this list here
> instead of on one of the CLISP mailing lists because they seem, as already
> pointed out, to be dead. I was unsure about whether to CC one of the
> maintainers, because it's discouraged in some communities, and so I didn't.
> I didn't CC one of the maintainers because such CCing is discouraged in
> some communities. What's the "correct" way to get in contact here? And: Are
> there any possible mentors for the CLISP project?

Yes, I am prepared to mentor you.
I hope that if you will show some progress, Bruno will chip in too.

> Finally, a very brief info about me: My name is Daniel Jour nee Oertwig,
> I'm currently pursuing my computer science master's degree at University
> Wuerzburg, Germany.
> I'm a self taught programmer, started learning about 14 years ago and have
> been doing all kinds of different things, like some hobby OS kernels,
> programming language ideas, an orbit trajectory calculation tool (I did my
> bachelor's degree in aerospace computer science :) ), C++ code
> transformation tools and a lot more. Thus I've been exposed to a lot of
> technologies, but I'm most proficient with C, C++ and (Common) Lisp and
> operating system concepts.
> I've been working as a teaching assistant for my university's operating
> systems course, teaching mostly stuff related to multithreading (examples
> in Java) and GNU/Linux usage. I'm an active user on stackoverflow.
> I'm 24 years old, married, two kids (and I should note that my family takes
> precedence over anything else, thus I'm probably an a bit "riskier"
> potential GSoC student)
>
> Best regards,
> Daniel Jour

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 15.10 (wily) X 11.0.11702000
http://www.childpsy.net/ http://think-israel.org http://iris.org.il
http://palestinefacts.org http://americancensorship.org http://dhimmi.org
My plan for 'after work' is to retire.

Please give me some advice and guidance for clisp proposal for GSoC

[Wataru N. <sti...@gm...>]

Hello sir,

I am Wataru NAKANISHI, planning to enroll the university in Japan as of 21
March 2016.
I have been using Common Lisp daily, and been interested in contributing
for some lisp project.
Then when I had come to know the participation of CLISP in GSoC, I wanted
keenly to contribute for CLISP.

I usually use Arch Linux, and sometimes use Windows 10. So I can work for
the tasks of both OSs.
The task which I'm the most interested in is developing thread-safe hash
tables, but I have almost no experiences about multi-threading.
At any cost, I would love to work for CLISP even if I should do other tasks.

Please give me some advice.

Thanks.
Wataru

[PATCH] Improve portability of clisp in the Hurd system

[Flavio C. <fla...@gm...>]

---

This allows clisp to be compiled in the Hurd by defining IS_EINVAL_EXTRA
and by removing the use of MAXPATHLEN.

diff -r d3f6e80fb705 modules/syscalls/calls.c
--- a/modules/syscalls/calls.c	Sun May 31 00:56:01 2015 -0400
+++ b/modules/syscalls/calls.c	Thu Dec 31 13:35:20 2015 -0500
@@ -5872,12 +5872,15 @@
   /* if DATEMSK is not set, set it to the clisp-supplied value */
   if (NULL == getenv("DATEMSK")) {
     with_string_0(physical_namestring(GLO(lib_dir)),GLO(pathname_encoding),ldz,{
-        char datemsk[MAXPATHLEN];
+        /* use enough space for datemsk */
+        const size_t datemsk_len = ldz_len + 1 + strlen("/syscalls/datemsk");
+        char *datemsk = malloc(sizeof(char) * datemsk_len);
         strcpy(datemsk,ldz);
         if (ldz[ldz_len-1] == '/')
           strcat(datemsk,"syscalls/datemsk");
         else strcat(datemsk,"/syscalls/datemsk");
         setenv("DATEMSK",datemsk,0);
+        free(datemsk);
       });
   }
 }
diff -r d3f6e80fb705 src/stream.d
--- a/src/stream.d	Sun May 31 00:56:01 2015 -0400
+++ b/src/stream.d	Thu Dec 31 13:35:20 2015 -0500
@@ -3484,6 +3484,8 @@
   #define IS_EINVAL_EXTRA  ((errno==EOPNOTSUPP)||(errno==ENOTSUP)||(errno==ENODEV))
 #elif defined(UNIX_SUNOS5)
   #define IS_EINVAL_EXTRA  ((errno==ENXIO))
+#elif defined(UNIX_HURD)
+  #define IS_EINVAL_EXTRA  ((errno==EOPNOTSUPP)||(errno==EMIG_BAD_ID))
 #else
   #define IS_EINVAL_EXTRA  0
 #endif

New French PO file for 'clisp' (version 2.48-pre1)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'clisp' has been submitted
by the French team of translators.  The file is available at:

    http://translationproject.org/latest/clisp/fr.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/clisp/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/clisp.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

Re: cl+ssl is unusable from saved image

[Anton V. <avo...@ya...>]

After loading the image, try to call (cl+ssl:reload).

>From its docstring:

Reload libssl. Call this function after restarting a Lisp core with CL+SSL dumped into it on Lisp implementations that do not reload shared libraries automatically.

Best regards,
- Anton

10.12.2015, 03:34, "wis...@ma..." <wis...@ma...>:
> I'd like to load cl+ssl, save the clisp image, resume it, and have cl+ssl still be usable. It isn't. I don't know if this is a general problem with saving/resuming an image containing any native library, or specific to the cl+ssl library.
>
> Even loading cl+ssl again into the resumed image doesn't help. (Otherwise, I'd just add that one step to my deployment process.)
>
> Has anybody on this list dealt with this, by chance?
>
> Thanks.
>
> ----------
> This message was sent from a MailNull anti-spam account. You can get
> your free account and take control over your email by visiting the
> following URL.
>
>    http://mailnull.com/
>
> ------------------------------------------------------------------------------
> _______________________________________________
> clisp-devel mailing list
> cli...@li...
> https://lists.sourceforge.net/lists/listinfo/clisp-devel

cl+ssl is unusable from saved image

[<wis...@ma...>]

I'd like to load cl+ssl, save the clisp image, resume it, and have cl+ssl still be usable. It isn't. I don't know if this is a general problem with saving/resuming an image containing any native library, or specific to the cl+ssl library.

Even loading cl+ssl again into the resumed image doesn't help. (Otherwise, I'd just add that one step to my deployment process.)

Has anybody on this list dealt with this, by chance?

Thanks.

----------
This message was sent from a MailNull anti-spam account.  You can get
your free account and take control over your email by visiting the
following URL.

   http://mailnull.com/

drakma https

[<wis...@ma...>]

On current clisp, drakma can't load https (i.e. ssl) urls.

On both OSX and Linux, giving #'drakma:http-request an https url causes clisp to hang and maxes out my CPU usage.

However on clisp version 2.49, drakma can fetch https URLs just fine.

http urls (no ssl) work correctly on each version of clisp.

Does anybody here have drakma https working on the current clisp? If so, please let me know. I'll immediately change my system configuration to match yours.

Thanks.

----------
This message was sent from a MailNull anti-spam account.  You can get
your free account and take control over your email by visiting the
following URL.

   http://mailnull.com/

[PATCH] fix build issues in Hurd systems

[Flávio C. <fla...@gm...>]

Hello

There has been some issues when building clisp in Debian Hurd. See
https://buildd.debian.org/status/fetch.php?pkg=clisp&arch=hurd-i386&ver=1%3A2.49-10&stamp=1440769077
where
compilation fails with:

Bytes permanently allocated:             90,464
Bytes currently in use:               5,313,132
Bytes available until next GC:        1,328,283

*** - handle_fault error2 ! address = 0x7fff6884 not in
[0x67d05128,0x680a1000) !
SIGSEGV cannot be cured. Fault address = 0x7fff6884.
GC count: 128
Space collected by GC: 0 97002732
Run time: 5 800000
Real time: 6 392980
GC time: 0 620000
Permanently allocated: 90464 bytes.
Currently in use: 6641408 bytes.
Free space: 7 bytes.

*** - UNIX error 16776913: (ipc/mig) bad request message ID

*** - UNIX error 16776913: (ipc/mig) bad request message ID

*** - UNIX error 16776913: (ipc/mig) bad request message ID
make[1]: *** [interpreted.mem] Segmentation fault

This happens because the call to fsync (on stream.d) sets errno to
EMIG_BAD_ID, which crashes clisp. This patch fixes the problem by
defining IS_EINVAL_EXTRA for Hurd.

Best
Flávio

Re: Maintainer?

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

Sam Steingold <sd...@gn...> writes:

>> * Pascal J. Bourguignon <cwo@vasbezngvzntb.pbz> [2015-08-17 19:20:11 +0200]:
>>
>> Sam Steingold <sd...@gn...> writes:
>>
>>>> * Pascal J. Bourguignon <cwo@vasbezngvzntb.pbz> [2015-08-16 00:04:42 +0200]:
>>>>
>>>> I can't retrieve the message, but IIRC, there was a call for maintainer
>>>> for clisp.
>>>>
>>>> Assuming it's not already taken, I'd volunter for this role, I won't
>>>> be able to allocate a lot of time to clisp, but I should be able make
>>>> a new release, and to correct a couple of bugs a month.
>>>
>>> Great, please go ahead.
>>> The first task is, indeed, making a release.
>>> The biggest problem is the gnulib interaction on windows: some gnulib
>>> code pulled into clisp uses integers while we expect handles.
>>> Do you have access to a msys/mingw dev env?
>>
>> I've got a Windows 10 box on which I could install it.
>
> cool!
> (note http://localghost.org/posts/a-traffic-analysis-of-windows-10)
>
>> Wouldn't I need write access to the mercurial repository?
>
> Yes, you will have to first submit some patches here which will prove
> that you mean business. :-)

Ok.  I should have something ready in a couple of weeks.

-- 
__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: Maintainer?

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

> * Pascal J. Bourguignon <cwo@vasbezngvzntb.pbz> [2015-08-17 19:20:11 +0200]:
>
> Sam Steingold <sd...@gn...> writes:
>
>>> * Pascal J. Bourguignon <cwo@vasbezngvzntb.pbz> [2015-08-16 00:04:42 +0200]:
>>>
>>> I can't retrieve the message, but IIRC, there was a call for maintainer
>>> for clisp.
>>>
>>> Assuming it's not already taken, I'd volunter for this role, I won't
>>> be able to allocate a lot of time to clisp, but I should be able make
>>> a new release, and to correct a couple of bugs a month.
>>
>> Great, please go ahead.
>> The first task is, indeed, making a release.
>> The biggest problem is the gnulib interaction on windows: some gnulib
>> code pulled into clisp uses integers while we expect handles.
>> Do you have access to a msys/mingw dev env?
>
> I've got a Windows 10 box on which I could install it.

cool!
(note http://localghost.org/posts/a-traffic-analysis-of-windows-10)

> Wouldn't I need write access to the mercurial repository?

Yes, you will have to first submit some patches here which will prove
that you mean business. :-)

Thanks!

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1348
http://www.childpsy.net/ http://camera.org http://www.memritv.org
http://honestreporting.com http://mideasttruth.com http://iris.org.il
If you want it done right, you have to do it yourself.

Re: Maintainer?

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

Sam Steingold <sd...@gn...> writes:

>> * Pascal J. Bourguignon <cwo@vasbezngvzntb.pbz> [2015-08-16 00:04:42 +0200]:
>>
>> I can't retrieve the message, but IIRC, there was a call for maintainer
>> for clisp.
>>
>> Assuming it's not already taken, I'd volunter for this role, I won't
>> be able to allocate a lot of time to clisp, but I should be able make
>> a new release, and to correct a couple of bugs a month.
>
> Great, please go ahead.
> The first task is, indeed, making a release.
> The biggest problem is the gnulib interaction on windows: some gnulib
> code pulled into clisp uses integers while we expect handles.
> Do you have access to a msys/mingw dev env?

I've got a Windows 10 box on which I could install it.

Wouldn't I need write access to the mercurial repository?


-- 
__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: Maintainer?

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

> * Pascal J. Bourguignon <cwo@vasbezngvzntb.pbz> [2015-08-16 00:04:42 +0200]:
>
> I can't retrieve the message, but IIRC, there was a call for maintainer
> for clisp.
>
> Assuming it's not already taken, I'd volunter for this role, I won't
> be able to allocate a lot of time to clisp, but I should be able make
> a new release, and to correct a couple of bugs a month.

Great, please go ahead.
The first task is, indeed, making a release.
The biggest problem is the gnulib interaction on windows: some gnulib
code pulled into clisp uses integers while we expect handles.
Do you have access to a msys/mingw dev env?

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1348
http://www.childpsy.net/ http://ffii.org http://think-israel.org
http://camera.org http://www.memritv.org http://mideasttruth.com
A snake who stung your enemy is not necessarily your friend.

Maintainer?

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

Hello,

I can't retrieve the message, but IIRC, there was a call for maintainer
for clisp.

Assuming it's not already taken, I'd volunter for this role,
I won't be able to allocate a lot of time to clisp,
but I should be able make a new release, and to correct a couple of bugs
a month.


-- 
__Pascal Bourguignon__

Re: ffcall fix for OS X

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

> *  <jvfclz.pyvfc@znvyahyy.pbz> [2015-08-01 23:11:55 -0400]:
>
> I needed to do two things to build ffcall on OS X.

alas, nobody maintains libffcall now (would you like to take over?)
at any rate, please be sure to add your patch to the libffcall bug
tracker on savannah.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1348
http://www.childpsy.net/ http://americancensorship.org
http://thereligionofpeace.com http://www.dhimmitude.org
-Nervous?  -Yes!  -First time?  -No, I've been nervous before!

ffcall fix for OS X

[<wis...@ma...>]

I needed to do two things to build ffcall on OS X.

1) use "--build=x86_64-apple-darwin14.4.0" flag to configure, else it thinks this is a 32-bit machine

2) edit three .s assembly files so they'd work on OS X instead of Linux. (I needed to insert an extra underscore before some symbols and remove some directives that were not recognised by the OS X assembler). Here is the patch.

diff -Naur ffcall_cvs_20150724/avcall/avcall-x86_64.s ffcall/avcall/avcall-x86_64.s
--- ffcall_cvs_20150724/avcall/avcall-x86_64.s	2004-01-25 15:25:43.000000000 +0000
+++ ffcall/avcall/avcall-x86_64.s	2015-07-25 02:49:44.000000000 +0100
@@ -1,9 +1,8 @@
 	.file	"avcall-x86_64.c"
 	.text
 	.p2align 4,,15
-.globl __builtin_avcall
-	.type	__builtin_avcall,@function
-__builtin_avcall:
+.globl ___builtin_avcall
+___builtin_avcall:
 .LFB1:
 	pushq	%r12
 .LCFI0:
@@ -328,8 +327,6 @@
 	jmp	.L24
 .LFE1:
 .Lfe1:
-	.size	__builtin_avcall,.Lfe1-__builtin_avcall
-	.section	.eh_frame,"aw",@progbits
 .Lframe1:
 	.long	.LECIE1-.LSCIE1
 .LSCIE1:
diff -Naur ffcall_cvs_20150724/callback/vacall_r/vacall-x86_64.s ffcall/callback/vacall_r/vacall-x86_64.s
--- ffcall_cvs_20150724/callback/vacall_r/vacall-x86_64.s	2004-01-25 15:25:43.000000000 +0000
+++ ffcall/callback/vacall_r/vacall-x86_64.s	2015-07-25 02:54:02.000000000 +0100
@@ -1,9 +1,8 @@
 	.file	"vacall-x86_64.c"
 	.text
 	.p2align 4,,15
-.globl __vacall_r
-	.type	__vacall_r,@function
-__vacall_r:
+.globl ___vacall_r
+___vacall_r:
 .LFB1:
 	pushq	%r13
 .LCFI0:
@@ -209,8 +208,6 @@
 	jmp	.L1
 .LFE1:
 .Lfe1:
-	.size	__vacall_r,.Lfe1-__vacall_r
-	.section	.eh_frame,"aw",@progbits
 .Lframe1:
 	.long	.LECIE1-.LSCIE1
 .LSCIE1:
diff -Naur ffcall_cvs_20150724/vacall/vacall-x86_64.s ffcall/vacall/vacall-x86_64.s
--- ffcall_cvs_20150724/vacall/vacall-x86_64.s	2004-06-02 20:22:10.000000000 +0100
+++ ffcall/vacall/vacall-x86_64.s	2015-07-25 02:51:57.000000000 +0100
@@ -1,9 +1,8 @@
 	.file	"vacall-x86_64.c"
 	.text
 	.p2align 4,,15
-.globl __vacall
-	.type	__vacall,@function
-__vacall:
+.globl ___vacall
+___vacall:
 .LFB1:
 	pushq	%r12
 .LCFI0:
@@ -205,8 +204,6 @@
 	jmp	.L1
 .LFE1:
 .Lfe1:
-	.size	__vacall,.Lfe1-__vacall
-	.section	.eh_frame,"aw",@progbits
 .Lframe1:
 	.long	.LECIE1-.LSCIE1
 .LSCIE1:

----

clisp would then build okay against readline, libsigsegv, and ffcall with:

ulimit -s 16384
CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ./configure --with-threads=POSIX_THREADS --with-readline --with-ffcall build1
cd build1 && make

----

Although I don't see any problems with the resulting clisp binary and can load and use every lisp library I've tried, including cffi, hunchentoot, bordeax-threads, and usocket, four of clisp's own tests do fail. socket.erg describes them all:


Form: (CHECK-OS-ERROR (SOCKET-CONNECT 12345 "localhost" :TIMEOUT 30) (:ECONNREFUSED 111))
CORRECT: T
CLISP  : 61
OUT:
"[OS-ERROR]: OS-ERROR(61): Connection refused
"


Form: (CHECK-OS-ERROR (READ-LINE *SOCKET-1*) (:ECONNREFUSED 111))
CORRECT: T
CLISP  : 61
OUT:
"[OS-STREAM-ERROR]: OS-STREAM-ERROR(61): Connection refused
"


Form: (MULTIPLE-VALUE-BIND (RUN ARGS) (CMD-ARGS) (LET ((SE (SOCKET-SERVER))) (RUN-PROGRAM RUN :ARGUMENTS (APPEND ARGS (LIST "-q" "-q" "-x" (FORMAT NIL "(close (socket:socket-connect ~D))" (SOCKET-SERVER-PORT SE)))) :WAIT NIL :INPUT NIL :OUTPUT NIL) (UNWIND-PROTECT (WITH-OPEN-STREAM (SO (SOCKET-ACCEPT SE)) (LIST (SOCKET-STATUS SO) (WRITE-LINE "foo" SO) (SOCKET-STATUS SO) (CHECK-OS-ERROR (READ-CHAR SO) (:ECONNRESET 104)) (NULL (MEMBER (SOCKET-STATUS SO) '(:EOF :APPEND))) (CHECK-OS-ERROR (WRITE-LINE "bar" SO) (:EPIPE 32)) (NULL (MEMBER (SOCKET-STATUS SO) '(:EOF :APPEND))) (HANDLER-CASE (READ-CHAR SO) (END-OF-FILE (C) (PRINC 'READ-CHAR) (PRINC-ERROR C) 'END-OF-FILE)))) (SOCKET-SERVER-CLOSE SE))))
CORRECT: (:OUTPUT "foo" :OUTPUT T NIL T NIL END-OF-FILE)
CLISP  : ERROR
READ: input stream #1=#<IO INPUT-BUFFERED SOCKET-STREAM CHARACTER 0.0.0.0:49996> has reached its end

OUT:
"[SIMPLE-END-OF-FILE]: READ: input stream #1=#<IO INPUT-BUFFERED SOCKET-STREAM CHARACTER 0.0.0.0:49996> has reached its end

"


Form: (CHECK-OS-ERROR (SOCKET-CONNECT 0) (:ECONNREFUSED 111))
CORRECT: T
CLISP  : 49
OUT:
"[OS-ERROR]: OS-ERROR(49): Can't assign requested address
"


----

[Optional section]

An alternative to patching the assembly files:

There is an alternative to patching ffcall's assembly files directly. That is to regenerate them on OS X from their corresponding .c files. However those C files contain gcc specific extensions that LLVM clang doesn't understand. OS X only ships with LLVM. So first build and install gcc. I needed to make some changes to gcc to have it build, which I've documented at:

https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00013.html

After installing gcc into /usr/local/gcc as described in that post, I did,
ln -s gcc /usr/local/gcc/bin/cc
PATH=/usr/local/gcc/bin:$PATH

Here is how I then regenerated the three .s assembly files from their .c files:

1) avcall/
avcall-x86_64.c has a comment that says it must be compiled with
gcc -O -fno-omit-frame-pointer
but Makefile.devel has
GCCFLAGS = -O2 -fomit-frame-pointer
you do get an .s file with no errors logged, either way
but it's probably best to do what Makefile.devel says over a possibly obsolete comment
gcc -O2 -fomit-frame-pointer -D__x86_64__ -S avcall-x86_64.c -o avcall-x86_64.s

2) vacall/
gcc -O2 -fomit-frame-pointer -DHAVE_LONG_LONG_INT -D__x86_64__ -S vacall-x86_64.c -o vacall-x86_64.s

3) callback/vacall_r/
cp -i ../../vacall/vacall.h.in .
gcc -O2 -fomit-frame-pointer -DHAVE_LONG_LONG_INT -DREENTRANT -D__x86_64__ -S vacall-x86_64.c -o vacall-x86_64.s

Now ffcall will build (even with clang).

----

ref:

Brett Hale's answer at:
http://stackoverflow.com/questions/20907946/error-unknown-directive-type-func-function

http://mail-index.netbsd.org/pkgsrc-users/2015/07/22/msg021906.html
someone else who is trying to get ffcall working (22 july 2015)
on darwin or netbsd

here's a bug report from 2012 regarding ffcall failing on OSX 64-bit
http://savannah.gnu.org/bugs/?36323

http://stackoverflow.com/questions/19720084/what-is-the-difference-between-assembly-on-mac-and-assembly-on-linux/19725269#19725269
The general idea is that the .s files are ELF x86_64 assembler not Mach-O x86_64

----------
This message was sent from a MailNull anti-spam account.  You can get
your free account and take control over your email by visiting the
following URL.

   http://mailnull.com/

New French PO file for 'clisp' (version 2.48-pre1)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'clisp' has been submitted
by the French team of translators.  The file is available at:

    http://translationproject.org/latest/clisp/fr.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/clisp/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/clisp.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

Re: Issues with CLISP on Debian (Jessie) and Arch

[Barry F. <bar...@ac...>]

On 2015-04-09 10:02:28 -0500, Blake McBride wrote:
> On Fri, Apr 3, 2015 at 9:53 AM, Barry Fishman <bar...@ac...> wrote:
>
>> The CLISP package has been withdrawn due to pending issues in Debian
>> test for some time.
>
>
> Withdrawn from where?  Debian?  Arch?  Both?

It has been removed from Debian testing (Jessie) since August 2014.

https://packages.qa.debian.org/c/clisp.html

Arch is just missing any dynamic modules.  I have been using my own
build, so I am not sure if it ever did.  When a Arch library
got updated, I needed to rebuild CLISP, and I noticed the issue, and
re-looked at its status on other platforms.

Since Jessie is still unrelease, it might not have been considered a
priority.  However, after all this time, and the lack of activity in the
repository since April 2013 (in spite of bugs in it bugtracking system),
I am starting to worry if CLISP is currently maintained.

I currently have two build problems:

  1) modules/binding/glibc/linux.lisp: The resulting linux.c file triggers:
 #error "never use bits/ipctypes.h" directly.  include <sys/ipc.h>  instead.
     I replaced bits/ipctypes.h with sys/ipc.h and the compile worked.
  2) src/makemake.in:  The missing library you fixed.

Since I only have non LTS linux systems, I don't know if these changes
break some other platform.  They seem to work for me.

--
Barry Fishman

Re: Issues with CLISP on Debian (Jessie) and Arch

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

On Fri, Apr 3, 2015 at 9:53 AM, Barry Fishman <bar...@ac...> wrote:

> The CLISP package has been withdrawn due to pending issues in Debian
> test for some time.


Withdrawn from where?  Debian?  Arch?  Both?

Thanks.

Blake

Re: Issues with CLISP on Debian (Jessie) and Arch

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

On Fri, Apr 3, 2015 at 8:53 AM, Barry Fishman <bar...@ac...> wrote:
> I found the Arch repository version doesn't supports '(require "linux")'.

Ah, good find.  I maintain the clisp package for Fedora Linux, and it
looks like we have the same problem.  The trouble is that the linker
is trying to take only what it thinks it needs from libgnu.a, so you
have to force the issue.  I think this should do the trick:

sed -i 's/\(${GLLIB_A}\) \(${LIBS}\)/-Wl,--whole-archive \1
-Wl,--no-whole-archive \2/' src/makemake.in

> When I disabled that code, the linux plugin seemed to work fine.

That may lead to trouble later, as the second argument to ioctl
differs in both size and signedness between what clisp expects and
glibc provides.
-- 
Jerry James
http://www.jamezone.org/

Issues with CLISP on Debian (Jessie) and Arch

[Barry F. <bar...@ac...>]

The CLISP package has been withdrawn due to pending issues in Debian
test for some time.  Is anyone working on getting it back.

I found the Arch repository version doesn't supports '(require "linux")'.

I built it from scratch on Arch GNU/Linux x86_64.  At a run time, it
gave me on the '(require "linux")' a message that 'rpl_ioctl' was not
found during the dynamic load.  This seems to be a result of the code in
src/gllib/sys_ioctl.in.h at line 47:

#if @GNULIB_IOCTL@
# if @REPLACE_IOCTL@
#  if !(defined __cplusplus && defined GNULIB_NAMESPACE)
#   undef ioctl
#   define ioctl rpl_ioctl
#  endif

and both @GNULIB_IOCTL@ and @REPLACE_IOCTL@ being set to 1.  I assume
the matching ioctl.c was included in the link, but I didn't see a reason
why the normal ioctl should not be used.

When I disabled that code, the linux plugin seemed to work fine.

--
Barry Fishman