From: N. R. <ra...@mr...> - 2009-06-08 17:16:06
|
I am trying to learn how to use external modules and the FFI, mainly by reading Sections 32.2 and 32.3 of the manual. I have followed the following procedure. 1. I created a file `foo.lisp' with this content: --8<---------------cut here---------------start------------->8--- (defpackage "FOO" (:use "COMMON-LISP" "FFI") (:export "EPERM")) (in-package "FOO") (default-foreign-language :stdc) (c-lines "#include <errno.h>~%") (def-c-const EPERM (:documentation "Operation not permitted")) --8<---------------cut here---------------end--------------->8--- 2. Compiled it: [griffin:/home/raghu/foo]% clisp -c foo.lisp 3. Created a module set: [griffin:/home/raghu/foo]% env CLISP_LINKKIT=/opt/lib/clisp/linkkit \ /opt/lib/clisp/clisp-link create-module-set foo-module foo.c 4. Modified `foo-module/link.sh' by replacing TO_LOAD='' with TO_LOAD='../foo.fas' 5. Created a new linking set % env CLISP_LINKKIT=/opt/lib/clisp/linkkit /opt/lib/clisp/clisp-link \ add-module-set foo-module /opt/lib/clisp/base base+foo 6. Tested it: ---------------------------------------------------------------------- [griffin:/home/raghu/foo]% base+foo/lisp.run -M base+foo/lispinit.mem [1]> (in-package "FOO") #<PACKAGE FOO> FOO[2]> (describe 'eperm) EPERM is the symbol EPERM, lies in #<PACKAGE FOO>, is accessible in 1 [snip] Documentation: VARIABLE: "Operation not permitted" FOO[3]> eperm 1 ---------------------------------------------------------------------- So that seems to be working. Now, my question is how do I use the constant EPERM from another Lisp file, say. `bar.lisp'? I thought I would put in `bar.lisp' these expressions: (load "foo") (format t "~A" foo:eperm) But when I evaluate (load "foo") I get this error: FFI::FIND-FOREIGN-FUNCTION: foreign function "module__foo__constant_map_int" does not exist I'd appreciate any help or advice on this. TIA, Raghavendra. -- N. Raghavendra <ra...@mr...> | http://www.retrotexts.net/ Harish-Chandra Research Institute | http://www.mri.ernet.in/ See message headers for contact and OpenPGP information. |
From: Kaz K. <kky...@gm...> - 2009-06-09 18:00:19
|
On Mon, Jun 8, 2009 at 9:38 AM, N. Raghavendra<ra...@mr...> wrote: > [griffin:/home/raghu/foo]% base+foo/lisp.run -M base+foo/lispinit.mem [ snip ] > So that seems to be working. Now, my question is how do I use the > constant EPERM from another Lisp file, say. `bar.lisp'? I thought I > would put in `bar.lisp' these expressions: > > (load "foo") > (format t "~A" foo:eperm) > > But when I evaluate (load "foo") I get this error: > > FFI::FIND-FOREIGN-FUNCTION: foreign function > "module__foo__constant_map_int" does not exist This looks like you are loading foo.fas into a Lisp image which doesn't have the C module linked to it. I.e. you are using the wrong lisp.run executable. You must use your base+fun/lisp.run and base+fun/lispinit.mem. There is no need to (load "foo") at all because foo.fas is already incorporated into the base+fun/lispinit.mem image. The base+fun/lispinit.mem has the Lisp parts of the module, and the base+fun/lisp.run executable has the compiled C parts to which the Lisp parts refer. |
From: Sam S. <sd...@gn...> - 2009-06-09 21:38:56
|
Kaz Kylheku wrote: > > This looks like you are loading foo.fas into a Lisp image which > doesn't have the C module > linked to it. I.e. you are using the wrong lisp.run executable. > > You must use your base+fun/lisp.run and base+fun/lispinit.mem. > > There is no need to (load "foo") at all because foo.fas is already > incorporated into the > base+fun/lispinit.mem image. > > The base+fun/lispinit.mem has the Lisp parts of the > module, and the base+fun/lisp.run executable has the compiled C parts to which > the Lisp parts refer. Kaz, thanks a lot for the answer. I wonder how I should rephrase the several places in the manual which already answer the original question... http://clisp.cons.org/impnotes/modules.html#linkset To run a CLISP contained in some linking set directory, call $ directory/lisp.run -M directory/lispinit.mem http://clisp.cons.org/impnotes/modules.html#mod-set-ex-bindings Run and try it $ base+linux/lisp.run -M base+linux/lispinit.mem -x '(linux:stat "/tmp")' |
From: N. R. <ra...@mr...> - 2009-06-10 06:38:39
|
At 2009-06-09T17:38:18-04:00, Sam Steingold wrote: > I wonder how I should rephrase the several places in the manual which > already answer the original question... > > > http://clisp.cons.org/impnotes/modules.html#linkset > > To run a CLISP contained in some linking set directory, call > > $ directory/lisp.run -M directory/lispinit.mem > > > > http://clisp.cons.org/impnotes/modules.html#mod-set-ex-bindings > > Run and try it > > $ base+linux/lisp.run -M base+linux/lispinit.mem -x '(linux:stat "/tmp")' As I mentioned in my reply to Kaz Kylheku, this was not the point of my confusion. I have, I hope, clarified my question in that reply. Regarding the manual itself, I think Sections 32.2 and 32.3 are difficult to read. I am willing, once I understand the basics of external modules and the FFI, to submit patches to the document. Meanwhile, here are some difficulties I have encountered while trying to read this part of the manual: 1. There is no high-level description of modules and the FFI. One possible place for such a description is in [32.2.1. Overview]. I think an overview section is not the place for describing the syntax of module-names. I feel it would be more helpful if this section contained introductory remarks on both modules and the FFI. 2. I think the manual needs a description of `clisp-link', instead of an abrupt introduction to it, with "CLISP has a facility for adding external modules (written in C, for example). It is invoked through clisp-link." 3. The section titled "Linking Set" begins with, "A linking set is a directory containing: makevars ..." That doesn't help much. A mere description of the contents of a linking set isn't enough to understand its significance. 4. Ditto for module sets. 5. On a minor note, there are many unnecessary links and colours in the HTML rendition of the manual. All those coloured words break the continuity of the essential content. I think there is no need to have a link to the project Web site every time CLISP is mentioned. Similarly, no need to link to the C-FAQ site at every mention of C. No need to colour the background of various keywords gray, cyan, etc., (sorry if the colour names are wrong --- I don't know the names well). No need to link /bin/sh to the SUSv3 Web site. Regards, -- N. Raghavendra <ra...@mr...> | http://www.retrotexts.net/ Harish-Chandra Research Institute | http://www.mri.ernet.in/ See message headers for contact and OpenPGP information. |
From: Sam S. <sd...@gn...> - 2009-06-10 14:08:24
|
N. Raghavendra wrote: > > Regarding the manual itself, I think Sections 32.2 and 32.3 are > difficult to read. I am willing, once I understand the basics of > external modules and the FFI, to submit patches to the document. thank you for your generous offer. please make sure that your patches are against the most recent CVS head. > 5. On a minor note, there are many unnecessary links and colours in the > HTML rendition of the manual. All those coloured words break the > continuity of the essential content. I think there is no need to > have a link to the project Web site every time CLISP is mentioned. > Similarly, no need to link to the C-FAQ site at every mention of C. > No need to colour the background of various keywords gray, cyan, > etc., (sorry if the colour names are wrong --- I don't know the names > well). No need to link /bin/sh to the SUSv3 Web site. Personally, I prefer it the way it is - just like I prefer to use font-lock in emacs. |
From: Sam S. <sd...@gn...> - 2009-06-10 17:48:39
|
N. Raghavendra wrote: > 1. There is no high-level description of modules I modified the manuals. please take a look at: http://clisp.podval.org/impnotes/clisp.html#using http://clisp.podval.org/impnotes/modules.html#mod-overview > and the FFI. this is just not true: http://clisp.cons.org/impnotes/dffi.html#dffi-intro Thanks for your feedback. Sam. |
From: N. R. <ra...@mr...> - 2009-06-11 15:04:00
|
At 2009-06-10T13:47:27-04:00, Sam Steingold wrote: > N. Raghavendra wrote: >> 1. There is no high-level description of modules > > I modified the manuals. please take a look at: > http://clisp.podval.org/impnotes/clisp.html#using > http://clisp.podval.org/impnotes/modules.html#mod-overview Thanks. It is easier to read than the current version. I have appended a modified version of that text, which describes what I had in mind. Of course, due to my inexperience with the subject, etc., I am sure the writeup needs substantial improvement, if at all it's acceptable. If you're interested, I can work on it. >> and the FFI. > > this is just not true: > http://clisp.cons.org/impnotes/dffi.html#dffi-intro I am sorry, I forgot about that, although I'd seen it. Still, I feel that a bit more explanation there may be useful. Regards, Raghavendra. --8<---------------cut here---------------start------------->8--- 32.2.1 Overview --------------- External modules are a mechanism to add extensions (written in C, for example) to CLISP. For the purpose of this description, it is assumed that the extensions are written in C. An external module consists of two objects, a module set and a linking set, which are built from the source files of the extension. Of these two, the module set is the primary object, directly built from the C source files of the extension. The linking set is built from the module set, by combining the extensions in it with existing CLISP facilities. In practice, module sets and linking sets are manipulated using a program called `clisp-link'. The following paragraphs describe module sets, linking sets, and the program `clisp-link'. Module Set ---------- A module set is a collection of files containing the C source code of the extension, and a few extra files which specify how that source code has to be compiled into CLISP. Explicitly, a module set is a directory consisting of the following files: 1. Symbolic links to the C source files of the extension. 2. link.sh: a shell script that is used to incorporate the current extension into CLISP. It contains some commands and assignments of certain environment variables. Explicitly, `link.sh' contains a make(1) command used by clisp-link for creating a linking set using this module set, and the following environment variable assignments: NEW_FILES... NEW_LIBS... ... TO_PRELOAD... 3. Makefile: used by clisp-link to build a linking set from this module set. Linking Set ----------- A linking set is a collection of files which provides a CLISP runtime executable, and a memory image which can be used by that executable. This memory image contains all the facilities defined by the current extension, and certain other existing facilities. Explicitly, a linking set is a directory containing at least these files: 1. lisp.run: runtime executable. 2. lispinit.mem: a memory image that contains all the facilities provided by the current extension, and certain other existing facilities. 3. modules.h: the list of modules contained in this linking set. 4. modules.o: the compiled list of modules contained in this linking set. 5. makevars: a shell script which sets the following variables: CC... CPPFLAGS... ... FILES... 6. all the FILES listed in `makevars'. clisp-link ---------- clisp-link is a shell script used to build module sets and linking sets from the C source files of an extension. By default, it is installed in *LIB-DIRECTORY*, and usually without executable permissions, so it may have to be invoked as `/bin/sh /path/to/clisp-link'. Usage ----- clisp-link can be used in four modes, as follows: clisp-link create-module-set <module-set> <source-files> clisp-link add-module-set <module-set> <old-linking-set> <new-linking-set> clisp-link add-module-sets <old-linking-set> <new-linking-set> <module-sets> clisp-link run <linking-set> <module-sets> The first form creates a module set <module-set> using <source-files>, which are assumed to contain the C code for an extension. If <module-set> is not a subdirectory of the current directory, then the symbolic links in <module-set> may have to be corrected after this command. The second form builds a linking set <new-linking-set> from the module set <module-set>, by combining it with the facilities provided by the existing linking set <old-linking-set>. The third form builds a linking set <new-linking-set>, from the module sets <module-sets> by combining them with the facilities provided by the existing linking set <old-linking-set>. The last form runs the runtime executable in the linking set <linking-set> with the extensions in the modules sets <module-sets> loaded. Files ----- clisp-link uses the C files `clisp.h' and `modules.c', which are installed with CLISP in *LIB-DIRECTORY*/linkkit. These files must be in the subdirectory `linkkit' of the current directory. An alternative directory can be specified using the environment variable `CLISP_LINKKIT.' Examples: 1. Suppose that the files `foo-1.c' and `foo-2.c' in the directory `foo' contain the source code for an extension. To build a module set in the subdirectory `foo-module' of `foo', invoke the following command in the directory `foo': clisp-link create-module-set foo-module foo-1.c foo-2.c 2. To build a linking set in the directory `/tmp/base+foo', by combining the above module set with the facilities provided by the `base' linking set, do this from the directory `foo': clisp-link add-module-set foo-module /opt/lib/clisp/base /tmp/base+foo 3. To do (1) without copying the `linkkit' directory into the directory `foo', give this command in the directory `foo': env CLISP_LINKKIT=/opt/lib/clisp/linkkit clisp-link \ create-module-set foo-module foo-1.c foo-2.c --8<---------------cut here---------------end--------------->8--- |
From: Sam S. <sd...@gn...> - 2009-06-11 16:46:17
|
N. Raghavendra wrote: > At 2009-06-10T13:47:27-04:00, Sam Steingold wrote: > > I have appended > a modified version of that text, which describes what I had in mind. I cannot do a diff with my naked eye. Sorry. Please send a diff against cvs head: edit doc/impext.xml and do cvs diff doc/impext.xml |
From: N. R. <ra...@mr...> - 2009-06-13 06:34:01
|
At 2009-06-11T12:45:54-04:00, Sam Steingold wrote: > I cannot do a diff with my naked eye. Sorry. > > Please send a diff against cvs head: Patch appended below. My apologies for errors and omissions. Regards, Raghavendra. --8<---------------cut here---------------start------------->8--- Index: impext.xml =================================================================== RCS file: /cvsroot/clisp/clisp/doc/impext.xml,v retrieving revision 1.573 diff -c -r1.573 impext.xml --- impext.xml 11 Jun 2009 19:40:56 -0000 1.573 +++ impext.xml 13 Jun 2009 06:27:57 -0000 @@ -2027,41 +2027,63 @@ <section id="mod-overview"><title>Overview</title> -<para>&clisp; has a facility for adding <emphasis>external - modules</emphasis> (written in &c-lang;, for example). -The main building blocks are &modset;s and &linkset;s.</para> +<para><emphasis>External modules</emphasis> are a mechanism to add +extensions (written in &c-lang;, for example) to &clisp;. For the +purpose of this overview, it is assumed that the extensions are +written in &c-lang;.</para> + +<para>Adding an extension to &clisp; using an external module involves +working with two objects, a &modset; and a &linkset;, which are built +from the source files of the extension. Of these two, the &modset; is +the primary object, directly built from the &c-lang; source files of +the extension. The &linkset; is built from the &modset;, by combining +the extensions in it with existing &clisp; facilities. In practice, +&modset;s and &linkset;s are manipulated using a program called +&clisp-link;.</para> + +<para>The following paragraphs describe &modset;s, &linkset;s, and the +program &clisp-link;.</para> <simplesect id="modset"><title>Module Set</title> -<para>A <firstterm>module<indexterm id="module" significance="preferred"> - <primary>module</primary></indexterm></firstterm> is a piece of code - (&c-lang; or Lisp) which defines extra (non-core) Lisp objects, symbols - and functions. Together with &link-sh;, which describes how to add the - module to an existing &clisp;, it comprises a &modset;.</para> -<para>More formally, - <firstterm>&modset;<indexterm id="modseti" significance="preferred"> - <primary>module set</primary></indexterm></firstterm> - is a directory containing: -<variablelist><varlistentry><term>&link-sh;</term> - <listitem><simpara>some &sh; commands, which prepare the directory - for linking, and set some &env-var;s, see <xref linkend="mod-vars"/> - </simpara></listitem></varlistentry> - <varlistentry><term>all other files that define the module functionality</term> - <listitem><simpara>needed by &link-sh;</simpara></listitem></varlistentry> + +<para>A <firstterm>&modset;<indexterm id="modseti" +significance="preferred"><primary>module +set</primary></indexterm></firstterm> is a collection of files +containing the &c-lang; source code of the extension, and a few extra +files which specify how that source code has to be compiled into +&clisp;. Explicitly, a &modset; is a directory consisting of the +following files:<variablelist><varlistentry><term>Symbolic +links</term> +<listitem><simpara>to the C source files of the +extension.</simpara></listitem></varlistentry> +<varlistentry><term>&link-sh;</term> +<listitem><simpara>a shell script that is used to incorporate the +current extension into CLISP. It contains some commands and +assignments of certain &env-var;s, see <xref +linkend="mod-vars"/>.</simpara></listitem></varlistentry> +<varlistentry><term>Makefile</term> +<listitem><simpara>used by clisp-link to build a linking set from this +module set.</simpara></listitem></varlistentry> </variablelist></para> <para>In &link-sh; the &modset; directory is referred to - as <varname>$modulename/</varname>.</para> -<para>A module <firstterm>name<indexterm id="module-name"> + as <varname>$modulename/</varname>. A module <firstterm>name<indexterm id="module-name"> <primary>module</primary><secondary>name</secondary></indexterm></firstterm> - must consist of the characters <filename>A</filename>-<filename>Z</filename>, - <filename>a</filename>-<filename>z</filename>, <filename>_</filename>, - <filename>0</filename>-<filename>9</filename>.</para> -<para>The module name <quote>clisp</quote> is reserved.</para> + must consist of the characters + <filename>A</filename>-<filename>Z</filename>, + <filename>a</filename>-<filename>z</filename>, + <filename>_</filename>, + <filename>0</filename>-<filename>9</filename>. The module name + <quote>clisp</quote> is reserved.</para> </simplesect> <simplesect id="linkset"><title>Linking Set</title> <para>A <firstterm>&linkset;<indexterm id="linkseti" significance="preferred"> <primary>linking set</primary></indexterm></firstterm> - is a set of files which allows performing two major tasks: + collection of files which provides a CLISP runtime +executable, and a memory image which can be used by that executable. +This memory image contains all the facilities defined by the current +extension, and certain other existing facilities.</para> +<para>A &linkset; allows performing two major tasks: <orderedlist><listitem><para>Running &clisp;: to run a &clisp; contained in some &linkset; &dir-r;, call<screen> &sh-prompt; &dir-r;/lisp.run &opt-M; &dir-r;/lispinit.mem</screen> @@ -2070,12 +2092,24 @@ <option><olink targetdoc="man" targetptr="opt-libdir">-B</olink></option> to the run-time).</para></listitem> <listitem><simpara>Adding a &modset; to create a new &linkset; which - will contain the module functionality</simpara></listitem></orderedlist> + will contain the module functionality.</simpara></listitem></orderedlist> The &clisp; build directory contains three &linkset;s in directories <command>boot</command>, &base;, and &full;, and a &clisp; installation normally contains two &linkset;s: &base;, and &full;</para> -<para>More formally, a &linkset; is a directory containing at least +<para>Explicitly, a &linkset; is a directory containing at least these files:<variablelist> +<varlistentry><term>&lisp-run;</term> + <listitem><simpara>runtime executable</simpara></listitem></varlistentry> +<varlistentry><term>&lispinit;</term> + <listitem><simpara>a &mem-image; that contains all the facilities + provided by the current extension, and certain other existing + facilities.</simpara></listitem></varlistentry> +<varlistentry><term><filename>modules.h</filename></term> + <listitem><simpara>the list of modules contained in this &linkset; +</simpara></listitem></varlistentry> +<varlistentry><term><filename>modules.o</filename></term> + <listitem><simpara>the compiled list of modules contained in this &linkset; +</simpara></listitem></varlistentry> <varlistentry><term><filename>makevars</filename></term> <listitem><para>some &sh; commands, setting the variables <variablelist>&varlist-table;<varlistentry><term><envar>CC</envar></term> @@ -2104,59 +2138,103 @@ <listitem><simpara>the list of files needed when linking </simpara></listitem></varlistentry> </variablelist></para></listitem></varlistentry> -<varlistentry><term><filename>modules.h</filename></term> - <listitem><simpara>the list of modules contained in this &linkset; -</simpara></listitem></varlistentry> -<varlistentry><term><filename>modules.o</filename></term> - <listitem><simpara>the compiled list of modules contained in this &linkset; -</simpara></listitem></varlistentry> <varlistentry><term>all the <envar>FILES</envar></term> <listitem><simpara>listed in <filename>makevars</filename> </simpara></listitem></varlistentry> -<varlistentry><term>&lisp-run;</term> - <listitem><simpara>the executable</simpara></listitem></varlistentry> -<varlistentry><term>&lispinit;</term> - <listitem><simpara>the &mem-image;</simpara></listitem></varlistentry> </variablelist></para> </simplesect> -<simplesect id="clisp-link"><title>Operating on &modset;s and &linkset;s</title> -<para>Adding one or several &modset;s to a &linkset;s produces a new - &linkset; which contains the functionality of those modules. This is - done by the &clisp-link; shell script.</para> -<para>&clisp-link; needs a directory containing: -<itemizedlist> - <listitem><simpara><filename>"modules.c"</filename></simpara></listitem> - <listitem><simpara>&clisp-h;</simpara></listitem> -</itemizedlist> -&clisp-link; expects to find these files in a -subdirectory <filename>linkkit/</filename> of the current directory. -This can be overridden by the &env-var; <envar>CLISP_LINKKIT</envar>.</para> +<simplesect id="clisp-link"><title>&clisp-link;</title> +<para>clisp-link is a shell script used to build &modset;s and +&linkset;s from the &c-lang; source files of an extension. By +default, it is installed in &libdir;, and usually without executable +permissions, so it may have to be invoked as +<screen>&sh-prompt; &sh; /path/to/&clisp-link; ...</screen></para> -<variablelist><title>&clisp-link; commands</title> -<varlistentry><term>create</term> +<para>&clisp-link; can be used in four modes as follows: +<variablelist> +<varlistentry><term>create-module-set</term> <listitem><para>The command - <screen>&sh-prompt; &clisp-link; create &mod-r; &file-r;...</screen> - creates a &modset; in &mod-r; directory which refers - (via symbolic links) to &file-r;... - The files are expected to be modules of their own. -</para></listitem></varlistentry> -<varlistentry><term>add</term> + <screen>&sh-prompt; &clisp-link; create-module-set <replaceable>module-set</replaceable> <replaceable>source-files</replaceable></screen> + creates a &modset; <replaceable>module-set</replaceable> using + <replaceable>source-files</replaceable>, which are expected to be + modules of their own. If <replaceable>module-set</replaceable> is + not a subdirectory of the current directory, then the symbolic links + in <replaceable>module-set</replaceable> may have to be corrected + after this command.</para></listitem></varlistentry> +<varlistentry><term>add-module-set</term> <listitem><para>The command - <screen>&sh-prompt; &clisp-link; add &source-r; &dest-r; &mod-r; ...</screen> - combines the &linkset; in directory &source-r; and the &module;s in - directories &mod-r;... to a new &linkset;, in the directory &dest-r; - which is newly created.</para></listitem></varlistentry> + <screen>&sh-prompt; &clisp-link; add-module-set <replaceable>module-set</replaceable> <replaceable>old-linking-set</replaceable> <replaceable>new-linking-set</replaceable></screen> + builds a &linkset; <replaceable>new-linking-set</replaceable> + from the &modset; <replaceable>module-set</replaceable>, by + combining it with the facilities provided by the existing linking + set + <replaceable>old-linking-set</replaceable>.</para></listitem></varlistentry> +<varlistentry><term>add-module-sets</term> + <listitem><para>The command + <screen>&sh-prompt; &clisp-link; add-module-sets <replaceable>old-linking-set</replaceable> <replaceable>new-linking-set</replaceable> <replaceable>module-sets</replaceable></screen> + builds a &linkset; <replaceable>new-linking-set</replaceable> + from the &modset;s <replaceable>module-sets</replaceable>, by + combining them with the facilities provided by the existing linking + set + <replaceable>old-linking-set</replaceable>.</para></listitem></varlistentry> <varlistentry><term>run</term> <listitem><para>The command - <screen>&sh-prompt; &clisp-link; run &source-r; &mod-r; ...</screen> - runs the &linkset; in directory &source-r;, with the &module;s - in directories &mod-r;.... - If &clisp; has been built with the configuration option &with-dynmod;, - the loading will be performed <link linkend="mod-dynload">dynamically</link>. - Otherwise - this is much slower - a temporary &linkset; will be created - and deleted afterwards.</para></listitem></varlistentry></variablelist> + <screen>&sh-prompt; &clisp-link; run <replaceable>linking-set</replaceable> <replaceable>module-sets</replaceable></screen> + runs the runtime executable in the &linkset; + <replaceable>linking-set</replaceable> with the extensions in the + modules sets <replaceable>module-sets</replaceable> loaded. If + &clisp; has been built with the configuration option &with-dynmod;, + the loading will be performed <link + linkend="mod-dynload">dynamically</link>. Otherwise — this is + much slower — a temporary &linkset; will be created and + deleted + afterwards.</para></listitem></varlistentry></variablelist></para> + + <para>&clisp-link; uses the &c-lang; files &clisp-h; and + <filename>"modules.c"</filename>, which are installed with &clisp; + in the directory &libdir;/linkkit. These two files must be in the + subdirectory <filename>linkkit/</filename> of the current directory. + An alternative directory can be specified using the &env-var; + <envar>CLISP_LINKKIT</envar>.</para> + <para>Here are some examples of using &clisp-link;</para> + <variablelist> + <varlistentry> + <term>Creating a &modset;</term> + <listitem> + <para>Suppose that the files <filename>foo-1.c</filename> and + <filename>foo-2.c</filename> in the directory + <filename>foo/</filename> contain the source code for an + extension. To build a &modset; in the subdirectory + <filename>foo-module/</filename> of <filename>foo/</filename>, + invoke the following command in the directory + <filename>foo/</filename>: + <screen>&sh-prompt; &clisp-link; create-module-set <filename>foo-module</filename> <filename>foo-1.c</filename> <filename>foo-2.c</filename></screen></para> + </listitem> + </varlistentry> + <varlistentry> + <term>Adding a &modset;</term> + <listitem> + <para>To build a &linkset; in the directory + <filename>/tmp/base+foo/</filename>, by combining the above + &modset; with the facilities provided by the &base; + &linkset;, do this from the directory + <filename>foo/</filename>: + <screen>&sh-prompt; &clisp-link; add-module-set <filename>foo-module</filename> <filename>/path/to/clisp/base</filename> <filename>/tmp/base+foo</filename></screen></para> + </listitem> + </varlistentry> + <varlistentry> + <term>Using <envar>CLISP_LINKKIT</envar></term> + <listitem> + <para>To do the first example above without copying the + <filename>linkkit</filename> directory into the directory + <filename>foo/</filename>, give this command in the directory + <filename>foo/</filename>: + <screen>&sh-prompt; env <envar>CLISP_LINKKIT</envar>=<filename>/path/to/clisp/linkkit</filename> &clisp-link; create-module-set <filename>foo-module</filename> <filename>foo-1.c</filename> <filename>foo-2.c</filename></screen></para> + </listitem> + </varlistentry> + </variablelist> </simplesect> <simplesect id="mod-vars"><title>Module set variables</title> --8<---------------cut here---------------end--------------->8--- |
From: N. R. <ra...@mr...> - 2009-06-13 07:22:14
|
At 2009-06-13T12:00:12+05:30, N. Raghavendra wrote: > At 2009-06-11T12:45:54-04:00, Sam Steingold wrote: > >> I cannot do a diff with my naked eye. Sorry. >> >> Please send a diff against cvs head: > > Patch appended below. My apologies for errors and omissions. There were problems when I tried to apply that patch, which I had saved from an Emacs *vc-diff* buffer. The following seems to work. Sorry about the mixup. Raghavendra. --8<---------------cut here---------------start------------->8--- Index: impext.xml =================================================================== RCS file: /cvsroot/clisp/clisp/doc/impext.xml,v retrieving revision 1.575 diff -r1.575 impext.xml 180c180 < the &full; &linkset; cannot be used with the &base; &rt;:<screen> --- > the &full; &linkset; cannot be used with the &base; runtime:<screen> 2024c2024 < for the &clisp; &rt;. --- > for the &clisp; run-time. 2030,2032c2030,2045 < <para>&clisp; has a facility for adding <emphasis>external < modules</emphasis> (written in &c-lang;, for example). < The main building blocks are &modset;s and &linkset;s.</para> --- > <para><emphasis>External modules</emphasis> are a mechanism to add > extensions (written in &c-lang;, for example) to &clisp;. For the > purpose of this overview, it is assumed that the extensions are > written in &c-lang;.</para> > > <para>Adding an extension to &clisp; using an external module involves > working with two objects, a &modset; and a &linkset;, which are built > from the source files of the extension. Of these two, the &modset; is > the primary object, directly built from the &c-lang; source files of > the extension. The &linkset; is built from the &modset;, by combining > the extensions in it with existing &clisp; facilities. In practice, > &modset;s and &linkset;s are manipulated using a program called > &clisp-link;.</para> > > <para>The following paragraphs describe &modset;s, &linkset;s, and the > program &clisp-link;.</para> 2035,2049c2048,2066 < <para>A <firstterm>module<indexterm id="module" significance="preferred"> < <primary>module</primary></indexterm></firstterm> is a piece of code < (&c-lang; or Lisp) which defines extra (non-core) Lisp objects, symbols < and functions. Together with &link-sh;, which describes how to add the < module to an existing &clisp;, it comprises a &modset;.</para> < <para>More formally, < <firstterm>&modset;<indexterm id="modseti" significance="preferred"> < <primary>module set</primary></indexterm></firstterm> < is a directory containing: < <variablelist><varlistentry><term>&link-sh;</term> < <listitem><simpara>some &sh; commands, which prepare the directory < for linking, and set some &env-var;s, see <xref linkend="mod-vars"/> < </simpara></listitem></varlistentry> < <varlistentry><term>all other files that define the module functionality</term> < <listitem><simpara>needed by &link-sh;</simpara></listitem></varlistentry> --- > > <para>A <firstterm>&modset;<indexterm id="modseti" > significance="preferred"><primary>module > set</primary></indexterm></firstterm> is a collection of files > containing the &c-lang; source code of the extension, and a few extra > files which specify how that source code has to be compiled into > &clisp;. Explicitly, a &modset; is a directory consisting of the > following files:<variablelist><varlistentry><term>Symbolic > links</term> > <listitem><simpara>to the C source files of the > extension.</simpara></listitem></varlistentry> > <varlistentry><term>&link-sh;</term> > <listitem><simpara>a shell script that is used to incorporate the > current extension into CLISP. It contains some commands and > assignments of certain &env-var;s, see <xref > linkend="mod-vars"/>.</simpara></listitem></varlistentry> > <varlistentry><term>Makefile</term> > <listitem><simpara>used by clisp-link to build a linking set from this > module set.</simpara></listitem></varlistentry> 2052,2053c2069 < as <varname>$modulename/</varname>.</para> < <para>A module <firstterm>name<indexterm id="module-name"> --- > as <varname>$modulename/</varname>. A module <firstterm>name<indexterm id="module-name"> 2055,2058c2071,2076 < must consist of the characters <filename>A</filename>-<filename>Z</filename>, < <filename>a</filename>-<filename>z</filename>, <filename>_</filename>, < <filename>0</filename>-<filename>9</filename>.</para> < <para>The module name <quote>clisp</quote> is reserved.</para> --- > must consist of the characters > <filename>A</filename>-<filename>Z</filename>, > <filename>a</filename>-<filename>z</filename>, > <filename>_</filename>, > <filename>0</filename>-<filename>9</filename>. The module name > <quote>clisp</quote> is reserved.</para> 2064c2082,2086 < is a set of files which allows performing two major tasks: --- > collection of files which provides a CLISP runtime > executable, and a memory image which can be used by that executable. > This memory image contains all the facilities defined by the current > extension, and certain other existing facilities.</para> > <para>A &linkset; allows performing two major tasks: 2071c2093 < to the &rt;).</para></listitem> --- > to the run-time).</para></listitem> 2073c2095 < will contain the module functionality</simpara></listitem></orderedlist> --- > will contain the module functionality.</simpara></listitem></orderedlist> 2077c2099 < <para>More formally, a &linkset; is a directory containing at least --- > <para>Explicitly, a &linkset; is a directory containing at least 2078a2101,2112 > <varlistentry><term>&lisp-run;</term> > <listitem><simpara>runtime executable</simpara></listitem></varlistentry> > <varlistentry><term>&lispinit;</term> > <listitem><simpara>a &mem-image; that contains all the facilities > provided by the current extension, and certain other existing > facilities.</simpara></listitem></varlistentry> > <varlistentry><term><filename>modules.h</filename></term> > <listitem><simpara>the list of modules contained in this &linkset; > </simpara></listitem></varlistentry> > <varlistentry><term><filename>modules.o</filename></term> > <listitem><simpara>the compiled list of modules contained in this &linkset; > </simpara></listitem></varlistentry> 2107,2112d2140 < <varlistentry><term><filename>modules.h</filename></term> < <listitem><simpara>the list of modules contained in this &linkset; < </simpara></listitem></varlistentry> < <varlistentry><term><filename>modules.o</filename></term> < <listitem><simpara>the compiled list of modules contained in this &linkset; < </simpara></listitem></varlistentry> 2116,2119d2143 < <varlistentry><term>&lisp-run;</term> < <listitem><simpara>the executable &rt;</simpara></listitem></varlistentry> < <varlistentry><term>&lispinit;</term> < <listitem><simpara>the &mem-image;</simpara></listitem></varlistentry> 2123,2135c2147,2152 < <simplesect id="clisp-link"><title>Operating on &modset;s and &linkset;s</title> < <para>Adding one or several &modset;s to a &linkset;s produces a new < &linkset; which contains the functionality of those modules in addition < to all the functionality present in the original &linkset;. < This is done by the &clisp-link; shell script.</para> < <para>&clisp-link; needs a directory containing: < <itemizedlist> < <listitem><simpara><filename>"modules.c"</filename></simpara></listitem> < <listitem><simpara>&clisp-h;</simpara></listitem> < </itemizedlist> < &clisp-link; expects to find these files in a < subdirectory <filename>linkkit/</filename> of the current directory. < This can be overridden by the &env-var; <envar>CLISP_LINKKIT</envar>.</para> --- > <simplesect id="clisp-link"><title>&clisp-link;</title> > <para>clisp-link is a shell script used to build &modset;s and > &linkset;s from the &c-lang; source files of an extension. By > default, it is installed in &libdir;, and usually without executable > permissions, so it may have to be invoked as > <screen>&sh-prompt; &sh; /path/to/&clisp-link; ...</screen></para> 2137,2138c2154,2156 < <variablelist><title>&clisp-link; commands</title> < <varlistentry><term>create</term> --- > <para>&clisp-link; can be used in four modes as follows: > <variablelist> > <varlistentry><term>create-module-set</term> 2140,2145c2158,2173 < <screen>&sh-prompt; &clisp-link; create &mod-r; &file-r; ...</screen> < creates a &modset; in &mod-r; directory which refers < (via symbolic links) to files &file-r;... < The files are expected to be modules of their own. < </para></listitem></varlistentry> < <varlistentry><term>add</term> --- > <screen>&sh-prompt; &clisp-link; create-module-set <replaceable>module-set</replaceable> <replaceable>source-files</replaceable></screen> > creates a &modset; <replaceable>module-set</replaceable> using > <replaceable>source-files</replaceable>, which are expected to be > modules of their own. If <replaceable>module-set</replaceable> is > not a subdirectory of the current directory, then the symbolic links > in <replaceable>module-set</replaceable> may have to be corrected > after this command.</para></listitem></varlistentry> > <varlistentry><term>add-module-set</term> > <listitem><para>The command > <screen>&sh-prompt; &clisp-link; add-module-set <replaceable>module-set</replaceable> <replaceable>old-linking-set</replaceable> <replaceable>new-linking-set</replaceable></screen> > builds a &linkset; <replaceable>new-linking-set</replaceable> > from the &modset; <replaceable>module-set</replaceable>, by > combining it with the facilities provided by the existing linking > set > <replaceable>old-linking-set</replaceable>.</para></listitem></varlistentry> > <varlistentry><term>add-module-sets</term> 2147,2150c2175,2180 < <screen>&sh-prompt; &clisp-link; add &source-r; &dest-r; &mod-r; ...</screen> < combines the &linkset; in directory &source-r; and the &module;s in < directories &mod-r;... to a new &linkset;, in the directory &dest-r; < which is newly created.</para></listitem></varlistentry> --- > <screen>&sh-prompt; &clisp-link; add-module-sets <replaceable>old-linking-set</replaceable> <replaceable>new-linking-set</replaceable> <replaceable>module-sets</replaceable></screen> > builds a &linkset; <replaceable>new-linking-set</replaceable> > from the &modset;s <replaceable>module-sets</replaceable>, by > combining them with the facilities provided by the existing linking > set > <replaceable>old-linking-set</replaceable>.</para></listitem></varlistentry> 2153,2159c2183,2199 < <screen>&sh-prompt; &clisp-link; run &source-r; &mod-r; ...</screen> < runs the &linkset; in directory &source-r;, with the &module;s < in directories &mod-r;... < If &clisp; has been built with the configuration option &with-dynmod;, < the loading will be performed <link linkend="mod-dynload">dynamically</link>. < Otherwise - this is much slower - a temporary &linkset; will be created < and deleted afterwards.</para></listitem></varlistentry></variablelist> --- > <screen>&sh-prompt; &clisp-link; run <replaceable>linking-set</replaceable> <replaceable>module-sets</replaceable></screen> > runs the runtime executable in the &linkset; > <replaceable>linking-set</replaceable> with the extensions in the > modules sets <replaceable>module-sets</replaceable> loaded. If > &clisp; has been built with the configuration option &with-dynmod;, > the loading will be performed <link > linkend="mod-dynload">dynamically</link>. Otherwise — this is > much slower — a temporary &linkset; will be created and > deleted > afterwards.</para></listitem></varlistentry></variablelist></para> > > <para>&clisp-link; uses the &c-lang; files &clisp-h; and > <filename>"modules.c"</filename>, which are installed with &clisp; > in the directory &libdir;/linkkit. These two files must be in the > subdirectory <filename>linkkit/</filename> of the current directory. > An alternative directory can be specified using the &env-var; > <envar>CLISP_LINKKIT</envar>.</para> 2160a2201,2237 > <para>Here are some examples of using &clisp-link;</para> > <variablelist> > <varlistentry> > <term>Creating a &modset;</term> > <listitem> > <para>Suppose that the files <filename>foo-1.c</filename> and > <filename>foo-2.c</filename> in the directory > <filename>foo/</filename> contain the source code for an > extension. To build a &modset; in the subdirectory > <filename>foo-module/</filename> of <filename>foo/</filename>, > invoke the following command in the directory > <filename>foo/</filename>: > <screen>&sh-prompt; &clisp-link; create-module-set <filename>foo-module</filename> <filename>foo-1.c</filename> <filename>foo-2.c</filename></screen></para> > </listitem> > </varlistentry> > <varlistentry> > <term>Adding a &modset;</term> > <listitem> > <para>To build a &linkset; in the directory > <filename>/tmp/base+foo/</filename>, by combining the above > &modset; with the facilities provided by the &base; > &linkset;, do this from the directory > <filename>foo/</filename>: > <screen>&sh-prompt; &clisp-link; add-module-set <filename>foo-module</filename> <filename>/path/to/clisp/base</filename> <filename>/tmp/base+foo</filename></screen></para> > </listitem> > </varlistentry> > <varlistentry> > <term>Using <envar>CLISP_LINKKIT</envar></term> > <listitem> > <para>To do the first example above without copying the > <filename>linkkit</filename> directory into the directory > <filename>foo/</filename>, give this command in the directory > <filename>foo/</filename>: > <screen>&sh-prompt; env <envar>CLISP_LINKKIT</envar>=<filename>/path/to/clisp/linkkit</filename> &clisp-link; create-module-set <filename>foo-module</filename> <filename>foo-1.c</filename> <filename>foo-2.c</filename></screen></para> > </listitem> > </varlistentry> > </variablelist> 2167,2169c2244,2246 < <listitem><simpara>the space-separated list of object files that < belong to the &modset; and will belong to every new &linkset; linked < with this &modset;.</simpara></listitem></varlistentry> --- > <listitem><simpara>the space-separated list of files that > belong to the &modset; and will belong to every new &linkset;. > </simpara></listitem></varlistentry> 2171c2248 < <listitem><simpara>the space-separated list of object files, libraries or --- > <listitem><simpara>the space-separated list of files or 2178,2179c2255,2256 < &modset; defines a module of its own. The module name is usually < derived from the file name.</simpara></listitem></varlistentry> --- > &modset; defines a module of its own. The module name is derived > from the file name.</simpara></listitem></varlistentry> 2405,2406c2482,2484 < allocations (&malloc; et al) - and must be saved on the &STACK; using &cpp; < macros <function>pushSTACK()</function>, <function>popSTACK()</function> --- > allocations (<function role="unix">malloc</function> et al) - > and must be saved on the &STACK; using &cpp; macros > <function>pushSTACK()</function>, <function>popSTACK()</function> 2418,2426c2496,2497 < </simpara><simpara>If the system call could block < (e.g., <function role="unix">read</function>) < you need to use <literal>begin_blocking_system_call()</literal> and < <literal>end_blocking_system_call()</literal> instead. This will < allow other threads to run while yours is inside the system call. < This means that &gc;ion could happen while you are inside this system < call and, thus, that all objects of type <type>object</type> are < invalidated by the call. See also <xref linkend="gc-safety"/>. < </simpara></listitem></itemizedlist> --- > </simpara></listitem> > </itemizedlist> 2472c2543 < <listitem><simpara>Certain &c-lang; structures have different --- > <listitem><simpara>Third, certain &c-lang; structures have different 2502,2504c2573,2575 < &def-call-out; form does not describe the &c-lang; function's < expectations with respect to the arguments and return values < (including &allocation;), you will probably learn that the hard way. --- > &def-call-out; form does not describe the function's expectations > with respect to the arguments and return values (including > &allocation;), you will probably learn that the hard way. 4394c4465 < cannot be permanently removed from the &rt;, and an experienced --- > cannot be permanently removed from the run-time, and an experienced --8<---------------cut here---------------end--------------->8--- |
From: Sam S. <sd...@gn...> - 2009-06-15 14:05:12
|
N. Raghavendra wrote: ... a web link to the diff is much preferred over an in-line diff. thanks. |
From: N. R. <ra...@mr...> - 2009-06-17 06:42:11
|
At 2009-06-15T14:33:35-04:00, Sam Steingold wrote: > mv ./doc/impext.xml.local ./doc/impext.xml > cvs up > cvs diff -uw ./doc/impext.xml > > now you need to go through your changes and make sure you mean EVERY > SINGLE ONE of them. Yes, I have done that, and the new diff at the same URL, http://www.retrotexts.net/tmp/impext.xml.diff I hope this is alright. Regards, |
From: Sam S. <sd...@gn...> - 2009-06-17 19:36:06
|
N. Raghavendra wrote: > > http://www.retrotexts.net/tmp/impext.xml.diff thanks. I applied some of the changes. alas, some changes were just text formatting, so it was hard to figure out what you were trying to do. some other changes reverted the changes I recently made (specifically, you still want to use old commands like "add-module-set" instead of simply "add"). please take a look at http://clisp.podval.org/impnotes/modules.html |
From: Sam S. <sd...@gn...> - 2009-06-15 14:08:05
|
N. Raghavendra wrote: > The following seems to work. 1. this is not against cvs head. please merge the head (cvs up) 2. plane diffs are unreliable and unreadable. please send unified context diffs (cvs diff -uw) thanks. |
From: Sam S. <sd...@gn...> - 2009-06-11 16:48:15
|
N. Raghavendra wrote: > At 2009-06-10T13:47:27-04:00, Sam Steingold wrote: > > An external module consists of two objects, a module set and a linking > set, which are built from the source files of the extension. false. a module is a part of a module set. |
From: Kaz K. <kky...@gm...> - 2009-06-11 18:12:29
|
On Thu, Jun 11, 2009 at 9:45 AM, Sam Steingold<sd...@gn...> wrote: > N. Raghavendra wrote: >> At 2009-06-10T13:47:27-04:00, Sam Steingold wrote: >> >> I have appended >> a modified version of that text, which describes what I had in mind. > > I cannot do a diff with my naked eye. Sorry. > > Please send a diff against cvs head: > edit doc/impext.xml and do > cvs diff doc/impext.xml You know, the docs are fine pretty much the way they are in this area. If you follow the steps, you will get a successful link. Note that N. Raghavendra did actually successfully make his custom linked CLISP; the only problem was a slight misconception regarding its use. A manual can't anticipate every possible misconception that may be entertained by every possible reader, because then the resulting text will be long-winded and obtuse. Everyone is different. This is why we have other resources like mailing lists, FAQ's and whatnot. The reference manual can't be everything to everyone. Is this a FAQ, by the way? I dispute the F. When was the last time someone asked why the custom linked functions, made by clisp-link in some ``foo+base'' module, did not appear in plain clisp? |
From: Sam S. <sd...@gn...> - 2009-06-11 19:06:52
|
Kaz Kylheku wrote: > > You know, the docs are fine pretty much the way they are in this area. thanks. > A manual can't anticipate every possible misconception > that may be entertained by every possible reader, because > then the resulting text will be long-winded and obtuse. > Everyone is different. this is the biggest problem in writing the manual (or a textbook): by the time you know the subject well enough to teach, you have already forgotten how hard it was to learn. I thought long and hard about the changes I made yesterday. I do think that was an improvement. I am open to suggestions - a word here and there might make a difference to a newbie. I do not expect to make any major changes though. (except for, possibly, merging add-module-set and add-module-sets commands) > Is this a FAQ, by the way? I dispute the F. When was the last time > someone asked why the custom linked functions, made by > clisp-link in some ``foo+base'' module, did not appear in > plain clisp? I do seem to recall that people were upset that the clisp resulting from "./configure --with-module=foo" did not have foo. they had to be reminded to use "clisp -K full". actually, now that you asked about it, I think I asked this question myself about 10 years ago. :-) Sam. |
From: N. R. <ra...@mr...> - 2009-06-15 18:10:00
|
At 2009-06-15T09:40:58-04:00, Sam Steingold wrote: > a web link to the diff is much preferred over an in-line diff. I have put the diff at http://www.retrotexts.net/tmp/impext.xml.diff It was made with the commands cd /tmp/clisp cvs update diff -uw ./doc/impext.xml ./doc/impext.xml.local > /tmp/impext.xml.diff Regards, -- N. Raghavendra <ra...@mr...> | http://www.retrotexts.net/ Harish-Chandra Research Institute | http://www.mri.ernet.in/ See message headers for contact and OpenPGP information. |
From: Sam S. <sd...@gn...> - 2009-06-15 18:34:51
|
N. Raghavendra wrote: > At 2009-06-15T09:40:58-04:00, Sam Steingold wrote: > >> a web link to the diff is much preferred over an in-line diff. > > I have put the diff at http://www.retrotexts.net/tmp/impext.xml.diff good. > It was made with the commands > > cd /tmp/clisp > cvs update > diff -uw ./doc/impext.xml ./doc/impext.xml.local > /tmp/impext.xml.diff wrong. your diff reverts many of my changes which I made after you forked (started to edit) the file - this is why it is so large. this is no good. you need: mv ./doc/impext.xml.local ./doc/impext.xml cvs up cvs diff -uw ./doc/impext.xml now you need to go through your changes and make sure you mean EVERY SINGLE ONE of them. E.g., you obviously do not mean this one: @@ -177,7 +177,7 @@ <para>Memory images are ¬-e; portable across different platforms (in contrast with platform-independent &fasl-file; files). They are ¬-e; even portable across &linkset;s: image saved using - the &full; &linkset; cannot be used with the &base; &rt;:<screen> + the &full; &linkset; cannot be used with the &base; runtime:<screen> &sh-prompt; clisp -K full -x '(&savemem;)' &sh-prompt; clisp -K base -M lispinit.mem base/lisp.run: initialization file `lispinit.mem' was not created by this version of CLISP runtime</screen> so please revert it. an alternative is to figure out which revision you forked and diff against it. the diff should be smaller. in the future, edit the file _in place_ and then "cvs up" will auto-merge the changes I made into your file. There might be conflicts, of course, but you will be able to resolve them manually. You might want to ask the cvs mailing list for further help. thanks. Sam. |
From: N. R. <ra...@mr...> - 2009-06-10 05:30:13
|
At 2009-06-09T11:00:16-07:00, Kaz Kylheku wrote: > This looks like you are loading foo.fas into a Lisp image which > doesn't have the C module > linked to it. I.e. you are using the wrong lisp.run executable. > > You must use your base+fun/lisp.run and base+fun/lispinit.mem. Thank you for your reply. As I wrote, I did try % base+foo/lisp.run -M base+foo/lispinit.mem and verified that it was indeed possible then to evaluate foo:EPERM from the REPL. My question, perhaps not clearly asked earlier, was: Can I access the above symbol foo:EPERM while running a (lisp.run,image) pair different from (base+foo/lisp.run,base+foo/lispinit.mem), e.g., while running the usual (base/lisp.run,base/lispinit.mem)? Regards, -- N. Raghavendra <ra...@mr...> | http://www.retrotexts.net/ Harish-Chandra Research Institute | http://www.mri.ernet.in/ See message headers for contact and OpenPGP information. |
From: <Joe...@t-...> - 2009-06-10 08:41:40
|
N. Raghavendra asked: >Can I access the above symbol foo:EPERM while running a >(lisp.run,image) >pair different from (base+foo/lisp.run,base+foo/lispinit.mem), e.g., >while running the usual (base/lisp.run,base/lispinit.mem)? You can TRY the following and see how far you get: - Search the module dynload facility that may have been compiled into your clisp. This is NOT FFI:OPEN-FOREIGN-LIBRARY! It is called SYS::DYNLOAD-MODULES. http://clisp.cons.org/impnotes/modules.html#mod-dynload - Use it to load the C module. - Loading will fail with a package error, as your package FOO is unknown yet. If there's another error, there's probably no way I can help you. That was the warm up phase. Now the real code: - Define (defpackage "FOO"...) exactly like in your original foo.lisp - Try to load the C module again. Now it should work. The basic idea is to fulfil all the requirements that the module has to be able to load. A module-specific package is the typical only one (or was, when I fiddled with modules years ago). Summary: (defpackage "FOO" ...) (sys::dynload-modules "foo.o") Regards, Jorg Hohle |
From: Sam S. <sd...@gn...> - 2009-06-10 14:09:15
|
N. Raghavendra wrote: > > Can I access the above symbol foo:EPERM while running a (lisp.run,image) > pair different from (base+foo/lisp.run,base+foo/lispinit.mem), e.g., > while running the usual (base/lisp.run,base/lispinit.mem)? if it were possible, why would we want to create the base+foo linking set?! |
From: N. R. <ra...@mr...> - 2009-06-10 17:36:14
|
At 2009-06-10T10:23:49+02:00, Joe...@t-... wrote: > You can TRY the following and see how far you get: > - Search the module dynload facility that may have been compiled into > your clisp. > This is NOT FFI:OPEN-FOREIGN-LIBRARY! It is called > SYS::DYNLOAD-MODULES. > http://clisp.cons.org/impnotes/modules.html#mod-dynload It looks like I didn't configure --with-dynamic-modules when building CLISP, so I have to rebuild before trying this. I'll do that. Thanks, -- N. Raghavendra <ra...@mr...> | http://www.retrotexts.net/ Harish-Chandra Research Institute | http://www.mri.ernet.in/ See message headers for contact and OpenPGP information. |
From: N. R. <ra...@mr...> - 2009-06-10 17:40:44
|
At 2009-06-10T09:55:42-04:00, Sam Steingold wrote: > if it were possible, why would we want to create the base+foo linking > set?! Okay, so linking sets and modules are the way to go. Generally, what do people do when they want to access the value of a constant defined in a C header file, while using the FFI without building a module? If I understand [Example 32.6. Accessing cpp macros], one writes a C wrapper function which just returns the value of the constant, and uses DEF-CALL-OUT on that C wrapper function with an appropriate :library argument. Is that correct? Thanks, -- N. Raghavendra <ra...@mr...> | http://www.retrotexts.net/ Harish-Chandra Research Institute | http://www.mri.ernet.in/ See message headers for contact and OpenPGP information. |
From: Sam S. <sd...@gn...> - 2009-06-10 17:51:56
|
N. Raghavendra wrote: > > Generally, what do people do when they want to access the value of a > constant defined in a C header file, while using the FFI without > building a module? If I understand [Example 32.6. Accessing cpp macros], > one writes a C wrapper function which just returns the value of the > constant, and uses DEF-CALL-OUT on that C wrapper function with an > appropriate :library argument. Is that correct? yes. you create a C file ===== #include <foo.h> int foo (void) { return MY_CONST; } ===== compile it to foo.so and use (:library "foo.so") def-c-const is much easier to use. |