[lkb] Getting Parse results from LKB

[Bernhard Fisseni]

Good evening,

for a course on accesibility in the WWW, a colleague of mine and I (me)
we wanted to try GG as the grammar for German to avoid re-inventing
the grammar wheel; using LKB or pet to interface it with a tts system
seemed a good idea.

But for some reason, I don't find the part of the documentation of
either programme that tells me whether there is any way to easily access
the syntactic representation[2] "from the outside" (e.g. the tty
interface of LKB), getting some plain text or even XML output? (I'm
probably searching for documentation in the wrong places – sorry!)

Could you help me and tell me how to access the syntactic
representation? Or would it be a good idea to have a look at trollet or
the lkb web server and modify what they do (they seem to have access to
syntactic information)? (And, is there any chance to arrive at a
working GUIless LKB with clisp or sbcl in the very near future?)

I'd be grateful for any hints,
Bernhard

[1] Using the binary LKB under Linux would be nice because it installed
quite nicely.

[2] For the moment, syntactic structures seem a bit more important to us
than semantics. It's just too difficult to pronounce MRSes. ;-)

[Stephan Oepen]

hi bernhard,

if what you are primarily interested in are labeled parse trees, e.g.

(S (NP "kim") (VP (V "arrived")))

then you will need to involve the LKB, as PET (for now) has no option
to do the label assignment (which is done post-parsing, and entirely a
display convenience). the ERG and GG on-line web interfaces are a tad
more complex: they run PET behind [incr tsdb()] for improved effiency;
but to get the labeled parse trees, after parsing, the derivation tree
returned by PET is re-built in the LKB (like deterministic parsing), so
as to then read off the tree node labels.

unless efficiency becomes a concern, i would suggest just running the
LKB in tty mode and talking to it through standard in- and output. the
Linux run-time binaries should be feasible, just unset DISPLAY so as to
suppress the GUI. then, writing a command like

(do-parse-tty "Kim arrived")

to the stdin of the LKB process should return one or more trees, which
you should be able to read off its stdout.

regarding CLISP or SBCL, have you tried? in theory, the source should
compile okay in either one, although then functionality will be limited
to tty mode. also, CLISP would not be your most efficient choice, and
rumour has that it the default memory layout in SBCL is insufficient
for large grammars (like the ERG or GG).

all best - oe

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++ Universitetet i Oslo (IFI); Boks 1080 Blindern; 0316 Oslo; ([phone]
+++ CSLI Stanford; Ventura Hall; Stanford, CA 94305; ([phone]
+++ --- ***@csli.stanford.edu; ***@ifi.uio.no; ***@oepen.net ---
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

[Bernhard Fisseni]

Dear Stephan,

thanks for your quick and patient reply!

However, it seems that LKB and I have problems communicating to each
other...

Post by Stephan Oepen
if what you are primarily interested in are labeled parse trees, e.g.
(S (NP "kim") (VP (V "arrived")))
then you will need to involve the LKB, as PET (for now) has no option
to do the label assignment (which is done post-parsing, and entirely a
display convenience). the ERG and GG on-line web interfaces are a tad
more complex: they run PET behind [incr tsdb()] for improved effiency;
but to get the labeled parse trees, after parsing, the derivation tree
returned by PET is re-built in the LKB (like deterministic parsing), so
as to then read off the tree node labels.

This sounds indeed a lot more complex than what we need. In fact, I'd
be happy to "just" have a feature structure showing at least the
functional relationships and syntactic dependencies. This information
must be used during the parsing process, and from Berthold's post I
gather that some access to this information is possible.

Post by Stephan Oepen
unless efficiency becomes a concern, i would suggest just running the
LKB in tty mode and talking to it through standard in- and output. the
Linux run-time binaries should be feasible, just unset DISPLAY so as to
suppress the GUI. then, writing a command like
(do-parse-tty "Kim arrived")
to the stdin of the LKB process should return one or more trees, which
you should be able to read off its stdout.

Unsetting DISPLAY does not work for me — LKB generates an error message
saying that the display cannot be accessed; with DISPLAY set, a graphic
tree is shown, even for "do-parse-tty".

Post by Stephan Oepen
regarding CLISP or SBCL, have you tried? in theory, the source should
compile okay in either one, although then functionality will be limited
to tty mode. also, CLISP would not be your most efficient choice, and
rumour has that it the default memory layout in SBCL is insufficient
for large grammars (like the ERG or GG).

Yes, I tried, and both of them failed during compilation – that's why I
asked. It seemed to me that CLISP was not ignoring some Allegro-related
code as it should have, and sbcl at least had problems discovering an
Intel Mac; yet, on Linux (Kubuntu), it fails, too, with the error message:

debugger invoked on a COMMON-LISP:TYPE-ERROR in thread #<THREAD
"initial thread" {A62F569}>:
The value EXTRA is not of type COMMON-LISP:LIST.

If you're interested in the log, I'll gladly send it to you, but
according to Ann Copestake's Mail <E1GKGWs-00013I-***@mta1.cl.cam.ac.uk>,
LKB doesn't compile with SBCL yet. As we don't use LISP very much, we
don't have any Allegrom license, which seems to be necessary if we want
to do painless modifications to LKB, it seems. I was just hoping you'd
already have found the right LISP voodoo for parasites like us to get
away taking advantage of your work using cheap LISPs. ;-)


Thanks again for your suggestions,
Bernhard

[Ann Copestake]

The most recent version of the LKB should compile under SBCL without graphics
- I think Ben Waldron may have announced this to the developers list but not
to the lkb list. However, I imagine someone will have to fiddle around with
the memory settings to get it to run with GG. If you don't want graphics,
SBCL sounds like an excellent option if the memory location problem can be
overcome: it is faster than Allegro CL on some tests/architectures.

Ann

[Bernhard Fisseni]

Dear Ann,

Post by Ann Copestake
The most recent version of the LKB should compile under SBCL without graphics
- I think Ben Waldron may have announced this to the developers list but not
to the lkb list. However, I imagine someone will have to fiddle around with
the memory settings to get it to run with GG. If you don't want graphics,
SBCL sounds like an excellent option if the memory location problem can be
overcome: it is faster than Allegro CL on some tests/architectures.

Thanks for the suggestion; but as I've already written, at the moment I
can't get LKB (2006-09-05, downloaded from
http://lingo.stanford.edu/ftp/latest/) to compile with SBCL on either
Mac OS 10.4.8 (0.9.17, I invented "darwin.x86.32" as the directory for
binaries in lkb/src/general/sbcl-patches.lisp) with an Intel Mac, nor on
Linux x86/32 (SBCL 0.9.16). In both cases, the error message is the same:
debugger invoked on a COMMON-LISP:TYPE-ERROR in thread
#<THREAD "initial thread" {A62F569}>:
The value EXTRA is not of type COMMON-LISP:LIST.

(Should I post the log somewhere?)

Cheers,
Bernhard

[Ann Copestake]

Post by Bernhard Fisseni
Thanks for the suggestion; but as I've already written, at the moment I
can't get LKB (2006-09-05, downloaded from http://lingo.stanford.edu/ftp/
latest/)

looks like Ben's fixes can't have been checked into latest, but there's a more
recent version in test.

[Bernhard Fisseni]

Post by Bernhard Fisseni
Dear Ann,

Post by Ann Copestake
The most recent version of the LKB should compile under SBCL without graphics
- I think Ben Waldron may have announced this to the developers list but not
to the lkb list. However, I imagine someone will have to fiddle around with
the memory settings to get it to run with GG. If you don't want graphics,
SBCL sounds like an excellent option if the memory location problem can be
overcome: it is faster than Allegro CL on some tests/architectures.

Thanks for the suggestion; but as I've already written, at the moment I
can't get LKB (2006-09-05, downloaded from
http://lingo.stanford.edu/ftp/latest/) to compile with SBCL on either
Mac OS 10.4.8 (0.9.17, I invented "darwin.x86.32" as the directory for
binaries in lkb/src/general/sbcl-patches.lisp) with an Intel Mac, nor on
debugger invoked on a COMMON-LISP:TYPE-ERROR in thread
The value EXTRA is not of type COMMON-LISP:LIST.
(Should I post the log somewhere?)

Or maybe I should first say what I do, in case I missed something
important. Taking the instructions from
http://wiki.delph-in.net/moin/LkbCompilation, I entered:

(load "lkb/src/general/loadup")
(compile-system "lkb" :force t)

before I got the errors.

Cheers,
Bernhard

[Bernhard Fisseni]

Thanks, it seems it loads in sbcl now ("test" version, not "latest") – some
success! And I suppose, the memory issue is responsible for the following
message I get when I try to load GG or ERG?
fake_foreign_call fell through

I don't know, but that's not the error Ben reported, which was

Argh! gc_find_freeish_pages failed (restart_page), nbytes=4456456.

The SBCL discussion is all on the developers list - e.g.,
http://lists.delph-in.net/archive/developers/2006/000566.html
I don't have any other info since I haven't tried it

I'll have a look at that tomorrow, thanks for the pointer!

Actually I'd be worried that that the error you have is due to something else
- have you tried on a smaller grammar? you might also have to have an up to

(read-script-file-aux "lkb/src/data/esslli2k/grammars/grammar9/script")
works. So it might be some kind of memory problem. Under Linux (under
Parallels, 1 of the 1.5 GB on the Mac; no bigger memory in sight), I get
a heap exhaustion for ERG; maybe the fake_foreign_call is a Mac OS problem?

date version of the ERG / GG. If it isn't the memory problem, you might want
to email the developers list with a trace - it's probably better to have the
discussion there than on lkb. or you can email me and I'll forward it.

I don't get a real trace; the script stops with
[...]
Reading preprocessor rules `rondane.fsr'
fatal error encountered in SBCL pid 652:
fake_foreign_call fell through
LDB monitor
ldb>

Is there any way to produce something more useful? (Posting this short
message to the developers' list will only amuse people, won't it?)

Thanks,
Bernhard

[Shuly Wintner]

Post by Bernhard Fisseni
This sounds indeed a lot more complex than what we need. In fact,
I'd be happy to "just" have a feature structure showing at least
the functional relationships and syntactic dependencies. This
information must be used during the parsing process, and from
Berthold's post I gather that some access to this information is
possible.

I should add that this is similar to my request on this list a few
weeks back. The ability to output feature structures, in any format,
to the standard output would be a welcome improvement of LKB. This is
particularly missing for the 'batch processing' option. Running LKB
from the command-line, reading a grammar and a file of input
sentences from the standard input and printing structures to the
standard output would be ideal for me.

Post by Bernhard Fisseni
Unsetting DISPLAY does not work for me — LKB generates an error
message saying that the display cannot be accessed; with DISPLAY
set, a graphic tree is shown, even for "do-parse-tty".

I'm running LKB on a Mac, and unfortunately I can't even run it from
the command line, let alone disable DISPLAY.

Shuly

[Bernhard Fisseni]

Dear Shuly,
[...]

Post by Shuly Wintner

Post by Bernhard Fisseni
I'd be happy to "just" have a feature structure showing at least
the functional relationships and syntactic dependencies. This

[...]

[...]

Post by Shuly Wintner
particularly missing for the 'batch processing' option. Running LKB
from the command-line, reading a grammar and a file of input
sentences from the standard input and printing structures to the
standard output would be ideal for me.

;-) Maybe Philipp, whom Berthold mentioned, has an solved this problem
in some way applicable to our cases? (I suppose some kind of server
mode would be interesting, because it takes quite long to load the grammar.)

Post by Shuly Wintner

Post by Bernhard Fisseni
Unsetting DISPLAY does not work for me — LKB generates an error
message saying that the display cannot be accessed; with DISPLAY
set, a graphic tree is shown, even for "do-parse-tty".

I'm running LKB on a Mac, and unfortunately I can't even run it from
the command line, let alone disable DISPLAY.

What LISP do you use? (And, if LKB doesn't work anyway, isn't DISPLAY
already "disabled"?)

Cheers,
Bernhard

[Berthold Crysmann]

Post by Bernhard Fisseni
Dear Shuly,
[...]

Post by Shuly Wintner

Post by Bernhard Fisseni
I'd be happy to "just" have a feature structure showing at least
the functional relationships and syntactic dependencies. This

[...]
[...]

Post by Shuly Wintner
particularly missing for the 'batch processing' option. Running LKB
from the command-line, reading a grammar and a file of input
sentences from the standard input and printing structures to the
standard output would be ideal for me.

;-) Maybe Philipp, whom Berthold mentioned, has an solved this
problem in some way applicable to our cases? (I suppose some kind of
server mode would be interesting, because it takes quite long to load
the grammar.)

Unfortunately, I think he used the [incr tsdb()] export functionality.
So it was an offline process.

Post by Bernhard Fisseni

Post by Shuly Wintner

Post by Bernhard Fisseni
Unsetting DISPLAY does not work for me — LKB generates an error
message saying that the display cannot be accessed; with DISPLAY
set, a graphic tree is shown, even for "do-parse-tty".

I'm running LKB on a Mac, and unfortunately I can't even run it from
the command line, let alone disable DISPLAY.

What LISP do you use? (And, if LKB doesn't work anyway, isn't DISPLAY
already "disabled"?)
Cheers,
Bernhard

[John Carroll]

Post by Shuly Wintner

Post by Bernhard Fisseni
This sounds indeed a lot more complex than what we need. In fact,
I'd be happy to "just" have a feature structure showing at least
the functional relationships and syntactic dependencies. This
information must be used during the parsing process, and from
Berthold's post I gather that some access to this information is
possible.

I should add that this is similar to my request on this list a few
weeks back. The ability to output feature structures, in any
format, to the standard output would be a welcome improvement of
LKB. This is particularly missing for the 'batch processing'
option. Running LKB from the command-line, reading a grammar and a
file of input sentences from the standard input and printing
structures to the standard output would be ideal for me.

Shuly,

Once the port to SBCL is stable you'll be able to run the LKB from
the command line on x86 and PPC Macs. The only thing missing then
would be the feature structure printing in batch parse mode.

John

[Stephan Oepen]

Post by John Carroll
Once the port to SBCL is stable you'll be able to run the LKB from
the command line on x86 and PPC Macs. The only thing missing then
would be the feature structure printing in batch parse mode.

as regards (the unofficial) LSP socket interface, it requires threads,
which SBCL only provides on Linux (x86 and AMD64). thus, i am afraid,
shuly and bernhard may be stuck with Linux for the time being.

if there were increasing demand for MacOS (x86), i would be prepared to
work on porting the LKB and [incr tsdb()]. it would require someone to
provide a machine and an (Enterprise-level) ACL and CLIM license.

all best - oe

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++ Universitetet i Oslo (IFI); Boks 1080 Blindern; 0316 Oslo; ([phone]
+++ CSLI Stanford; Ventura Hall; Stanford, CA 94305; ([phone]
+++ --- ***@csli.stanford.edu; ***@ifi.uio.no; ***@oepen.net ---
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

[Stephan Oepen]

hi again, bernhard,

Unsetting DISPLAY does not work for me — LKB generates an error
message saying that the display cannot be accessed; with DISPLAY set,
a graphic tree is shown, even for "do-parse-tty".

apologies, i now see that the LKB with DISPLAY unset does not work the
way i thought it would. we should try fixing that at some point, i.e.
essentially drop back into tty mode when there is no DISPLAY (on Un*x).

i believe getting SBCL to work with GG seems like your best option for
now. however, your query (and the one by shuly) prompted me to dig up
some old notes on the undocumented LSP (linguistic server protocol) in
the LKB. essentially, there is a way of talking an ASCII protocol to
the LKB over a socket connection.

the protocol is old-fashioned: sequences of strings (with C escapes),
numbers, and symbols (say in C identifier syntax) for now. a command
is terminated by a form feed character. optionally, commands can be
prefixed with `wait' to request synchronous execution. this mode is
required for all commands that expect (a) return value(s). for each
command (synchronous or not), the client will see a numerical success
code (preceded by whatever else the command returned) plus a trailing
form feed (to allow both ends to synchronize cleanly). a preliminary
list of (non-)success codes is at the top of `lkb/src/glue/lsp.lsp'.

if you wanted to experiment, please see `lsp.lsp'. i just confirmed
that basic functionality (parsing inputs and retrieving parse tree(s),
AVM(s), or MRS(s)) is there. assuming a functional LKB installation,
try the following:

- launch the `server' script attached below; this should initialize
an LKB sans-GUI, load the ERG, and go into LSP server mode.

- create a socket connection to port 4712 and send commands from the
file `client' attached below. if you have nc(1) installed, simply

cat /tmp/client - | /usr/bin/nc localhost 4712

however, LSP currently only works with Allegro CL, i.e. you would have
to rely on our pre-compiled binaries for the above. also, please note
that LSP remains officially unsupported for the time being :-).

best - oe

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++ Universitetet i Oslo (IFI); Boks 1080 Blindern; 0316 Oslo; ([phone]
+++ CSLI Stanford; Ventura Hall; Stanford, CA 94305; ([phone]
+++ --- ***@csli.stanford.edu; ***@ifi.uio.no; ***@oepen.net ---
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

[Bernhard Fisseni]

Hi Stephan,

thanks very much for the unofficial server/client scripts. I'll play a
bit with them this week; they're probably more trustworthy than my LISP
system hacking would be for the moment.

Cheers,
Bernhard

Post by Stephan Oepen
hi again, bernhard,

Post by Bernhard Fisseni
Unsetting DISPLAY does not work for me — LKB generates an error
message saying that the display cannot be accessed; with DISPLAY set,
a graphic tree is shown, even for "do-parse-tty".

apologies, i now see that the LKB with DISPLAY unset does not work the
way i thought it would. we should try fixing that at some point, i.e.
essentially drop back into tty mode when there is no DISPLAY (on Un*x).
i believe getting SBCL to work with GG seems like your best option for
now. however, your query (and the one by shuly) prompted me to dig up
some old notes on the undocumented LSP (linguistic server protocol) in
the LKB. essentially, there is a way of talking an ASCII protocol to
the LKB over a socket connection.
the protocol is old-fashioned: sequences of strings (with C escapes),
numbers, and symbols (say in C identifier syntax) for now. a command
is terminated by a form feed character. optionally, commands can be
prefixed with `wait' to request synchronous execution. this mode is
required for all commands that expect (a) return value(s). for each
command (synchronous or not), the client will see a numerical success
code (preceded by whatever else the command returned) plus a trailing
form feed (to allow both ends to synchronize cleanly). a preliminary
list of (non-)success codes is at the top of `lkb/src/glue/lsp.lsp'.
if you wanted to experiment, please see `lsp.lsp'. i just confirmed
that basic functionality (parsing inputs and retrieving parse tree(s),
AVM(s), or MRS(s)) is there. assuming a functional LKB installation,
- launch the `server' script attached below; this should initialize
an LKB sans-GUI, load the ERG, and go into LSP server mode.
- create a socket connection to port 4712 and send commands from the
file `client' attached below. if you have nc(1) installed, simply
cat /tmp/client - | /usr/bin/nc localhost 4712
however, LSP currently only works with Allegro CL, i.e. you would have
to rely on our pre-compiled binaries for the above. also, please note
that LSP remains officially unsupported for the time being :-).
best - oe
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++ Universitetet i Oslo (IFI); Boks 1080 Blindern; 0316 Oslo; ([phone]
+++ CSLI Stanford; Ventura Hall; Stanford, CA 94305; ([phone]
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

[Berthold Crysmann]

Post by Bernhard Fisseni
Good evening,
for a course on accesibility in the WWW, a colleague of mine and I (me)
we wanted to try GG as the grammar for German to avoid re-inventing
the grammar wheel; using LKB or pet to interface it with a tts system
seemed a good idea.

Dear Bernhard,

this looks like a very interesting application. If you need any
information grammar-wise, feel free to contact me.

Somewhat related to your TTS scenario, there is a most recent MA
thesis submitted by Philipp von Böselager at Cologne University
(Phonetik/Sprachliche Informationsverarbeitung), where he interfaced
GG (in generation mode) with the MARY text-to-speech system, using the
grammar as the basis for disambiguating prosody in a CTS setting. The
component takes HPSG trees ("functional" rule back bone and labelled
PS-tree) as input to XSLT style sheets that insert prosodic mark-up for
the MARY TTS-engine. He also ran experiments on the disambiguation
effect of the synthesized prosody with some good results. If you are
interested in this work, I can let him know.

Cheers,

Berthold

Post by Bernhard Fisseni
But for some reason, I don't find the part of the documentation of
either programme that tells me whether there is any way to easily access
the syntactic representation[2] "from the outside" (e.g. the tty
interface of LKB), getting some plain text or even XML output? (I'm
probably searching for documentation in the wrong places – sorry!)
Could you help me and tell me how to access the syntactic
representation? Or would it be a good idea to have a look at trollet or
the lkb web server and modify what they do (they seem to have access to
syntactic information)? (And, is there any chance to arrive at a
working GUIless LKB with clisp or sbcl in the very near future?)
I'd be grateful for any hints,
Bernhard
[1] Using the binary LKB under Linux would be nice because it installed
quite nicely.
[2] For the moment, syntactic structures seem a bit more important to us
than semantics. It's just too difficult to pronounce MRSes. ;-)

[Bernhard Fisseni]

Dear Berthold,

Post by Berthold Crysmann

Post by Bernhard Fisseni
for a course on accesibility in the WWW, a colleague of mine and I (me)
we wanted to try GG as the grammar for German to avoid re-inventing
the grammar wheel; using LKB or pet to interface it with a tts system
seemed a good idea.

this looks like a very interesting application. If you need any
information grammar-wise, feel free to contact me.

Thank you very much for the offer! I'll suggest GG to our students –
and tell them that there's a friendly maintainer (to prevent spamming, I
could act as a relay if you wish).

Post by Berthold Crysmann
Somewhat related to your TTS scenario, there is a most recent MA
thesis submitted by Philipp von Böselager at Cologne University
(Phonetik/Sprachliche Informationsverarbeitung), where he interfaced
GG (in generation mode) with the MARY text-to-speech system, using the
grammar as the basis for disambiguating prosody in a CTS setting. The
component takes HPSG trees ("functional" rule back bone and labelled
PS-tree) as input to XSLT style sheets that insert prosodic mark-up for
the MARY TTS-engine. He also ran experiments on the disambiguation
effect of the synthesized prosody with some good results. If you are
interested in this work, I can let him know.

This sounds very interesting (for myself and for our course) and a bit
like the reverse of what we want to do with GG. If he feels able to
travel the long distance from Cologne to Bonn, he would be very welcome ;-)

Cheers,
Bernhard

PS: Maybe we should continue off-list?

[Ann Copestake]

unfortunately I don't know whether there's any way of getting
something better in terms of an error message. That sort of thing is
Lisp specific and I haven't tried SBCL. If the small grammar works in
MacOS, then I'd be inclined to think it's just the way that the memory
symptom shows up in Mac vs Linux. I don't think anyone on developers
will laugh if you post that, and it might be useful info, but I also
can't promise you'll get much help - it'd only be if someone with a
Mac is prepared to play with SBCL. Probably easiest to start with the
Linux version and see whether you can figure out how to recompile SBCL
- Ben posted something which suggested he'd found instructions on how
to do it, and if you can't work it out, maybe the SBCL crowd could
help. (If you do work it out, let us know, so we can put instructions
on the Wiki, or register and do that yourself!)

Ann

[Bernhard Fisseni]

Dear Ann,

Post by Ann Copestake
unfortunately I don't know whether there's any way of getting
something better in terms of an error message. That sort of thing is
Lisp specific and I haven't tried SBCL. If the small grammar works in
MacOS, then I'd be inclined to think it's just the way that the memory
symptom shows up in Mac vs Linux. I don't think anyone on developers
will laugh if you post that, and it might be useful info, but I also
can't promise you'll get much help - it'd only be if someone with a
Mac is prepared to play with SBCL. Probably easiest to start with the
Linux version and see whether you can figure out how to recompile SBCL
- Ben posted something which suggested he'd found instructions on how
to do it, and if you can't work it out, maybe the SBCL crowd could
help. (If you do work it out, let us know, so we can put instructions
on the Wiki, or register and do that yourself!)

It seems that what was meant to be a short test is evolving into
something more ;-). I'll first try LSP which Stephan sent (because if
it works, we can stay with the “official” builds), and have a look at
the Delphin and the SBCL developers' list archive, for lack of time
probably only this weekend (because I'd like to have LKB running on my
Mac natively and possibly be able to play with changing it).

Google only knows of two recent mentions of "fake_foreign_call fell
through" in chats, so it might have to do with the pretty new Intel Mac
version, I guess.

Another problem is that the scripts for loading GG set some values (like
"LAST-PARSES"), which aren't initialised if I load LKB in SBCL; I've
tried to guess appropriate values, but maybe I've messed up something,
that's why I've tried to load ERG first (i.e. get a working SBCL version
able to load big grammars).


Thanks again for your quick and helpful replies,
Bernhard