From: Sam S. <sd...@gn...> - 2005-08-16 19:19:55
|
defsystem uses eval to run initially-do and finally-do. this is politically incorrect ("EVAL is to be avoided") and practically inconvenient (initially-do and finally-do have to exchange information via global variables, thus compiling CLLIB/cllib.system produces warnings). do you mind if I fix that? -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://pmw.org.il/> <http://www.honestreporting.com> <http://www.camera.org> <http://www.dhimmi.com/> <http://www.jihadwatch.org/> <http://www.memri.org/> Murphy's Law was probably named after the wrong guy. |
From: Marco A. <ma...@cs...> - 2005-08-16 19:32:57
|
Hi Sam as a matter of fact this has bugged me for quite some time. However, I would be careful to touch it. Matlisp depends on :initially-do and :finally-do. If your solution is backward compatible I wouldn't mind at all if you fixed it. Cheers -- Marco On Aug 16, 2005, at 3:14 PM, Sam Steingold wrote: > defsystem uses eval to run initially-do and finally-do. > this is politically incorrect ("EVAL is to be avoided") > and practically inconvenient (initially-do and finally-do have to > exchange information via global variables, thus compiling > CLLIB/cllib.system produces warnings). > > do you mind if I fix that? > > > > -- > Sam Steingold (http://www.podval.org/~sds) running w2k > <http://pmw.org.il/> <http://www.honestreporting.com> > <http://www.camera.org> > <http://www.dhimmi.com/> <http://www.jihadwatch.org/> > <http://www.memri.org/> > Murphy's Law was probably named after the wrong guy. > > > > ------------------------------------------------------- > 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-devel mailing list > clo...@li... > https://lists.sourceforge.net/lists/listinfo/clocc-devel > -- 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 19:56:02
|
Hi Marco, > * Marco Antoniotti <zn...@pf...h.rqh> [2005-08-16 15:32:40 -0400]: > > as a matter of fact this has bugged me for quite some time. actually, there are quire a few EVALs there - I would rather fix them all in one shot. > However, I would be careful to touch it. Matlisp depends on > :initially-do and :finally-do. > If your solution is backward compatible I wouldn't mind at all if you > fixed it. it should be. the obvious solution is to evaluate some DEFSYSTEM arguments at EVAL time. right now no DEFSYSTEM arguments are evaluated except with an explicit EVAL. -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.memri.org/> <http://ffii.org/> <http://www.savegushkatif.org> <http://www.openvotingconsortium.org/> <http://pmw.org.il/> Type louder, please. |
From: Marco A. <ma...@cs...> - 2005-08-16 20:11:03
|
On Aug 16, 2005, at 3:51 PM, Sam Steingold wrote: > Hi Marco, > >> * Marco Antoniotti <zn...@pf...h.rqh> [2005-08-16 15:32:40 -0400]: >> >> as a matter of fact this has bugged me for quite some time. > > actually, there are quire a few EVALs there - I would rather fix them > all in one shot. > >> However, I would be careful to touch it. Matlisp depends on >> :initially-do and :finally-do. >> If your solution is backward compatible I wouldn't mind at all if you >> fixed it. > > it should be. > > the obvious solution is to evaluate some DEFSYSTEM arguments at EVAL > time. > right now no DEFSYSTEM arguments are evaluated except with an explicit > EVAL. Yes. That would fix it. However, I think this is not an easy task to pull off. If you try it, please create a branch before merging the changes in. 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: Sam S. <sd...@gn...> - 2005-08-16 21:00:21
|
> * Marco Antoniotti <zn...@pf...h.rqh> [2005-08-16 16:10:56 -0400]: > >> the obvious solution is to evaluate some DEFSYSTEM arguments at EVAL >> time. right now no DEFSYSTEM arguments are evaluated except with an >> explicit EVAL. > > Yes. That would fix it. However, I think this is not an easy task to > pull off. If you try it, please create a branch before merging the > changes in. oops - too late, sorry. I just checked in a simple fix. please try it. -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.openvotingconsortium.org/> <http://www.palestinefacts.org/> <http://www.savegushkatif.org> <http://www.camera.org> Warning! Dates in calendar are closer than they appear! |
From: Marco A. <ma...@cs...> - 2005-08-16 21:09:29
|
Hi Sam I am pretty sure it will work with regular definitions. It is the Matlisp kind of stuff that may suffer. Anyway, if it breaks we can revert it. Marco On Aug 16, 2005, at 4:59 PM, Sam Steingold wrote: >> * Marco Antoniotti <zn...@pf...h.rqh> [2005-08-16 16:10:56 -0400]: >> >>> the obvious solution is to evaluate some DEFSYSTEM arguments at EVAL >>> time. right now no DEFSYSTEM arguments are evaluated except with an >>> explicit EVAL. >> >> Yes. That would fix it. However, I think this is not an easy task to >> pull off. If you try it, please create a branch before merging the >> changes in. > > oops - too late, sorry. > I just checked in a simple fix. > please try it. > > -- > Sam Steingold (http://www.podval.org/~sds) running w2k > <http://www.openvotingconsortium.org/> <http://www.palestinefacts.org/> > <http://www.savegushkatif.org> <http://www.camera.org> > Warning! Dates in calendar are closer than they appear! > > > ------------------------------------------------------- > 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-devel mailing list > clo...@li... > https://lists.sourceforge.net/lists/listinfo/clocc-devel > -- 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: Marco A. <ma...@cs...> - 2005-08-18 19:46:16
|
Hi the change to get rid of EVAL breaks several definitions. Essentially you cannot deal with situations like the following. (defsystem :foo :components ((:module "bar" :finally-do (print-something)))) The :FINALLY-DO in the :MODULE spec is not expanded (I mean "wrapped in a lambda" ) properly and it causes a runtime error. The EVAL are ingrained in the way the subcomponents are built. This is unfortunate, but it's the way it is. To fix this you would have to change the way subcomponents are created (I did this for MK4/5 and ASDF does it as well AFAIK) or you would have to walk through the component subcomponent definitions and manipulate the slots as needed. I see not other way but to revert to the previous version. Cheers -- Marco On Aug 16, 2005, at 5:09 PM, Marco Antoniotti wrote: > Hi Sam > > I am pretty sure it will work with regular definitions. It is the > Matlisp kind of stuff that may suffer. > > Anyway, if it breaks we can revert it. > > Marco > > > > > > On Aug 16, 2005, at 4:59 PM, Sam Steingold wrote: > >>> * Marco Antoniotti <zn...@pf...h.rqh> [2005-08-16 16:10:56 -0400]: >>> >>>> the obvious solution is to evaluate some DEFSYSTEM arguments at EVAL >>>> time. right now no DEFSYSTEM arguments are evaluated except with an >>>> explicit EVAL. >>> >>> Yes. That would fix it. However, I think this is not an easy task >>> to >>> pull off. If you try it, please create a branch before merging the >>> changes in. >> >> oops - too late, sorry. >> I just checked in a simple fix. >> please try it. >> >> -- >> Sam Steingold (http://www.podval.org/~sds) running w2k >> <http://www.openvotingconsortium.org/> >> <http://www.palestinefacts.org/> >> <http://www.savegushkatif.org> <http://www.camera.org> >> Warning! Dates in calendar are closer than they appear! >> >> >> ------------------------------------------------------- >> 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-devel mailing list >> clo...@li... >> https://lists.sourceforge.net/lists/listinfo/clocc-devel >> > -- > 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. > > > > ------------------------------------------------------- > 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-devel mailing list > clo...@li... > https://lists.sourceforge.net/lists/listinfo/clocc-devel > -- 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:12:14
|
> * Marco Antoniotti <zn...@pf...h.rqh> [2005-08-18 15:45:00 -0400]: > > I see not other way but to revert to the previous version. you can replace (eval foo) with (typecase foo (function (funcall foo)) (otherwise (eval foo))) this will work for the top-level cases. -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.jihadwatch.org/> <http://ffii.org/> <http://truepeace.org> Of course, I haven't tried it. But it will work. - Isaak Asimov |
From: Marco A. <ma...@cs...> - 2005-08-18 21:22:11
|
On Aug 18, 2005, at 5:07 PM, Sam Steingold wrote: >> * Marco Antoniotti <zn...@pf...h.rqh> [2005-08-18 15:45:00 -0400]: >> >> I see not other way but to revert to the previous version. > > you can replace (eval foo) with > (typecase foo > (function (funcall foo)) > (otherwise (eval foo))) > this will work for the top-level cases. Ok. But what do you gain with this? You can write :finally-do #'foo instead of :finally-do (foo) ? Is that all? 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: Sam S. <sd...@gn...> - 2005-08-18 21:36:20
|
> * Marco Antoniotti <zn...@pf...h.rqh> [2005-08-18 17:21:08 -0400]: > > On Aug 18, 2005, at 5:07 PM, Sam Steingold wrote: > >>> * Marco Antoniotti <zn...@pf...h.rqh> [2005-08-18 15:45:00 -0400]: >>> >>> I see not other way but to revert to the previous version. >> >> you can replace (eval foo) with >> (typecase foo >> (function (funcall foo)) >> (otherwise (eval foo))) >> this will work for the top-level cases. > > Ok. But what do you gain with this? You can write > > :finally-do #'foo > > instead of > > :finally-do (foo) > > ? I am not sure I understand you. > Is that all? look at cllib.system: (let (x) (defsystem ... :initally-do (setq x 1) :finally-do (print x)) ) replacing (setq x 1) with (lambda()(setq x 1)) will not eliminate compilation warnings. -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.honestreporting.com> <http://www.memri.org/> <http://www.dhimmi.com/> <http://www.savegushkatif.org> My other CAR is a CDR. |
From: Marco A. <ma...@cs...> - 2005-08-19 02:43:05
|
On Aug 18, 2005, at 5:33 PM, Sam Steingold wrote: >> * Marco Antoniotti <zn...@pf...h.rqh> [2005-08-18 17:21:08 -0400]: >> >> On Aug 18, 2005, at 5:07 PM, Sam Steingold wrote: >> >>>> * Marco Antoniotti <zn...@pf...h.rqh> [2005-08-18 15:45:00 -0400]: >>>> >>>> I see not other way but to revert to the previous version. >>> >>> you can replace (eval foo) with >>> (typecase foo >>> (function (funcall foo)) >>> (otherwise (eval foo))) >>> this will work for the top-level cases. >> >> Ok. But what do you gain with this? You can write >> >> :finally-do #'foo >> >> instead of >> >> :finally-do (foo) >> >> ? > > I am not sure I understand you. > > >> Is that all? > > look at cllib.system: > > (let (x) > (defsystem ... > :initally-do (setq x 1) > :finally-do (print x)) > ) > > replacing (setq x 1) with (lambda()(setq x 1)) will not eliminate > compilation warnings. A simple workaround is to declare X (or TBC in cllib.system) SPECIAL. That should do it as EVAL uses the current dynamic environment. 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: Marco A. <ma...@cs...> - 2005-08-19 03:15:54
|
Forget my last message. It is crap. I don't think you can do it with a lexical. You need a global to achieve what you want. Marco On Aug 18, 2005, at 10:42 PM, Marco Antoniotti wrote: > > On Aug 18, 2005, at 5:33 PM, Sam Steingold wrote: > >>> * Marco Antoniotti <zn...@pf...h.rqh> [2005-08-18 17:21:08 -0400]: >>> >>> On Aug 18, 2005, at 5:07 PM, Sam Steingold wrote: >>> >>>>> * Marco Antoniotti <zn...@pf...h.rqh> [2005-08-18 15:45:00 >>>>> -0400]: >>>>> >>>>> I see not other way but to revert to the previous version. >>>> >>>> you can replace (eval foo) with >>>> (typecase foo >>>> (function (funcall foo)) >>>> (otherwise (eval foo))) >>>> this will work for the top-level cases. >>> >>> Ok. But what do you gain with this? You can write >>> >>> :finally-do #'foo >>> >>> instead of >>> >>> :finally-do (foo) >>> >>> ? >> >> I am not sure I understand you. >> >> >>> Is that all? >> >> look at cllib.system: >> >> (let (x) >> (defsystem ... >> :initally-do (setq x 1) >> :finally-do (print x)) >> ) >> >> replacing (setq x 1) with (lambda()(setq x 1)) will not eliminate >> compilation warnings. > > A simple workaround is to declare X (or TBC in cllib.system) SPECIAL. > > That should do it as EVAL uses the current dynamic environment. > > 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. > > > > ------------------------------------------------------- > 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-devel mailing list > clo...@li... > https://lists.sourceforge.net/lists/listinfo/clocc-devel > -- 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. |