[developers] LKB-FOS now includes [incr tsdb()]

John Carroll J.A.Carroll at sussex.ac.uk
Thu May 21 23:38:57 CEST 2020


Hi all,

I've just released a new version of LKB-FOS. The main change is that the Linux version includes all of the non-LOGON parts of [incr tsdb()]. The podium runs, and I believe that all of its menu commands are working correctly. I've created a foreign function interface in SBCL for the BDB C program, so training maxent models also works. Anything that's at all CPU-intensive runs a lot quicker than in the LOGON run-time binary.

For macOS, I haven't made a serious attempt at recompiling the core [incr tsdb()] C programs (tsdb, swish++), so there's not much of it that works - the main useful exception being reading and applying maxent models (e.g. as described at the end of http://moin.delph-in.net/LkbGeneration).

No LOGON-specific functionality is available (i.e. source code enabled by the :logon feature), which means that PVM, WWW demo, SVMs and language models, external MT system interfaces etc are missing. If anyone particularly wants one of these features in LKB-FOS, it should be possible now there's a solid foundation to start from.

BTW, below is a relevant posting to the developers list by Stephan in 2006. The previous posting in that thread was over-optimistic: a number of issues (which I won't bore this list with) made the port to SBCL harder than one might have expected. Anyway, I'm pleased to have made progress on this issue 14 years on!

All the best,

John

PS The new LKB-FOS contains many other improvements - please see the README. Download link at http://moin.delph-in.net/LkbFos


> http://lists.delph-in.net/archives/developers/2006/000632.html
> 
> [developers] SBCL port
> Stephan Oepen oe at csli.Stanford.EDU 
> Mon Oct 30 11:23:05 CET 2006
> 
> howdy,
> 
> > But I expect a port would not be too difficult to achieve for either
> > of these systems. Stephan, what do you think?
> 
> [incr tsdb()] makes fairly central use of foreign functions, which are 
> non-standard.  also, the [incr tsdb()] GUI depends on threads, which in
> SBCL are just barely available (in a way different from the traditional
> MP package), and only for Linux on x86 and AMD64 currently.  i have no
> current plans to port [incr tsdb()] to other Lisps, and personally i am
> not too keen on getting other developers involved in that right now.  i
> would want to review patches to [incr tsdb()] code so as to make sure i
> can maintain its overall design.  these days i am afraid i have no time
> for such activity.
> 
> the LOGON MT architecture is an extension to [incr tsdb()], i.e it has
> inherited the same constraints on cross-platform portability.  however,
> we are about to release a complete run-time edition of LOGON, such that 
> people will be able to get full functionality without their own license 
> for Allegro CL.
> 
> more high-level, SBCL does look like a Lisp going the right direction.
> but before it makes sense for us to make the coordinated effort towards
> supporting the breadth of DELPH-IN software on a new Lisp, we should be
> sure of our minimum requirements.  the following come to my mind:
> 
>   (1) stable, efficient, actively maintained ANSI CL implementation
>   (2) UniCode strings, including full external format support
>   (3) cross-platform availability
>   (4) multi-processing, preferably with Lisp control of scheduler
>   (5) foreign function interface
>   (6) high-level OS interface: run-shell-command(), sockets, et al.
> 
> SBCL appears to have all of the above but (4).  i know CMU-CL used to
> include the traditional MP package, but i have no idea about the other
> desiderata there.
> 
>                                                           best  -  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 csli.stanford.edu; oe at ifi.uio.no; stephan at oepen.net ---
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++




More information about the developers mailing list