From: Sam S. <sd...@gn...> - 2005-08-16 19:07:51
|
is it true that "defsystem is dead and everyone should switch to asdf"? (sorry if I sound provocative :-) -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.memri.org/> <http://www.honestreporting.com> <http://pmw.org.il/> <http://www.savegushkatif.org> <http://www.dhimmi.com/> "A pint of sweat will save a gallon of blood." -- George S. Patton |
From: Paolo A. <am...@mc...> - 2005-08-16 19:30:25
|
Sam Steingold <sd...@gn...> writes: > is it true that "defsystem is dead and everyone should switch to asdf"? I don't know whether DEFSYSTEM is dead. But I would use CLOCC subsystems much more if there was support for ASDF. > (sorry if I sound provocative :-) Likewise :-) Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log |
From: Marco A. <ma...@cs...> - 2005-08-16 19:34:20
|
On Aug 16, 2005, at 3:30 PM, Paolo Amoroso wrote: > Sam Steingold <sd...@gn...> writes: > >> is it true that "defsystem is dead and everyone should switch to >> asdf"? > > I don't know whether DEFSYSTEM is dead. But I would use CLOCC > subsystems much more if there was support for ASDF. > But MK:DEFSYSTEM supports subsystems in a nicer way than ASDF. So, the question is why don't you give it a spin. Cheers Marco -- Marco Antoniotti http://bioinformatics.nyu.edu NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 715 Broadway 10th FL fax. +1 - 212 - 998 3484 New York, NY, 10003, U.S.A. |
From: Paolo A. <am...@mc...> - 2005-08-16 19:49:26
|
Marco Antoniotti <ma...@cs...> writes: > On Aug 16, 2005, at 3:30 PM, Paolo Amoroso wrote: > >> Sam Steingold <sd...@gn...> writes: >> >>> is it true that "defsystem is dead and everyone should switch to >>> asdf"? >> >> I don't know whether DEFSYSTEM is dead. But I would use CLOCC >> subsystems much more if there was support for ASDF. >> > > But MK:DEFSYSTEM supports subsystems in a nicer way than ASDF. So, > the question is why don't you give it a spin. I probably didn't explain correctly what I meant. By "CLOCC subsystem" I simply mean some library or tool included in CLOCC. I would like to be able to to with ASDF do something like: (asdf:operate 'asdf:load-op :cllib) ; src/cllib or even: (asdf:operate 'asdf:load-op :gnuplot) ; src/cllib/gnuplot or also: (defsystem my-app :depends-on (net shell gnuplot) ; src/port/net, src/port/shell, src/cllib/gnuplot ...) Is this what you mean? In any case, I personally feel more "comfortable" with ASDF, and use it for all my projects. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log |
From: Marco A. <ma...@cs...> - 2005-08-16 20:08:55
|
On Aug 16, 2005, at 3:49 PM, Paolo Amoroso wrote: > Marco Antoniotti <ma...@cs...> writes: > >> On Aug 16, 2005, at 3:30 PM, Paolo Amoroso wrote: >> >>> Sam Steingold <sd...@gn...> writes: >>> >>>> is it true that "defsystem is dead and everyone should switch to >>>> asdf"? >>> >>> I don't know whether DEFSYSTEM is dead. But I would use CLOCC >>> subsystems much more if there was support for ASDF. >>> >> >> But MK:DEFSYSTEM supports subsystems in a nicer way than ASDF. So, >> the question is why don't you give it a spin. > > I probably didn't explain correctly what I meant. By "CLOCC > subsystem" I simply mean some library or tool included in CLOCC. I > would like to be able to to with ASDF do something like: > > (asdf:operate 'asdf:load-op :cllib) ; src/cllib > > or even: > > (asdf:operate 'asdf:load-op :gnuplot) ; src/cllib/gnuplot > > or also: > > (defsystem my-app > :depends-on (net shell gnuplot) ; src/port/net, src/port/shell, > src/cllib/gnuplot > ...) On that I agree. CLOCC does feel a bit "monolithic". > > Is this what you mean? Nope. MK:DEFSYSTEMs are ASDF-INSTALLABLE for one thing. Doing (REQUIRE "some-mk-defsystem") on CMUCL works as expected, and above all, the setup of MK:DEFSYSTEM is now much easier. Essentially you just need to tell MK:DEFSYSTEM where your packages are, without having to link in the .system file (provided that the package unpacks in a directory contaning a .system file with the same name). Moreover, now "component" systems work intuitively and can be made dependent on other components as well. This considerably facilitates the construction of hierarchical systems (witness the struggle I just went through to make CLSQL build under Windows). > In any case, I personally feel more > "comfortable" with ASDF, and use it for all my projects. Of course. I have no problems with that. I just want people to know that MK:DEFSYSTEM is live and well. :) Cheers -- Marco Antoniotti http://bioinformatics.nyu.edu NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 715 Broadway 10th FL fax. +1 - 212 - 998 3484 New York, NY, 10003, U.S.A. |
From: Sam S. <sd...@gn...> - 2005-08-16 21:14:54
|
> * Paolo Amoroso <nz...@zp...> [2005-08-16 21:49:24 +0200]: > > would like to be able to to with ASDF do something like: > (asdf:operate 'asdf:load-op :cllib) ; src/cllib > or even: > (asdf:operate 'asdf:load-op :gnuplot) ; src/cllib/gnuplot > or also: > (defsystem my-app > :depends-on (net shell gnuplot) ; src/port/net, src/port/shell, src/cllib/gnuplot > ...) http://cygwin.com/acronyms/#PTC http://cygwin.com/acronyms/#SHTDI -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.jihadwatch.org/> <http://www.savegushkatif.org> <http://ffii.org/> <http://www.palestinefacts.org/> <http://www.iris.org.il> People hear what they want to hear and discard the rest. |
From: Sam S. <sd...@gn...> - 2005-08-16 20:02:42
|
> * Marco Antoniotti <zn...@pf...h.rqh> [2005-08-16 15:34:09 -0400]: > > On Aug 16, 2005, at 3:30 PM, Paolo Amoroso wrote: > >> Sam Steingold <sd...@gn...> writes: >> >>> is it true that "defsystem is dead and everyone should switch to >>> asdf"? >> >> I don't know whether DEFSYSTEM is dead. But I would use CLOCC >> subsystems much more if there was support for ASDF. >> > > But MK:DEFSYSTEM supports subsystems in a nicer way than ASDF. in what ways? > So, the question is why don't you give it a spin. I would much rather have one de-facto standard SDF than two similar but incompatible ones. since ASDF was created _after_ DEFSYSTEM, apparently it addresses some problems with DEFSYSTEM (which ones?) and does not carry the same backwards compatibility baggage. -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.memri.org/> <http://truepeace.org> <http://pmw.org.il/> <http://www.openvotingconsortium.org/> <http://www.savegushkatif.org> Someone has changed your life. Save? (y/n) |
From: Paolo A. <am...@mc...> - 2005-08-16 20:14:10
|
Sam Steingold <sd...@gn...> writes: > since ASDF was created _after_ DEFSYSTEM, apparently it addresses some > problems with DEFSYSTEM (which ones?) and does not carry the same From the ASDF README file: asdf is extensible to new operations and to new component types. This allows the addition of behaviours: for example, a new component could be added for Java JAR archives, and methods specialised on compile-op added for it that would accomplish the relevant actions. * Inspiration ** mk-defsystem (defsystem-3.x) We aim to solve basically the same problems as mk-defsystem does. However, our architecture for extensibility better exploits CL language features (and is documented), and we intend to be portable rather than just widely-ported. No slight on the mk-defsystem authors and maintainers is intended here; that implementation has the unenviable task of supporting non-ANSI implementations, which I propose to ignore. The surface defsystem syntax of asdf is more-or-less compatible with mk-defsystem The mk-defsystem code for topologically sorting a module's dependency list was very useful. ** defsystem-4 proposal Marco and Peter's proposal for defsystem 4 served as the driver for many of the features in here. Notable differences are - we don't specify output files or output file extensions as part of the system If you want to find out what files an operation would create, ask the operation - we don't deal with CL packages If you want to compile in a particular package, use an in-package form in that file (ilisp will like you more if you do this anyway) - there is no proposal here that defsystem does version control. A system has a given version which can be used to check dependencies, but that's all. The defsystem 4 proposal tends to look more at the external features, whereas this one centres on a protocol for system introspection. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log |
From: Marco A. <ma...@cs...> - 2005-08-16 20:20:42
|
On Aug 16, 2005, at 3:57 PM, Sam Steingold wrote: >> * Marco Antoniotti <zn...@pf...h.rqh> [2005-08-16 15:34:09 -0400]: >> >> On Aug 16, 2005, at 3:30 PM, Paolo Amoroso wrote: >> >>> Sam Steingold <sd...@gn...> writes: >>> >>>> is it true that "defsystem is dead and everyone should switch to >>>> asdf"? >>> >>> I don't know whether DEFSYSTEM is dead. But I would use CLOCC >>> subsystems much more if there was support for ASDF. >>> >> >> But MK:DEFSYSTEM supports subsystems in a nicer way than ASDF. > > in what ways? See my answer to Paolo. > >> So, the question is why don't you give it a spin. > > I would much rather have one de-facto standard SDF than two similar but > incompatible ones. Of course. The right way to go ahead and do this is to write up a spec first and then to go ahead and re-implement. > since ASDF was created _after_ DEFSYSTEM, apparently it addresses some > problems with DEFSYSTEM (which ones?) and does not carry the same > backwards compatibility baggage. It surely does not carry the baggage, but it has one characteristics that makes it somewhat monolithic as well. Essentially the dependency relationships are computed in one shot. This is one thing that I personally don't like and that I think somewhat restrict extensibility (of course MK:DEFSYSTEM 3.5 does not allow that either). One thing that MK:DEFSYSTEM has is that it still does a little more "out of the box" (at least for me) than ASDF. BTW. I think that KMP papers on "DEFSYSTEMS" is interesting but it falls too much short of describing what is really needed: i.e. dependency checking. Moreover I deeply dislike the :in-order-to etc syntax and its (implied) semantics. Mark Kantrowitz was very right in moving away from it. All in all I have been debating myself whether to switch to ASDF. Somehow, I just haven't. Plus, I have some semi-working code for MK:DEFSYSTEM 5.0 that I have been using locally, but I am not satisfied with that either and time is a tyrant. Cheers -- Marco > > > > -- > Sam Steingold (http://www.podval.org/~sds) running w2k > <http://www.memri.org/> <http://truepeace.org> <http://pmw.org.il/> > <http://www.openvotingconsortium.org/> <http://www.savegushkatif.org> > Someone has changed your life. Save? (y/n) > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing > & QA > Security * Process Improvement & Measurement * > http://www.sqe.com/bsce5sf > _______________________________________________ > clocc-list mailing list > clo...@li... > https://lists.sourceforge.net/lists/listinfo/clocc-list > -- Marco Antoniotti http://bioinformatics.nyu.edu NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 715 Broadway 10th FL fax. +1 - 212 - 998 3484 New York, NY, 10003, U.S.A. |
From: Sam S. <sd...@gn...> - 2005-08-16 21:23:24
|
> * Marco Antoniotti <zn...@pf...h.rqh> [2005-08-16 16:20:34 -0400]: > >> >> I would much rather have one de-facto standard SDF than two similar but >> incompatible ones. > > Of course. The right way to go ahead and do this is to write up a > spec first and then to go ahead and re-implement. I don't want to re-implement anything. I want to use one of the two existing facilities. > All in all I have been debating myself whether to switch to ASDF. that does it. > Somehow, I just haven't. Plus, I have some semi-working code for > MK:DEFSYSTEM 5.0 that I have been using locally, but I am not > satisfied with that either and time is a tyrant. it appears that defsystem 3 is frozen and defsystem 4 is vaporware. now you are saying that you have v5?! -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.savegushkatif.org> <http://ffii.org/> <http://truepeace.org> <http://www.mideasttruth.com/> <http://www.openvotingconsortium.org/> "Syntactic sugar causes cancer of the semicolon." -Alan Perlis |
From: Marco A. <ma...@cs...> - 2005-08-16 23:37:21
|
On Aug 16, 2005, at 5:09 PM, Sam Steingold wrote: > The following message is a courtesy copy of an article > that has been posted to gmane.lisp.clocc.general as well. > >> * Marco Antoniotti <zn...@pf...h.rqh> [2005-08-16 16:20:34 -0400]: >> >>> >>> I would much rather have one de-facto standard SDF than two similar >>> but >>> incompatible ones. >> >> Of course. The right way to go ahead and do this is to write up a >> spec first and then to go ahead and re-implement. > > I don't want to re-implement anything. > I want to use one of the two existing facilities. Well. Neither does TRT IMO. I just feel that MK:DEFSYSTEM despite its internal clunkiness is still better for me. > >> All in all I have been debating myself whether to switch to ASDF. > > that does it. > >> Somehow, I just haven't. Plus, I have some semi-working code for >> MK:DEFSYSTEM 5.0 that I have been using locally, but I am not >> satisfied with that either and time is a tyrant. > > it appears that defsystem 3 is frozen and defsystem 4 is vaporware. > now you are saying that you have v5?! 3.x is very stable. Apart from your EVAL message and the GCL crowd who cannot get their head around the fact that ANSI got out in 1994 :) there have not been complaints recently. And I know it is still been used, so it is not a lack of users that can account for all the silence about it. v4 is effectively dead. I have a v5 in my computer, but I have not released it at all. I decided that I will never release anything until I have decent documentation for it. The main features are a truly open dependency checking and traversal framework, plus the ability to compile C/C++/ Java/Fortran et al "out of the box". Unfortunately I always find that there are some more fundamental things to do with CL than working on MK5. Cheers -- Marco Antoniotti http://bioinformatics.nyu.edu NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 715 Broadway 10th FL fax. +1 - 212 - 998 3484 New York, NY, 10003, U.S.A. |
From: Sam S. <sd...@gn...> - 2005-08-17 13:24:15
|
> * Marco Antoniotti <zn...@pf...h.rqh> [2005-08-16 19:36:07 -0400]: > > I have a v5 in my computer, but I have not released it at all. does it suffer from the EVAL problem I just fixed in 3.x? > I decided that I will never release anything until I have decent > documentation for it. I think this is a mistake. If you wait for perfection, you never get anything done. > Unfortunately I always find that there are some more fundamental > things to do with CL than working on MK5. "release early, release often" -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.palestinefacts.org/> <http://www.camera.org> <http://www.savegushkatif.org> <http://www.mideasttruth.com/> I don't like cats! -- Come on, you just don't know how to cook them! |
From: Marco A. <ma...@cs...> - 2005-08-17 14:45:44
|
On Aug 17, 2005, at 9:22 AM, Sam Steingold wrote: >> * Marco Antoniotti <zn...@pf...h.rqh> [2005-08-16 19:36:07 -0400]: >> >> I have a v5 in my computer, but I have not released it at all. > > does it suffer from the EVAL problem I just fixed in 3.x? No. It does not. >> I decided that I will never release anything until I have decent >> documentation for it. > > I think this is a mistake. > If you wait for perfection, you never get anything done. True, but it is truly not working yet. > >> Unfortunately I always find that there are some more fundamental >> things to do with CL than working on MK5. > > "release early, release often" An early broken release dooms the whole thing. Seriously, it is not ready for prime time yet. Marco -- Marco Antoniotti http://bioinformatics.nyu.edu NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 715 Broadway 10th FL fax. +1 - 212 - 998 3484 New York, NY, 10003, U.S.A. |
From: Raymond T. <rt...@ea...> - 2005-08-17 01:39:02
|
Sam Steingold wrote: >>* Marco Antoniotti <zn...@pf...h.rqh> [2005-08-16 16:20:34 -0400]: >> >> >>>I would much rather have one de-facto standard SDF than two similar but >>>incompatible ones. >> >>Of course. The right way to go ahead and do this is to write up a >>spec first and then to go ahead and re-implement. > > > I don't want to re-implement anything. > I want to use one of the two existing facilities. > > >>All in all I have been debating myself whether to switch to ASDF. > > > that does it. > > FWIW, maxima uses mk:defsys. There are no plans I know of to switch to asdf. Matlisp also uses mk:defsys because there was no asdf back then. There's an asdf file now for matlisp, but I don't support it and have no plans to do so. And I use mk:defsys for everything personally. It does what I want, I know how to use it, and I'm too lazy to learn adsf. :-) Ray |
From: Sam S. <sd...@gn...> - 2005-08-17 13:32:58
|
> * Raymond Toy <eg...@rn...g> [2005-08-16 21:37:09 -0400]: > > Matlisp also uses mk:defsys because there was no asdf back then. could you please try the latest clocc cvs head of defsystem? defsystem now evaluates some arguments: (defparameter *component-evaluated-slots* '(:source-root-dir :source-pathname :source-extension :binary-root-dir :binary-pathname :binary-extension)) (defparameter *component-form-slots* '(:initially-do :finally-do :compile-form :load-form)) -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.dhimmi.com/> <http://www.palestinefacts.org/> <http://www.jihadwatch.org/> <http://ffii.org/> <http://pmw.org.il/> Single tasking: Just Say No. |
From: Raymond T. <ray...@er...> - 2005-08-18 21:04:59
|
>>>>> "Sam" == Sam Steingold <sd...@gn...> writes: >> * Raymond Toy <eg...@rn...g> [2005-08-16 21:37:09 -0400]: >> >> Matlisp also uses mk:defsys because there was no asdf back then. Sam> could you please try the latest clocc cvs head of defsystem? Sam> defsystem now evaluates some arguments: Matlisp compiles just fine. But matlisp doesn't do anything special in its use of defsystem. Perhaps you meant maxima? Unfortunately maxima uses its own hacked version to support gcl. I can certainly try it with cmucl, though. Ray |
From: Marco A. <ma...@cs...> - 2005-08-18 21:27:20
|
On Aug 18, 2005, at 10:01 AM, Raymond Toy wrote: >>>>>> "Sam" == Sam Steingold <sd...@gn...> writes: > >>> * Raymond Toy <eg...@rn...g> [2005-08-16 21:37:09 -0400]: >>> >>> Matlisp also uses mk:defsys because there was no asdf back then. > > Sam> could you please try the latest clocc cvs head of defsystem? > Sam> defsystem now evaluates some arguments: > > Matlisp compiles just fine. But matlisp doesn't do anything special > in its use of defsystem. Matlisp compiles fine be because its use of :FINALLY-DO is a special case that is unaffected by the latest changes. > Perhaps you meant maxima? Unfortunately maxima uses its own hacked > version to support gcl. I can certainly try it with cmucl, though. The Maxima hacked version just includes a number of missing ANSI thingies. WITH-COMPILATION-UNIT and (unbelievalbly!!!) *LOAD-PATHNAME*. IMO, all in all the change must be reverted. Otherwise, an inconsistency is introduced between top-level DEFSYSTEM specs and subcomponent specs. Sorry Sam :) What exactly would the change allow that it is not allowed now? Cheers -- Marco Antoniotti http://bioinformatics.nyu.edu NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 715 Broadway 10th FL fax. +1 - 212 - 998 3484 New York, NY, 10003, U.S.A. |
From: Sam S. <sd...@gn...> - 2005-08-18 21:57:02
|
> * Marco Antoniotti <zn...@pf...h.rqh> [2005-08-18 17:26:43 -0400]: > > IMO, all in all the change must be reverted. Otherwise, an > inconsistency is introduced between top-level DEFSYSTEM specs and > subcomponent specs. Sorry Sam :) just release defsystem 5 before I switch to asdf. > What exactly would the change allow that it is not allowed now? allows lexicals in :initally-do/:finally-do cd src/cllib LISPTYPE=cmucl make system ==> warnings about tbc -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.honestreporting.com> <http://www.dhimmi.com/> <http://pmw.org.il/> <http://truepeace.org> <http://www.memri.org/> <http://www.jihadwatch.org/> Programming is like sex: one mistake and you have to support it for a lifetime. |
From: Raymond T. <ray...@er...> - 2005-08-19 12:44:54
|
>>>>> "Marco" == Marco Antoniotti <ma...@cs...> writes: Marco> On Aug 18, 2005, at 10:01 AM, Raymond Toy wrote: >> Matlisp compiles just fine. But matlisp doesn't do anything special >> in its use of defsystem. Marco> Matlisp compiles fine be because its use of :FINALLY-DO is a special Marco> case that is unaffected by the latest changes. At first, I didn't know what you were talking about. But now I see that blas.system has a :finally-do. That was an experiment to build the BLAS library using defsystem. We don't do actually use that. :-) Ray |
From: Marco A. <ma...@cs...> - 2005-08-19 15:04:01
|
On Aug 19, 2005, at 8:41 AM, Raymond Toy wrote: >>>>>> "Marco" == Marco Antoniotti <ma...@cs...> writes: > > Marco> On Aug 18, 2005, at 10:01 AM, Raymond Toy wrote: > >>> Matlisp compiles just fine. But matlisp doesn't do anything special >>> in its use of defsystem. > > Marco> Matlisp compiles fine be because its use of :FINALLY-DO is > a special > Marco> case that is unaffected by the latest changes. > > At first, I didn't know what you were talking about. But now I see > that blas.system has a :finally-do. That was an experiment to build > the BLAS library using defsystem. We don't do actually use that. :-) Then things are pretty much straightforward for Matlisp. :) Cheers -- Marco Antoniotti http://bioinformatics.nyu.edu NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 715 Broadway 10th FL fax. +1 - 212 - 998 3484 New York, NY, 10003, U.S.A. |