You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
(2) |
Apr
(8) |
May
(23) |
Jun
(2) |
Jul
(1) |
Aug
(27) |
Sep
(8) |
Oct
(5) |
Nov
(15) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(7) |
Feb
(6) |
Mar
|
Apr
(50) |
May
(12) |
Jun
(21) |
Jul
(6) |
Aug
(1) |
Sep
(48) |
Oct
(7) |
Nov
(16) |
Dec
(8) |
2002 |
Jan
(27) |
Feb
(4) |
Mar
(56) |
Apr
(21) |
May
(11) |
Jun
(12) |
Jul
(4) |
Aug
(9) |
Sep
(8) |
Oct
(7) |
Nov
(1) |
Dec
|
2003 |
Jan
(7) |
Feb
(6) |
Mar
(7) |
Apr
(23) |
May
(4) |
Jun
(7) |
Jul
(9) |
Aug
(2) |
Sep
(7) |
Oct
(8) |
Nov
(6) |
Dec
(7) |
2004 |
Jan
(2) |
Feb
(24) |
Mar
(11) |
Apr
(4) |
May
(5) |
Jun
(1) |
Jul
(9) |
Aug
(26) |
Sep
(5) |
Oct
|
Nov
|
Dec
(10) |
2005 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
(5) |
May
|
Jun
(4) |
Jul
(8) |
Aug
(21) |
Sep
(5) |
Oct
(1) |
Nov
(1) |
Dec
(3) |
2006 |
Jan
(13) |
Feb
(1) |
Mar
(3) |
Apr
|
May
|
Jun
(5) |
Jul
(2) |
Aug
|
Sep
(3) |
Oct
(17) |
Nov
(11) |
Dec
(28) |
2007 |
Jan
(19) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
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-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: 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: 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: 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: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 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 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 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: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: 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: Paul L. I. <aea...@gm...> - 2005-07-30 04:07:25
|
My last attempt left something to be desired. I have tried to derive the proper way print error conditions from slime. Index: run-lisp =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvsroot/clocc/clocc/bin/run-lisp,v retrieving revision 1.15 diff -u -w -r1.15 run-lisp --- run-lisp=0914 Dec 2001 19:06:01 -0000=091.15 +++ run-lisp=0930 Jul 2005 04:01:27 -0000 @@ -304,7 +304,12 @@ (multiple-value-setq (.res .cond) (ignore-errors (progn $todo (fresh-line) (finish-output)))) - (unix:unix-exit (if .cond 1 0))))" + (unix:unix-exit (if .cond=20 + (progn=20 + (princ .cond)=20 + (fresh-line) (finish-output)= =20 + 1)=20 + 0))))" test -z "$image" || image=3D"-core ${image}.core"; exec ${CMUCL-lisp} -noinit ${image} -eval "$todo" ;; |
From: Paul L. I. <aea...@gm...> - 2005-07-30 00:04:50
|
Sorry, I can't tell if the patch I tried to send actually made it anywhere, so here it is inline: Index: run-lisp =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvsroot/clocc/clocc/bin/run-lisp,v retrieving revision 1.15 diff -u -w -r1.15 run-lisp --- run-lisp=0914 Dec 2001 19:06:01 -0000=091.15 +++ run-lisp=0929 Jul 2005 21:56:44 -0000 @@ -304,7 +304,7 @@ (multiple-value-setq (.res .cond) (ignore-errors (progn $todo (fresh-line) (finish-output)))) - (unix:unix-exit (if .cond 1 0))))" + (unix:unix-exit (if .cond (progn (describe .cond) 1) 0= ))))" test -z "$image" || image=3D"-core ${image}.core"; exec ${CMUCL-lisp} -noinit ${image} -eval "$todo" ;; |
From: Paul L. I. <aea...@gm...> - 2005-07-29 22:06:27
|
>> There was an error message which I could only see when I manually execut= ed >> lisp -noinit -core .../../clocc-top.core -eval '(load "cllib.system")' > >maybe you could fix bin/run-lisp script? If you make the attached change to the run-lisp script, the appropriate error message is displayed. A similar patch for sbcl might also be appropriate. If it is, I suspect it would be identical. Paul |
From: Sam S. <sd...@gn...> - 2005-07-29 21:12:58
|
> * Paul Ledbetter III <nrnpvqrf@tznvy.pbz> [2005-07-29 15:33:58 -0500]: > > Aha, I found and resolved the problem. good! > There was an error message which I could only see when I manually executed > lisp -noinit -core .../../clocc-top.core -eval '(load "cllib.system")' maybe you could fix bin/run-lisp script? -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.palestinefacts.org/> <http://www.dhimmi.com/> <http://pmw.org.il/> <http://www.memri.org/> <http://www.camera.org> <http://www.iris.org.il> Those who value Life above Freedom are destined to lose both. |
From: Paul L. I. <aea...@gm...> - 2005-07-29 20:34:12
|
Aha, I found and resolved the problem. =20 There was an error message which I could only see when I manually executed lisp -noinit -core .../../clocc-top.core -eval '(load "cllib.system")' The error turned out to be in (translate-logical-pathname "clocc:src;cllib;= ") and it occured because I did not end the path with a '/' in the clocc.lisp's *clocc-root* definition. Thankyou! Paul >> * Paul Ledbetter III <nrnpvqrf@tznvy.pbz> [2005-07-28 18:17:46 -0500]: >> >> Under FreeBSD with cmucl-19b, I am trying to compile the cllib >> package. I am encountering the following error: >> >> ; In: LET (TBC) >> >> ; (LET (TBC) >> ; (MAKE:ADD-REGISTRY-LOCATION #) >> ; (MAKE:ADD-REGISTRY-LOCATION #) >> ; (MAKE:DEFSYSTEM CLLIB :SOURCE-PATHNAME # :SOURCE-EXTENSION ...)) >> ; Note: Variable TBC defined but never used. >> gmake: *** [system] Error 1 > >this is not an error, just a style warning >(and an incorrect one to boot: TBC _is_ used, see cllib.system). >please run the failing command that make issues and see is $? is indeed no= n-0. >if it is, please report this as a bug to the CMUCL people: a warning >should not produce non-0 error code from CMUCL. >if it is not, you will have to figure out what the error is. |
From: Sam S. <sd...@gn...> - 2005-07-29 13:15:35
|
> * Paul Ledbetter III <nrnpvqrf@tznvy.pbz> [2005-07-28 18:17:46 -0500]: > > Under FreeBSD with cmucl-19b, I am trying to compile the cllib > package. I am encountering the following error: > > ; In: LET (TBC) > > ; (LET (TBC) > ; (MAKE:ADD-REGISTRY-LOCATION #) > ; (MAKE:ADD-REGISTRY-LOCATION #) > ; (MAKE:DEFSYSTEM CLLIB :SOURCE-PATHNAME # :SOURCE-EXTENSION ...)) > ; Note: Variable TBC defined but never used. > gmake: *** [system] Error 1 this is not an error, just a style warning (and an incorrect one to boot: TBC _is_ used, see cllib.system). please run the failing command that make issues and see is $? is indeed non-0. if it is, please report this as a bug to the CMUCL people: a warning should not produce non-0 error code from CMUCL. if it is not, you will have to figure out what the error is. -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://pmw.org.il/> <http://ffii.org/> <http://www.jihadwatch.org/> <http://www.palestinefacts.org/> Rhinoceros has poor vision, but, due to his size, it's not his problem. |
From: Paul L. I. <aea...@gm...> - 2005-07-28 23:18:02
|
Under FreeBSD with cmucl-19b, I am trying to compile the cllib package. I = am=20 encountering the following error: ; In: LET (TBC) ; (LET (TBC) ; (MAKE:ADD-REGISTRY-LOCATION #) ; (MAKE:ADD-REGISTRY-LOCATION #) ; (MAKE:DEFSYSTEM CLLIB :SOURCE-PATHNAME # :SOURCE-EXTENSION ...)) ; Note: Variable TBC defined but never used. gmake: *** [system] Error 1 And so the package will not build. Advice would be appreciated. Paul Ledbetter |
From: Sam S. <sd...@gn...> - 2005-06-16 21:48:31
|
> * Ryan Adams <ec...@pn....hx> [2005-06-16 21:36:00 +0100]: > >> > * Ryan Adams <ec...@pn....hx> [2005-06-16 20:29:44 +0100]: >> > >> > Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER: >> > NIL is not of type BASE-STRING >> should be fixed in the CVS > > I have the latest snapshot from http://clocc.sourceforge.net/snapshot. the snapshot is 4 months old. I fixed the bug today, _after_ you reported it. please try anon cvs. -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://ffii.org/> <http://pmw.org.il/> <http://www.camera.org> <http://www.honestreporting.com> <http://www.palestinefacts.org/> Daddy, what does "format disk c: complete" mean? |
From: Ryan A. <rp...@ca...> - 2005-06-16 20:36:03
|
> > * Ryan Adams <ec...@pn....hx> [2005-06-16 20:29:44 +0100]: > > > > Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER: > > NIL is not of type BASE-STRING > should be fixed in the CVS I have the latest snapshot from http://clocc.sourceforge.net/snapshot. Ryan |
From: Sam S. <sd...@gn...> - 2005-06-16 20:12:48
|
> * Ryan Adams <ec...@pn....hx> [2005-06-16 20:29:44 +0100]: > > Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER: > NIL is not of type BASE-STRING should be fixed in the CVS -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.honestreporting.com> <http://www.mideasttruth.com/> <http://ffii.org/> <http://www.memri.org/> <http://pmw.org.il/> Hard work has a future payoff. Laziness pays off NOW. |
From: Ryan A. <rp...@ca...> - 2005-06-16 19:29:41
|
Hello All: I've installed CLOCC under CMUCL and I've been trying to use the Gnuplot functionality in cllib to generate graphs. I have been successful with plot-functions and plot-lists, but I have not been able to get plot-histogram to work. I have the latest CVS snapshot (clocc-02-08-05.tgz). When I do this: (cllib:plot-histogram (list 1 2 1 3 4 5 1 3 3 5) 5) I get this error: Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER: NIL is not of type BASE-STRING [Condition of type TYPE-ERROR] Restarts: 0: [ABORT] Abort handling SLIME request. 1: [ABORT] Return to Top-Level. Backtrace: 0: ("DEFSTRUCT (PLOT-AXIS (:CONC-NAME PLAX-))" 268431297 14)[:OPTIONAL] 1: (CLLIB::MAKE-PLOT :DATA #<Closure Over Function (FLET #:WPS-BODY-FUNCTION-2 CLLIB:PLOT-HISTOGRAM) {586F5431}> :PLOT :PLOT ...) 2: (CLLIB::INTERNAL-WITH-PLOT-STREAM #<Closure Over Function (FLET #:WPS-BODY-FUNCTION-2 CLLIB:PLOT-HISTOGRAM) {586F5431}> :TITLE "histogram" :DATA-STYLE ...) I am a Lisp novice, so it may well be that I've done something dumb. It's worth mentioning that I can replicate this on another machine as well. Any ideas? Thanks in advance. Ryan Adams |
From: Marco A. <ma...@cs...> - 2005-04-26 17:46:17
|
Hi I just packaged up all the changes to MK:DEFSYSTEM and released a new version named 3.5i. Here is the SF log. http://sourceforge.net/project/shownotes.php?release_id=323402 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: Ram B. <ra...@ve...> - 2005-04-22 22:39:26
|
Here are the changes I needed to make to get the current cvs head version of clocc to compiler under sbcl-0.8.21. The changes are: 1. According to some of the docs I found eval-when with compile, load eval is deprecated and the new thing is :compile-toplevel etc. So I made those changes. Turns out this change is not required, but it did reduce some of the warning messages. 2. *random-state* is being added to the common-lisp package. sbcl has this package locked and thus the compile fails. I added some commands that unlock the package to allow this symbol to be defined. Probably there are many portability issues that I am not thinking about - someone with more experience with lisp will need to think about that. 3. the definition of +beta-algo-go+ needs to be moved closer to the start of the file. otherwise sbcl will complain that this symbol is undefined when trying to compile ziggurat-init. I hope these patches can be incorporated into clocc. -Ram axis47b> cvs diff -c rng.lisp Index: rng.lisp =================================================================== RCS file: /cvsroot/clocc/clocc/src/cllib/rng.lisp,v retrieving revision 1.14 diff -u -3 -p -c -r1.14 rng.lisp cvs diff: conflicting specifications of output style *** rng.lisp 8 Mar 2005 22:50:54 -0000 1.14 --- rng.lisp 22 Apr 2005 22:32:10 -0000 *************** *** 108,114 **** ;;;; Initial revision ;;;; ! (eval-when (compile load eval) (require :cllib-base (translate-logical-pathname "clocc:src;cllib;base")) ;; `dfloat', `with-type' (require :cllib-withtype (translate-logical-pathname "cllib:withtype"))) --- 108,114 ---- ;;;; Initial revision ;;;; ! (eval-when (:compile-toplevel :load-toplevel :execute) (require :cllib-base (translate-logical-pathname "clocc:src;cllib;base")) ;; `dfloat', `with-type' (require :cllib-withtype (translate-logical-pathname "cllib:withtype"))) *************** *** 165,170 **** --- 165,176 ---- ;; ;; where r = x[n]. ;; + (eval-when (:compile-toplevel :execute) + (defconstant +beta-algo-go+ 0.009572265238289d0) + (declaim (type (double-float 0.009572265238289d0 0.009572265238289d0) + +beta-algo-go+)) + ) + (defun ziggurat-init (n r v scale f finv) ;; n = one less than the number of elements in the tables ;; r = x[n] *************** mean of mu: *** 243,250 **** --- 249,258 ---- STATE is the random state to use. The logarithmic method is used. " + (declare (disable-package-locks common-lisp) (declare (type random-state *random-state*) (type (double-float (0d0)) mu)) + (declare (enable-package-locks common-lisp)) (* mu (- (log (random 1d0))))) *************** order ORDER. *** 1562,1573 **** (- (gen-gamma-variate-small-order r) (log x)))))) - (eval-when (compile eval) - (defconstant +beta-algo-go+ 0.009572265238289d0) - (declaim (type (double-float 0.009572265238289d0 0.009572265238289d0) - +beta-algo-go+)) - ) - ;; Ahrens and Dieter's Algorithm GO. #+(or) (defun gen-gamma-variate-algo-go (a &optional (*random-state* *random-state*)) --- 1570,1575 ---- *************** with parameters a and b: *** 1822,1828 **** ;;; Binomial random variate #+(or) ! (eval-when (compile eval) (declaim (ftype (function ((and (integer 0) fixnum) (non-negative-float double-float 1d0) &optional random-state) --- 1824,1830 ---- ;;; Binomial random variate #+(or) ! (eval-when (:compile-toplevel :execute) (declaim (ftype (function ((and (integer 0) fixnum) (non-negative-float double-float 1d0) &optional random-state) *************** with parameters N and p: *** 1877,1883 **** ;;; Poisson random variate #+(or) ! (eval-when (compile) (declaim (ftype (function ((double-float 0d0) &optional random-state) (and (integer 0) fixnum)) gen-poisson-variate))) --- 1879,1885 ---- ;;; Poisson random variate #+(or) ! (eval-when (:compile-toplevel) (declaim (ftype (function ((double-float 0d0) &optional random-state) (and (integer 0) fixnum)) gen-poisson-variate))) |
From: Ram B. <ra...@ve...> - 2005-04-20 23:22:48
|
The comment from Sam Steingold was: > fixed in the cvs Sorry to be dense - but does this mean that you checked in a fix to CVS or that the version currently in CVS is already fixed. If there was a checkin to CVS - I'm not seeing it - repeated "cvs update" commands did not show any file changes. The reason I ask is that I encountered this package lock problem using the version of clocc from CVS. Perhaps I did not do the checkout correctly. I did it this way: cvs -d ... co -P clocc Should the CVS version of clocc build on solaris sbcl-0.8.21 without any errors? If yes - then something is wrong. Please see my previous email. Thanks for any help. -Ram |