From: Pillsy
Subject: Delivering a .so/.dylib
Date: 
Message-ID: <be967d8d-de0d-4094-96a5-2f3ecf999c4e@18g2000yqa.googlegroups.com>
For a specific project, it would be very useful to be able to deliver
a library that people could link to from C and C++ programs. I have a
pretty large base of Common Lisp code (in SBCL as of now) that
implements 95% of the functionality the users need, and I really would
prefer not to have to rewrite it in C++.

What are my options for this, in terms of Lisp implementations? The
requirements are that people would need to be able to use the library
on Macs and Linux machines, but not Windows, and that it would need to
be based on a free implementation (which is too bad, since it looks
like both ACL and LW will do exactly what I need). Speed is also
pretty important.

I'm given to understand that SBCL does not support this kind of thing,
but other implementations may. Or I can think about a different
strategy.

Thanks in advance,
Pillsy

From: D Herring
Subject: Re: Delivering a .so/.dylib
Date: 
Message-ID: <4a541d45$0$29138$6e1ede2f@read.cnntp.org>
Pillsy wrote:
> For a specific project, it would be very useful to be able to deliver
> a library that people could link to from C and C++ programs. I have a
> pretty large base of Common Lisp code (in SBCL as of now) that
> implements 95% of the functionality the users need, and I really would
> prefer not to have to rewrite it in C++.
> 
> What are my options for this, in terms of Lisp implementations? The
> requirements are that people would need to be able to use the library
> on Macs and Linux machines, but not Windows, and that it would need to
> be based on a free implementation (which is too bad, since it looks
> like both ACL and LW will do exactly what I need). Speed is also
> pretty important.
> 
> I'm given to understand that SBCL does not support this kind of thing,
> but other implementations may. Or I can think about a different
> strategy.

Most lisps are designed to control the external world, not be called 
by it.  Could you have lisp call your user's code?  If not, ECL is the 
easiest free implementation for what you asked for.

ecls.sf.net

- Daniel
From: Pillsy
Subject: Re: Delivering a .so/.dylib
Date: 
Message-ID: <9ef604f5-e169-4129-b6aa-db68a39e4bda@d32g2000yqh.googlegroups.com>
On Jul 8, 12:15 am, D Herring <········@at.tentpost.dot.com> wrote:

> Most lisps are designed to control the external world, not be called
> by it.

So I've noticed. I usually don't mind so much.

> Could you have lisp call your user's code?

That's one possibility that I'm considering. Less ideal, but
possible.

> If not, ECL is the easiest free implementation for what you asked for.

> ecls.sf.net

ECL looks like it may be my best bet. Do you know of existing OSS
efforts that use it in a way like that I describe?

Cheers,
Pillsy
From: Duane Rettig
Subject: Re: Delivering a .so/.dylib
Date: 
Message-ID: <046e05cd-5781-44ba-9f6f-2c8de9951039@y7g2000yqa.googlegroups.com>
On Jul 7, 8:22 pm, Pillsy <·········@gmail.com> wrote:
> For a specific project, it would be very useful to be able to deliver
> a library that people could link to from C and C++ programs. I have a
> pretty large base of Common Lisp code (in SBCL as of now) that
> implements 95% of the functionality the users need, and I really would
> prefer not to have to rewrite it in C++.
>
> What are my options for this, in terms of Lisp implementations? The
> requirements are that people would need to be able to use the library
> on Macs and Linux machines, but not Windows, and that it would need to
> be based on a free implementation (which is too bad, since it looks
> like both ACL and LW will do exactly what I need). Speed is also
> pretty important.
>
> I'm given to understand that SBCL does not support this kind of thing,
> but other implementations may. Or I can think about a different
> strategy.

Check out

http://www.franz.com/support/documentation/current/doc/unix-shared-library.htm

and

http://www.franz.com/support/documentation/current/doc/dll.htm

Duane
From: Pillsy
Subject: Re: Delivering a .so/.dylib
Date: 
Message-ID: <377517d8-81d9-44d7-9d37-e1ee8caa29bb@h11g2000yqb.googlegroups.com>
On Jul 8, 3:39 am, Duane Rettig <·····@franz.com> wrote:
> On Jul 7, 8:22 pm, Pillsy <·········@gmail.com> wrote:
[...]
> > The
> > requirements are that people would need to be able to use the library
> > on Macs and Linux machines, but not Windows, and that it would need to
> > be based on a free implementation (which is too bad, since it looks
> > like both ACL and LW will do exactly what I need). Speed is also
> > pretty important.

> Check out

> http://www.franz.com/support/documentation/current/doc/unix-shared-li...

> and

> http://www.franz.com/support/documentation/current/doc/dll.htm

Exactly what I'm looking for, but probably not something I can sell
the users on, since they'd need to purchase Allegro licenses if they
wanted to modify and maintain the Lisp side of the library themselves.
I guess it can't hurt to ask, though.

Cheers,
Pillsy
From: Rainer Joswig
Subject: Re: Delivering a .so/.dylib
Date: 
Message-ID: <8d3aba51-0d29-4f2e-9426-8f74bb695da4@g31g2000yqc.googlegroups.com>
On 8 Jul., 16:20, Pillsy <·········@gmail.com> wrote:
> On Jul 8, 3:39 am, Duane Rettig <·····@franz.com> wrote:
>
> > On Jul 7, 8:22 pm, Pillsy <·········@gmail.com> wrote:
> [...]
> > > The
> > > requirements are that people would need to be able to use the library
> > > on Macs and Linux machines, but not Windows, and that it would need to
> > > be based on a free implementation (which is too bad, since it looks
> > > like both ACL and LW will do exactly what I need). Speed is also
> > > pretty important.
> > Check out
> >http://www.franz.com/support/documentation/current/doc/unix-shared-li...
> > and
> >http://www.franz.com/support/documentation/current/doc/dll.htm
>
> Exactly what I'm looking for, but probably not something I can sell
> the users on, since they'd need to purchase Allegro licenses if they
> wanted to modify and maintain the Lisp side of the library themselves.
> I guess it can't hurt to ask, though.
>
> Cheers,
> Pillsy

LispWorks:

  Dynamic libraries can be built on Microsoft Windows (.dll), Intel
Macintosh (.dylib), Linux and FreeBSD (.so).

  Delivering a dynamic library
  http://www.lispworks.com/documentation/lw51/DV/html/deluser-51.htm#pgfId-865189


Tthe delivered code does not include the ability to compile files, but
one can include the interpreter and the function COMPILE. I guess that
should also work when delivering as a shared library.
From: Thomas A. Russ
Subject: Re: Delivering a .so/.dylib
Date: 
Message-ID: <ymiskh5alup.fsf@blackcat.isi.edu>
Pillsy <·········@gmail.com> writes:

> For a specific project, it would be very useful to be able to deliver
> a library that people could link to from C and C++ programs. I have a
> pretty large base of Common Lisp code (in SBCL as of now) that
> implements 95% of the functionality the users need, and I really would
> prefer not to have to rewrite it in C++.
> 
> What are my options for this, in terms of Lisp implementations?

I'm not sure there is much in the way of direct, free lisp solutions.
You've seen the ACL answer.

Some other options might be to run the lisp code as a socket-listening
service or perhaps even as a web service and provide a thin C++
interface that communicates with the lisp code or web service.  This
might be the simplest solution.

If you have to go the re-coding route, you might want to take a look at
Stella first <http://www.isi.edu/isd/LOOM/Stella/>.  This would still
require re-writing the code, but the target language is a lot closer to
Common Lisp than C++ would be.  The resulting code can then be delivered
as a library. [Note:  I'm one of the Stella developers].  Stella is open
source licensed.

-- 
Thomas A. Russ,  USC/Information Sciences Institute
From: Pillsy
Subject: Re: Delivering a .so/.dylib
Date: 
Message-ID: <109941d2-451e-4dee-9f1f-39fdde4fbb1d@j9g2000vbp.googlegroups.com>
On Jul 7, 11:22 pm, Pillsy <·········@gmail.com> wrote:

> For a specific project, it would be very useful to be able to deliver
> a library that people could link to from C and C++ programs. I have a
> pretty large base of Common Lisp code (in SBCL as of now) that
> implements 95% of the functionality the users need, and I really would
> prefer not to have to rewrite it in C++.

After I put together a preliminary set of options, what it turned out
the user really wanted is a self-contained program they can call from
the command line. I'm not entirely certain where that got turned into
a library for C programs to make use of, but it's something that any
Lisp implementation can provide.

Still, I appreciate the advice.

Thanks again,
Pillsy