Discussion: Packaging and Delivery
July 20 (Mon) 16:30--17:00
Moderator: Emily Bender, Francis Bond; Scribe: Richard Bergmair
Recent great improvements in ease of deployment of DELPH-IN tools. SVN, LOGON distribution, ubuntu-nlp. Some issues remain --- loss of working windows version of LKB, a lot of reliance on Oslo, components are not tested in a variety of environments.
- share knowledge of the various "distributions"
- UW bootable disc
- Ubuntu NLP
- dependency on CLIM (and Allegro CL)
- discuss the state of DELPH-IN tools on other OSes (Mac, MS)
- where should we package glue scripts? In the grammar or in the distribution?
- can we define sensible defaults for these
- client scripts
- tsdb cpu definitions
- where should we put "universal" files?
- predicates.tdl, mrs.tdl mtr.tdl
- How to add new tools to the distributions?
Some additional background:
Date: Tue, 21 Apr 2009 14:50:25 +0900 From: Francis Bond <firstname.lastname@example.org> To: email@example.com Subject: [delph-in] DELPHIN Agenda G'day, On the developers list Emily suggested: > I've had conversations with some of you about breaking free of > Franz: My question is whether we could pool the funds we would be > putting into these licenses for the next couple of years and use them > to hire someone to do the UI coding necessary to undo our reliance > on CLIM. Perhaps it's time to renew that discussion? I propose this to be added for the agenda at the upcoming Summit at Barcelona. I volunteer to chair the session, and would like to request any developers who will be attending, especially people working on the LISP code base, to attend.
Date: Tue, 21 Apr 2009 16:38:09 +0100 From: Ann Copestake <Ann.Copestake@cl.cam.ac.uk> To: firstname.lastname@example.org Cc: Ann.Copestake@cl.cam.ac.uk, email@example.com Subject: Re: [delph-in] DELPHIN Agenda I'm afraid I won't be able to make it to the Barcelona meeting. I had assumed I'd be able to escape from JHU for a couple of days but it turns out that's not possible. I'll try and participate in this session via some sort of videolink, however. I'm afraid we're not buying ACL licences here, other than the single user Windows licence, so there isn't any significant money for the pool. I'm expecting to distribute SBCL versions of the *MRS code at some point (separate from the LKB). Most currently looks OK under SBCL - it's a matter of tidying it up and keeping it working.
SBCL Known Issues
No CLIM => no text entry box, no type hierarchy viewer
no [incr tsdb()] <old, partial patch available from Ben>
no LOGON (=> no web demonstrators, among other things)
- not yet a consensus to support it for all subsytems
Windows problem is an issue because Bulgarian friends of Valia's were trying to "join" the group, and were trying to use Windows. Francis has had numerous requests from Korea etc. as well.
Dan reports that Ann values her Windows user group as well, and that she thinks that VirtualBox is a possible solution to that, and has tested it.
Stephan: It seems we are no longer supporting Windows. Hoping that Cambridge (possibly together with UW) will provide instructions for less technically-minded users to use the VirtualBox solution.
Emily: UW sys-admin could support the live CD, which is also used for teaching at UW.
Stephan: At Oslo we're commited to continue supporting the Linux license for Allegro, so a similar problem to the Windows problem should not occur for Linux.
Emily: UW does as well.
Fracis: NICT no longer does.
Can we break free of Allegro?
Dan: Ann has focused on MRS code, core functionality for porting to SBCL.
Yi: Bernd Kiefer is working (in his own time) on a Java visualization utility to interface with PET. (potential replacement of the current CLIM functionality).
Dan: There is free "slave labor" for this as Bernd is teaching a Java class and has students working on it.
Francis: long range goal, as SBCL is still not a viable replacement for what we are doing with CLIM. no consensus to support SBCL for all subsystems.
Berthold: still font issues with LUI.
Francis: code for pango-LUI now available
Francis: Perhaps the only reason why DELPH-IN hasn't taken Japan in a storm is that you can't enter Japanese into a parse window. At least we can cut and paste now. That was a big improvement. Getting rid of CLIM and getting rid of Allegro are two different issues.
Tim: ...got a project where we build a web environment where we do tree display and direct input of strings, as well as l-path style queries. It's running in a browser, maybe that's not a good idea.
Stephan: ...maybe it's the way to go.
Tsuji-group have released some of their visualization code
Tim: not quite a viable solution at the moment. (only runs in certain cases, uses a lot of CPU etc.)
Stephan: I've seen several rather complex user-interactions that are hosted in browsers. I'd be looking at browser-hosted applications rather than yet another widget library. (HTML + DOM + CSS + ...)
Student at UW working on a C# parser for TDL. Basically rewriting cheap?
...speculation concerning the benefits. maybe better integration with Windows, but cheap currently runs in windows.
Emily: started because he has this website called thai language dot com. tried to integrate DELPH-IN tools. started building the TDL parser as a learning exercises.
Francis: barrier to entrance for adding features to CHEAP is very high, since you have to please everybody involved.
Dan: doesn't sound like something that has a high benefit for people here, but no objection to students trying to learn tings.
more on packaging
Rebecca: an official way of putting things into SVN repositories?
Stephan: LOGON was originally only aimed at the people at the three sites working on LOGON. ...we should support traditional LinGO install scripts. That's the primary deliverable for the public, particularly non-power users. Happy to make LOGON trees available, but shouldn't become the primary "delivery vehicle".
Rebecca: Rather than a PUBLIC distribution, is there a central archive where we put stuff to share amongst us.
Stephan: There is now an official DELPH-IN repository, distinct from the one for LOGON. Anyone who wants to host a DELPH-IN project can have their subversion repository established there. People are supposed to put it into the right place. should be decided on a case-by-case basis. ...other consortia do this (GNU, Redhat, ...)
Berthold: What if there is a functional dependency with LOGON.
Stephan: Tools should be independent. A distribution happens by getting all the tools. There shouldn't be a dependency on the entire distribution, only between individual tools.
Bill: There is a DELPH-IN Ruby "gem", that currently I'm the only developer of. Hosted on rubyforge.
Dan: cloud computing kernel, that could sit on amazon elastic cloud or something similar. We were trying to get that setup with acrolynx. Any experience?
Yi: Set up ad-hoc grid computing engine.
Emily: (added online) SIDGrid (NSF sponsored supercomputing for social sciences) might also be relevant as a grid to use.