[developers] LKB on Windows

Stephan Oepen oe at ifi.uio.no
Sun Apr 19 13:43:33 CEST 2009


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