[developers] consolidating LKB and [incr tsdb()] versions

[Ann Copestake]

Go for it! The mrsmunge code was still used in a number of individual 
projects even after the creation of the much more powerful transfer rule 
mechanism, but (as far as I am concerned) has been entirely superseded 
by the python code that Alex (and others) wrote to manipulate DMRS.

Best wishes,

Ann

On 31/07/2020 17:52, Stephan Oepen wrote:
> hi again, john (and all):
>
> ann and emily, please read on.
>
>> in terms of internal DELPH-IN responsibilities, the current LKB trunk used to be packaged via what we call the LinGO builds (http://lingo.delph-in.net) and the Ubuntu+LKB live CD (https://wiki.ling.washington.edu/bin/view.cgi/Main/KnoppixLKB).  both are maintained by UW, so i am not quite sure about the breadth of their user base?  but i am wondering whether these UW builds could move to using the FOS code in the foreseeable future (seeing as i am proposing to officially call an end ?
> i sent the above (incomplete) message somewhat hastily during the
> summit, so that folks in the LKB (FOS) tutorial could look at it then
> and there.
>
> in the meantime, john and i have started consolidating the FOS and the
> LOGON branches of the LKB and [incr tsdb()] code bases.  we hope to
> have a unified version available in a week or two, which would mean
> that LKB and [incr tsdb()] functionality will again be more closely
> synchronized across the two branches (some functionality will only
> remain available in the LOGON environment, though, e.g. due to
> dependencies on external, linux-only binaries).
>
> we would like to propose that this new, actively developed version of
> the LKB and [incr tsdb()] become the 'trunk' in the DELPH-IN
> SubVersioN repository sometime in late august.  the current 'trunk'
> (where there has not been active development for the past few years)
> would then be preserved as a tag (or possibly a branch, if there was
> an expectation of future revisions).  at that point, the LinGO builds
> and Ubuntu+LKB creation (both maintained at UW) would likely need some
> attention, to either work off the new tag or adapt the build
> environment to the new version.
>
> once the consolidation is complete, i would be tempted to spring-clean
> the LKB and [incr tsdb()] code bases, seeking to remove 'dead' code,
> for example sub-modules that have been superseded by newer
> developments or have long fallen out of use and are not actively
> maintained.  the following candidates for removal come to my mind (but
> there are likely more):
>
> src/glue/sppp.lsp (precursor to REPP; oe)
> src/main/ltemplates.lsp (unused since mid-1990s; oe)
> src/mrs/spell.lisp (ERG-specific and long unused; ann)
> src/mrs/mrsmunge.lisp (superseded by transfer rules; ann)
> src/mt/fragments.lisp (oe)
> src/mt/smt.lisp (oe)
> src/preprocess/ (SPPP reimplementation, SAF, SMAF; ben)
>
> i imagine john and i should take a joint pass and compile a more
> definite list of candidates for code cleaning for review.  in the list
> above, i have tried to indicate who i believe was the original code
> owner.  ann, hoping you have read this far: would you be okay with
> some purging of long unused code?  everyone else, if you suspect you
> might be using any of the above sub-modules, please get in touch with
> john and me!
>
> best wishes, oe
>
>