[Openmcl-devel] ILISP & compiling

[Gary Byers]

On Thu, 21 Feb 2002 lambda at mac.com wrote:

> I'm fairly new to common lisp, so forgive me if any of these
> questions are simply my fault for not knowing common lisp well
> enough. If the answer to any of these questions is RTFM, please
> point out where in TFM to look. Thanks!
>
> I have a problem using ILISP and loading the file I'm currently
> working on into OpenMCL. When I type C-z l in a file, it asks if
> I want to compile it first. If I say no, it runs just fine. If I
> say yes, OpenMCL prints the following:
>
> ;;;Compile /Users/lambda/Development/Common Lisp/nlet.lisp
>
> #P"/Users/lambda/Development/Common Lisp/nlet.pfsl"
> NIL
> NIL
> ? > Error: Unbound variable: \\377
>  > While executing: LOAD-FROM-STREAM
>  > Type :GO to continue, :POP to abort.
>  > If continued: Retry getting the value of \\377.
> Type :? for other options.
>
> This confuses me, since if I run compile file by hand, I get a
> dfsl file, which works just fine. I thought pfsl files were for
> linux; I'm running Darwin. Why does C-z l produce a pfsl file,
> and why doesn't it load? When I ran M-x ilisp-compile-inits, it
> generated pfsl files, but running OpenMCL within ILISP seems to
> work OK. Am I being incredibly dense?
>

No; I'm being slightly (or more) lazy.

The ILISP patches for OpenMCL were written for LinuxPPC; the file
ilisp-opemcl.el defines ILISP-BINARY-EXTENSION,
ILISP-INIT-BINARY-EXTENSION, and ILISP-BINARY-COMMAND as
(effectively) "pfsl".  If these definitions are removed, ILISP
will ask the lisp (via COMPILE-FILE-PATHNAME) for the pathname-type
to use for FASL files.

I probably should say something about this on the web site; I've been
under the impression that ILISP 5.12 (with OpenMCL support, including
this fix) will be released any day now, and that it'd be simpler to
refer people to it than it would be to generate another patch and
instructions.  I've been under that impression for over a month now,
so I'm starting to wonder ...

If it's not clear, the symptom you're seeing is:
 a) ILISP tells COMPILE-FILE to produce an output file with a .pfsl
    extension.
 b) LOAD sees that its argument isn't a FASL file (e.g, doesn't have
    a .dfsl extension under MacOSX/Darwin) and tries to load the
    file as if it was lisp source code.  It isn't.

> I was also wondering if there were any way to get ilisp to
> recognize the fact that the prompt that OpenMCL prints causes
> the indentation to increase by two characters. When I type a
> multiple line statement in the interaction buffer, the second
> line is always indented two spaces behind what it should be.
>
>  > (dufun foo (x)
>    (+ 1 x))

I don't know enough about how ILISP does things to know how hard this
is to change. If no one else on this list knows, you might check the
ILISP page at sourceforge.

>
> One last question. I've downloaded the SERIES package from
> sourceforge, and it compiles and tests just fine, but when I try
> and run (series::install), I get the following error:
>
>  > Error: Using #<Package "SERIES"> in #<Package "CCL">
>  >        would cause name conflicts with symbols already present
> in that package:
>  >        MASK  SERIES:MASK
>  >        SPLIT  SERIES:SPLIT
>  >        UNTIL  SERIES:UNTIL
>  >
>  > While executing: USE-PACKAGE-1
>  > Type :GO to continue, :POP to abort.
>  > If continued: Try again to use #<Package "SERIES"> in #<Package "CCL">
> Type :? for other options.
>
> If I add an (in-package "COMMON-LISP-USER"), it works fine, but
> then I have to call common-lisp-user::foo instead of just foo.
> Maybe I don't understand how packages work? I thought that
> common-lisp-user was supposed to be the default interaction
> package.

The COMMON-LISP-USER package is supposed to be the default initial
package (and shouldn't contain anything that'd conflict with anything
inherited from any packages it uses.)

The FAQ on the web site actually mentions this.

If and when OpenMCL is releaseed in a more user-friendly,
ready-for-prime-time way, there should be some additional changes that
would make it harder than it currently is to accidentally redefine
built-in functions (in addition to setting *PACKAGE* correctly.)

The heap image that's distributed is one that's
oriented toward making it easy to work -on- OpenMCL, but not necessarily
towards making it easier to work -in- by isolating the implementation
>from the environment.

Turning the former type of image into the latter isn't too hard (just
a matter of loading a little bit of code and calling SAVE-APPLICATION.)
I'll try to dust that code off and explain this better in the next
release.

>
> Thanks for the help,
> Brian
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel
>
>


_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel