Trying to get all the lexicons code whipped into shape for an official
release, and I'm running into a weird problem with SBCL when I try to
load the following file:
http://www.flownet.com/ron/lisp/dictionary.lisp
I have to load utilities.lisp first manually because SBCL's "require"
doesn't by default load a correspondingly named file. But when I've
done this, when I then try to load dictionary.lisp it just returns T but
doesn't actually load the file.
If some SBCL wizard could give me a clue why this is happening that
would be much appreciated. This code works fine under CCL and CLisp.
rg
(Just in case you're curious, here's the current state of things: all
lexicon features are now at the "working once" stage under CCL. There's
a bug with deferred bindings under CLisp that I'm trying to hash out
now, and of course I can't get it to work at all under SBCL because of
the issue in this post. The latest code is up on my web site if anyone
wants to help in the porting effort.)
Den Mon, 25 Feb 2008 10:57:19 -0800 skrev Ron Garret:
> Trying to get all the lexicons code whipped into shape for an official
> release, and I'm running into a weird problem with SBCL when I try to
> load the following file:
>
> http://www.flownet.com/ron/lisp/dictionary.lisp
>
> I have to load utilities.lisp first manually because SBCL's "require"
> doesn't by default load a correspondingly named file. But when I've
> done this, when I then try to load dictionary.lisp it just returns T but
> doesn't actually load the file.
>
> If some SBCL wizard could give me a clue why this is happening that
> would be much appreciated. This code works fine under CCL and CLisp.
>
> rg
>
> (Just in case you're curious, here's the current state of things: all
> lexicon features are now at the "working once" stage under CCL. There's
> a bug with deferred bindings under CLisp that I'm trying to hash out
> now, and of course I can't get it to work at all under SBCL because of
> the issue in this post. The latest code is up on my web site if anyone
> wants to help in the porting effort.)
I was just fighting with this, as I happen to be using SBCL. I have no
clue why it doesn't load (it's seriously weird), but the REQUIRE failure
I suspect is because of the fact that SBCL comes with ASDF loaded by
default, which installs its hooks into require, so that (require :foo) is
really equivalent to (asdf:oos 'asdf:load-op :foo). I've defined my own
ASDF system that just depends on {utilities,dictionary,lexicons}.lisp,
but even so, REQUIRE fails to see the previously PROVIDEd dictionary,
which IMHO seems like a bug. Unless you have some specific reasons to
avoid ASDF, I'd suggest using it instead of the REQUIRE/PROVIDE combo, as
they are under-specified and weren't really meant to be used by the
standard.
Cheers,
Maciej
In article <············@news.net.uni-c.dk>,
Maciej Katafiasz <········@gmail.com> wrote:
> Unless you have some specific reasons to avoid ASDF
Just inertia. But I'd still like to know why load is failing silently.
rg
In article <·······························@news.gha.chartermi.net>,
Ron Garret <·········@flownet.com> wrote:
> In article <············@news.net.uni-c.dk>,
> Maciej Katafiasz <········@gmail.com> wrote:
>
> > Unless you have some specific reasons to avoid ASDF
>
> Just inertia. But I'd still like to know why load is failing silently.
Figured it out. The file uses the old Mac end-of-line conventions (CR
instead of LF) and SBCL doesn't like that.
rg
In article <·······························@news.gha.chartermi.net>,
Ron Garret <·········@flownet.com> wrote:
> In article <·······························@news.gha.chartermi.net>,
> Ron Garret <·········@flownet.com> wrote:
>
> > In article <············@news.net.uni-c.dk>,
> > Maciej Katafiasz <········@gmail.com> wrote:
> >
> > > Unless you have some specific reasons to avoid ASDF
> >
> > Just inertia. But I'd still like to know why load is failing silently.
>
> Figured it out. The file uses the old Mac end-of-line conventions (CR
> instead of LF) and SBCL doesn't like that.
>
> rg
OK, fixed the bug (and a few others), and the demo now works under CCL,
SBCL and CLisp.
Writing up a primer now.
rg
Den Mon, 25 Feb 2008 12:23:04 -0800 skrev Ron Garret:
>> Figured it out. The file uses the old Mac end-of-line conventions (CR
>> instead of LF) and SBCL doesn't like that.
>>
>> rg
>
> OK, fixed the bug (and a few others), and the demo now works under CCL,
> SBCL and CLisp.
Indeed it seems to be working much better now. A small fix: LDEFCLASS and
LDEFMETHOD don't have a &body parameter declared, so SLIME doesn't know
how to indent them. In the case of LDEFCLASS, just s/&rest/&body/, and
for LDEFMETHOD, you'd need to split "&rest args" into "args &body body".
More substantial feedback after I play more with it.
Cheers,
Maciej
In article <············@news.net.uni-c.dk>,
Maciej Katafiasz <········@gmail.com> wrote:
> Den Mon, 25 Feb 2008 12:23:04 -0800 skrev Ron Garret:
>
> >> Figured it out. The file uses the old Mac end-of-line conventions (CR
> >> instead of LF) and SBCL doesn't like that.
> >>
> >> rg
> >
> > OK, fixed the bug (and a few others), and the demo now works under CCL,
> > SBCL and CLisp.
>
> Indeed it seems to be working much better now. A small fix: LDEFCLASS and
> LDEFMETHOD don't have a &body parameter declared, so SLIME doesn't know
> how to indent them. In the case of LDEFCLASS, just s/&rest/&body/, and
> for LDEFMETHOD, you'd need to split "&rest args" into "args &body body".
>
> More substantial feedback after I play more with it.
>
> Cheers,
> Maciej
Thanks!
Since you're already noodling around with it, I've uploaded an
incomplete but still potentially useful version of the primer to
http://www.flownet.com/ron/lisp/Lexicons.doc. You might want to take a
look at it. (Note to fellow Microsoft haters: I will convert it to PDF
when it's done, never fear.)
rg
Ron Garret <·········@flownet.com> writes:
> In article <·······························@news.gha.chartermi.net>,
> Ron Garret <·········@flownet.com> wrote:
> >
> > Just inertia. But I'd still like to know why load is failing silently.
>
> Figured it out. The file uses the old Mac end-of-line conventions (CR
> instead of LF) and SBCL doesn't like that.
Yes. Background for others: Typically the first line of lisp files are
semi-colon comments, and if the end-of-line character isn't what is
expected, the reader treats the entire file as being one single-line
comment. So nothing gets evaluated.
There was actually a nice little code snippet from John DeSoi that I ran
across that helps solve this little problem. It doesn't help with
format strings that use ~<Newline>, though.
#|
Note: Do not put any semicolon comments before this line.
The next forms define a semicolon reader for both #\linefeed
and #\return line endings so Lisp can read Mac, Unix or DOSn
format files.
|#
(defun semicolon-reader (stream char)
(declare (ignore char))
(do ((c #\null)) ((or (char= c #\linefeed) (char= c #\return)))
(setf c (read-char stream nil #\newline t)))
(values))
--
Thomas A. Russ, USC/Information Sciences Institute
From: Richard M Kreuter
Subject: Re: Need help from an SBCL wizard
Date:
Message-ID: <871w70ls8m.fsf@progn.net>
Ron Garret <·········@flownet.com> writes:
> Trying to get all the lexicons code whipped into shape for an official
> release, and I'm running into a weird problem with SBCL when I try to
> load the following file:
>
> http://www.flownet.com/ron/lisp/dictionary.lisp
>
> I have to load utilities.lisp first manually because SBCL's "require"
> doesn't by default load a correspondingly named file. But when I've
> done this, when I then try to load dictionary.lisp it just returns T but
> doesn't actually load the file.
>
> If some SBCL wizard could give me a clue why this is happening that
> would be much appreciated. This code works fine under CCL and CLisp.
Are you sure that "UTILITIES" isn't already present in *MODULES*?
The docstring for REQUIRE explains what SBCL's REQUIRE does in the
one-argument this case; it's also in the manual [1]:
If PATHNAMES is not supplied, functions from the list
*module-provider-functions* are called in order with module-name as
an argument, until one of them returns non-NIL. User code is
responsible for calling provide to indicate a successful load of the
module.
Anyhow, the default functions only look under $SBCL_HOME (which is
usually the neighborhood around the sbcl.core file) for modules, so
something like
(push (lambda (module)
(load (make-pathname :name (string-downcase module)
:type "lisp")))
sb-ext:*module-provider-functions*)
might do what you want to do, maybe.
--
RmK
[1] http://www.sbcl.org/manual/Customization-Hooks-for-Users.html#Customization-Hooks-for-Users