From: Raymond T. <to...@rt...> - 2001-02-26 23:07:07
|
Is there a way to get defsystem to tell me what order the files will be loaded? Something like (mk:oos system :load-order) that returns a list of the files in the order that they would be loaded if everything were up-to-date. I'm just looking for a simple way to concatenate a bunch of (CMUCL) fasl files together to make a library, ala clx-library, clm-library, or hemlock-library. Need to concatenate them in the right order, and defsystem knows what that order should be. Thanks, Ray |
From: Daniel B. <da...@no...> - 2001-02-27 14:07:26
|
Raymond Toy <to...@rt...> writes: > Is there a way to get defsystem to tell me what order the files will > be loaded? Something like (mk:oos system :load-order) that returns a > list of the files in the order that they would be loaded if everything > were up-to-date. > > I'm just looking for a simple way to concatenate a bunch of (CMUCL) > fasl files together to make a library, ala clx-library, clm-library, > or hemlock-library. Need to concatenate them in the right order, and > defsystem knows what that order should be. You might look at agglomerate-system in db-sockets, which does exactly this. Feel free to use it for whatever purpose. http://loaclhost.telent.net/cgi-bin/cvsweb/telent/sockets/agglomerate-system.lisp?rev=1.1&content-type=text/x-cvsweb-markup -dan -- http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources |
From: Marco A. <ma...@cs...> - 2001-02-27 14:14:08
|
> X-Authentication-Warning: edgedsp4.rtp.ericsson.se: toy set sender to to...@rt... using -f > From: Raymond Toy <to...@rt...> > User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.2 (Thelxepeia) > Content-Type: text/plain; charset=us-ascii > Sender: clo...@li... > X-BeenThere: clo...@li... > X-Mailman-Version: 2.0 > Precedence: bulk > List-Help: <mailto:clo...@li...?subject=help> > List-Post: <mailto:clo...@li...> > List-Subscribe: <http://lists.sourceforge.net/lists/listinfo/clocc-devel>, > <mailto:clo...@li...?subject=subscribe> > List-Id: <clocc-devel.lists.sourceforge.net> > List-Unsubscribe: <http://lists.sourceforge.net/lists/listinfo/clocc-devel>, > <mailto:clo...@li...?subject=unsubscribe> > List-Archive: <http://lists.sourceforge.net/archives//clocc-devel/> > Date: 26 Feb 2001 18:08:17 -0500 > Content-Length: 657 > > > Is there a way to get defsystem to tell me what order the files will > be loaded? Something like (mk:oos system :load-order) that returns a > list of the files in the order that they would be loaded if everything > were up-to-date. The functions MK:FILES-IN-SYSTEM MK::FILES-IN-SYSTEM-* MK::FILE-PATHNAMES-* should do. > > I'm just looking for a simple way to concatenate a bunch of (CMUCL) > fasl files together to make a library, ala clx-library, clm-library, > or hemlock-library. Need to concatenate them in the right order, and > defsystem knows what that order should be. Yep. I like the idea and was kind of fiddling around with it. However, please note that we need the equivalent for ACL, LWW, CLisp, MCL, and Corman Lisp. Cheers -- Marco Antoniotti ======================================================== NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 719 Broadway 12th Floor fax +1 - 212 - 995 4122 New York, NY 10003, USA http://bioinformatics.cat.nyu.edu Like DNA, such a language [Lisp] does not go out of style. Paul Graham, ANSI Common Lisp |
From: Stig E. S. <st...@ii...> - 2001-02-27 15:03:20
|
On Tue, 27 Feb 2001, Marco Antoniotti wrote: > > > Is there a way to get defsystem to tell me what order the files will > > be loaded? Something like (mk:oos system :load-order) that returns a > > list of the files in the order that they would be loaded if everything > > were up-to-date. > > > I'm just looking for a simple way to concatenate a bunch of (CMUCL) > > fasl files together to make a library, ala clx-library, clm-library, > > or hemlock-library. Need to concatenate them in the right order, and > > defsystem knows what that order should be. I use such a system for SDS (sds.sourceforge.net) to get both the list of binary files (for catenating to a library) and the source-files to allow them to be distributed easily by automake/autoconf. If the other suggestions don't work I can mail you the defsystem add-on. > Yep. I like the idea and was kind of fiddling around with it. > However, please note that we need the equivalent for ACL, LWW, CLisp, > MCL, and Corman Lisp. catenating ACL's fasl-files and clisp fas-files also seem to work with simple 'cat'. ------------------------------------------------------------------ Stig Erik Sandoe st...@ii... http://www.ii.uib.no/~stig/ |
From: Bruno H. <ha...@il...> - 2001-02-27 15:30:17
|
Stig Erik Sandoe writes: > catenating ACL's fasl-files and clisp fas-files also seem to work > with simple 'cat'. 'cat'ing CLISP's .fas files works, with a limitation: If the first files starts with an 'in-package' declaration and the second doesn't, concatenating them might extend the scope of the 'in-package' declaration. Bruno |
From: Raymond T. <to...@rt...> - 2001-02-27 22:53:10
|
>>>>> "Marco" == Marco Antoniotti <ma...@cs...> writes: >> Is there a way to get defsystem to tell me what order the files will >> be loaded? Something like (mk:oos system :load-order) that returns a >> list of the files in the order that they would be loaded if everything >> were up-to-date. Marco> The functions Marco> MK:FILES-IN-SYSTEM Marco> MK::FILES-IN-SYSTEM-* Marco> MK::FILE-PATHNAMES-* Marco> should do. FILES-IN-SYSTEM is just what I was looking for. However, I want to thank everyone who had suggestions. >> >> I'm just looking for a simple way to concatenate a bunch of (CMUCL) >> fasl files together to make a library, ala clx-library, clm-library, >> or hemlock-library. Need to concatenate them in the right order, and >> defsystem knows what that order should be. Marco> Yep. I like the idea and was kind of fiddling around with it. Marco> However, please note that we need the equivalent for ACL, LWW, CLisp, Marco> MCL, and Corman Lisp. Well it seems that "cat" would work for CMUCL, ACL, and Clisp (with one problem), as others have mentioned. What are you looking for? Some function, MK:MAKE-SYSTEM-LIBRARY, say, that cat's these all together? Ray |
From: Marco A. <ma...@cs...> - 2001-02-28 20:53:53
|
> From: Raymond Toy <to...@rt...> > Date: 27 Feb 2001 17:54:25 -0500 > User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.2 (Thelxepeia) > Content-Type: text/plain; charset=us-ascii > Content-Length: 1275 > > >>>>> "Marco" == Marco Antoniotti <ma...@cs...> writes: > > Marco> MK:FILES-IN-SYSTEM > Marco> MK::FILES-IN-SYSTEM-* > Marco> MK::FILE-PATHNAMES-* > > Marco> should do. > > FILES-IN-SYSTEM is just what I was looking for. However, I want to > thank everyone who had suggestions. > > >> > >> I'm just looking for a simple way to concatenate a bunch of (CMUCL) > >> fasl files together to make a library, ala clx-library, clm-library, > >> or hemlock-library. Need to concatenate them in the right order, and > >> defsystem knows what that order should be. > > Marco> Yep. I like the idea and was kind of fiddling around with it. > Marco> However, please note that we need the equivalent for ACL, > Marco> LWW, CLisp, MCL, and Corman Lisp. > > Well it seems that "cat" would work for CMUCL, ACL, and Clisp (with > one problem), as others have mentioned. > > What are you looking for? Some function, MK:MAKE-SYSTEM-LIBRARY, say, > that cat's these all together? Yes. That would be perfect. I believe also LWW may work. Any idea about how to fix the CLisp problem? Also, anybody knows whether it would work in MCL? An alternative could be to just dump a script and sort of a tar file and have a way to load the result. Maybe asking LOAD to take care of it is a little too much. BTW. I am just thinking out loud. But please, do not put anything in the CVS repository until a satisfactory and portable solution has been found. Cheers -- Marco Antoniotti ======================================================== NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 719 Broadway 12th Floor fax +1 - 212 - 995 4122 New York, NY 10003, USA http://bioinformatics.cat.nyu.edu Like DNA, such a language [Lisp] does not go out of style. Paul Graham, ANSI Common Lisp |
From: Raymond T. <to...@rt...> - 2001-03-07 23:57:12
|
>>>>> "Marco" == Marco Antoniotti <ma...@cs...> writes: >> From: Raymond Toy <to...@rt...> Marco> LWW, CLisp, MCL, and Corman Lisp. >> >> Well it seems that "cat" would work for CMUCL, ACL, and Clisp (with >> one problem), as others have mentioned. >> >> What are you looking for? Some function, MK:MAKE-SYSTEM-LIBRARY, say, >> that cat's these all together? Marco> Yes. That would be perfect. I believe also LWW may work. I see that defsystem already has allegro-make-system-fasl that just cat's all the files together. Marco> Any idea about how to fix the CLisp problem? Also, anybody knows Make sure you do an in-package on every file? Let the Clisp folks fix it if it's important to them? Marco> An alternative could be to just dump a script and sort of a tar file Marco> and have a way to load the result. Maybe asking LOAD to take care of Marco> it is a little too much. BTW. I am just thinking out loud. At one time, as a proof of concept, I actually wrote some portable lisp that could parse the contents of a tar file. Pretty easy. Don't think I have that code anymore. But since load only works on file names, this doesn't help. You have to extract the files from the tar file first, so what's the point? Would be cool if we could. We could have zip files of compiled code like Java's jar files. (Are they essentially the same?) Marco> But please, do not put anything in the CVS repository until a Marco> satisfactory and portable solution has been found. Of course not! Even though I can, I don't like modifying some package that really belongs to someone else. If I do anything, I'd post some code here to let the owner decide if it makes sense. Ray |
From: Marco A. <ma...@cs...> - 2001-03-08 15:50:04
|
> From: Raymond Toy <to...@rt...> > Date: 07 Mar 2001 18:58:50 -0500 > Content-Length: 1933 > > > Marco> Yes. That would be perfect. I believe also LWW may work. > > I see that defsystem already has allegro-make-system-fasl that just > cat's all the files together. Yes. But that is an Allegro-only thing. It'd be worthwhile to also look at how different CL build "images" and "applications". E.g. ACL now can build applications just by selecting a set of files. > Marco> Any idea about how to fix the CLisp problem? Also, anybody knows > > Make sure you do an in-package on every file? Let the Clisp folks fix > it if it's important to them? Bruno and Sam could probably do better than any of us. It does not seem that difficult. Basically you would have to add a form at the beginning of each concatenated file that would expand into something like. (in-package *package*) If I remember correctly from the CLHS, subsequent IN-PACKAGE should behave properly. > Marco> An alternative could be to just dump a script and sort of > Marco> a tar file and have a way to load the result. Maybe asking LOAD > Marco> to take care of it is a little too much. BTW. I am just > Marco> thinking out loud. > > At one time, as a proof of concept, I actually wrote some portable > lisp that could parse the contents of a tar file. Pretty easy. Don't > think I have that code anymore. But since load only works on file > names, this doesn't help. You have to extract the files from the tar > file first, so what's the point? > > Would be cool if we could. We could have zip files of compiled code > like Java's jar files. (Are they essentially the same?) Exactly. Note that .jar files are just .zip files with some extra meta information. I bet they chose .zip because it was more readily portable across platforms. Yet, in Java, the class loaders know about .jar (and .zip) files. Hence, there is no way around but to extend LOAD. Not an easy task. Cheers -- Marco Antoniotti ======================================================== NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 719 Broadway 12th Floor fax +1 - 212 - 995 4122 New York, NY 10003, USA http://bioinformatics.cat.nyu.edu Like DNA, such a language [Lisp] does not go out of style. Paul Graham, ANSI Common Lisp |
From: Raymond T. <to...@rt...> - 2001-03-08 16:05:40
|
>>>>> "Marco" == Marco Antoniotti <ma...@cs...> writes: >> From: Raymond Toy <to...@rt...> >> >> Make sure you do an in-package on every file? Let the Clisp folks fix >> it if it's important to them? Marco> Bruno and Sam could probably do better than any of us. It does not Indeed. That's why I said let them fix it. :-) >> At one time, as a proof of concept, I actually wrote some portable >> lisp that could parse the contents of a tar file. Pretty easy. Don't >> think I have that code anymore. But since load only works on file >> names, this doesn't help. You have to extract the files from the tar I was mistaken. CLHS says load accepts a stream. It is now very feasible to create a library using tar files as the underlying structure, and do it all in portable lisp. >> file first, so what's the point? >> >> Would be cool if we could. We could have zip files of compiled code >> like Java's jar files. (Are they essentially the same?) Marco> Exactly. Note that .jar files are just .zip files with some extra Marco> meta information. I bet they chose .zip because it was more readily Marco> portable across platforms. Using FFI we could probably get at the contents of a zip file. I have no plans on doing this. I'd rather work on tar, which is simpler and isn't compressed. (Unfortunately, tar format isn't really well specified. Maybe GNU tar would be the right standard.) Marco> Yet, in Java, the class loaders know about .jar (and .zip) Marco> files. Hence, there is no way around but to extend LOAD. Marco> Not an easy task. Yes, but we don't have to extend load. It might not be as tightly integrated as you want, but I would have no problem saying (load-library "my-favorite-lib") using whatever library type we have. Ray |
From: Sam S. <sd...@gn...> - 2001-03-08 19:06:33
|
> * In message <4no...@rt...> > * On the subject of "Re: defsystem and getting file load order?" > * Sent on 08 Mar 2001 11:05:01 -0500 > * Honorable Raymond Toy <to...@rt...> writes: > > >>>>> "Marco" == Marco Antoniotti <ma...@cs...> writes: > >> From: Raymond Toy <to...@rt...> > >> Let the Clisp folks fix > >> it if it's important to them? > Marco> Bruno and Sam could probably do better than any of us. > Indeed. That's why I said let them fix it. :-) fix what? if the author did not bother to include an `in-package' statement in the file, it does not matter to him and thus his users in which package the file will be loaded. or, if you want to be extra nice, just add an (in-package :cl-user) form before each file in your concatenation. > >> Would be cool if we could. We could have zip files of compiled > >> code like Java's jar files. (Are they essentially the same?) > > Marco> Exactly. Note that .jar files are just .zip files with > Marco> some extra meta information. I bet they chose .zip because > Marco> it was more readily portable across platforms. > > Using FFI we could probably get at the contents of a zip file. I have > no plans on doing this. I'd rather work on tar, which is simpler and > isn't compressed. (Unfortunately, tar format isn't really well > specified. Maybe GNU tar would be the right standard.) compression would be very nice to have. lack of standard is discouraging. I suggest, following the KISS dictum, to concatenate the FASL files and gzip the result, either with an external gzip, or with the algorithm re-implemented in CL. If you want to be as sophisticated as the Java crowd, zip them into a "LAR" file, adding a Manifest with information of what function is to be called instead of the standard top-level (a la JAR). TAR would be my last choice. -- Sam Steingold (http://www.podval.org/~sds) Support Israel's right to defend herself! <http://www.i-charity.com/go/israel> Read what the Arab leaders say to their people on <http://www.memri.org/> char*a="char*a=%c%s%c;main(){printf(a,34,a,34);}";main(){printf(a,34,a,34);} |
From: Raymond T. <to...@rt...> - 2001-12-04 22:54:59
|
>>>>> "Sam" == Sam Steingold <sd...@gn...> writes: Sam> I suggest, following the KISS dictum, to concatenate the FASL files and Sam> gzip the result, either with an external gzip, or with the algorithm Sam> re-implemented in CL. Sam> If you want to be as sophisticated as the Java crowd, zip them into a Sam> "LAR" file, adding a Manifest with information of what function is to be Sam> called instead of the standard top-level (a la JAR). Both of these are now possible since Franz has implemented an inflate function. Unzipping a zip file wouldn't be too hard either since the format of a zip file is pretty well-defined. Zipping would have to be done by an external program though. Maybe Franz will implement deflate as well someday? Anyone still interested in this? Wasn't a whole lot of interest before, and I don't have a personal need for this. Would be kind of fun to do, though. Ray |
From: Raymond T. <to...@rt...> - 2001-03-08 19:45:22
|
>>>>> "Sam" == Sam Steingold <sd...@gn...> writes: Sam> fix what? Sam> if the author did not bother to include an `in-package' statement in the Sam> file, it does not matter to him and thus his users in which package the Sam> file will be loaded. Sam> or, if you want to be extra nice, just add an Sam> (in-package :cl-user) Sam> form before each file in your concatenation. Exactly. >> no plans on doing this. I'd rather work on tar, which is simpler and >> isn't compressed. (Unfortunately, tar format isn't really well >> specified. Maybe GNU tar would be the right standard.) Sam> compression would be very nice to have. Sam> lack of standard is discouraging. I think basic tar is pretty portable. It's only when you have long file names (> 100?) that tar is weird. But we don't need the whole pathname; the file name should be fine. There is the pax format which is standardized, I think. Sam> I suggest, following the KISS dictum, to concatenate the FASL files and That's the problem. Is it really possible to just cat all fasl files together and expect it to work? Maybe, but we only know that it's true for ACL, CMUCL, and CLISP. I'm pretty sure it won't work for GCL since their fasl files are .o files. The tar solution (or zip) is nice because we get the individual files. However, I'm not sure that, even if we provide a stream to load, will load know how to interpret what it's getting? For example on CMUCL: (with-open-file (f "hello.lisp" :direction :input) (load f)) works. But compile it and try: (with-open-file (f "hello.sparcf" :direction :input) (load f)) This doesn't. (CMUCL thinks it's a source file, by default.) But this (with-open-file (f "hello.sparcf" :direction :input :element-type '(unsigned-byte 8)) (load f :contents :binary)) works, by using a non-standard option to load. What about other systems? Sam> gzip the result, either with an external gzip, or with the algorithm Sam> re-implemented in CL. I looked once. I'm not going to translate it. Ray |
From: Raymond T. <to...@rt...> - 2001-04-06 13:09:27
|
>>>>> "Sam" == Sam Steingold <sd...@gn...> writes: Marco> Exactly. Note that .jar files are just .zip files with Marco> some extra meta information. I bet they chose .zip because Marco> it was more readily portable across platforms. >> >> Using FFI we could probably get at the contents of a zip file. I have >> no plans on doing this. I'd rather work on tar, which is simpler and >> isn't compressed. (Unfortunately, tar format isn't really well >> specified. Maybe GNU tar would be the right standard.) Sam> compression would be very nice to have. Sam> lack of standard is discouraging. Sam> I suggest, following the KISS dictum, to concatenate the FASL files and Sam> gzip the result, either with an external gzip, or with the algorithm Sam> re-implemented in CL. Sam> If you want to be as sophisticated as the Java crowd, zip them into a Sam> "LAR" file, adding a Manifest with information of what function is to be Sam> called instead of the standard top-level (a la JAR). Sam> TAR would be my last choice. I've looked into the idea of a lisp library format. While I think a LAR file would be nice, we'd have to use a FFI to zlib to extract the compressed data. Also zlib doesn't parse zip files, so we'd have to write that, but I think that could be done portably. However, a peek at GNU tar mentions a POSIX tar format. We could standardize on that. Writing some lisp code to grovel over a tar file is pretty easy and portable. And finally look at cllib/port. There are functions for piping the output of a program back into Lisp. Thus, we can run gunzip on a gzipped tar file, and gzip to create the desired library file. So that's my proposal: the defsystem library format is a gzipped posix tar file. The only necessary stuff for this to work is that all systems must have a load function that accepts 1. Loading from a stream instead of a file 2. The :external-format option to load Both of these are required by the CLHS. I know CMUCL can do 1. CMUCL doesn't have 2, but it does have :contents which will do what is needed. We'd also have to solve the problem of figuring out whether a file is a fasl file or not, but a reasonable solution would be to use the file name extension that's stored in the tar file anyway. How does that sound? Ray |
From: Marco A. <ma...@cs...> - 2001-04-10 17:56:21
|
> X-Authentication-Warning: edgedsp4.rtp.ericsson.se: toy set sender to to...@rt... using -f > From: Raymond Toy <to...@rt...> > User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.2 (Urania) > Content-Type: multipart/mixed; boundary="=-=-=" > Sender: clo...@li... > X-BeenThere: clo...@li... > X-Mailman-Version: 2.0.3 > Precedence: bulk > List-Help: <mailto:clo...@li...?subject=help> > List-Post: <mailto:clo...@li...> > List-Subscribe: <http://lists.sourceforge.net/lists/listinfo/clocc-devel>, > <mailto:clo...@li...?subject=subscribe> > List-Id: <clocc-devel.lists.sourceforge.net> > List-Unsubscribe: <http://lists.sourceforge.net/lists/listinfo/clocc-devel>, > <mailto:clo...@li...?subject=unsubscribe> > List-Archive: <http://lists.sourceforge.net/archives//clocc-devel/> > Date: 10 Apr 2001 09:10:19 -0400 > Content-Length: 5519 > > >>>>> "Raymond" == Raymond Toy <to...@rt...> writes: > > > Raymond> So that's my proposal: the defsystem library format is a gzipped > Raymond> posix tar file. > > [snip] > > Raymond> How does that sound? > > No comments. Either everyone is busy, or no one cares. The first one you said. :{ > > In any case, here is a hack to demonstrate this approach. It doesn't > do gzip, but given clocc, that's not a problem. Cool. Cheers -- Marco Antoniotti ======================================================== NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 719 Broadway 12th Floor fax +1 - 212 - 995 4122 New York, NY 10003, USA http://bioinformatics.cat.nyu.edu "Hello New York! We'll do what we can!" Bill Murray in `Ghostbusters'. |