clisp-devel — closed list for developers and testers

Re: How to use another module at build time?

[Michael K. <mic...@gm...>]

On 04/09/2012 08:26 PM, Sam Steingold wrote:
>> * Michael Kappert<zvp...@tz...g>  [2012-04-08 22:08:02 +0200]:
>>
>> Nothing is wrong with the above REQUIRE form itself, but with the way
>> clisp-link is used in the overall Makefile (in the 'full' target): It
>> first tries to compile all requested modules before creating dynmod
>> entries.
>
> This is not true.
> prepare_dynamic_module in clisp-link is called for each module one by
> one and it does create the files in dynmod one by one.

Indeed, sorry.
Looks like the Makefile of module gtk+3 is invoked from the anymodule 
target because it's a prerequisite for target all (via  $(MODULES)).

My gtk+3 Makefile contains
  gtkffi.fas gtkffi.c : $(srcdir)/gtkffi.cl gtk3-package.fas
	$(CLISP) -c $(srcdir)/gtkffi.cl -o ./
and compiling gtkffi.cl requires the 'gir' module   (the GTK+ 
introspection typelibs are queried to produce FFI forms at compile time).

I moved the resp. prerequisites from the clisp-module target to a new 
target and call the new target from link.sh(.in). I still need to clean 
things up but building the modules now works as desired.

Thanks!


Michael
--

Re: How to use another module at build time?

[Michael K. <mic...@gm...>]

On 03/28/2012 05:59 PM, Sam Steingold wrote:
>> * Michael Kappert<zvp...@tz...g>  [2012-03-28 00:12:21 +0200]:
>>
>>> I think it is best to use dynamic modules and put (require
>>> "requirement") in the lisp file.
>>
>> Ok - unfortunately simply require-ing the module did not work because
>> clisp-link first compiles all requested modules and only then creates
>> the dynmod directory and shared libs.
>
> so what's wrong with (eval-when (:compile-toplevel) (require...)) ?

Sorry if I was unclear. I didn't call clisp-link directly but tried

   configure --with-module=gir --with-module=gtk+3 --cbc build.gtk+3

Iow. I didn't look at clisp-link at all but copied&modified files from 
the modules included with CLISP.

Nothing is wrong with the above REQUIRE form itself, but with the way 
clisp-link is used in the overall Makefile (in the 'full' target): It 
first tries to compile all requested modules before creating dynmod 
entries. The above REQUIRE form above is executed when compiling module 
gtk+3, but the gir module load file (dynmod/gir.lisp) is not yet 
available at this point.

I was able to compile the modules one after the other with
   configure --with-module=gir --cbc build.gtk+3
   cd build.gtk+3
   make MODULES='gir gtk+3'
Strangely, omitting module gir from the initial build does not work - 
probably the same effect as above.

Btw, module gir does not use a C component (anymore), which means that a 
current CLISP (newer than 2010-09-14) is needed to build it.

Apart from that, I do have some things working already.
If anyone wants to take a look or try it, I've uploaded the modules here:
   https://bitbucket.org/mak08/clisp-gir
(examples included) but beware that it's still under development.
Any kind of feedback is welcome of course.

>> I guess I need to understand clisp-link and link.sh better...
>
> this will help, yes :-)
> please help with the docs too.

I have the following remarks:

- The example at http://www.clisp.org/impnotes.html#mod-set-example
   has the argument to clisp-link in the wrong order:
     4. $ -link add linux base base+linux
   should be
     4. $ -link add base base+linux linux

- clisp-link handles absolute directories incorrectly:
    ./clisp-link add base base+gir /modules/configured/gir
    produces dynmod/gir.lisp
    (ext:appease-cerrors ; for DEF-CALL-OUT to non-existent functions
      (cl:load (cl:merge-pathnames 
"..//modules/configured/gir/ffigen.fas" cl:*load-truename*)))
    => note the "../" is wrong here.

- clisp-link add <source> <target> <module>
   exits with error if <target> exists. It would be nice if at least
   clisp-link add <target> <target> <module> was allowed.


Michael
--

Re: GSoC multithreading project question

[Vladimir T. <vtz...@gm...>]

Hello Sergey,

Thanks for interest.

The GC integration is not the hardest part of the task, imo.
In current implementation there is no big difference between weak hash
tables (http://clisp.org/impnotes/weak.html#weak-ht) and normal ones
besides the special treatment during GC (see spvw_weak.d).

I am willing to assist you with handling GC issues.

BR
  Vladimir

On Thu, Apr 5, 2012 at 11:14 AM, Sergey Vinokurov <ser...@gm...> wrote:
> Hello,
>
> My name is Sergey Vinokurov, I'm student from Ukraine and I would like to
> work on thread safe lock-free hash tables. Project suggestion from official GNU
> site mentions integration with garbage collector and in particular handling of
> weak relations, and these weak relations make me doubt in my ability to finish
> stated suggestion in full during summer due to my lack of experience with GCs.
>
> So I'd like to ask, is it feasible to left handling of weak relations
> as optional
> and leave hash table implementation and basic GC integration as required? Or am
> I just confused and weak relations can be added without much ado once
> hash tables
> are implemented and properly integrated with GC?
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> clisp-devel mailing list
> cli...@li...
> https://lists.sourceforge.net/lists/listinfo/clisp-devel

GSoC multithreading project question

[Sergey V. <ser...@gm...>]

Hello,

My name is Sergey Vinokurov, I'm student from Ukraine and I would like to
work on thread safe lock-free hash tables. Project suggestion from official GNU
site mentions integration with garbage collector and in particular handling of
weak relations, and these weak relations make me doubt in my ability to finish
stated suggestion in full during summer due to my lack of experience with GCs.

So I'd like to ask, is it feasible to left handling of weak relations
as optional
and leave hash table implementation and basic GC integration as required? Or am
I just confused and weak relations can be added without much ado once
hash tables
are implemented and properly integrated with GC?

Re: GSoC Question

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

Graham Smith <gr...@uc...> writes:

> My name is Graham Smith, and I'm a student at the University of
> Chicago. I'm very interested in working on a project concerning CLISP,
> specifically the one about embedding CLISP into Firefox or
> LibreOffice.  However, I am not sure I have a very good idea of what
> that would entail. Could anyone clarify that project?

ECL would be a better choice to embed into a C or C++ application.
ECL means Embedable Common Lisp.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

Re: GSoC Question

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

Hi,

> * Graham Smith <tenunzf@hpuvpntb.rqh> [2012-04-02 15:59:36 -0500]:
>
> My name is Graham Smith, and I'm a student at the University of
> Chicago.  I'm very interested in working on a project concerning
> CLISP, specifically the one about embedding CLISP into Firefox or
> LibreOffice. However, I am not sure I have a very good idea of what
> that would entail. Could anyone clarify that project?

The basic idea is to make the target application (FF or LO) extensible
with CLISP the same way Emacs is extensible with Emacs Lisp.
E.g., the end result should be that one can write a common lisp program
which can be used to do something useful in the target application.
Say, you select some lisp code in FF or LO, press a button or hit a key,
and the code is evaluated and inserted in the Office window (or
displayed as a pop-up in the browser). Or you select a roman numeral,
and a lisp function is called to convert it to the normal representation
(or vice versa). Or you select some text in the editor, and let the
embedded clisp shuffle it.

All this can, of course, be done by running an inferior clisp process
and communicating with it via a pipe of socket, sending and receiving
text.  This, however, is not enough for this project: the idea here is
that CLISP should be able to call the application functions directly.
E.g., consider embedding CLISP into a spreadsheet. Not only one should
be able to use a lisp function just like one now can use AVERAGE or
STDEV, but the lisp function should be able to call the spreadsheet
functions like PLOT or PIVOT.

It might be easier to start with an application which already is
extensible with several other languages, e.g., vim embeds python, ruby
and perl, so this could be the low-hanging fruit.

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 11.10 (oneiric) X 11.0.11004000
http://www.childpsy.net/ http://truepeace.org http://ffii.org http://pmw.org.il
http://dhimmi.com http://palestinefacts.org http://jihadwatch.org
If you're being passed on the right, you're in the wrong lane.

GSoC Question

[Graham S. <gr...@uc...>]

Hello,

My name is Graham Smith, and I'm a student at the University of Chicago.
I'm very interested in working on a project concerning CLISP, specifically
the one about embedding CLISP into Firefox or LibreOffice. However, I am
not sure I have a very good idea of what that would entail. Could anyone
clarify that project?

Thank you,

-- Graham Smith

[ clisp-Bugs-3514029 ] clisp does not build on OSX (Macports)

[SourceForge.net <no...@so...>]

Bugs item #3514029, was opened at 2012-04-01 21:40
Message generated for change (Tracker Item Submitted) made by cstacy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3514029&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: build problems
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christopher Stacy (cstacy)
Assigned to: Bruno Haible (haible)
Summary: clisp does not build on OSX (Macports)

Initial Comment:
Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386

System Version: Mac OS X 10.6.8 (10K549)
Kernel Version: Darwin 10.8.0
Secure Virtual Memory:  Enabled
64-bit Kernel and Extensions: No

Model Name:   Mac mini
Model Identifier:     Macmini3,1
Processor Name:       Intel Core 2 Duo
Processor Speed:      2.26 GHz
Number Of Processors: 1
Total Number Of Cores: 2
L2 Cache:     3 MB
Memory:       8 GB
Bus Speed:    1.07 GHz
SMC Version (system): 1.35f1

There does not seem to be a custom GCC in Macports, so I guess it's using this one:
i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)

 sudo port install clisp
--->  Computing dependencies for clisp
--->  Building clisp
Error: Target org.macports.build returned: shell command failed (see log for details)
Log for clisp is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_clisp/clisp/main.log
Error: Status 1 encountered during processing.



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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3514029&group_id=1355

Re: How to use another module at build time?

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

> * Michael Kappert <zvp...@tz...g> [2012-03-28 00:12:21 +0200]:
>
>> I think it is best to use dynamic modules and put (require
>> "requirement") in the lisp file.
>
> Ok - unfortunately simply require-ing the module did not work because
> clisp-link first compiles all requested modules and only then creates
> the dynmod directory and shared libs.

so what's wrong with (eval-when (:compile-toplevel) (require...)) ?

> I guess I need to understand clisp-link and link.sh better...

this will help, yes :-)
please help with the docs too.

>>> but I still see
>>> make[1]: Entering directory `<clisp>/build.gir/gtk+3'
>>> <clisp>/clisp -K boot  ...
>>
>> this is weird. new-clx requires syscalls and the build works fine.
>> please take a look at how it is done.
>
> The new-clx lisp files are compiled with -K boot. It seems new-clx
> does not call syscalls functions at compile time. (The "gtk+3" module
> queries GTK+ Typelibs[1] at compile time, via a macro that produces a
> huge progn containing FFI forms.).

take a look at the anymodule target in Makefile.
if you are not using configure, you should be able to do

$ cd gtk+3 && make clisp-module CLISP="whatever"

if you discover that you really do need all those other make variables,
you can just edit the build Makefile and replace

CLISP="/home/sds/src/clisp/current/build/clisp -K boot  -E UTF-8 -Emisc 1:1 -Epathname 1:1 -norc" ; \

with whatever suits you.


-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 11.10 (oneiric) X 11.0.11004000
http://www.childpsy.net/ http://camera.org http://americancensorship.org
http://dhimmi.com http://ffii.org http://mideasttruth.com http://jihadwatch.org
God had a deadline, so He wrote it all in Lisp.

clisp-cvs Digest, Vol 68, Issue 2

[<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: SYSTEM::SIMPLE-FILE-ERROR -> OS-FILE-ERROR
      (cli...@li...)
   2. clisp: * modules/i18n/gettext.c (bool_char_lconv,
      int_char_lconv): (cli...@li...)
   3. clisp: * modules/pcre/cpcre.c (pcre_config_option): check the
      re... (cli...@li...)


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

Message: 1
Date: Tue, 27 Mar 2012 17:50:44 +0000
From: cli...@li...
Subject: clisp: SYSTEM::SIMPLE-FILE-ERROR -> OS-FILE-ERROR
To: cli...@li...
Message-ID:
	<hg....@vz...g>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/a757b338719c
changeset: 15565:a757b338719ca69a43915e5ed705cae42f0076aa
user:      Sam Steingold <sd...@po...>
date:      2012-03-27 13:47:42 -0400
description:
SYSTEM::SIMPLE-FILE-ERROR -> OS-FILE-ERROR

diffstat:

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



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

Message: 2
Date: Tue, 27 Mar 2012 17:50:45 +0000
From: cli...@li...
Subject: clisp: * modules/i18n/gettext.c (bool_char_lconv,
	int_char_lconv):
To: cli...@li...
Message-ID:
	<hg....@vz...g>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/f8c20fbc51c8
changeset: 15566:f8c20fbc51c89e57f4ae1f54d9e958bb3e916725
user:      Sam Steingold <sd...@po...>
date:      2012-03-27 13:49:15 -0400
description:
* modules/i18n/gettext.c (bool_char_lconv, int_char_lconv):
treat -1 like CHAR_MAX and use sfixnum instead of fixnum

diffstat:

 modules/i18n/gettext.c |  14 +++++++-------
 src/ChangeLog          |   5 +++++
 2 files changed, 12 insertions(+), 7 deletions(-)



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

Message: 3
Date: Tue, 27 Mar 2012 17:50:47 +0000
From: cli...@li...
Subject: clisp: * modules/pcre/cpcre.c (pcre_config_option): check the
	re...
To: cli...@li...
Message-ID:
	<hg....@vz...g>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/d7607c83d414
changeset: 15567:d7607c83d4146ed5e7ea2a04d504aca290f3af26
user:      Sam Steingold <sd...@po...>
date:      2012-03-27 13:50:27 -0400
description:
* modules/pcre/cpcre.c (pcre_config_option): check the return
value of pcre_config() and use a long for value storage

diffstat:

 modules/pcre/cpcre.c |  11 ++++++-----
 src/ChangeLog        |   5 +++++
 2 files changed, 11 insertions(+), 5 deletions(-)



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

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure

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

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


End of clisp-cvs Digest, Vol 68, Issue 2
****************************************

Re: How to use another module at build time?

[Michael K. <mic...@gm...>]

On 03/25/2012 05:49 AM, Sam Steingold wrote:
>> * Michael Kappert<zvp...@tz...g>  [2012-03-23 23:54:25 +0100]:
>>
>> Is there a way to make clisp load the prerequisite, or use the 'full'
>> linking set when building the dependent module?
>
> I think it is best to use dynamic modules and put (require
> "requirement") in the lisp file.

Ok - unfortunately simply require-ing the module did not work because 
clisp-link first compiles all requested modules and only then creates 
the dynmod directory and shared libs.

I guess I need to understand clisp-link and link.sh better...

>> I tried (in link.sh.in)
>> ${MAKE-make} clisp-module \
>>     CC="${CC}" CPPFLAGS="${CPPFLAGS}" CFLAGS="${CFLAGS}" \
>>     CLISP_LINKKIT="$absolute_linkkitdir" CLISP="${CLISP} -K full"
>>
>> and then try to build the module with

>> $ make MODULES=gtk+3
btw, this was wrong, it does not add modules to dynmod/ but replaces 
them with the newly requested...

>> but I still see
>> make[1]: Entering directory `<clisp>/build.gir/gtk+3'
>> <clisp>/clisp -K boot  ...
>
> this is weird. new-clx requires syscalls and the build works fine.
> please take a look at how it is done.

The new-clx lisp files are compiled with -K boot. It seems new-clx does 
not call syscalls functions at compile time. (The "gtk+3" module queries 
GTK+ Typelibs[1] at compile time, via a macro that produces a huge progn 
containing FFI forms.).


Thanks,
Michael

[1] http://developer.gnome.org/gi/unstable/gi-overview.html
--

[ clisp-Bugs-3512035 ] (require "linux") fails on undefined symbol rpl_ioctl

[SourceForge.net <no...@so...>]

Bugs item #3512035, was opened at 2012-03-27 10:36
Message generated for change (Comment added) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3512035&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: lisp error
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Pascal J. Bourguignon (informatimago)
Assigned to: Bruno Haible (haible)
Summary: (require "linux") fails on undefined symbol rpl_ioctl 

Initial Comment:
On gentoo: 

$ uname -a
Linux kuiper 2.6.38-gentoo-r6-pjb-c9 #2 SMP Wed Jul 13 00:23:08 CEST 2011 x86_64 Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz GenuineIntel GNU/Linux

I cannot load the linux module, because of some undefined symbol:

TEST> (lisp-implementation-version)
"2.49+ (2010-07-17) (built 3541129397) (memory 3541129660)"
TEST> (require "linux")
;; Loading file /data/languages/clisp-hg/lib/clisp-2.49+/dynmod/linux.lisp ...
;;  Loading module linux from /data/languages/clisp-hg/lib/clisp-2.49+/dynmod/lib-linux.so

*** - SYSTEM::DYNLOAD-MODULES: "dlopen" -> "/data/languages/clisp-hg/lib/clisp-2.49+/dynmod/lib-linux.so: undefined symbol: rpl_ioctl"
The following restarts are available:
SKIP           :R1      skip (DYNLOAD-MODULES # '#)
RETRY          :R2      retry (DYNLOAD-MODULES # '#)
STOP           :R3      stop loading file /data/languages/clisp-hg/lib/clisp-2.49+/dynmod/linux.lisp
RETRY          :R4      Retry SLIME REPL evaluation request.
PROCESS-INPUT  :R5      Continue reading input.
ABORT          :R6      Return to SLIME's top level.
CLOSE-CONNECTION :R7    Close SLIME connection.
ABORT          :R8      Abort main loop
C/Break 1 COM.INFORMATIMAGO.RUN-PROGRAM.TEST[2]> :bt



Indeed, there's a reference to rpl_ioctl in lib-linux.so:
[pjb@kuiper :0 tmp]$ nm /data/languages/clisp-hg/lib/clisp-2.49+/dynmod/lib-linux.so|grep rpl
                 U rpl_ioctl
[pjb@kuiper :0 tmp]$ ldd /data/languages/clisp-hg/lib/clisp-2.49+/dynmod/lib-linux.so
	linux-vdso.so.1 =>  (0x00007fff269ff000)
	libm.so.6 => /lib/libm.so.6 (0x00007f9738b13000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x00007f97388f5000)
	libc.so.6 => /lib/libc.so.6 (0x00007f973858f000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f9738fa2000)

But I can't find it in those libraries.

[pjb@kuiper :0 tmp]$ nm /lib64/ld-linux-x86-64.so.2 | grep rpl
nm: /lib64/ld-linux-x86-64.so.2: no symbols
[pjb@kuiper :0 tmp]$ nm /lib/libc.so.6 | grep rpl
nm: /lib/libc.so.6: no symbols

Sam says:

rpl_* come from gnulib, so it is in libgnu.a;
libgnu.a is linked into lisp.run
(all of them: boot, base, and full, so "clisp -K full" works);
but since rpl_ioctl is not used by base,
it is dropped from base/lisp.run;
so when you try to load lib-linux.so which uses rpl_ioctl, it fails.

This patch fixes the error, but I don't like the solution because it means that
every module which uses rpl_ioctl will come with its own implementation.

A better solution is welcome.


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

>Comment By: Sam Steingold (sds)
Date: 2012-03-27 11:15

Message:
at least rawsock needs a similar patch to fix require.
a better approach is necessary.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3512035&group_id=1355

[ clisp-Bugs-3512035 ] (require "linux") fails on undefined symbol rpl_ioctl

[SourceForge.net <no...@so...>]

Bugs item #3512035, was opened at 2012-03-27 10:36
Message generated for change (Tracker Item Submitted) made by informatimago
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3512035&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: lisp error
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Pascal J. Bourguignon (informatimago)
Assigned to: Bruno Haible (haible)
Summary: (require "linux") fails on undefined symbol rpl_ioctl 

Initial Comment:
On gentoo: 

$ uname -a
Linux kuiper 2.6.38-gentoo-r6-pjb-c9 #2 SMP Wed Jul 13 00:23:08 CEST 2011 x86_64 Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz GenuineIntel GNU/Linux

I cannot load the linux module, because of some undefined symbol:

TEST> (lisp-implementation-version)
"2.49+ (2010-07-17) (built 3541129397) (memory 3541129660)"
TEST> (require "linux")
;; Loading file /data/languages/clisp-hg/lib/clisp-2.49+/dynmod/linux.lisp ...
;;  Loading module linux from /data/languages/clisp-hg/lib/clisp-2.49+/dynmod/lib-linux.so

*** - SYSTEM::DYNLOAD-MODULES: "dlopen" -> "/data/languages/clisp-hg/lib/clisp-2.49+/dynmod/lib-linux.so: undefined symbol: rpl_ioctl"
The following restarts are available:
SKIP           :R1      skip (DYNLOAD-MODULES # '#)
RETRY          :R2      retry (DYNLOAD-MODULES # '#)
STOP           :R3      stop loading file /data/languages/clisp-hg/lib/clisp-2.49+/dynmod/linux.lisp
RETRY          :R4      Retry SLIME REPL evaluation request.
PROCESS-INPUT  :R5      Continue reading input.
ABORT          :R6      Return to SLIME's top level.
CLOSE-CONNECTION :R7    Close SLIME connection.
ABORT          :R8      Abort main loop
C/Break 1 COM.INFORMATIMAGO.RUN-PROGRAM.TEST[2]> :bt



Indeed, there's a reference to rpl_ioctl in lib-linux.so:
[pjb@kuiper :0 tmp]$ nm /data/languages/clisp-hg/lib/clisp-2.49+/dynmod/lib-linux.so|grep rpl
                 U rpl_ioctl
[pjb@kuiper :0 tmp]$ ldd /data/languages/clisp-hg/lib/clisp-2.49+/dynmod/lib-linux.so
	linux-vdso.so.1 =>  (0x00007fff269ff000)
	libm.so.6 => /lib/libm.so.6 (0x00007f9738b13000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x00007f97388f5000)
	libc.so.6 => /lib/libc.so.6 (0x00007f973858f000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f9738fa2000)

But I can't find it in those libraries.

[pjb@kuiper :0 tmp]$ nm /lib64/ld-linux-x86-64.so.2 | grep rpl
nm: /lib64/ld-linux-x86-64.so.2: no symbols
[pjb@kuiper :0 tmp]$ nm /lib/libc.so.6 | grep rpl
nm: /lib/libc.so.6: no symbols

Sam says:

rpl_* come from gnulib, so it is in libgnu.a;
libgnu.a is linked into lisp.run
(all of them: boot, base, and full, so "clisp -K full" works);
but since rpl_ioctl is not used by base,
it is dropped from base/lisp.run;
so when you try to load lib-linux.so which uses rpl_ioctl, it fails.

This patch fixes the error, but I don't like the solution because it means that
every module which uses rpl_ioctl will come with its own implementation.

A better solution is welcome.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3512035&group_id=1355

Re: How to use another module at build time?

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

Hi,

> * Michael Kappert <zvp...@tz...g> [2012-03-23 23:54:25 +0100]:
>
> Is there a way to make clisp load the prerequisite, or use the 'full'
> linking set when building the dependent module?

I think it is best to use dynamic modules and put (require
"requirement") in the lisp file.

> I tried (in link.sh.in)
> ${MAKE-make} clisp-module \
>    CC="${CC}" CPPFLAGS="${CPPFLAGS}" CFLAGS="${CFLAGS}" \
>    CLISP_LINKKIT="$absolute_linkkitdir" CLISP="${CLISP} -K full"
>
> and then try to build the module with
> $ make MODULES=gtk+3
>
> but I still see
> make[1]: Entering directory `<clisp>/build.gir/gtk+3'
> <clisp>/clisp -K boot  ...

this is weird. new-clx requires syscalls and the build works fine.
please take a look at how it is done.

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 11.10 (oneiric) X 11.0.11004000
http://www.childpsy.net/ http://truepeace.org http://openvotingconsortium.org
http://ffii.org http://jihadwatch.org http://thereligionofpeace.com
The plural of "anecdote" is not "data".

How to use another module at build time?

[Michael K. <mic...@gm...>]

Hi,

I'm using hand-written bindings (for libgirepository) to generate 
GTK+-3.x bindings. I can put everything in one module but I'd like to 
have the libgirepository bindings in a separate module.

Is there a way to make clisp load the prerequisite, or use the 'full' 
linking set when building the dependent module?

I tried (in link.sh.in)
${MAKE-make} clisp-module \
   CC="${CC}" CPPFLAGS="${CPPFLAGS}" CFLAGS="${CFLAGS}" \
   CLISP_LINKKIT="$absolute_linkkitdir" CLISP="${CLISP} -K full"

and then try to build the module with
$ make MODULES=gtk+3

but I still see
make[1]: Entering directory `<clisp>/build.gir/gtk+3'
<clisp>/clisp -K boot  ...


Michael
--

[ clisp-Bugs-3509539 ] generic function not available in DEFINE-METHOD-COMBINATION

[SourceForge.net <no...@so...>]

Bugs item #3509539, was opened at 2012-03-20 18:18
Message generated for change (Tracker Item Submitted) made by pfeilgm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3509539&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: ANSI compliance issue
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Greg Pfeil (pfeilgm)
Assigned to: Bruno Haible (haible)
Summary: generic function not available in DEFINE-METHOD-COMBINATION

Initial Comment:
The following code prints "this function: NIL" when I would expect something like "this function: #<STANDARD-GENERIC-FUNCTION ECHO>".

(define-method-combination print-gf ()
  ((primary () :required t))
  (:generic-function gf)
  `(progn (format t "this function: ~A" ,gf)
          (call-method ,(first primary) ,(rest primary))))

(defgeneric echo (x)
  (:method-combination print-gf)
  (:method (x)
    x))

(echo t)
=>
this function: NIL
T

my system: Darwin Tiamat.local 11.3.0 Darwin Kernel Version 11.3.0: Thu Jan 12 18:47:41 PST 2012; root:xnu-1699.24.23~1/RELEASE_X86_64 x86_64
my clisp:

GNU CLISP 2.49+ (2010-07-17) (built 3538508120) (memory 3538508385)
Software: GNU C 4.2.1 (Apple Inc. build 5666) (dot 3) 
gcc-4.2 -std=c99 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O -falign-functions=4 -pthread -DUNIX_BINARY_DISTRIB -DENABLE_UNICODE -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_MODULES -DNO_GETTEXT  libgnu.a -lncurses  -liconv -L/usr/local/lib -lsigsegv -lc -R/usr/local/lib  -L/usr/X11/lib -R/usr/X11/lib
SAFETY=0 HEAPCODES STANDARD_HEAPCODES WIDE_HARD GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.10
libiconv 1.11
Features: 
(REGEXP WILDCARD SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP
 LISP=CL INTERPRETER LOGICAL-PATHNAMES MT SOCKETS GENERIC-STREAMS SCREEN
 UNICODE BASE-CHAR=CHARACTER WORD-SIZE=64 UNIX MACOS)
C Modules: (clisp i18n syscalls regexp)
Installation directory: /Users/greg/Documents/sources/clisp/src/
User language: ENGLISH
Machine: X86_64 (X86_64) tiamat.local [10.0.1.103]

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3509539&group_id=1355

[ clisp-Bugs-3508185 ] NO-APPLICABLE-METHOD when an applicable method exists

[SourceForge.net <no...@so...>]

Bugs item #3508185, was opened at 2012-03-18 16:33
Message generated for change (Settings changed) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3508185&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: ANSI compliance issue
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Greg Pfeil (pfeilgm)
Assigned to: Bruno Haible (haible)
Summary: NO-APPLICABLE-METHOD when an applicable method exists

Initial Comment:
(ql:quickload "closer-mop")
(closer-mop:make-method-lambda #'make-instance
                               (class-prototype (find-class 'standard-method))
                               '(lambda (class &rest initargs) t)
                               nil)
=>
NO-APPLICABLE-METHOD: When calling #<STANDARD-GENERIC-FUNCTION
  CLOSER-MOP:MAKE-METHOD-LAMBDA> with arguments (#<STANDARD-GENERIC-FUNCTION
   MAKE-INSTANCE>
 #<STANDARD-METHOD :UNINITIALIZED>
 (LAMBDA (CLASS &REST INITARGS) T) NIL), no method is applicable.
   [Condition of type METHOD-CALL-ERROR]

Yet, when I inspect the function (in SLIME) I see:

#<STANDARD-GENERIC-FUNCTION #x000000020043F601>
--------------------
Name: CLOSER-MOP:MAKE-METHOD-LAMBDA
Arguments: (GENERIC-FUNCTION METHOD CLOSER-MOP::LAMBDA-EXPRESSION CLOSER-MOP::ENVIRONMENT)
Method class: #<STANDARD-CLASS STANDARD-METHOD>
Method combination: #<METHOD-COMBINATION STANDARD #x0000000200124B31>
Methods: 
(STANDARD-GENERIC-FUNCTION STANDARD-METHOD T T) [remove method]

showing that the specializers on the one method defined on the function match the call that failed with NO-APPLICABLE-METHOD.

my system: Darwin Tiamat.local 11.3.0 Darwin Kernel Version 11.3.0: Thu Jan 12 18:47:41 PST 2012; root:xnu-1699.24.23~1/RELEASE_X86_64 x86_64
my clisp: GNU CLISP 2.49+ (2010-07-17) (built 3538508120) (memory 3538508385)
Software: GNU C 4.2.1 (Apple Inc. build 5666) (dot 3) 
gcc-4.2 -std=c99 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O -falign-functions=4 -pthread -DUNIX_BINARY_DISTRIB -DENABLE_UNICODE -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_MODULES -DNO_GETTEXT  libgnu.a -lncurses  -liconv -L/usr/local/lib -lsigsegv -lc -R/usr/local/lib  -L/usr/X11/lib -R/usr/X11/lib
SAFETY=0 HEAPCODES STANDARD_HEAPCODES WIDE_HARD GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.10
libiconv 1.11
Features: 
(REGEXP WILDCARD SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP
 LISP=CL INTERPRETER LOGICAL-PATHNAMES MT SOCKETS GENERIC-STREAMS SCREEN
 UNICODE BASE-CHAR=CHARACTER WORD-SIZE=64 UNIX MACOS)
C Modules: (clisp i18n syscalls regexp)
Installation directory: /Users/greg/Documents/sources/clisp/src/
User language: ENGLISH
Machine: X86_64 (X86_64) tiamat.local [10.0.1.103]

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

Comment By: Greg Pfeil (pfeilgm)
Date: 2012-03-19 09:48

Message:
Sorry, this was my mistake. Pascal Costanza pointed out that one of those
was CLOSER-MOP:STANDARD-GENERIC-FUNCTION, and that's why they didn't match
up.

Sorry for the noise.

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

Comment By: Greg Pfeil (pfeilgm)
Date: 2012-03-19 09:48

Message:
This bug report is now marked as "pending"/"invalid".
This means that we think that the problem you report is not a problem with
CLISP.
Unless you - the reporter - act within 2 weeks, the bug will be permanently
closed.
Sorry about the inconvenience - we hope your silence means that you agree
that this is not a bug in CLISP.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3508185&group_id=1355

[ clisp-Bugs-3508185 ] NO-APPLICABLE-METHOD when an applicable method exists

[SourceForge.net <no...@so...>]

Bugs item #3508185, was opened at 2012-03-18 16:33
Message generated for change (Comment added) made by pfeilgm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3508185&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: ANSI compliance issue
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Greg Pfeil (pfeilgm)
Assigned to: Bruno Haible (haible)
Summary: NO-APPLICABLE-METHOD when an applicable method exists

Initial Comment:
(ql:quickload "closer-mop")
(closer-mop:make-method-lambda #'make-instance
                               (class-prototype (find-class 'standard-method))
                               '(lambda (class &rest initargs) t)
                               nil)
=>
NO-APPLICABLE-METHOD: When calling #<STANDARD-GENERIC-FUNCTION
  CLOSER-MOP:MAKE-METHOD-LAMBDA> with arguments (#<STANDARD-GENERIC-FUNCTION
   MAKE-INSTANCE>
 #<STANDARD-METHOD :UNINITIALIZED>
 (LAMBDA (CLASS &REST INITARGS) T) NIL), no method is applicable.
   [Condition of type METHOD-CALL-ERROR]

Yet, when I inspect the function (in SLIME) I see:

#<STANDARD-GENERIC-FUNCTION #x000000020043F601>
--------------------
Name: CLOSER-MOP:MAKE-METHOD-LAMBDA
Arguments: (GENERIC-FUNCTION METHOD CLOSER-MOP::LAMBDA-EXPRESSION CLOSER-MOP::ENVIRONMENT)
Method class: #<STANDARD-CLASS STANDARD-METHOD>
Method combination: #<METHOD-COMBINATION STANDARD #x0000000200124B31>
Methods: 
(STANDARD-GENERIC-FUNCTION STANDARD-METHOD T T) [remove method]

showing that the specializers on the one method defined on the function match the call that failed with NO-APPLICABLE-METHOD.

my system: Darwin Tiamat.local 11.3.0 Darwin Kernel Version 11.3.0: Thu Jan 12 18:47:41 PST 2012; root:xnu-1699.24.23~1/RELEASE_X86_64 x86_64
my clisp: GNU CLISP 2.49+ (2010-07-17) (built 3538508120) (memory 3538508385)
Software: GNU C 4.2.1 (Apple Inc. build 5666) (dot 3) 
gcc-4.2 -std=c99 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O -falign-functions=4 -pthread -DUNIX_BINARY_DISTRIB -DENABLE_UNICODE -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_MODULES -DNO_GETTEXT  libgnu.a -lncurses  -liconv -L/usr/local/lib -lsigsegv -lc -R/usr/local/lib  -L/usr/X11/lib -R/usr/X11/lib
SAFETY=0 HEAPCODES STANDARD_HEAPCODES WIDE_HARD GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.10
libiconv 1.11
Features: 
(REGEXP WILDCARD SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP
 LISP=CL INTERPRETER LOGICAL-PATHNAMES MT SOCKETS GENERIC-STREAMS SCREEN
 UNICODE BASE-CHAR=CHARACTER WORD-SIZE=64 UNIX MACOS)
C Modules: (clisp i18n syscalls regexp)
Installation directory: /Users/greg/Documents/sources/clisp/src/
User language: ENGLISH
Machine: X86_64 (X86_64) tiamat.local [10.0.1.103]

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

>Comment By: Greg Pfeil (pfeilgm)
Date: 2012-03-19 09:48

Message:
Sorry, this was my mistake. Pascal Costanza pointed out that one of those
was CLOSER-MOP:STANDARD-GENERIC-FUNCTION, and that's why they didn't match
up.

Sorry for the noise.

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

Comment By: Greg Pfeil (pfeilgm)
Date: 2012-03-19 09:48

Message:
This bug report is now marked as "pending"/"invalid".
This means that we think that the problem you report is not a problem with
CLISP.
Unless you - the reporter - act within 2 weeks, the bug will be permanently
closed.
Sorry about the inconvenience - we hope your silence means that you agree
that this is not a bug in CLISP.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3508185&group_id=1355

[ clisp-Bugs-3508185 ] NO-APPLICABLE-METHOD when an applicable method exists

[SourceForge.net <no...@so...>]

Bugs item #3508185, was opened at 2012-03-18 16:33
Message generated for change (Tracker Item Submitted) made by pfeilgm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3508185&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: ANSI compliance issue
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Greg Pfeil (pfeilgm)
Assigned to: Bruno Haible (haible)
Summary: NO-APPLICABLE-METHOD when an applicable method exists

Initial Comment:
(ql:quickload "closer-mop")
(closer-mop:make-method-lambda #'make-instance
                               (class-prototype (find-class 'standard-method))
                               '(lambda (class &rest initargs) t)
                               nil)
=>
NO-APPLICABLE-METHOD: When calling #<STANDARD-GENERIC-FUNCTION
  CLOSER-MOP:MAKE-METHOD-LAMBDA> with arguments (#<STANDARD-GENERIC-FUNCTION
   MAKE-INSTANCE>
 #<STANDARD-METHOD :UNINITIALIZED>
 (LAMBDA (CLASS &REST INITARGS) T) NIL), no method is applicable.
   [Condition of type METHOD-CALL-ERROR]

Yet, when I inspect the function (in SLIME) I see:

#<STANDARD-GENERIC-FUNCTION #x000000020043F601>
--------------------
Name: CLOSER-MOP:MAKE-METHOD-LAMBDA
Arguments: (GENERIC-FUNCTION METHOD CLOSER-MOP::LAMBDA-EXPRESSION CLOSER-MOP::ENVIRONMENT)
Method class: #<STANDARD-CLASS STANDARD-METHOD>
Method combination: #<METHOD-COMBINATION STANDARD #x0000000200124B31>
Methods: 
(STANDARD-GENERIC-FUNCTION STANDARD-METHOD T T) [remove method]

showing that the specializers on the one method defined on the function match the call that failed with NO-APPLICABLE-METHOD.

my system: Darwin Tiamat.local 11.3.0 Darwin Kernel Version 11.3.0: Thu Jan 12 18:47:41 PST 2012; root:xnu-1699.24.23~1/RELEASE_X86_64 x86_64
my clisp: GNU CLISP 2.49+ (2010-07-17) (built 3538508120) (memory 3538508385)
Software: GNU C 4.2.1 (Apple Inc. build 5666) (dot 3) 
gcc-4.2 -std=c99 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O -falign-functions=4 -pthread -DUNIX_BINARY_DISTRIB -DENABLE_UNICODE -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_MODULES -DNO_GETTEXT  libgnu.a -lncurses  -liconv -L/usr/local/lib -lsigsegv -lc -R/usr/local/lib  -L/usr/X11/lib -R/usr/X11/lib
SAFETY=0 HEAPCODES STANDARD_HEAPCODES WIDE_HARD GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.10
libiconv 1.11
Features: 
(REGEXP WILDCARD SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP
 LISP=CL INTERPRETER LOGICAL-PATHNAMES MT SOCKETS GENERIC-STREAMS SCREEN
 UNICODE BASE-CHAR=CHARACTER WORD-SIZE=64 UNIX MACOS)
C Modules: (clisp i18n syscalls regexp)
Installation directory: /Users/greg/Documents/sources/clisp/src/
User language: ENGLISH
Machine: X86_64 (X86_64) tiamat.local [10.0.1.103]

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3508185&group_id=1355

clisp-cvs Digest, Vol 68, 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: (FOREIGN-CALL-OUT): foreign call may block. use
      begin/end... (cli...@li...)
   2. clisp: [MULTITHREAD, MACOSX]: ignore SIGHUP & SIGCONT until I
      kn... (cli...@li...)
   3. clisp: [MACOSX, WIDE_HARD]: ARRAY-DIMENSION-LIMIT = 2^24-1
      since... (cli...@li...)
   4. clisp: (prepare_resize): check kvtable size (not hash table
      size... (cli...@li...)


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

Message: 1
Date: Fri, 09 Mar 2012 22:44:55 +0000
From: cli...@li...
Subject: clisp: (FOREIGN-CALL-OUT): foreign call may block. use
	begin/end...
To: cli...@li...
Message-ID:
	<hg....@vz...g>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/91d9c8180f7d
changeset: 15561:91d9c8180f7dc8bdb552ff751e748055c921e8a9
user:      Vladimir Tzankov <vtz...@gm...>
date:      2012-03-10 00:13:16 +0200
description:
(FOREIGN-CALL-OUT): foreign call may block. use begin/end_block_system_call()

diffstat:

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



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

Message: 2
Date: Fri, 09 Mar 2012 22:44:57 +0000
From: cli...@li...
Subject: clisp: [MULTITHREAD, MACOSX]: ignore SIGHUP & SIGCONT until I
	kn...
To: cli...@li...
Message-ID:
	<hg....@vz...g>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/bdad92e53193
changeset: 15562:bdad92e5319335a29631229c156ebec8885cb3a0
user:      Vladimir Tzankov <vtz...@gm...>
date:      2012-03-10 00:24:47 +0200
description:
[MULTITHREAD, MACOSX]: ignore SIGHUP & SIGCONT until I know how to handle them (vfork() causes SIGHUP - e.g. (DISASSEMBLE 'CAR))

diffstat:

 src/ChangeLog |  6 ++++++
 src/spvw.d    |  7 +++++++
 2 files changed, 13 insertions(+), 0 deletions(-)



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

Message: 3
Date: Fri, 09 Mar 2012 22:44:58 +0000
From: cli...@li...
Subject: clisp: [MACOSX, WIDE_HARD]: ARRAY-DIMENSION-LIMIT = 2^24-1
	since...
To: cli...@li...
Message-ID:
	<hg....@vz...g>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/e923da58f1b6
changeset: 15563:e923da58f1b697c4ec35c2c284e2f8d0f3441dae
user:      Vladimir Tzankov <vtz...@gm...>
date:      2012-03-10 00:40:59 +0200
description:
[MACOSX, WIDE_HARD]: ARRAY-DIMENSION-LIMIT = 2^24-1 since HEAPCODES memory model is used

diffstat:

 src/ChangeLog   |  5 +++++
 src/lispbibl.d  |  9 +++++++--
 tests/ChangeLog |  5 +++++
 tests/array.tst |  2 ++
 4 files changed, 19 insertions(+), 2 deletions(-)



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

Message: 4
Date: Fri, 09 Mar 2012 22:44:59 +0000
From: cli...@li...
Subject: clisp: (prepare_resize): check kvtable size (not hash table
	size...
To: cli...@li...
Message-ID:
	<hg....@vz...g>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/1d2051482ae4
changeset: 15564:1d2051482ae4431866658964b03f9add11ff9831
user:      Vladimir Tzankov <vtz...@gm...>
date:      2012-03-10 00:42:38 +0200
description:
(prepare_resize): check kvtable size (not hash table size) against ARRAY-DIMENSION-LIMIT

diffstat:

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



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

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/

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

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


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

[ clisp-Feature Requests-3498384 ] Please add a -e / --eval option to the command-line

[SourceForge.net <no...@so...>]

Feature Requests item #3498384, was opened at 2012-03-07 01:05
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=3498384&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: UI
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Please add a -e / --eval option to the command-line

Initial Comment:
Many Common Lisp implementations provide a -e / --eval command-line option (in addition to -l / --load) which allows one to evaluate an expression during startup (before entering the REPL). Both -e and -l are usually handled in order, which is very convenient for automation (e.g. when building a library from a set of configurable Makefiles).

CLISP has -i which behaves more or less like --load. There are two problem is with -x:
- first, it quits the program, unless you add -repl at the end of the command-line, so it is semantically different from -e,
- next, a -x expression cannot be evaluated before a -i file.

Consequently, I would like to have a -e / --eval option that would not quit the program, and be evaluated exactly where it is on the command-line, with respect to other -e options, -i options. I haven't given it much thought, but it seems to me that -x options should continue to be executed after everything else, including -e options.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=3498384&group_id=1355

[ clisp-Bugs-3432970 ] Case-sensitive structs miscompiled? [suggested fix]

[SourceForge.net <no...@so...>]

Bugs item #3432970, was opened at 2011-11-03 13:37
Message generated for change (Settings changed) made by mak08
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3432970&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: lisp error
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Michael Kappert (mak08)
>Assigned to: Bruno Haible (haible)
Summary: Case-sensitive structs miscompiled? [suggested fix]

Initial Comment:
It seems that keywords are stored incorrectly in the fasl for case-sensitive struct literals:

$ cat struct-case.cl
(defpackage "STORE" (:modern t))
(in-package store)

(defstruct book title author)

(defmacro defbook-expand (title author)
  (make-book :title title :author author))

(defvar *et-book* (defbook-expand  "aTitle" "anAuthor"))
......
cs-user> (compile-file "/home/michael/Projects/scratch/struct-case.cl")
;; Compiling file /home/michael/Projects/scratch/struct-case.cl ...
;; Wrote file /home/michael/Projects/scratch/struct-case.fas
0 errors, 0 warnings
#P"/home/michael/Projects/scratch/struct-case.fas"
nil
nil
cs-user> (load *)
;; Loading file /home/michael/Projects/scratch/struct-case.fas ...
; Evaluation aborted on #<system::simple-keyword-error #x0003348AA920>.
cs-user> 

The struct literal appears in the fasl as
S(|STORE|::|book| :|title| "aTitle" :|author| "anAuthor")


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

Comment By: Michael Kappert (mak08)
Date: 2011-11-07 12:55

Message:
This is probably much too crude, but it fixes the problem for me: I think
keywords should always be printed in upppercase in pr_structure_default. I
could see no regressions in make check (tested only on Ubuntu). 

diff -r 8f5a8b96a72d src/io.d
--- a/src/io.d	Mon Oct 17 14:59:11 2011 +0300
+++ b/src/io.d	Mon Nov 07 21:48:12 2011 +0100
@@ -8409,7 +8409,7 @@
         {    /* Print (symbol-name (clos:slot-definition-name slot)): */
           var object obj = TheSlotDefinition(*slot_)->slotdef_name;
           if (!symbolp(obj)) goto bad_clas;
-          pr_like_symbol(stream_,Symbol_name(obj)); /* print symbolname of
component */
+          pr_symbol_part(stream_,Symbol_name(obj),false,false); /* print
symbolname of component */
         }
         JUSTIFY_SPACE;
         JUSTIFY_LAST(true);


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

Comment By: Michael Kappert (mak08)
Date: 2011-11-04 14:58

Message:
Now it seems more like a bug in the print-object method for structs:
cs-user> (defstruct foo bar)
foo
cs-user> (let ((*print-readably* nil)) (read-from-string (format nil "~s"
#s(foo :bar "bar"))))
#S(foo :bar "bar")
18
cs-user> (let ((*print-readably* t)) (read-from-string (format nil "~s"
#s(foo :bar "bar"))))
; Evaluation aborted on #<system::simple-keyword-error #x0003348EB220>.
cs-user> (let ((*print-readably* t)) (read-from-string (format nil "~s"
#s(foo :BAR "bar"))))
; Evaluation aborted on #<system::simple-keyword-error #x0003348EB240>.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3432970&group_id=1355

[ clisp-Bugs-3432970 ] Case-sensitive structs miscompiled? [suggested fix]

[SourceForge.net <no...@so...>]

Bugs item #3432970, was opened at 2011-11-03 13:37
Message generated for change (Settings changed) made by mak08
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3432970&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: clisp
>Group: lisp error
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Michael Kappert (mak08)
Assigned to: Nobody/Anonymous (nobody)
Summary: Case-sensitive structs miscompiled? [suggested fix]

Initial Comment:
It seems that keywords are stored incorrectly in the fasl for case-sensitive struct literals:

$ cat struct-case.cl
(defpackage "STORE" (:modern t))
(in-package store)

(defstruct book title author)

(defmacro defbook-expand (title author)
  (make-book :title title :author author))

(defvar *et-book* (defbook-expand  "aTitle" "anAuthor"))
......
cs-user> (compile-file "/home/michael/Projects/scratch/struct-case.cl")
;; Compiling file /home/michael/Projects/scratch/struct-case.cl ...
;; Wrote file /home/michael/Projects/scratch/struct-case.fas
0 errors, 0 warnings
#P"/home/michael/Projects/scratch/struct-case.fas"
nil
nil
cs-user> (load *)
;; Loading file /home/michael/Projects/scratch/struct-case.fas ...
; Evaluation aborted on #<system::simple-keyword-error #x0003348AA920>.
cs-user> 

The struct literal appears in the fasl as
S(|STORE|::|book| :|title| "aTitle" :|author| "anAuthor")


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

Comment By: Michael Kappert (mak08)
Date: 2011-11-07 12:55

Message:
This is probably much too crude, but it fixes the problem for me: I think
keywords should always be printed in upppercase in pr_structure_default. I
could see no regressions in make check (tested only on Ubuntu). 

diff -r 8f5a8b96a72d src/io.d
--- a/src/io.d	Mon Oct 17 14:59:11 2011 +0300
+++ b/src/io.d	Mon Nov 07 21:48:12 2011 +0100
@@ -8409,7 +8409,7 @@
         {    /* Print (symbol-name (clos:slot-definition-name slot)): */
           var object obj = TheSlotDefinition(*slot_)->slotdef_name;
           if (!symbolp(obj)) goto bad_clas;
-          pr_like_symbol(stream_,Symbol_name(obj)); /* print symbolname of
component */
+          pr_symbol_part(stream_,Symbol_name(obj),false,false); /* print
symbolname of component */
         }
         JUSTIFY_SPACE;
         JUSTIFY_LAST(true);


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

Comment By: Michael Kappert (mak08)
Date: 2011-11-04 14:58

Message:
Now it seems more like a bug in the print-object method for structs:
cs-user> (defstruct foo bar)
foo
cs-user> (let ((*print-readably* nil)) (read-from-string (format nil "~s"
#s(foo :bar "bar"))))
#S(foo :bar "bar")
18
cs-user> (let ((*print-readably* t)) (read-from-string (format nil "~s"
#s(foo :bar "bar"))))
; Evaluation aborted on #<system::simple-keyword-error #x0003348EB220>.
cs-user> (let ((*print-readably* t)) (read-from-string (format nil "~s"
#s(foo :BAR "bar"))))
; Evaluation aborted on #<system::simple-keyword-error #x0003348EB240>.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3432970&group_id=1355

[ clisp-Bugs-3498026 ] *** - SYSTEM::DO-FORMAT-CHARACTER: variable SYSTEM::*FORMAT-

[SourceForge.net <no...@so...>]

Bugs item #3498026, was opened at 2012-03-06 14:35
Message generated for change (Tracker Item Submitted) made by mak08
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3498026&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: lisp error
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Michael Kappert (mak08)
Assigned to: Bruno Haible (haible)
Summary: *** - SYSTEM::DO-FORMAT-CHARACTER: variable SYSTEM::*FORMAT-

Initial Comment:
A somewht pathological error, but this is a bug I think, and it hides the actual error:

$ clisp  -norc
...
GNU CLISP 2.49+ (2010-07-17)
...
[1]> (funcall (compile nil (lambda () (format () "~c" 0))))

*** - SYSTEM::DO-FORMAT-CHARACTER: variable SYSTEM::*FORMAT-CS* has no value
The following restarts are available:
ABORT          :R1      Abort main loop
Break 1 [2]> :r1
[3]> (format () "~c" 0)

*** - The ~C format directive requires a character argument, not 0
      Current point in control string:
        "~c"
         |
The following restarts are available:
ABORT          :R1      Abort main loop
Break 1 [4]> :r1


Best Regards
Michael

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3498026&group_id=1355

[ clisp-Bugs-3485514 ] Cygwin & Pipes

[SourceForge.net <no...@so...>]

Bugs item #3485514, was opened at 2012-02-07 14:46
Message generated for change (Comment added) made by toddcpierce
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3485514&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: build problems
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Todd Pierce (toddcpierce)
Assigned to: Bruno Haible (haible)
Summary: Cygwin & Pipes

Initial Comment:
Hello CLISP crew!

This is not really a bug.  After all, Cygwin just started supporting named pipes.  It appears, though, that the build of CLISP being distributed along with Cygwin doesn't recognize them.  The version of CLISP is this:

Welcome to GNU CLISP 2.48 (2009-07-28) 

Since CLISP is turrning out to be the most comfy place for my artificial intelligence to, well... think.

The behavior I noticed is that CLISP would just lock when trying to write to a pipe.  Writing to files works fine.  Reading from the pipe in another terminal window invoked an error in the CLISP session.

I'll mention this to the Cygwin guys too.  I just want you to be on the same page.

Thanks for all the help.

Sincerely, 

-Todd



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

Comment By: Todd Pierce (toddcpierce)
Date: 2012-03-05 15:45

Message:
Crew:

Opening the file binary or not seems to cause the open file to lock.  Here
(the open hidden in my own function):

[2]> (setf stream (open-sparser "../stanford-parser/fifoin"))

locks the repl.  However, if I try to read from the other end of the pipe,
I do get this error (binary or not):

*** - UNIX error 22 (EINVAL): Invalid argument
The following restarts are available:
ABORT          :R1      Abort main loop

*** - UNIX error 11 (EWOULDBLOCK): Operation would block
The following restarts are available:
ABORT          :R1      Abort main loop

So, I'm not sure what is going on there.  I'm hoping I can just port my
whole project to a real unix system soon.  Whatever happens, I'll mention
this stuff to the cygwin guys.

Thanks for keeping an eye out for me.

-Todd

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

Comment By: Todd Pierce (toddcpierce)
Date: 2012-02-08 15:49

Message:
Someone mentioned that this could be a CRLF issue in the mailing list. 

This is not an issue that occurs when reading or writing to the pipe, this
is something that happens when opening it..  If you can even call Cygwin
having pipes yet.  

As I mentioned before, all the file open/close read/write happens fine. 
It's just when dealing with these new Cygwin pipes that things get
strange.

And no, I still haven't posted this matter with the Cygwin guys...  hell...
I'm homeless.

-Todd cambio y fuera

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

Comment By: Todd Pierce (toddcpierce)
Date: 2012-02-08 15:49

Message:
This bug report is now marked as "pending"/"invalid".
This means that we think that the problem you report is not a problem with
CLISP.
Unless you - the reporter - act within 2 weeks, the bug will be permanently
closed.
Sorry about the inconvenience - we hope your silence means that you agree
that this is not a bug in CLISP.

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

Comment By: Sam Steingold (sds)
Date: 2012-02-08 07:07

Message:
Todd: maybe you could try binary i/o with pipes? 

Reini: clisp accepts all 3 line terminators (cr, lf, crlf) on input, 
please see http://clisp.org/impnotes/clhs-newline.html

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

Comment By: Reini Urban (rurban)
Date: 2012-02-07 17:34

Message:
Maybe because clisp upstream decided to read from pipes with crlf
line-endings, so \n will not end a line. Only the cygwin release reads from
pipes binary. Which makes more sense to cygwin, since we (cygwin) cannot
deal with crlf and we want to pipe streams with line endings to clisp.

Otherwise I see no difference but i haven't tested the new named pipes yet.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3485514&group_id=1355