[developers] LKB on Windows

Emily M. Bender emily.m.bender at gmail.com
Tue Apr 21 05:17:29 CEST 2009


Hello all,

At UW we certainly have web capacity, and we have a site-license
for ACL (and CLIM) on linux, but not Windows.  At least, I believe
it's a proper license and not a lease.  I could probably learn how to
manage the build (with some assistance from our local tech gurus).
However, our budget situation at UW is presently quite dire, and so
I don't have great confidence that we will continue to have this license.

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?

Regarding Richard's suggestion about the ASP model, while it
could be an interesting thing to add to the DELPH-IN inventory,
I think that there will remain a userbase for the LKB at least who
want it installed locally.  If you're using the LKB for grammar engineering
(rather than batch processing), any latency in displaying the various
windows is quite annoying.

Emily

On Sun, Apr 19, 2009 at 4:43 AM, Stephan Oepen <oe at ifi.uio.no> wrote:
> hi again, my apologies for a tardy follow-up to this thread!
>
>> Currently (2009-04-14) there is no working Windows version available
>> for download as the lisp license has expired.  [...] Ann and Stephen
>> know about it, and hope to fix it at some stage (I think).
>
> well, to be precise: i can do the knowing.  ann (or someone else) will
> have to do the fixing.  DELPH-IN work at oslo makes no use of Windows,
> so we do not have the infrastructure.
>
> but maybe this is a good opportunity to start a broader discussion: on
> how to distribute responsibilities among ourselves.  anyone who could
> see themselves get involved in packaging of DELPH-IN resources, please
> read on!
>
> for the past several years, we have provided LKB and [incr tsdb()] run-
> time binaries for 32-bit Windows and 32- and 64-bit Linux.  being able
> to build and distribute these binaries requires an Allegro Common Lisp
> license in `good standing' (with active maintenance), i.e. there is an
> annual cost involved.  in recent years, LinGO was responsible for 32-
> bit Linux, UiO for 64-bit Linux, and cambridge for Windows; i took the
> role of a `build master': coordinating (to a certain degree), creating
> Linux binaries, maintaining the `install' script and download site.  i
> would now like to pass on this responsibility to someone else.
>
> the cambridge license expired sometime last fall, which to our surprise
> rendered existing builds for Windows dysfunctional (owed to the type of
> license, which was only `leased').  ann is aiming to renew her license,
> but she is currently unsure as to when this can happen and for how long
> she will be able to provide Windows run-time binaries in the future.
>
> all of the above relates to the so-called LinGO builds, i.e. the bundle
> of LKB, [incr tsdb()], and the ERG available for download from stanford
> (e.g. via the `install' script described under `LkbInstallation' on the
> wiki).
>
> in more recent developments, i have started to make available the exact
> development environment originally used for the LOGON MT project, i.e.
> a much larger bundle of tools, the so-called LOGON tree (see `LogonTop'
> on the wiki).  this is effectively an alternate way of doing a DELPH-IN
> install, but there are important differences: (a) LOGON is primarily my
> way of organizing (DELPH-IN) projects at UiO and close partners, hence
> it may at times use older versions of individual components or include
> experimental new features; (b) LOGON makes more restrictive assumptions
> about the use environment: only Linux (both 32- and 64-bit) and Allegro
> CL are supported, accessible via SVN only; and (c) the LOGON tree uses
> a lot of disk space (a minimum of four gigabytes) and is `intrusive' in
> how it expects to be installed.
>
> in the future, i would like to focus my (nowadays more limited) time on
> the LOGON tree.  but i believe it cannot replace the older distribution
> methods, e.g. we need the more lightweight, more general-purpose LinGO
> builds (or something similar) for new users, use in teaching, folks who
> only want part of the bundle (typically the LKB) or different platforms
> (typically Windows).  so, in practical terms, there are different types
> of user groups, and the LOGON distribution only accomdates a small sub-
> set of these.
>
> --- in conclusion, we are looking for volunteers to take over the LinGO
> build infrastructure.  ideally, this would be a site with ACL licenses,
> preferably not as leases, for all current platforms; or a federation of
> sites who complement each other in terms of platform-specific licenses.
> furthermore, one site would have to provide a web server with download
> space, similar to the current `http://lingo.stanford.edu/ftp/'.  we can
> wrap a virtual DELPH-IN address around that web server, which will make
> it easier to `move around' the actual server in the future.  finally, i
> think there should be one individual who takes the `build master' role,
> i.e. someone who understands how things `hang together', and who would
> maintain (and revise) the build setup over time (essentially, a complex
> Makefile).  as i am trying to demonstrate just now, this need not be a
> lifetime job, but in my view there should be a commitment for at least
> a few years :-).
>
> please either reply to the list or to `lkb-bugs at csli.stanford.edu', to
> include all parties involved.
>
>                                                  best wishes  -  oe
>
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> +++ Universitetet i Oslo (IFI); Boks 1080 Blindern; 0316 Oslo; (+47) 2284 0125
> +++     CSLI Stanford; Ventura Hall; Stanford, CA 94305; (+1 650) 723 0515
> +++       --- oe at ifi.uio.no; oe at csli.stanford.edu; stephan at oepen.net ---
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>




More information about the developers mailing list