From: Sashank Varma on
On Apr 14, 3:44 pm, dstein64 <DStei...(a)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.
From: Sashank Varma on
On Apr 14, 3:48 pm, Sashank Varma <varm...(a)gmail.com> wrote:
> On Apr 14, 3:44 pm, dstein64 <DStei...(a)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>
From: Sashank Varma on
One more tidbit.

On Apr 14, 2:50 pm, Sashank Varma <varm...(a)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.
From: Sashank Varma on
On Apr 14, 4:07 pm, vanekl <va...(a)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.
From: Madhu on
[CC attempted to slime-devel list to report a different bug, (*) at the
bottom of my reply]

* Sashank Varma wrote in article
<95319b1d-190d-493c-b0c8-14d1a5491249(a)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