Re: please help test the CMUCL 19b release
On Mon, 13 Jun 2005, Nicolas Neuss wrote: > > ... while more algebraically minded people (like me, > > for example) avoid it like hell. > > And what do you use then? Always labels/named-let? More or less. (Except, for example, when working with screamer, which cannot code-walk labels. Then, the best technique available seems to directly use the fixed-point principle. But screamer is not really a beautiful solution for non-deterministic problems anyway.) But sometimes, a "loop" just is not the right abstraction for what you want to do. In such cases, it is best to take a deep breath, think again what the actual idea which you want to catch is, and use metalinguistic abstraction to catch just that. -- regards, [EMAIL PROTECTED] (o_ Thomas Fischbacher - http://www.cip.physik.uni-muenchen.de/~tf //\ (lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y) V_/_ (if (= x 0) y (g g (- x 1) (* x y n 1)) (Debian GNU)
Re: please help test the CMUCL 19b release
Thomas Fischbacher <[EMAIL PROTECTED]> writes: > ... while more algebraically minded people (like me, > for example) avoid it like hell. And what do you use then? Always labels/named-let? Nicolas.
Re: please help test the CMUCL 19b release
On Sun, 12 Jun 2005, Nikodemus Siivola wrote: > I suspect one reason some people dislike loop is that very few > implementation get all of it right, making things more confusing then > they really are. One of the main reasons why some people avoid loop is that it is generally much harder to reason about the correctness of an iterative block of code than for equivalent recursive code that makes structural induction (even if it's only over natural numbers) explicit. (Besides this, it's easier to port loop-free code to other functional languages.) My impression is that people with a background in numerical calculations will generally prefer a loopish style, presumably because that's what they were brought up with, while more algebraically minded people (like me, for example) avoid it like hell. -- regards, [EMAIL PROTECTED] (o_ Thomas Fischbacher - http://www.cip.physik.uni-muenchen.de/~tf //\ (lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y) V_/_ (if (= x 0) y (g g (- x 1) (* x y n 1)) (Debian GNU)
Re: Fun with LOOP <= Re: please help test the CMUCL 19b release
GP lisper <[EMAIL PROTECTED]> writes: > [a good explanation with reference to ANS 6.1.1.6] OK, you've convinced me. Seems to me a little unintuitive, but maybe there are situations where it can be useful in the way it is specified. > -- > The LOOP construct is really neat, it's got lots of knobs to turn! > Don't push the yellow one on the bottom. :-) Thanks, Nicolas.
Fun with LOOP <= Re: please help test the CMUCL 19b release
On Sun, 12 Jun 2005 18:40:48 +0100, <[EMAIL PROTECTED]> wrote: > GP lisper <[EMAIL PROTECTED]> writes: >> On Sun, 12 Jun 2005 12:30:01 +0300 (EEST), <[EMAIL PROTECTED]> wrote: >>> On Sun, 12 Jun 2005, Nicolas Neuss wrote: >>> >>> (loop with m = 5 >>> initially (setq m 3) >>> for i below m do (princ i)) >>> >>> should print only "012", no? >> >> After reading 6.1.1.6, I say "no" still. The progn for the prologue is: >> (setq m 3) >> >> and then 'm' is set to 5 every pass thru the loop. >> >> On the other hand, I keep wondering what you see that I miss... > > From the page which you said you read: > > A with clause introduces a variable binding and an optional initial > value. The initial values are calculated in the order in which the > with clauses occur. > > Things which "with" clauses do not do include any kind of stepping or > setting at each iteration round the loop. (loop with m = 5 initially (setq m 0) for i below m do (princ i)) ==> 01234 But (loop with m = 5 initially (setq m 0) for i below m do (princ m)) ==> 0 Which matches your reply. So the clause "for i below m do (princ m)" is translated to "for i below 5 do (princ m)" before the loop prologue is run. That follows "All variables are initialized first, regardless of where the establishing clauses appear in the source." (JonL CLtL2 26.3.1) Thanks! I think...depends if I get run over in the next c.l.l. LOOP thread. Or more likely, how bad I get run over -- The LOOP construct is really neat, it's got lots of knobs to turn! Don't push the yellow one on the bottom.
Re: please help test the CMUCL 19b release
GP lisper <[EMAIL PROTECTED]> writes: > On Sun, 12 Jun 2005 12:30:01 +0300 (EEST), <[EMAIL PROTECTED]> wrote: >> On Sun, 12 Jun 2005, Nicolas Neuss wrote: >> >> (loop with m = 5 >> initially (setq m 3) >> for i below m do (princ i)) >> >> should print only "012", no? > > After reading 6.1.1.6, I say "no" still. The progn for the prologue is: > (setq m 3) > > and then 'm' is set to 5 every pass thru the loop. > > On the other hand, I keep wondering what you see that I miss... Words? >From the page which you said you read: A with clause introduces a variable binding and an optional initial value. The initial values are calculated in the order in which the with clauses occur. Things which "with" clauses do not do include any kind of stepping or setting at each iteration round the loop. Cheers, Christophe
Re: please help test the CMUCL 19b release
On Sun, 12 Jun 2005 12:30:01 +0300 (EEST), <[EMAIL PROTECTED]> wrote: > On Sun, 12 Jun 2005, Nicolas Neuss wrote: > > (loop with m = 5 > initially (setq m 3) > for i below m do (princ i)) > > should print only "012", no? After reading 6.1.1.6, I say "no" still. The progn for the prologue is: (setq m 3) and then 'm' is set to 5 every pass thru the loop. On the other hand, I keep wondering what you see that I miss... > I suspect one reason some people dislike loop is that very few > implementation get all of it right, making things more confusing then > they really are. The syntax is different, but I've seen several different syntactical forms over the years. I remember hating the new syntax in BIND 7 (over BIND 4) and rarely getting it right for sometime. Using BIND 7 was confusing and annoying and I avoided it if possible. Once I forgot that I disliked the BIND 7 syntax, I could write near error-free configs. I think I forgot 'bind 7 hate' shortly after needing some feature in BIND 7 unavailable in BIND 4. Perhaps LOOP is similar, the different syntax is annoying until you really need LOOP. Winston & Horn (3rd) say "LOOP never stops, almost". I have one problem like that, so I'm wandering off to read 26.1 in CLtL2. -- With sufficient thrust, pigs fly fine.
Re: please help test the CMUCL 19b release
Nikodemus Siivola <[EMAIL PROTECTED]> writes:
> Not vague at all. ("012" is right.) SBCL is wrong here too.
>
> I suspect one reason some people dislike loop is that very few
> implementation get all of it right, making things more confusing then they
> really are.
Is there any implementation which gets this right? Allegro, CLISP, and
Lispworks all print "01234". (Maybe their LOOPs have all a common
ancestor?)
Nicolas.
Re: please help test the CMUCL 19b release
On Sun, 12 Jun 2005, Nicolas Neuss wrote:
(loop with m = 5
initially (setq m 3)
for i below m do (princ i))
should print only "012", no?
> second one is simply false. Look at 6.1.1.6 (LOOP: Order of Execution).
> This is clearly not an example. The problem is that it is somewhat vague.
>From 6.1.7.2:
"The initially construct causes the supplied compound-forms to be
evaluated in the loop prologue, which precedes all loop code except for
initial settings supplied by constructs with, for, or as. The code for any
initially clauses is executed in the order in which the clauses appeared
in the loop."
Not vague at all. ("012" is right.) SBCL is wrong here too.
I suspect one reason some people dislike loop is that very few
implementation get all of it right, making things more confusing then
they really are.
Cheers,
-- Nikodemus Schemer: "Buddha is small, clean, and serious."
Lispnik: "Buddha is big, has hairy armpits, and laughs."
Re: please help test the CMUCL 19b release
GP lisper <[EMAIL PROTECTED]> writes: > On Sat, 11 Jun 2005 21:52:49 +0200, <[EMAIL PROTECTED]> wrote: >> Nicolas Neuss <[EMAIL PROTECTED]> writes: >> >>> P.S.: Maybe this is also the right time for this bug report: >>> >>> (loop with m = 5 >>> initially (setq m 3) >>> for i below m do (princ i)) >>> >>> should print only "012", no? >> >> Hmm, SBCL/CLISP/Allegro behave the same. I guess this would be ^^^ (i.e. they print "01234") >> something for the loop haters. Good that I didn't post it in cll:-) > > Ah, initially m is 3 in the prologue to loop, and on each body pass > thru the loop, m is 5. At least that is my understanding (and you > notice I'm hiding from cll too). I like the Graham comments "No one > understands loop" and the "ANSI spec just consists of examples". I don't like them, because the first one is true in a strict sense for every complex program (do you know every quirk of C, for example?), the second one is simply false. Look at 6.1.1.6 (LOOP: Order of Execution). This is clearly not an example. The problem is that it is somewhat vague. If I parse it correctly, my form above should print "012". Nicolas.
Re: please help test the CMUCL 19b release
On Sat, 11 Jun 2005 21:52:49 +0200, <[EMAIL PROTECTED]> wrote: > Nicolas Neuss <[EMAIL PROTECTED]> writes: > >> P.S.: Maybe this is also the right time for this bug report: >> >> (loop with m = 5 >> initially (setq m 3) >> for i below m do (princ i)) >> >> should print only "012", no? > > Hmm, SBCL/CLISP/Allegro behave the same. I guess this would be > something for the loop haters. Good that I didn't post it in cll:-) Ah, initially m is 3 in the prologue to loop, and on each body pass thru the loop, m is 5. At least that is my understanding (and you notice I'm hiding from cll too). I like the Graham comments "No one understands loop" and the "ANSI spec just consists of examples". -- With sufficient thrust, pigs fly fine.
Re: please help test the CMUCL 19b release
Nicolas Neuss <[EMAIL PROTECTED]> writes: > P.S.: Maybe this is also the right time for this bug report: > > (loop with m = 5 > initially (setq m 3) > for i below m do (princ i)) > > should print only "012", no? Hmm, SBCL/CLISP/Allegro behave the same. I guess this would be something for the loop haters. Good that I didn't post it in cll:-) Nicolas.
Re: please help test the CMUCL 19b release
Hello, Femlisp works fine with the 19b pre-release. The speed is the same as before. Thank you for all the work, Nicolas. P.S.: Maybe this is also the right time for this bug report: (loop with m = 5 initially (setq m 3) for i below m do (princ i)) should print only "012", no?
Re: please help test the CMUCL 19b release
Andras Simon <[EMAIL PROTECTED]> writes: > Your distribution's package manager should tell you which package these > libraries belong to. E.g: > > [EMAIL PROTECTED] j]$ rpm -qf /usr/X11R6/lib/libXm.so.3 > openmotif-2.2.3-6.FC3.1 As I said elsewhere in this thread, I have Lesstif 0.93.94. Ray, however, would like to know which Motif version it is compatible with. But you give a good hint. From /usr/share/doc/lesstif-0.93.94/INSTALL.txt: As of LessTif 0.87.2 the build system is capable of building multiple LessTif libraries. The purpose of this is to have several libraries that are compatible with several releases of OSF/Motif®. Starting with 0.93.3 we install our Motif 2.1 version by default. Though some functionality is still missing it sounds more reasonable to use that version nowadays. This was introduced because an increasing number of people are using Motif 2.* functions, and the binary releases of LessTif only supported the 1.2 version of Motif. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
Re: please help test the CMUCL 19b release
On Sat, 11 Jun 2005, Paolo Amoroso wrote: > > Examining /usr/X11R6/lib/libXm.so.2.0.1 and /usr/X11R6/lib/libXm.a > with strings doesn't turn out any Motif version number. Your distribution's package manager should tell you which package these libraries belong to. E.g: [EMAIL PROTECTED] j]$ rpm -qf /usr/X11R6/lib/libXm.so.3 openmotif-2.2.3-6.FC3.1 Andras
Re: please help test the CMUCL 19b release
GP lisper <[EMAIL PROTECTED]> writes:
> If you know where libXm is located, adjust the root of the find search..
> If you have NFS (or other) mounted X libs, remove the '-mount'
>
> find /usr -mount -name "libXm.*" -ls -exec strings "{}" \; | grep -i Version
> | grep -i Motif
>
> In my case:
> the libXm.so.3.0.2 is Motif Version 2.2.3
> the libXm.so.2.1 is Motif Version 2.1.30
I get:
motifVersion
MotifVersion
motifVersion
MotifVersion
motifVersion
MotifVersion
motifVersion
MotifVersion
If I run this command instead:
find /usr -mount -name "libXm.*" -ls
I get:
1603 1608 -rw-r--r-- 1 root root 1643316 Dec 11 2003
/usr/X11R6/lib/libXm.a
16854744 1252 -rwxr-xr-x 1 root root 1281268 Dec 11 2003
/usr/X11R6/lib/libXm.so.2.0.1
168592324 -rwxr-xr-x 1 root root 940 Dec 11 2003
/usr/X11R6/lib/libXm.la
168592950 lrwxrwxrwx 1 root root 14 Nov 1 2004
/usr/X11R6/lib/libXm.so.2 -> libXm.so.2.0.1
167894100 lrwxrwxrwx 1 root root 14 Nov 1 2004
/usr/X11R6/lib/libXm.so -> libXm.so.2.0.1
Examining /usr/X11R6/lib/libXm.so.2.0.1 and /usr/X11R6/lib/libXm.a
with strings doesn't turn out any Motif version number.
Paolo
--
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
Re: please help test the CMUCL 19b release
On Fri, 10 Jun 2005 15:32:44 -0400, <[EMAIL PROTECTED]> wrote:
>> "Paolo" == Paolo Amoroso <[EMAIL PROTECTED]> writes:
>
> >> Also, can you tell me what version of Motif are you using? I know
> >> it's LessTif, but is it the Motif 2.1 compatible version or something
> >> else?
>
>Paolo> Huh... How do I find out?
>
> Other than that, I don't know. I don't know much about Motif either.
Brute Force!
If you know where libXm is located, adjust the root of the find search..
If you have NFS (or other) mounted X libs, remove the '-mount'
find /usr -mount -name "libXm.*" -ls -exec strings "{}" \; | grep -i Version |
grep -i Motif
In my case:
the libXm.so.3.0.2 is Motif Version 2.2.3
the libXm.so.2.1 is Motif Version 2.1.30
--
With sufficient thrust, pigs fly fine.
Re: please help test the CMUCL 19b release
> "Paolo" == Paolo Amoroso <[EMAIL PROTECTED]> writes: >> Also, can you tell me what version of Motif are you using? I know >> it's LessTif, but is it the Motif 2.1 compatible version or something >> else? Paolo> Huh... How do I find out? My libXm.so was linked to LessTif/Motif2.1/libXm.so.x, so I assume that's Motif 2.1. Other than that, I don't know. I don't know much about Motif either. Ray
Re: please help test the CMUCL 19b release
Raymond Toy <[EMAIL PROTECTED]> writes: > Paolo> Warning: XmFontListCreate() is an obsolete function! > > Paolo> Warning: Toolkit Server -- XmFontListCreate() is an obsolete > function! > > Paolo> Warning: XmFontListAdd() is an obsolete function! > > Paolo> Warning: Toolkit Server -- XmFontListAdd() is an obsolete > function! > > > Do you know where those warnings come from? I don't get them. I don't know, I don't know Motif much. > Also, can you tell me what version of Motif are you using? I know > it's LessTif, but is it the Motif 2.1 compatible version or something > else? Huh... How do I find out? Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
Re: please help test the CMUCL 19b release
> "Paolo" == Paolo Amoroso <[EMAIL PROTECTED]> writes: Paolo> Raymond Toy <[EMAIL PROTECTED]> writes: >> Can you try the 19b-pre1-a linux binary in the experimental directory? Paolo> I Paolo> It works fine: Paolo> * (inspect *package*) Paolo> Starting server: Paolo>will_fork = False Paolo>will_trace = False Paolo>No Inet domain socket created. Paolo>path = /tmp/.motif_socket-p4675 Paolo> Waiting for connection. Paolo> Accepting client on Unix socket. Paolo> Accepted client on fd 4 Paolo> Server not forking. Paolo> Warning: XmFontListCreate() is an obsolete function! Paolo> Warning: Toolkit Server -- XmFontListCreate() is an obsolete function! Paolo> Warning: XmFontListAdd() is an obsolete function! Paolo> Warning: Toolkit Server -- XmFontListAdd() is an obsolete function! Do you know where those warnings come from? I don't get them. Also, can you tell me what version of Motif are you using? I know it's LessTif, but is it the Motif 2.1 compatible version or something else? I also found out that I actually have OpenMotif 3.0 on my home machine. But I'm unable to get gcc to link that version. gcc says it can't find -lXm and I don't know why. But using my old LessTif seems to be ok. Ray
Re: please help test the CMUCL 19b release
GP lisper <[EMAIL PROTECTED]> writes: > Have you built your own CMUCL? Just rebuild an image, but remove the I have never tried to build CMUCL from source. > McCLIM probably doesn't use CLM, correct? McCLIM doesn't use CLM, only CLX. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
Re: please help test the CMUCL 19b release
Raymond Toy <[EMAIL PROTECTED]> writes: > Can you try the 19b-pre1-a linux binary in the experimental directory? I It works fine: * (inspect *package*) Starting server: will_fork = False will_trace = False No Inet domain socket created. path = /tmp/.motif_socket-p4675 Waiting for connection. Accepting client on Unix socket. Accepted client on fd 4 Server not forking. Warning: XmFontListCreate() is an obsolete function! Warning: Toolkit Server -- XmFontListCreate() is an obsolete function! Warning: XmFontListAdd() is an obsolete function! Warning: Toolkit Server -- XmFontListAdd() is an obsolete function! # * Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
Re: please help test the CMUCL 19b release
Paolo Amoroso wrote: > Eric Marsden <[EMAIL PROTECTED]> writes: > > >>CMUCL version 19b will be released in July. We would appreciate help >>in testing the prerelease binaries that are available for various Can you try the 19b-pre1-a linux binary in the experimental directory? I rebuilt it on my home machine with motifd dynamically linked to motif 2.1 (Lesstif 0.92.6). I hope it works. Ray
Re: please help test the CMUCL 19b release
On Wed, 08 Jun 2005 21:39:07 +0200, <[EMAIL PROTECTED]> wrote:
>> On Wed, 08 Jun 2005 13:54:54 +0200, <[EMAIL PROTECTED]> wrote:
>>> Eric Marsden <[EMAIL PROTECTED]> writes:
>>>
CMUCL version 19b will be released in July. We would appreciate help
...
- try connecting to your X11 display:
,
| CL-USER> (require :clx)
| ; Loading
#p"/opt/cmucl-19b-pre/lib/cmucl/lib/subsystems/clx-library.x86f".
| ("CLX")
>>>
>>> ; Loading
>>> #P"/usr/local/cmucl-2005-06/lib/cmucl/lib/subsystems/clx-library.x86f".
>>> Warning: XLIB previously used the following packages:
>>> (#)
>>> ("CLX")
>>> *
>>
> In this case I forgot the OK. Except for the warning, which I have
> been noticing since pre-19a snapshots, CLX loads and works fine: I
> heavily use it with McCLIM.
I think that warning turns out to be important. There is a mismatch
in the libs, you uncover it later with the inspector. I used to have
a similar problem with the debugger, until I compiled CMUCL myself.
Have you built your own CMUCL? Just rebuild an image, but remove the
-static and -dynamic from Config.x86 first and build the extras. The
docs work fine, except that you need to start with a simple image,
without the "extras".
McCLIM probably doesn't use CLM, correct?
--
With sufficient thrust, pigs fly fine.
Re: please help test the CMUCL 19b release
GP lisper <[EMAIL PROTECTED]> writes:
> On Wed, 08 Jun 2005 13:54:54 +0200, <[EMAIL PROTECTED]> wrote:
>> Eric Marsden <[EMAIL PROTECTED]> writes:
>>
>>> CMUCL version 19b will be released in July. We would appreciate help
>>> ...
>>>- try connecting to your X11 display:
>>>
>>> ,
>>> | CL-USER> (require :clx)
>>> | ; Loading
>>> #p"/opt/cmucl-19b-pre/lib/cmucl/lib/subsystems/clx-library.x86f".
>>> | ("CLX")
>>
>> ; Loading
>> #P"/usr/local/cmucl-2005-06/lib/cmucl/lib/subsystems/clx-library.x86f".
>> Warning: XLIB previously used the following packages:
>> (#)
>> ("CLX")
>> *
>
> I note that generally you type 'OK', but didn't happen to do so here. I get:
In this case I forgot the OK. Except for the warning, which I have
been noticing since pre-19a snapshots, CLX loads and works fine: I
heavily use it with McCLIM.
Paolo
--
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
Re: please help test the CMUCL 19b release
On Wed, 08 Jun 2005 13:54:54 +0200, <[EMAIL PROTECTED]> wrote:
> Eric Marsden <[EMAIL PROTECTED]> writes:
>
>> CMUCL version 19b will be released in July. We would appreciate help
>> ...
>>- try connecting to your X11 display:
>>
>> ,
>> | CL-USER> (require :clx)
>> | ; Loading
>> #p"/opt/cmucl-19b-pre/lib/cmucl/lib/subsystems/clx-library.x86f".
>> | ("CLX")
>
> ; Loading
> #P"/usr/local/cmucl-2005-06/lib/cmucl/lib/subsystems/clx-library.x86f".
> Warning: XLIB previously used the following packages:
> (#)
> ("CLX")
> *
I note that generally you type 'OK', but didn't happen to do so here. I get:
CL-USER> ("CLX")
; In: "CLX"
; ("CLX")
; Error: Illegal function call.
Invoking debugger...
Starting server:
will_fork = False
will_trace = False
No Inet domain socket created.
path = /tmp/.motif_socket-p20622
Waiting for connection.
Accepting client on Unix socket.
Accepted client on fd 4
Server not forking.
Leaving debugger.
With the graphical debugger popping up. Did that happen?
(alas this is not 19b-pre at the moment)
>> | CL-USER> (inspect *package*)
>
> * (inspect *package*)
>
> A Toolkit error has occurred.
> Encountered error reading packet: Connection reset by peer
>[Condition of type TOOLKIT-INTERNALS::SIMPLE-TOOLKIT-ERROR]
This works fine for me in my April self-produced image (with -static
and -dynamic removed from Config.x86). I'll try to find the time to
make a 19b-relI think I tried that and hit some wall (I probably
needed some additional bootfile).
>
> Restarts:
> 0: [CONTINUE] Ignore problem and continue.
> 1: [KILL-APP] Close current application.
> 2: [ABORT ] Return to Top-Level.
>
> Debug (type H for help)
>
> (TOOLKIT-INTERNALS:TOOLKIT-ERROR # #)
> Source: Error finding source:
> Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer
> exists:
> target:motif/lisp/internals.lisp.
> 0]
> Connection to server broken: Hit EOF while reading packet
> Hit EOF while reading packet
> Error flushed ...
> 0] backtrace
--
With sufficient thrust, pigs fly fine.
Re: please help test the CMUCL 19b release
> "Paolo" == Paolo Amoroso <[EMAIL PROTECTED]> writes:
>> - try using the Motif debugger and inspector:
>>
>> ,
>> | CL-USER> (require :clm)
>> | ; Loading
Paolo> #p"/opt/cmucl-19b-pre/lib/cmucl/lib/subsystems/clm-library.x86f".
>> | ("CLM")
Paolo> OK.
>> | CL-USER> (inspect *package*)
Paolo> * (inspect *package*)
Paolo> Starting server:
Paolo>will_fork = False
Paolo>will_trace = False
Paolo>No Inet domain socket created.
Paolo>path = /tmp/.motif_socket-p4705
Paolo> Waiting for connection.
Paolo> Accepting client on Unix socket.
Paolo> Accepted client on fd 4
Paolo> Server not forking.
Paolo> Warning: Motif server died.
Paolo> Status = :SIGNALED, exit code = 11.
Aargh. I can confirm this problem, even on the machine I used to
build the binaries.
I don't know what the issue is. It works fine on Solaris.
Ray
Re: please help test the CMUCL 19b release
Eric Marsden <[EMAIL PROTECTED]> writes:
> CMUCL version 19b will be released in July. We would appreciate help
> in testing the prerelease binaries that are available for various
I use CMUCL Snapshot (19B) under Slackware Linux 10.0 with a
customized 2.6.10 kernel.
>- try loading shared object files and ".o" object files using the
> function EXT:LOAD-FOREIGN, and check that you can resolve symbols
> in these libraries and call the corresponding functions. For
> example:
>
> ,
> | CL-USER> (ext:load-foreign "/usr/lib/libcrypt.so")
[...]
OK.
>- try dumping an customized CMUCL image (using the function
> EXT:SAVE-LISP) and restarting it.
I do this with McCLIM, and it works fine.
>- try connecting to your X11 display:
>
> ,
> | CL-USER> (require :clx)
> | ; Loading
> #p"/opt/cmucl-19b-pre/lib/cmucl/lib/subsystems/clx-library.x86f".
> | ("CLX")
; Loading
#P"/usr/local/cmucl-2005-06/lib/cmucl/lib/subsystems/clx-library.x86f".
Warning: XLIB previously used the following packages:
(#)
("CLX")
*
> | CL-USER> (ext:open-clx-display)
OK.
>- try using the Motif debugger and inspector:
>
> ,
> | CL-USER> (require :clm)
> | ; Loading
> #p"/opt/cmucl-19b-pre/lib/cmucl/lib/subsystems/clm-library.x86f".
> | ("CLM")
OK.
> | CL-USER> (inspect *package*)
* (inspect *package*)
Starting server:
will_fork = False
will_trace = False
No Inet domain socket created.
path = /tmp/.motif_socket-p4705
Waiting for connection.
Accepting client on Unix socket.
Accepted client on fd 4
Server not forking.
Warning: Motif server died.
Status = :SIGNALED, exit code = 11.
A Toolkit error has occurred.
Encountered error reading packet: Connection reset by peer
[Condition of type TOOLKIT-INTERNALS::SIMPLE-TOOLKIT-ERROR]
Restarts:
0: [CONTINUE] Ignore problem and continue.
1: [KILL-APP] Close current application.
2: [ABORT ] Return to Top-Level.
Debug (type H for help)
(TOOLKIT-INTERNALS:TOOLKIT-ERROR # #)
Source: Error finding source:
Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists:
target:motif/lisp/internals.lisp.
0]
Connection to server broken: Hit EOF while reading packet
Hit EOF while reading packet
Error flushed ...
0] backtrace
0: (TOOLKIT-INTERNALS:TOOLKIT-ERROR # #)
1: (TOOLKIT-INTERNALS::READ-SOME-BYTES #
#
#)
2: (TOOLKIT-INTERNALS:RECEIVE-MESSAGE 5)
3: (TOOLKIT::DISPATCH-SERVER-REPLY 5)
4: (TOOLKIT::WAIT-FOR-SERVER-REPLY 5)
5: (TOOLKIT:IS-MANAGED #)
6: (INTERFACE::VERIFY-CONTROL-PANE-DISPLAYED)
7: (INTERFACE::START-MOTIF-INSPECTOR
#)
8: (INSPECT #
:GRAPHICS)
9: (INTERACTIVE-EVAL (INSPECT *PACKAGE*))
10: (LISP::%TOP-LEVEL)
11: ((LABELS LISP::RESTART-LISP
SAVE-LISP))
0]
I have X.Org 6.7.0 and Lesstif 0.93.94.
>- try using the Hemlock editor:
OK.
Paolo
--
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
