Re: [Gcl-devel] Various questions about GCL

[Camm Maguire]

Greetings!

"Goffioul Michael" <address@hidden> writes:

>  
>                                    1) Would it be possible to make GCL 
> embedded into a C library (preferably
>           shared) such that
>                     a 3rd party application could make use of GCL as an 
> embedded computation engine? This
>                     would mean to have an API to initialize/terminate the GCL 
> engine, to convert between C
>           types
>                     and LISP objects, to "eval()" or "funcall()" arbitrary 
> code. Our final target is actually
>           to embed
>                     a LISP engine into a MEX file such that our framework 
> written in LISP can be accessed
>           from
>                     the MATLAB user interface. 
>                      
>           As you may have already discovered, GCL is not set up to do this.  
> My guess is that if compiler::link
>      were to be altered appropriately and the necessary initialise/terminate 
> functions written, it would be
>      possible to produce a "GCL in a box" in the form of a DLL or Unix shared 
> library.
> 
> Would anyone be interested to do it? (I guess it's mainly a matter of 
> cut-n-paste from the
> 
> "main" function). 
> 

I am interested, given a clear understanding of how to proceed, which
appears, alas, notrivial.

>  
>                I don't know how MATLAB and MEX work, but if the DLL had to be 
> a COM server rather than a simple C
>      based DLL on Windows, then things might (or might not) be much tougher; 
> I have a faint memory that COM
>      servers have to be reentrant.   If COM is needed, you should seriously 
> consider Corman Common Lisp which is
>      supplied as an in-process COM server.
> 
> No, it simply has to be a normal DLL linked against MATLAB libraries. 
> 
>  
>                                    2) Is there any FFI framework?
>                      
>           Yes, but compared to other functional programming language 
> implementations it is very primitive. 
>      Examples may be seen in the xlib, opengl, JAPI and MPI extensions to GCL.
> 
> Is there any documentation about this? (I saw in gcl_japi.lsp that it uses 
> "defentry", but I couldn't
> 
> find any doc about it; I couldn't find the opengl or MPI extensions in the 
> code, and "make" in
> 
> xgcl-2 fails...). Can it be used to define C-functions located in a shared 
> library (to be loaded at
> 
> run-time)? 

gcl-si.info.  defentry, clines, defcfun, compiler::link.

> 
>  
>                                    3) (make-hash-table :test #'equalp) is not 
> supported
>           I'm not an ANSI expert but I assume we will add that if it is part 
> of the spec, or if you really need
>      it.
> 
> I don't know if it's ANSI, but it's in the doc. See (describe 
> 'make-hash-table). 
> 
>  
>                                    4) Code like the following does not 
> compile:
>                     (unless (find-package "MYPKG")
>                       (defpackage "MYPKG" (:use "COMMON-LISP")))
>                     (in-package "MYPKG")
>                     (export 'f1)
>                     (defun f1 (x) (* x x))
>                      
>                     It complains at "in-package" statement. If I enclose the 
> first 2 top-level forms (unless,
>           in-package)
>                     into an "(eval-when (compile load eval) ...)" form, it 
> compiles but doesn't load (after
>           restarting GCL),
>                     still complaining at "in-package" statement.
>                     (Note: I'm using anonymous CVS version under Linux)
>           You're probably talking about the warning ";; Warning: The package 
> operation (IN-PACKAGE "MYPKG") was in
>      a bad place." shown below.  This is  a long standing problem and is, I 
> believe something we mean to address
>      during the move towards releasing version 2.7.0:
> 
> Yes, that's the error I get. 

(Bad) Warning only, to my understanding.

Take care,


>                                    5) Would GCL compile/work under 
> Win32/MSVC6?
>           I would be pleased to help you if you went ahead and tried this.  I 
> would suggest simply building under
>      MSYS for the convenience of the build system, using the VC6 compiler and 
> linker instead of gcc/ld.  The
>      alternative would be to write nmake compatible makefiles and run under a 
> Windows command prompt, but you
>      would then always be one step behind the main build system.
> 
> I can have a look when I boot Windows again.
> 
>  
> 
> Thanks for your answers.
> 
> Michael.
> 
>  
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gcl-devel

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah