From: Erann Gat
Subject: libclisp.a
Date: 
Message-ID: <gNOSPAMat-0103041423430001@k-137-79-50-101.jpl.nasa.gov>
I'd like to be able to do something like the following with CLisp:

> cat foo.cc

#include <clisp.h>

main () {
  LispObj& o1 = read_from_string("(defun foo () ...");
  LispObj& o2 = eval(o1);
  LispObj& o3 = eval("(foo)");  // Eval is overloaded
  print(o3);
  // The following would also be really cool, but optional
  LispObj& o5 = read_from_string("123");
  LispObj& o6 = o5 + sqrt(o5);   // + and sqrt are heavily overloaded :-)
}

> gcc foo.cc -lclisp

> ./a.out


Is this possible?  Well, I know it's possible, but is it easy?  Can CLisp
be used like this out of the box?  If not, how much work would it be to
make it possible?

One problem that immediately arises is how to handle GC given that C code
can hold pointers (or references) to things on the Lisp heap.  I'd be
willing to include explicit calls to LispFree or something like that so
that the Lisp GC would not have to explore the C heap for roots, but could
assume that everything passed to C was not garbage until told otherwise.

Thanks,
E.

From: Marco Antoniotti
Subject: Re: libclisp.a
Date: 
Message-ID: <MjQ0c.69$IJ5.50889@typhoon.nyu.edu>
I think you may have more luck with ECL for this sort of things.

Cheers

Marco



Erann Gat wrote:

> I'd like to be able to do something like the following with CLisp:
> 
> 
>>cat foo.cc
> 
> 
> #include <clisp.h>
> 
> main () {
>   LispObj& o1 = read_from_string("(defun foo () ...");
>   LispObj& o2 = eval(o1);
>   LispObj& o3 = eval("(foo)");  // Eval is overloaded
>   print(o3);
>   // The following would also be really cool, but optional
>   LispObj& o5 = read_from_string("123");
>   LispObj& o6 = o5 + sqrt(o5);   // + and sqrt are heavily overloaded :-)
> }
> 
> 
>>gcc foo.cc -lclisp
> 
> 
>>./a.out
> 
> 
> 
> Is this possible?  Well, I know it's possible, but is it easy?  Can CLisp
> be used like this out of the box?  If not, how much work would it be to
> make it possible?
> 
> One problem that immediately arises is how to handle GC given that C code
> can hold pointers (or references) to things on the Lisp heap.  I'd be
> willing to include explicit calls to LispFree or something like that so
> that the Lisp GC would not have to explore the C heap for roots, but could
> assume that everything passed to C was not garbage until told otherwise.
> 
> Thanks,
> E.
From: Sam Steingold
Subject: Re: libclisp.a
Date: 
Message-ID: <ud67rapx5.fsf@gnu.org>
> * Erann Gat <·········@wcy.anfn.tbi> [2004-03-01 14:23:43 -0800]:
>
> I'd like to be able to do something like the following with CLisp:

yes.

>> cat foo.cc
>
> #include <clisp.h>
>
> main () {
>   LispObj& o1 = read_from_string("(defun foo () ...");
>   LispObj& o2 = eval(o1);
>   LispObj& o3 = eval("(foo)");  // Eval is overloaded
>   print(o3);
>   // The following would also be really cool, but optional
>   LispObj& o5 = read_from_string("123");
>   LispObj& o6 = o5 + sqrt(o5);   // + and sqrt are heavily overloaded :-)
> }
>
>> gcc foo.cc -lclisp
>
>> ./a.out
>
> Is this possible?  Well, I know it's possible, but is it easy?  Can
> CLisp be used like this out of the box?  If not, how much work would
> it be to make it possible?

you fashion your code into a module and build the image with
    (saveinitmem "gat.mem" :init-function #'my-main)
then you do
    clisp -K full -M gat.mem
and MY-MAIN is run.

<http://clisp.cons.org/impnotes/p-indep.html#image>
<http://clisp.cons.org/impnotes/modules.html>

> One problem that immediately arises is how to handle GC given that C
> code can hold pointers (or references) to things on the Lisp heap.
> I'd be willing to include explicit calls to LispFree or something like
> that so that the Lisp GC would not have to explore the C heap for
> roots, but could assume that everything passed to C was not garbage
> until told otherwise.

<http://clisp.cons.org/impnotes/gc-safety.html>

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
Murphy's Law was probably named after the wrong guy.
From: Erann Gat
Subject: Re: libclisp.a
Date: 
Message-ID: <gNOSPAMat-0503041913150001@192.168.1.52>
Thanks for the response, but this is not quite what I had in mind.  I
already knew about the procedure that you describe, but it's important for
my purposes that the build process go the way I described, that is, that I
be able to build with "gcc foo.cc -lclisp" instead of having to run
(saveinitmem).

The reason for this is that I need to be able to "hide" the fact that Lisp
is being used.  This is (unfortunately) necessary in my situation.

E.

In article <·············@gnu.org>, ···@gnu.org wrote:

> > * Erann Gat <·········@wcy.anfn.tbi> [2004-03-01 14:23:43 -0800]:
> >
> > I'd like to be able to do something like the following with CLisp:
> 
> yes.
> 
> >> cat foo.cc
> >
> > #include <clisp.h>
> >
> > main () {
> >   LispObj& o1 = read_from_string("(defun foo () ...");
> >   LispObj& o2 = eval(o1);
> >   LispObj& o3 = eval("(foo)");  // Eval is overloaded
> >   print(o3);
> >   // The following would also be really cool, but optional
> >   LispObj& o5 = read_from_string("123");
> >   LispObj& o6 = o5 + sqrt(o5);   // + and sqrt are heavily overloaded :-)
> > }
> >
> >> gcc foo.cc -lclisp
> >
> >> ./a.out
> >
> > Is this possible?  Well, I know it's possible, but is it easy?  Can
> > CLisp be used like this out of the box?  If not, how much work would
> > it be to make it possible?
> 
> you fashion your code into a module and build the image with
>     (saveinitmem "gat.mem" :init-function #'my-main)
> then you do
>     clisp -K full -M gat.mem
> and MY-MAIN is run.
> 
> <http://clisp.cons.org/impnotes/p-indep.html#image>
> <http://clisp.cons.org/impnotes/modules.html>
> 
> > One problem that immediately arises is how to handle GC given that C
> > code can hold pointers (or references) to things on the Lisp heap.
> > I'd be willing to include explicit calls to LispFree or something like
> > that so that the Lisp GC would not have to explore the C heap for
> > roots, but could assume that everything passed to C was not garbage
> > until told otherwise.
> 
> <http://clisp.cons.org/impnotes/gc-safety.html>
From: Frank Goenninger DG1SBG
Subject: Re: libclisp.a
Date: 
Message-ID: <87brnaw3j6.fsf@stargate.de.goenninger.com>
This assumes the build process is done on a Unix plattform...

·········@jpl.nasa.gov (Erann Gat) writes:

> I
> already knew about the procedure that you describe, but it's important for
> my purposes that the build process go the way I described, that is, that I
> be able to build with "gcc foo.cc -lclisp" instead of having to run
> (saveinitmem).

Create a shell file that calls clisp with (saveinitmem) as the executed function
(I don't know how to do that for clisp, though):

#!/whatever/path/to/clisp

# Here the line with clisp getting called to execute the (saveinitmem):
whateverdontknowwhatittakesforclisp

...
Name this file, say "gcc-gat"

Then:
chmod +x /path/to/gcc-gat
chmod go-rw /path/to/gcc-gat
...
In your Makefile:

SUFFIXES: .lsp

.lsp.a:
        /path/to/gcc-gat -parameters-to-create-the-image-file-and-are-understood-by-your-shell-file

> The reason for this is that I need to be able to "hide" the fact that Lisp
> is being used.  This is (unfortunately) necessary in my situation.
>
> E.
>

I am sure you get the idea!

People who want to be lied to get fooled easily. 

I once wanted to use C++ instead of C and did something very similar. This is 
now almost 9 years ago...

;-)))


Frank
From: Sam Steingold
Subject: Re: libclisp.a
Date: 
Message-ID: <uishhahfc.fsf@gnu.org>
> * Erann Gat <·········@wcy.anfn.tbi> [2004-03-05 19:13:15 -0800]:
>
> Thanks for the response, but this is not quite what I had in mind.  I
> already knew about the procedure that you describe, but it's important
> for my purposes that the build process go the way I described, that
> is, that I be able to build with "gcc foo.cc -lclisp" instead of
> having to run (saveinitmem).

clisp does come with a libclisp.a, which, of course, can be linked
against.
it includes the C runtime and does not include the Lisp code.
E.g., it does include EVAL and READ, so your "main()" code would
work, but it does not include COMPILE and LOOP.

> The reason for this is that I need to be able to "hide" the fact that
> Lisp is being used.  This is (unfortunately) necessary in my
> situation.

You can hide that in a script.
A module is built by a single "make" invocation, so it should not be
too hard.

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
The early bird may get the worm, but the second mouse gets the cheese.
From: Erann Gat
Subject: Re: libclisp.a
Date: 
Message-ID: <gNOSPAMat-0703042206160001@dialin-152.jpl.nasa.gov>
In article <·············@gnu.org>, ···@gnu.org wrote:

> > * Erann Gat <·········@wcy.anfn.tbi> [2004-03-05 19:13:15 -0800]:
> >
> > Thanks for the response, but this is not quite what I had in mind.  I
> > already knew about the procedure that you describe, but it's important
> > for my purposes that the build process go the way I described, that
> > is, that I be able to build with "gcc foo.cc -lclisp" instead of
> > having to run (saveinitmem).
> 
> clisp does come with a libclisp.a, which, of course, can be linked
> against.

That's what I thought.

> it includes the C runtime and does not include the Lisp code.
> E.g., it does include EVAL and READ, so your "main()" code would
> work, but it does not include COMPILE and LOOP.

Ah.


> > The reason for this is that I need to be able to "hide" the fact that
> > Lisp is being used.  This is (unfortunately) necessary in my
> > situation.
> 
> You can hide that in a script.
> A module is built by a single "make" invocation, so it should not be
> too hard.


That does sound like it might work then.  I'll give it a whirl.

Thanks!

E.