[developers] Structured output from ACE
Michael Wayne Goodman
goodmami at uw.edu
Fri Jun 24 02:30:59 CEST 2016
I was able to compile ACE (with a change to Makefile to dynamically link
libutil instead of statically; if anyone wants my notes for compiling just
The data now output by ACE will make things much easier, so thanks for
that! I compared the output to what Stephan offers from his RESTful server,
and note a couple of differences:
2. rule and lexical types in the derivation (e.g. the "arrive_v1" in the
derivation for "Abrams arrived." would have type "v_-_le")
I can get (1) with --tsdb-notes, but when combined with --tsdb-stdout it is
concatenated to the stdout line instead of appearing on its own. E.g.:
[...] (:aedges . 23) NOTE: tsdb parse: (:total . 9) [...]
Since the syntax is the same, maybe they can be concatenated without the
"NOTE: tsdb parse: " string?
As for (2), it's not part of UDF derivation trees, nor is it stored in
[incr tsdb()] profiles as far as I know, so I don't think I can reasonably
ask for this. It's not necessary, but it would be nice, if it is something
ACE can easily provide. But I'm not sure where to put it (maybe in the
:flags of a result?).
Also, it seems the --tsdb-stdout is not working fully with generation. The
surface string is being printed in the middle of the s-expression:
$ echo "Abrams arrived." | ./ace -g ~/erg-1214-x86-64-0.9.23.dat | ./ace -g
~/erg-1214-x86-64-0.9.23.dat -e --tsdb-stdout --report-labels
(:results . (Abrams arrived.
((:result-id . 0)(:surface . "Abrams arrived.") [...]
I assume you just got it working in ACE's SVN as a preview for parsing and
not generation, so this is fine for now.
On Thu, Jun 23, 2016 at 4:48 PM Stephan Oepen <oe at ifi.uio.no> wrote:
> > The output is formatted as (a list of) s-expressions, and is identical to
> > the data sent to [incr tsdb()] [...]
> thanks, woodley. that was in fact a thought i too had entertained
> during the API discussion: my RESTful server actually works off [incr
> tsdb()] item structures, so ACE communicating with different callers
> in the outside world using that same format seems utterly plausible to
> me :-).
> cheers, oe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the developers