Hi,
I know the subject line is a little obscure, however, here is what I
have in mind.
In CMUCL you can concatenate a set of .fasl files into a single one
which can then be "loaded" without problems. This is almost the same
thing you do with C/C++ and friends with archive files. In Java you
have .jar files that fill a similar role.
So here is the question.
Is there a way to achieve the same effect in other CL implementations?
I.e. to concatenate (or better "archive") a bunch of .fasl files into
a single one that can then be "loaded"?
Any help will be appreciated. I know this is a RTFM question, but you
guys can same me time :)
Thanks
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
> Is there a way to achieve the same effect in other CL implementations?
> I.e. to concatenate (or better "archive") a bunch of .fasl files into
> a single one that can then be "loaded"?
In Harl^H^H^H^H Xanalys lisps (LW, LWW, Liquid),
(concatenate-system output-file system &key)
See the Reference manual for details
http://www.xanalys.com/software_tools/reference/lww41/lwref/LWRM-176.html
(but note that this manual page misreports the argument list)
Example:
(defsystem my-system()
:members (
"file1"
"file2"))
(concatenate-system "application.fsl" 'my-system)
- nick
From: Tim Bradshaw
Subject: Re: Building a "loadable" tar file.
Date:
Message-ID: <ey3d7ongrx8.fsf@cley.com>
* Marco Antoniotti wrote:
> Is there a way to achieve the same effect in other CL implementations?
> I.e. to concatenate (or better "archive") a bunch of .fasl files into
> a single one that can then be "loaded"?
ACL lets you do this, I think just by concatenating the files.
--tim
Tim Bradshaw <···@cley.com> writes:
> * Marco Antoniotti wrote:
>
> > Is there a way to achieve the same effect in other CL implementations?
> > I.e. to concatenate (or better "archive") a bunch of .fasl files into
> > a single one that can then be "loaded"?
>
> ACL lets you do this, I think just by concatenating the files.
>
Thanks to all who answered. However, I would like to know whether I
can just do a 'cat f1.fasl f2.fasl ... fn.fasl > mappazza.fasl'
from the shell (or something equivalent).
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
> Thanks to all who answered. However, I would like to know whether I
> can just do a 'cat f1.fasl f2.fasl ... fn.fasl > mappazza.fasl'
> from the shell (or something equivalent).
(As fas as I remember) In Liquid: yes. In LW / LWW: no.
- n
Ok. Thanks.
So, here is the current list of "CL implementations which can 'cat'
fasl files together".
CMUCL
ACL
Liquid/Lucid
CLisp
The only negative response regards LW.
What about other implementations?
Corman, ECLipse, KCL/AKCL/GCL/Ecolisp. MCL?
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
From: Tim Bradshaw
Subject: Re: Building a "loadable" tar file.
Date:
Message-ID: <ey3vh2ef4zm.fsf@cley.com>
* Marco Antoniotti wrote:
> Corman, ECLipse, KCL/AKCL/GCL/Ecolisp. MCL?
gcl can only do it if .o files can be catted together, and I kind if
doubt that will work (but maybe, who knows?).
--tim
Tim Bradshaw <···@cley.com> writes:
> * Marco Antoniotti wrote:
>
> > Corman, ECLipse, KCL/AKCL/GCL/Ecolisp. MCL?
>
> gcl can only do it if .o files can be catted together, and I kind if
> doubt that will work (but maybe, who knows?).
Dah! Good point. This is a sign that I need another cappuccino this
morning. (BTW. I mean cappuccino, not the Starbucks crap! :) )
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
Marco Antoniotti <·······@parades.rm.cnr.it> writes:
> Tim Bradshaw <···@cley.com> writes:
>
> > * Marco Antoniotti wrote:
> >
> > > Corman, ECLipse, KCL/AKCL/GCL/Ecolisp. MCL?
> >
> > gcl can only do it if .o files can be catted together, and I kind if
> > doubt that will work (but maybe, who knows?).
>
> Dah! Good point. This is a sign that I need another cappuccino this
> morning. (BTW. I mean cappuccino, not the Starbucks crap! :) )
Some versions of "ld" have an option for "incremental
linking", which is used for bundling several .o files into a single
file. I'm not sure if this would be usable with gcl, though.
--
Raymond Wiker, Orion Systems AS
+47 370 61150
From: Fernando D. Mato Mira
Subject: Re: Building a "loadable" tar file.
Date:
Message-ID: <38D9EE02.EE5ED48C@iname.com>
Tim Bradshaw wrote:
> * Marco Antoniotti wrote:
>
> > Corman, ECLipse, KCL/AKCL/GCL/Ecolisp. MCL?
>
> gcl can only do it if .o files can be catted together, and I kind if
> doubt that will work (but maybe, who knows?).
Can you use `ar' otherwise?
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
Fernando D. Mato Mira wrote:
> > gcl can only do it if .o files can be catted together, and I kind if
> > doubt that will work (but maybe, who knows?).
>
> Can you use `ar' otherwise?
I don't think you can. Why do I say this? Because .o files (on Solaris at
least) are not in ar file format.
Cheers,
:) will
Will> Fernando D. Mato Mira wrote:
>> > gcl can only do it if .o files can be catted together, and I kind if
>> > doubt that will work (but maybe, who knows?).
>>
>> Can you use `ar' otherwise?
Will> I don't think you can. Why do I say this? Because .o files (on Solaris at
Will> least) are not in ar file format.
No, but to all intents and purposes that doesn't matter, because all you ever
do with a thing.o file (apart from nm) is link it as
gcc -o bar foo.o thing.o -L.... -l....
and you can always say
gcc -o bar foo.o libthing.a -L.... -l....
so you can use ar in a way similar to concatting.
Philip
--
Not getting what you want is sometimes a wonderful stroke of luck.
-----------------------------------------------------------------------------
Philip Lijnzaad, ········@ebi.ac.uk | European Bioinformatics Institute,rm A2-24
+44 (0)1223 49 4639 | Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax) | Cambridgeshire CB10 1SD, GREAT BRITAIN
PGP fingerprint: E1 03 BF 80 94 61 B6 FC 50 3D 1F 64 40 75 FB 53
Philip Lijnzaad <········@ebi.ac.uk> writes:
> Will> Fernando D. Mato Mira wrote:
>
> >> > gcl can only do it if .o files can be catted together, and I kind if
> >> > doubt that will work (but maybe, who knows?).
> >>
> >> Can you use `ar' otherwise?
>
> Will> I don't think you can. Why do I say this? Because .o files (on Solaris at
> Will> least) are not in ar file format.
>
>
> No, but to all intents and purposes that doesn't matter, because all you ever
> do with a thing.o file (apart from nm) is link it as
>
> gcc -o bar foo.o thing.o -L.... -l....
>
> and you can always say
>
> gcc -o bar foo.o libthing.a -L.... -l....
>
> so you can use ar in a way similar to concatting.
Exactly. It be nice if LOAD could handle the equivalent of a .a file
in any case. I'd be glad to be able to concatenate fasl files.
So, how do you do it with LispWorks? (No CONCATENATE-SYSTEM please).
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
Marco Antoniotti wrote:
> It be nice if LOAD could handle the equivalent of a .a file in any case. I'd be
> glad to be able to concatenate fasl files.
I'm stumped now. Don't you want something like ar for fasl files? This would set up a
symbol lookup table that could be tell the system what you were loading.
Cheers,
:) will
William Deakin <·····@pindar.com> writes:
> Marco Antoniotti wrote:
>
> > It be nice if LOAD could handle the equivalent of a .a file in any case. I'd be
> > glad to be able to concatenate fasl files.
>
> I'm stumped now. Don't you want something like ar for fasl files? This would set up a
> symbol lookup table that could be tell the system what you were loading.
Let's backtrack a minute.
1 - Yes. I'd like LOAD to recognize a file which was the result of a
collection operation of many fasl files, and "do the right" thing
with it.
2 - This would require a change in the standard.
3 - Some CL implementations allow you to actually 'cat' fasl files
together for the benefit of LOAD.
So we are stuck with (3) and I am trying to understand whether this is
doable and how with CLs which do not allow you to 'cat' fasl files
together.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
* Marco Antoniotti <·······@parades.rm.cnr.it>
| 1 - Yes. I'd like LOAD to recognize a file which was the result of a
| collection operation of many fasl files, and "do the right" thing
| with it.
|
| 2 - This would require a change in the standard.
huh? why is this?
| 3 - Some CL implementations allow you to actually 'cat' fasl files
| together for the benefit of LOAD.
if we regard a Common Lisp source file as a sequence of individual
top-level forms that does not know about file boundaries between them,
you can easily concatenate source files and end up with something that
can be loaded as a unit. if we regard the compiled fasl files the same
way, and this can obviously be done if each top-level form is saved to
disk individually, possibly including some file-specific prologue that is
generated by the compiler, there really is nothing special involved in
concatenating files.
if you can load from a stream, you can load from a concatenated-stream,
so there should already be support in the standard for the whole concept.
#:Erik
Erik Naggum <····@naggum.no> writes:
> * Marco Antoniotti <·······@parades.rm.cnr.it>
> | 1 - Yes. I'd like LOAD to recognize a file which was the result of a
> | collection operation of many fasl files, and "do the right" thing
> | with it.
> |
> | 2 - This would require a change in the standard.
>
> huh? why is this?
I was too fast. Here is my line of thought: (1) the "fasl" format
is implementation dependent, (2) the specs for LOAD somewhat imply
that the operation has to deal with a single "fasl" file. In order to
make sure that LOAD operated on a file which is the "concatenation" or
"archival" (given appropriate definitions of "concatenation" and
"archival") in a "standard" way, would require you to put contraints
on the content of a fasl file.
> | 3 - Some CL implementations allow you to actually 'cat' fasl files
> | together for the benefit of LOAD.
>
> if we regard a Common Lisp source file as a sequence of individual
> top-level forms that does not know about file boundaries between them,
> you can easily concatenate source files and end up with something that
> can be loaded as a unit. if we regard the compiled fasl files the same
> way, and this can obviously be done if each top-level form is saved to
> disk individually, possibly including some file-specific prologue that is
> generated by the compiler, there really is nothing special involved in
> concatenating files.
Of course. However, it seems like LW does not support this operation.
> if you can load from a stream, you can load from a concatenated-stream,
> so there should already be support in the standard for the whole concept.
This is a very good point which would invalidate my reasoning above.
I'll have to try it.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
Marco Antoniotti wrote:
> In order to make sure that LOAD operated on a file which is the "concatenation"
> or "archival" (given appropriate definitions of "concatenation" and "archival")
> in a "standard" way, would require you to put contraints on the content of a
> fasl file.
I didn't mean to go all language-lawyer about this. It is just that (as far as I
know) the word concatenate has a very specific meaning. Particularly when used in
a UNIX context.
Cheers,
:) will
From: Tim Bradshaw
Subject: Re: Building a "loadable" tar file.
Date:
Message-ID: <ey3d7olg11h.fsf@cley.com>
* Philip Lijnzaad wrote:
> No, but to all intents and purposes that doesn't matter, because all you ever
> do with a thing.o file (apart from nm) is link it as
> gcc -o bar foo.o thing.o -L.... -l....
> and you can always say
> gcc -o bar foo.o libthing.a -L.... -l....
> so you can use ar in a way similar to concatting.
You can also do other things with them, like call dlopen, which I
think is what gcl does now ld -A doesn't work on most machines.
--tim
Philip wrote:
> No, but to all intents and purposes that doesn't matter, because all you ever
> do with a thing.o file (apart from nm) is link it as
>
> gcc -o bar foo.o thing.o -L.... -l....
>
> and you can always say
>
> gcc -o bar foo.o libthing.a -L.... -l....
>
> so you can use ar in a way similar to concatting.
Yes, you use ar in a way similar to concatting but it is fundamentally different. If
you run
cat foo.o bar.o > foobar.o
You end up with a different (and mostly unusable) file foobar.o. Whilst
ar cru libthing.a foo.o bar.o
creates a libthing.a archive which can then be used to link into an executable. Also
I believe you can also use .o files to create libraries.
Cheers,
:) will
Tim Bradshaw <···@cley.com> writes:
> * Marco Antoniotti wrote:
>
> > Corman, ECLipse, KCL/AKCL/GCL/Ecolisp. MCL?
>
> gcl can only do it if .o files can be catted together, and I kind if
> doubt that will work (but maybe, who knows?).
With object files, one usually uses "ar" to build a library, a single
file that subsumes all the .o files.
--
Tom Breton, http://world.std.com/~tob
Not using "gh" since 1997. http://world.std.com/~tob/ugh-free.html
Rethink some Lisp features, http://world.std.com/~tob/rethink-lisp/index.html
Marco Antoniotti <·······@parades.rm.cnr.it> writes:
> What about other implementations?
>
> Corman, ECLipse, KCL/AKCL/GCL/Ecolisp. MCL?
MCL comes with source code of functions that do "fasl" concatenation
(fasl-concatenate and pfsl-concatenate). It's a little more
complicated than simple file concatenation.
John Wiseman
Marco Antoniotti <·······@parades.rm.cnr.it> wrote:
Here is function I use to concatenate fasl files in ACL5 (should be
portable):
(defun concat-files (files to)
(let ((buffer (make-array 2048 :element-type '(unsigned-byte 8))))
(with-open-file (out to :direction :output
:if-exists :supersede
:element-type '(unsigned-byte 8))
(dolist (file files)
(with-open-file (in file :element-type '(unsigned-byte 8))
(do ((bytes (read-sequence buffer in)
(read-sequence buffer in)))
((zerop bytes))
(write-sequence buffer out :start 0 :end bytes)))))))
Regards
Francis
--
Francis Leboutte
··@algo.be www.algo.be +32-(0)4.388.39.19
From: Thom Goodsell
Subject: Re: Building a "loadable" tar file.
Date:
Message-ID: <38D8D5ED.17DD7443@cra.com>
From CLISP implementation notes:
"If your application is made up of several lsp or fas files, you can
simply concatenate them (using cat(1)) into one file."
http://clisp.sourceforge.net/impnotes.html
On Wed, 22 Mar 2000 09:17:17 -0500, Thom Goodsell <···@cra.com> wrote:
> From CLISP implementation notes:
> "If your application is made up of several lsp or fas files, you can
> simply concatenate them (using cat(1)) into one file."
What about .lib files? Do they need to be kept separate? Can they be
concatenated together, possibly to the .fas files?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: Sam Steingold
Subject: Re: Building a "loadable" tar file.
Date:
Message-ID: <u7leuwu3k.fsf@ksp.com>
>>>> In message <····························@4ax.com>
>>>> On the subject of "Re: Building a "loadable" tar file."
>>>> Sent on Wed, 22 Mar 2000 21:52:32 +0100
>>>> Honorable Paolo Amoroso <·······@mclink.it> writes:
>> On Wed, 22 Mar 2000 09:17:17 -0500, Thom Goodsell <···@cra.com> wrote:
>>
>> > From CLISP implementation notes:
>> > "If your application is made up of several lsp or fas files, you can
>> > simply concatenate them (using cat(1)) into one file."
>>
>> What about .lib files? Do they need to be kept separate? Can they be
>> concatenated together, possibly to the .fas files?
From CLISP implementation notes:
#p".lib": used by compile-file when compiling a require form referring
to the input file
you don't need *.lib for running, only when compiling other files.
--
Sam Steingold (http://www.podval.org/~sds)
Micros**t is not the answer. Micros**t is a question, and the answer is Linux,
(http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation.
Takeoffs are optional. Landings are mandatory.
Marco,
Since your focus is primarily on CMUCL it is worth mentioning the SPARCF
of X86F files
that are native. Perhaps you should address the native files as well.
Tunc
Marco Antoniotti wrote:
>
> Hi,
>
> I know the subject line is a little obscure, however, here is what I
> have in mind.
>
> In CMUCL you can concatenate a set of .fasl files into a single one
> which can then be "loaded" without problems. This is almost the same
> thing you do with C/C++ and friends with archive files. In Java you
> have .jar files that fill a similar role.
>
> So here is the question.
>
> Is there a way to achieve the same effect in other CL implementations?
> I.e. to concatenate (or better "archive") a bunch of .fasl files into
> a single one that can then be "loaded"?
>
> Any help will be appreciated. I know this is a RTFM question, but you
> guys can same me time :)
>
> Thanks
>
> --
> Marco Antoniotti ===========================================
> PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
> tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
> http://www.parades.rm.cnr.it/~marcoxa