<div dir="ltr">That looks very reasonable! Thanks.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 1, 2020 at 6:04 PM John Carroll <<a href="mailto:J.A.Carroll@sussex.ac.uk">J.A.Carroll@sussex.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div style="overflow-wrap: break-word;"> Hi Francis, <div><br> </div> <div>Thanks for the report and suggestions about LD_LIBARY_PATH. I put a hint about what to do in the README, but it's buried in dense text so not easy to find ("LD_LIBARY_PATH must include <path-to-lkb_fos>/lib/linux.x86.64"). It's a good ides to have a couple of sentences about this in LkbFos.</div> <div><br> </div> <div>Here's what LKB-FOS does on startup:</div> <div><br> </div> <div>* it finds the absolute path to the lkb_fos directory, and from that, it constructs a path to where it thinks bdb.so should be (e.g. on my system this is /home/ubuntu/Documents/delphin/lkb_fos/src/tsdb/linux.x86.64/bdb.so)</div> <div><br> </div> <div>* it attempts to load bdb.so from this path as a shared library</div> <div><br> </div> <div>* if there's an error in this load, it's either because the user has moved bdb.so, or <a href="http://libdb-4.2.so" target="_blank">libdb-4.2.so</a> (which bdb.so depends on) can't be found</div> <div><br> </div> <div>* <a href="http://libdb-4.2.so" target="_blank">libdb-4.2.so</a> will be pulled in if LD_LIBARY_PATH points to lkb_fos/lib/linux.x86.64</div> <div><br> </div> <div><br> </div> <div>Later in a session, if you start up the [incr tsdb()] podium it tries to load libtermcap.so.2; on my system this is in a standard Linux shared library directory so is picked up fine. But evidently this isn't the case for everyone. So to avoid installation fuss, I was just going to provide it in lkb_fos/lib/linux.x86.64 - the file is very small. LOGON also takes this approach. I'll do this in the next LKB-FOS release.</div> <div><br> </div> <div>If DELPHINHOME is set as recommended, then I think the following should be sufficient:</div> <div><br> </div> <div> <div>export LD_LIBRARY_PATH=$DELPHINHOME/lkb_fos/lib/linux.x86.64:$LD_LIBRARY_PATH</div> </div> <div><br> </div> <div>And for the moment, some users will also need to execute:</div> <div><br> </div> <div>ln -s <some system library directory>/libncurses.so.5.7 .../lkb_fos/lib/linux.x86.64/libtermcap.so.2</div> <div><br> </div> <div><br> </div> <div>Does this look reasonable? If so I'll update LkbFos.</div> <div><br> </div> <div>John</div> <div><br> </div> <div> <div><br> <blockquote type="cite"> <div>On 1 Jun 2020, at 05:35, Francis Bond <<a href="mailto:bond@ieee.org" target="_blank">bond@ieee.org</a>> wrote:</div> <br> <div> <div dir="ltr">Hi, <div><br> </div> <div>to get it working on ubuntu 18.04.4, I had to make some libraries visible:</div> <div>bdb.so, <a href="http://libdb-4.2.so" target="_blank">libdb-4.2.so</a>, libtermcap.so.2 </div> <div><br> </div> <div>I did this with:</div> <div>export LD_LIBRARY_PATH=/home/bond/delphin/lkb_fos.2020/src/tsdb/linux.x86.64:/home/bond/delphin/lkb_fos.2020/lib/linux.x86.64<br> </div> <div><br> </div> <div>I also had to link libtermcap.so.2 -> /lib/x86_64-linux-gnu/libncurses.so.5.9</div> <div><br> </div> <div>Maybe we could have a symbolic link from src/tsdb/linux.x86.64/bdb.so to lib/linux.x86.64/bdb.so</div> <div>so that we only have to point to a single directory?</div> <div><br> </div> <div>Should I make an installation section in LkbFos and add the notes there?</div> <div><br> </div> </div> <br> <div class="gmail_quote"> <div dir="ltr" class="gmail_attr">On Fri, May 22, 2020 at 5:39 AM John Carroll <<a href="mailto:J.A.Carroll@sussex.ac.uk" target="_blank">J.A.Carroll@sussex.ac.uk</a>> wrote:<br> </div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Hi all,<br> <br> 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.<br> <br> 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 <a href="http://moin.delph-in.net/LkbGeneration" rel="noreferrer" target="_blank"> http://moin.delph-in.net/LkbGeneration</a>).<br> <br> 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.<br> <br> 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!<br> <br> All the best,<br> <br> John<br> <br> PS The new LKB-FOS contains many other improvements - please see the README. Download link at <a href="http://moin.delph-in.net/LkbFos" rel="noreferrer" target="_blank"> http://moin.delph-in.net/LkbFos</a><br> <br> <br> > <a href="http://lists.delph-in.net/archives/developers/2006/000632.html" rel="noreferrer" target="_blank"> http://lists.delph-in.net/archives/developers/2006/000632.html</a><br> > <br> > [developers] SBCL port<br> > Stephan Oepen oe at <a href="http://csli.Stanford.EDU" rel="noreferrer" target="_blank"> csli.Stanford.EDU</a> <br> > Mon Oct 30 11:23:05 CET 2006<br> > <br> > howdy,<br> > <br> > > But I expect a port would not be too difficult to achieve for either<br> > > of these systems. Stephan, what do you think?<br> > <br> > [incr tsdb()] makes fairly central use of foreign functions, which are <br> > non-standard. also, the [incr tsdb()] GUI depends on threads, which in<br> > SBCL are just barely available (in a way different from the traditional<br> > MP package), and only for Linux on x86 and AMD64 currently. i have no<br> > current plans to port [incr tsdb()] to other Lisps, and personally i am<br> > not too keen on getting other developers involved in that right now. i<br> > would want to review patches to [incr tsdb()] code so as to make sure i<br> > can maintain its overall design. these days i am afraid i have no time<br> > for such activity.<br> > <br> > the LOGON MT architecture is an extension to [incr tsdb()], i.e it has<br> > inherited the same constraints on cross-platform portability. however,<br> > we are about to release a complete run-time edition of LOGON, such that <br> > people will be able to get full functionality without their own license <br> > for Allegro CL.<br> > <br> > more high-level, SBCL does look like a Lisp going the right direction.<br> > but before it makes sense for us to make the coordinated effort towards<br> > supporting the breadth of DELPH-IN software on a new Lisp, we should be<br> > sure of our minimum requirements. the following come to my mind:<br> > <br> > (1) stable, efficient, actively maintained ANSI CL implementation<br> > (2) UniCode strings, including full external format support<br> > (3) cross-platform availability<br> > (4) multi-processing, preferably with Lisp control of scheduler<br> > (5) foreign function interface<br> > (6) high-level OS interface: run-shell-command(), sockets, et al.<br> > <br> > SBCL appears to have all of the above but (4). i know CMU-CL used to<br> > include the traditional MP package, but i have no idea about the other<br> > desiderata there.<br> > <br> > best - oe<br> > <br> > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br> > +++ Universitetet i Oslo (IFI); Boks 1080 Blindern; 0316 Oslo; (+47) 2284 0125<br> > +++ CSLI Stanford; Ventura Hall; Stanford, CA 94305; (+1 650) 723 0515<br> > +++ --- oe at <a href="http://csli.stanford.edu" rel="noreferrer" target="_blank"> csli.stanford.edu</a>; oe at <a href="http://ifi.uio.no" rel="noreferrer" target="_blank"> ifi.uio.no</a>; stephan at <a href="http://oepen.net" rel="noreferrer" target="_blank"> oepen.net</a> ---<br> > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br> <br> <br> </blockquote> </div> <br clear="all"> <div><br> </div> -- <br> <div dir="ltr">Francis Bond <<a href="http://www3.ntu.edu.sg/home/fcbond/" target="_blank">http://www3.ntu.edu.sg/home/fcbond/</a>><br> Division of Linguistics and Multilingual Studies<br> Nanyang Technological University<br> </div> </div> </blockquote> </div> <br> </div> </div> </blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Francis Bond <<a href="http://www3.ntu.edu.sg/home/fcbond/" target="_blank">http://www3.ntu.edu.sg/home/fcbond/</a>><br>Division of Linguistics and Multilingual Studies<br>Nanyang Technological University<br></div>