ACE processing deadlocks on empty string for input

[goodmami]

If an input file to ACE has an empty string (e.g., if the last line in a file is terminated with a newline), then PyDelphin deadlocks waiting for a certain line of output from ACE. This is what ACE would say:

$ ace -g ../../grammars/erg-1214-x86-64-0.9.27.dat 

SKIP: 


NOTE: ignore

The NOTE line is on stderr, and only occurs for actual blank input. Compare this to another SKIP message for non-empty input:

$ ace -g ../../grammars/erg-1214-x86-64-0.9.27.dat 
a
NOTE: 0 readings, added 78 / 1 edges to chart (9 fully instantiated, 1 actives used, 1 passives used)	RAM: 465k
SKIP: a

Generation and Transfer, however, do not return anything, so this will need to be detected prior to sending (the same could be done for parsing, too). Maybe just fabricating a SKIP message for the response is the way to go.

More troubling is how generation and transfer don't return anything for non-MRS input. It seems to wait until a full MRS has been read (e.g., entering [\n doesn't do anything, but then ]\n causes it to say there are 0 results). Perhaps PyDelphin needs to validate that the input for generation and transfer are actual MRSs and only send those that are.

[goodmami]

Other findings for transfer/generation:

• ACE seems to count the number of brackets. [ [ ]\n does not trigger processing, but the next ]\n does.
• ACE does not ignore escaped brackets when counting. [ \] and [ \\] both trigger processing.
• Multiple MRSs on one line are possible; [ ] [ ] triggers processing for two inputs (there are two sets of outputs).

I think for AceTransferer and AceGenerator, the interact() method should just raise an exception if the input is not a simple MRS (based on simple bracket matching rather than actual MRS parsing)

[goodmami]

Maybe raising an exception is too much, as it could be a situation that occurs with normal input files (that is, blank lines). Instead, mocking a response with the appropriate NOTE and SKIP lines could be less disruptive and still useful.

[fcbond]

Maybe, now that your PhD is over, it may be time to look at a direct python to c interface, to avoid these kinds of problems.

[goodmami]

Yes, it's something I've wanted to do for a while, but there are several things holding me back:

1. ACE is not ready to be used as a library; in particular, Woodley has said (as I recall) that there's no easy way to give ACE a simplemrs string and have it parse to an internal MRS structure, e.g., for generation.
2. It would take a significant amount of time to accomplish the above C changes as well as the necessary bridge to/from Python.
3. It would complicate the distribution of PyDelphin. Either users would need to compile the extensions when they install PyDelphin, or I would need to ship pre-built binaries for a variety of platforms.

Maintaining this stdin/stdout interface already takes a bit of time, so (2) maybe isn't the strongest argument.

[arademaker]

Why is Python the only alternative? ;-) Lua, http://www.lua.org, has a much better integration with C.

[goodmami]

@arademaker Python isn't really the problem. I've done some work in Cython and I think it would be straightforward to create C bindings that way. The problem is that ACE is not engineered to be driven through bindings, so much of the effort would be spent refitting ACE for such usage.

And I would be happy to see a LuaDelphin. Having multiple implementations strengthens our formalisms and frameworks.