Re: [lkb] Getting Parse results from LKB

Dear Stephan,

thanks for your quick and patient reply!

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

Scripsit Stephan Oepen di=C4=93 16.10.2006 13:58:
> if what you are primarily interested in are labeled parse trees, e.g.
>=20
>   (S (NP "kim") (VP (V "arrived")))
>=20
> 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=20
be happy to "just" have a feature structure showing at least the=20
functional relationships and syntactic dependencies.  This information=20
must be used during the parsing process, and from Berthold's post I=20
gather that some access to this information is possible.

> 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
>=20
>   (do-parse-tty "Kim arrived")
>=20
> 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 =E2=80=94 LKB generates an error m=
essage=20
saying that the display cannot be accessed; with DISPLAY set, a graphic=20
tree is shown, even for "do-parse-tty".

> 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 =E2=80=93 that's=
 why I=20
asked.  It seemed to me that CLISP was not ignoring some Allegro-related=20
  code as it should have, and sbcl at least had problems discovering an=20
Intel Mac; yet, on Linux (Kubuntu), it fails, too, with the error message=
:

   debugger invoked on a COMMON-LISP:TYPE-ERROR in thread #<THREAD=20
"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=20
according to Ann Copestake's Mail <[email protected]>,=20
LKB doesn't compile with SBCL yet.  As we don't use LISP very much, we=20
don't have any Allegrom license, which seems to be necessary if we want=20
to do painless modifications to LKB, it seems.  I was just hoping you'd=20
already have found the right LISP voodoo for parasites like us to get=20
away taking advantage of your work using cheap LISPs. ;-)


Thanks again for your suggestions,
Bernhard