Hi. After several years away from Common Lisp I'm back using it again.
Unfortunately, my old version of MCL won't run on my new MacBook Pro
so I have to learn a new environment. I downloaded Peter's Lispbox
built around ACL. I have been able to struggle through ACL, Emacs, and
Slime for the most part. However, there is one problem that I haven't
been able to solve, and it's starting to piss me off. I'm hoping it's
something you all can help me with.
I have a file of pretty generic ANSI Common Lisp code. If it's in an
Emacs buffer and I hit C-c C-k, the *slime-repl-allegro* buffer tells
me everything went okay:
; SLIME 2005-11-22
;;;; Compile file /Users/sv0f/Desktop/4caps-2.1.lisp ...
;;; Compiling file /Users/sv0f/Desktop/4caps-2.1.lisp
;;; Writing fasl file /Users/sv0f/Desktop/4caps-2.1.fasl
;;; Fasl write complete
The Slime manual says this should both compile the buffer and load the
resulting fasl file.
However, if I attempt to evaluate a special variable defined in the
buffer or call a function, I get an error saying undefined value or
function. In others words, the fasl file has not been loaded.
Surprisingly, the same problem occurs if directly load the fasl file.
That is, if I type "(load "<filename>") in the *slime-repl-allegro*
buffer, I still lack access to its special variabless, functions,
macros, and classes.
However, I have had success with the following workaround: If I split
the file into 6 smaller files, and compile and load each separately
(with C-c C-k), everything works fine.
This has me puzzled. Is it a Slime issue? Or is it an ACL 8.1 Express
issue? (Should I switch to OpenMCL)?
I am new to Common Lisp, but maybe the symbols are being interned to a
different package than the package you are in when calling them. If
this is the case, there would probably something that looks like: (in-
package packagename) in the code. From the REPL, you can access these
functions and other symbols by switching to the relevant package by
typing (in-package packagename) where packagename is the same as in
the code, or by typing 'packagename:x' instead of just 'x' when trying
to access x. I hope this helps. Again, I am still new to the language.
On Apr 14, 5:50 pm, Sashank Varma <·······@gmail.com> wrote:
> Hi. After several years away from Common Lisp I'm back using it again.
> Unfortunately, my old version of MCL won't run on my new MacBook Pro
> so I have to learn a new environment. I downloaded Peter's Lispbox
> built around ACL. I have been able to struggle through ACL, Emacs, and
> Slime for the most part. However, there is one problem that I haven't
> been able to solve, and it's starting to piss me off. I'm hoping it's
> something you all can help me with.
>
> I have a file of pretty generic ANSI Common Lisp code. If it's in an
> Emacs buffer and I hit C-c C-k, the *slime-repl-allegro* buffer tells
> me everything went okay:
>
> ; SLIME 2005-11-22
> ;;;; Compile file /Users/sv0f/Desktop/4caps-2.1.lisp ...
> ;;; Compiling file /Users/sv0f/Desktop/4caps-2.1.lisp
> ;;; Writing fasl file /Users/sv0f/Desktop/4caps-2.1.fasl
> ;;; Fasl write complete
>
> The Slime manual says this should both compile the buffer and load the
> resulting fasl file.
>
> However, if I attempt to evaluate a special variable defined in the
> buffer or call a function, I get an error saying undefined value or
> function. In others words, the fasl file has not been loaded.
>
> Surprisingly, the same problem occurs if directly load the fasl file.
> That is, if I type "(load "<filename>") in the *slime-repl-allegro*
> buffer, I still lack access to its special variabless, functions,
> macros, and classes.
>
> However, I have had success with the following workaround: If I split
> the file into 6 smaller files, and compile and load each separately
> (with C-c C-k), everything works fine.
>
> This has me puzzled. Is it a Slime issue? Or is it an ACL 8.1 Express
> issue? (Should I switch to OpenMCL)?
On Apr 14, 3:44 pm, dstein64 <········@gmail.com> wrote:
> I am new to Common Lisp, but maybe the symbols are being interned to a
> different package than the package you are in when calling them. If
> this is the case, there would probably something that looks like: (in-
> package packagename) in the code. From the REPL, you can access these
> functions and other symbols by switching to the relevant package by
> typing (in-package packagename) where packagename is the same as in
> the code, or by typing 'packagename:x' instead of just 'x' when trying
> to access x. I hope this helps. Again, I am still new to the language.
I should have mentioned: Everything's happening in CL-USER.
On Apr 14, 3:48 pm, Sashank Varma <·······@gmail.com> wrote:
> On Apr 14, 3:44 pm, dstein64 <········@gmail.com> wrote:
>
> > I am new to Common Lisp, but maybe the symbols are being interned to a
> > different package than the package you are in when calling them. If
> > this is the case, there would probably something that looks like: (in-
> > package packagename) in the code. From the REPL, you can access these
> > functions and other symbols by switching to the relevant package by
> > typing (in-package packagename) where packagename is the same as in
> > the code, or by typing 'packagename:x' instead of just 'x' when trying
> > to access x. I hope this helps. Again, I am still new to the language.
>
> I should have mentioned: Everything's happening in CL-USER.
Just to make sure, I compiled/loaded the file again and then searched
each package for occurrences of the "center", which occurs in several
special variables, method names, and macro names. None were found.
;;;; Compile file /Users/sv0f/Desktop/4caps-2.1.lisp ...
;;; Compiling file /Users/sv0f/Desktop/4caps-2.1.lisp
;;; Writing fasl file /Users/sv0f/Desktop/4caps-2.1.fasl
;;; Fasl write complete
CL-USER> (mapc #'(lambda (package)
(format t "~%~A:" (package-name package))
(apropos "center" package)
(format t "~%"))
(list-all-packages))
ACL-SOCKET:
ACLMOP:
ASDF:
COM.GIGAMONKEYS.ASDF-EXTENSIONS:
COMMON-LISP:
COMMON-LISP-USER:
COMPILER:
CROSS-REFERENCE:
DEBUGGER:
DEFSYSTEM:
EXCL:
EXCL.SCM:
FOREIGN-FUNCTIONS:
GARBAGE:
INSPECT:
KEYWORD:
LEP:
LEP-IO:
MULTIPROCESSING:
NET.URI:
NULL-PACKAGE-REPLY-SESSION:
PROFILER:
SLIME-NREGEX:
SWANK:
SWANK-BACKEND:
SWANK-COMPLETION-TEST:
SWANK-IO-PACKAGE:
SWANK-LOADER:
SWANK-MOP:
SYSTEM:
TOP-LEVEL:
(#<The ACL-SOCKET package> #<The ACLMOP package> #<The ASDF package>
#<The COM.GIGAMONKEYS.ASDF-EXTENSIONS package>
#<The COMMON-LISP package> #<The COMMON-LISP-USER package>
#<The COMPILER package> #<The CROSS-REFERENCE package>
#<The DEBUGGER package> #<The DEFSYSTEM package> ...)
CL-USER>
Sashank Varma <·······@gmail.com> writes:
> On Apr 14, 3:48 pm, Sashank Varma <·······@gmail.com> wrote:
>> On Apr 14, 3:44 pm, dstein64 <········@gmail.com> wrote:
>>
>> > I am new to Common Lisp, but maybe the symbols are being interned to a
>> > different package than the package you are in when calling them. If
>> > this is the case, there would probably something that looks like: (in-
>> > package packagename) in the code. From the REPL, you can access these
>> > functions and other symbols by switching to the relevant package by
>> > typing (in-package packagename) where packagename is the same as in
>> > the code, or by typing 'packagename:x' instead of just 'x' when trying
>> > to access x. I hope this helps. Again, I am still new to the language.
>>
>> I should have mentioned: Everything's happening in CL-USER.
>
> Just to make sure, I compiled/loaded the file again and then searched
> each package for occurrences of the "center", which occurs in several
> special variables, method names, and macro names. None were found.
>
> ;;;; Compile file /Users/sv0f/Desktop/4caps-2.1.lisp ...
> ;;; Compiling file /Users/sv0f/Desktop/4caps-2.1.lisp
> ;;; Writing fasl file /Users/sv0f/Desktop/4caps-2.1.fasl
> ;;; Fasl write complete
> CL-USER> (mapc #'(lambda (package)
> (format t "~%~A:" (package-name package))
> (apropos "center" package)
> (format t "~%"))
> (list-all-packages))
Depending on the implementation, APROPOS may or may not be case sensitive.
If it is not, then you won't find any symbol named CENTER with (apropos "center").
Try: (apropos (string-upcase "center"))
Note that STRING-UPCASE is what the lisp reader applies on all the
unescaped symbol characters it reads, by default. See READTABLE-CASE.
If you prefer the output format you've programmed, I'm ok with that,
but a plain APROPOS call gives enough information to know how you can
access the symbol from the current package:
C/USER[6]> (shadow "LONG-SITE-NAME")
T
C/USER[7]> (apropos "SITE-NAME")
COMMON-LISP:LONG-SITE-NAME function
LONG-SITE-NAME
SHORT-SITE-NAME function
--
__Pascal Bourguignon__ http://www.informatimago.com/
Wanna go outside.
Oh, no! Help! I got outside!
Let me back inside!
P� Wed, 16 Apr 2008 21:04:43 +0200, skrev Pascal Bourguignon
<···@informatimago.com>:
> Depending on the implementation, APROPOS may or may not be case
> sensitive.
> If it is not, then you won't find any symbol named CENTER with (apropos
> "center").
>
> Try: (apropos (string-upcase "center"))
>
> Note that STRING-UPCASE is what the lisp reader applies on all the
> unescaped symbol characters it reads, by default. See READTABLE-CASE.
>
>
> If you prefer the output format you've programmed, I'm ok with that,
> but a plain APROPOS call gives enough information to know how you can
> access the symbol from the current package:
>
>
> C/USER[6]> (shadow "LONG-SITE-NAME")
> T
> C/USER[7]> (apropos "SITE-NAME")
> COMMON-LISP:LONG-SITE-NAME function
> LONG-SITE-NAME
> SHORT-SITE-NAME function
>
>
also look at *print-case*
--------------
John Thingstad
One more tidbit.
On Apr 14, 2:50 pm, Sashank Varma <·······@gmail.com> wrote:
>
> ; SLIME 2005-11-22
> ;;;; Compile file /Users/sv0f/Desktop/4caps-2.1.lisp ...
> ;;; Compiling file /Users/sv0f/Desktop/4caps-2.1.lisp
> ;;; Writing fasl file /Users/sv0f/Desktop/4caps-2.1.fasl
> ;;; Fasl write complete
I just checked. The resulting fasl file is only 4k.
> However, I have had success with the following workaround: If I split
> the file into 6 smaller files, and compile and load each separately
> (with C-c C-k), everything works fine.
By contrast, these files range in size from 28K to 124K.
So it looks like C-c C-k is not compiling the original source file,
but it is compiling the smaller ones.
Now I'm wondering whether I'm running up against the limits of the ACL
8.1 Express version. It is a trial version after all.
[CC attempted to slime-devel list to report a different bug, (*) at the
bottom of my reply]
* Sashank Varma wrote in article
<····································@k10g2000prm.googlegroups.com> :
on Mon, 14 Apr 2008 16:40:44 -0700 (PDT):
|
|> ; SLIME 2005-11-22
|> ;;;; Compile file /Users/sv0f/Desktop/4caps-2.1.lisp ...
|> ;;; Compiling file /Users/sv0f/Desktop/4caps-2.1.lisp
|> ;;; Writing fasl file /Users/sv0f/Desktop/4caps-2.1.fasl
|> ;;; Fasl write complete
|
| I just checked. The resulting fasl file is only 4k.
q|
|> However, I have had success with the following workaround: If I split
|> the file into 6 smaller files, and compile and load each separately
|> (with C-c C-k), everything works fine.
|
| By contrast, these files range in size from 28K to 124K.
|
| So it looks like C-c C-k is not compiling the original source file,
| but it is compiling the smaller ones.
|
| Now I'm wondering whether I'm running up against the limits of the ACL
| 8.1 Express version. It is a trial version after all.
Did you try starting up alisp (without SLIME in the picture) and calling
(compile-file 4caps-2.1.lisp").
Is the fasl still 4k ?
It is likely that the problem you face is an external-format issue. The
original source file may not be of the correct CRLF/LF type which ACL is
expecting, and ACL may be reading it as a single comment and generating
an empty fasl. However your smaller files may have been saved in a
different coding system, which ACL groks correctly.
Other lisps (CMUCL, LW) have had similar issues reported.
--
Madhu
PS: Your slime version is very old. I've been using acl81_express (alisp)
on linux with a more recent Slime (CVS 2008-04-06) for a few days now
and have been compiling > 1Mb source files.
(*) I've noticed a different intermittent problem where forms were being
truncated before being sent to ACL (via a file in /tmp) when
*print-lines* is non-NIL. This is a bug in swank-allegro.lisp which
should be rebinding printer variables when printing stuff to send to
lisp. Setting *print-lines* to NIL solves this
Madhu,
Very nice suggestions. One even worked! Read below for the details.
On Apr 14, 9:56 pm, Madhu <·······@meer.net> wrote:
> [CC attempted to slime-devel list to report a different bug, (*) at the
> bottom of my reply]
>
> * Sashank Varma wrote in article
> <····································@k10g2000prm.googlegroups.com> :
> on Mon, 14 Apr 2008 16:40:44 -0700 (PDT):
> |
> |> ; SLIME 2005-11-22
> |> ;;;; Compile file /Users/sv0f/Desktop/4caps-2.1.lisp ...
> |> ;;; Compiling file /Users/sv0f/Desktop/4caps-2.1.lisp
> |> ;;; Writing fasl file /Users/sv0f/Desktop/4caps-2.1.fasl
> |> ;;; Fasl write complete
> |
> | I just checked. The resulting fasl file is only 4k.
>
> Did you try starting up alisp (without SLIME in the picture) and calling
> (compile-file 4caps-2.1.lisp").
>
> Is the fasl still 4k ?
The problem persisted.
> It is likely that the problem you face is an external-format issue. The
> original source file may not be of the correct CRLF/LF type which ACL is
> expecting, and ACL may be reading it as a single comment and generating
> an empty fasl. However your smaller files may have been saved in a
> different coding system, which ACL groks correctly.
>
> Other lisps (CMUCL, LW) have had similar issues reported.
This was exactly the problem. My code had been sitting in files
created once upon a time by MCL. I had been viewing the code just
fine in Emacs, and assumed it was generic enough text, but the CR/LF
incompatibility must have been there. In retrospect, when I broke the
code into smaller files, I created those files from scratch, so they
didn't inherit the old format -- that's why they worked.
I created a fresh version of my file and C-c C-k did the trick.
> PS: Your slime version is very old. I've been using acl81_express (alisp)
> on linux with a more recent Slime (CVS 2008-04-06) for a few days now
> and have been compiling > 1Mb source files.
Good to know. I downloaded it back in August, when I first got this
machine, but didn't start playing with it until a couple of days ago.
I'll get a fresh copy soon.
> (*) I've noticed a different intermittent problem where forms were being
> truncated before being sent to ACL (via a file in /tmp) when
> *print-lines* is non-NIL. This is a bug in swank-allegro.lisp which
> should be rebinding printer variables when printing stuff to send to
> lisp. Setting *print-lines* to NIL solves this
It turns out this wasn't the problem I faced -- *print-lines* was
already set to NIL.
Thanks again.
On Apr 15, 7:43 am, Sashank Varma <·······@gmail.com> wrote:
> Madhu,
>
> Very nice suggestions. One even worked! Read below for the details.
>
> On Apr 14, 9:56 pm, Madhu <·······@meer.net> wrote:
>
>
>
> > [CC attempted to slime-devel list to report a different bug, (*) at the
> > bottom of my reply]
>
> > * Sashank Varma wrote in article
> > <····································@k10g2000prm.googlegroups.com> :
> > on Mon, 14 Apr 2008 16:40:44 -0700 (PDT):
> > |
> > |> ; SLIME 2005-11-22
> > |> ;;;; Compile file /Users/sv0f/Desktop/4caps-2.1.lisp ...
> > |> ;;; Compiling file /Users/sv0f/Desktop/4caps-2.1.lisp
> > |> ;;; Writing fasl file /Users/sv0f/Desktop/4caps-2.1.fasl
> > |> ;;; Fasl write complete
> > |
> > | I just checked. The resulting fasl file is only 4k.
>
> > Did you try starting up alisp (without SLIME in the picture) and calling
> > (compile-file 4caps-2.1.lisp").
>
> > Is the fasl still 4k ?
>
> The problem persisted.
>
> > It is likely that the problem you face is an external-format issue. The
> > original source file may not be of the correct CRLF/LF type which ACL is
> > expecting, and ACL may be reading it as a single comment and generating
> > an empty fasl. However your smaller files may have been saved in a
> > different coding system, which ACL groks correctly.
>
> > Other lisps (CMUCL, LW) have had similar issues reported.
>
> This was exactly the problem. My code had been sitting in files
> created once upon a time by MCL. I had been viewing the code just
> fine in Emacs, and assumed it was generic enough text, but the CR/LF
> incompatibility must have been there. In retrospect, when I broke the
> code into smaller files, I created those files from scratch, so they
> didn't inherit the old format -- that's why they worked.
>
> I created a fresh version of my file and C-c C-k did the trick.
>
> > PS: Your slime version is very old. I've been using acl81_express (alisp)
> > on linux with a more recent Slime (CVS 2008-04-06) for a few days now
> > and have been compiling > 1Mb source files.
>
> Good to know. I downloaded it back in August, when I first got this
> machine, but didn't start playing with it until a couple of days ago.
> I'll get a fresh copy soon.
>
> > (*) I've noticed a different intermittent problem where forms were being
> > truncated before being sent to ACL (via a file in /tmp) when
> > *print-lines* is non-NIL. This is a bug in swank-allegro.lisp which
> > should be rebinding printer variables when printing stuff to send to
> > lisp. Setting *print-lines* to NIL solves this
>
> It turns out this wasn't the problem I faced -- *print-lines* was
> already set to NIL.
>
> Thanks again.
This may be OT, but since you come from MCL, why don't you try LW
Personal?
Cheers
--
Marco
On Apr 15, 1:47 am, Marco Antoniotti <·······@gmail.com> wrote:
>
> This may be OT, but since you come from MCL, why don't you try LW
> Personal?
Actually, I will be starting an academic position in the fall and have
already allocated funds to pay for LW then.
I have to get through the next few months though, and thought it was a
good opportunity to gain some mastery over the Emacs/Slime approach.
Sashank Varma wrote:
> Hi. After several years away from Common Lisp I'm back using it again.
> Unfortunately, my old version of MCL won't run on my new MacBook Pro
> so I have to learn a new environment. I downloaded Peter's Lispbox
> built around ACL. I have been able to struggle through ACL, Emacs, and
> Slime for the most part. However, there is one problem that I haven't
> been able to solve, and it's starting to piss me off. I'm hoping it's
> something you all can help me with.
>
> I have a file of pretty generic ANSI Common Lisp code. If it's in an
> Emacs buffer and I hit C-c C-k, the *slime-repl-allegro* buffer tells
> me everything went okay:
>
> ; SLIME 2005-11-22
> ;;;; Compile file /Users/sv0f/Desktop/4caps-2.1.lisp ...
> ;;; Compiling file /Users/sv0f/Desktop/4caps-2.1.lisp
> ;;; Writing fasl file /Users/sv0f/Desktop/4caps-2.1.fasl
> ;;; Fasl write complete
snip
I don't have anything like your setup, so I'm just riffing here.
What happens if you rename 4caps-2.1.lisp to just 4caps.lisp and
do a C-c C-k? The multiple "dots" in the filename may be a problem.
On Apr 14, 4:07 pm, vanekl <·····@acd.net> wrote:
>
> I don't have anything like your setup, so I'm just riffing here.
> What happens if you rename 4caps-2.1.lisp to just 4caps.lisp and
> do a C-c C-k? The multiple "dots" in the filename may be a problem.
Nice idea. I was hopeful for a moment...but it didn't work.