[pet] Poll to identify actively used functionality in PET
Berthold Crysmann
crysmann at ifk.uni-bonn.de
Mon Jul 12 01:24:27 CEST 2010
On Tue, 2010-07-06 at 19:17 +0200, Bernd Kiefer wrote:
> This mail adresses all people using PET.
>
> We (the developers of PET) are planning major code changes that include
> also the removal of unused or unsupported functionality. We ask for
> your kind contribution to get a better picture of which of it is still
> in use and maybe needs to be supported. If you still actively use one
> of the following, please let us know.
>
> Input formats we'd like to discard:
>
> - pic / pic_counts
> - yy_counts
> - smaf
> - fsr
>
> Diverse options and the functionality behind it (some of them maybe more
> controversial):
>
> -default-les=traditional determine default les by posmapping for all
> lexical gaps
> -no-chart-man Old style chart manipulation aka chart
> dependencies
> -no-hyper Disable hyper-active parsing
This is some magic I was told to use when computing qc paths. If it's
obsolte for that use case, I don't care.
> -no-filter Disable automatically computed rule filter.
> -key=n Selecting the method for determining the rule
> argument that will be filled first
Is this not the flag needed to determine empirically what would be the
best KEY-ARG ? I do appreciate your trust in most grammar developers to
figure that out with pencil and paper, but I personally would like to
keep this functionality.
Berthold
> -lattice (allows combination restrictions specifying path numbers)
> -server (yy -- Stephan?)
>
> The removal of the following functionality has already been agreed
> upon by a lot of people, still, you may also give feedback to that:
>
> - MRS modes that are only supported using Lisp code from the LKB with
> ECL Modes that will still be supported are: native MRX and simple MRS
> Conversion to rmrs formats is planned to be supported by a standalone
> binary
> - FSPP input mode (requires ECL)
>
> Because these are the only modules that require the inclusion of ECL,
> support for ECL in PET will also be removed.
>
> Please take the time for answering us because we don't want to
> create unnecessary problems by removing important functionality.
>
> Best,
> Bernd Kiefer
>
More information about the pet
mailing list