Re: [asdf-devel] Alternate default lisp system location

good morning; On 13 Mar 2014, at 08:34, Attila Lendvai wrote: >> I *do* get the objection that Pascal had, and I absolutely agree that we >> should not choose a directory name that will collide with existing >> users' directories. > > > […] > > but hopefully by the time my children are old en

Re: [asdf-devel] The issue at hand

good afternoon, On 23 Jan 2014, at 6:18 PM, Robert P. Goldman wrote: > James Anderson has asked for a "concise statement of the issue at hand." thank you for responding to my questions and for shifting the focus of the discussion to how to ensure that deployments of your librar

Re: [asdf-devel] In defense of ASDF & Semantic versioning

good afternoon; On 21 Nov 2013, at 12:02 PM, Stelian Ionescu wrote: > On Wed, 2013-11-20 at 23:24 +0100, Didier Verna wrote: >> Pascal Costanza wrote: >> >>> Just to chime in in the middle: There is no known solution to the >>> so-called "DLL hell" problem. >> >> You're right of course, but in

Re: [asdf-devel] Logical pathnames vs ASDF & SBCL

good morning, faré, gentlemen; On 2011-06-12, at 02:25 , Faré wrote: TL;DR: ASDF currently doesn't play so well with logical pathnames. I'm seeking advice on how to make things better — or on whether it's worth the trouble. Dear all, [...] POTENTIAL SOLUTIONS [...] Finally, I could do not

Re: [asdf-devel] ASDF 2.0 requirements : simplify the output locations mechanism

On 2010-04-21, at 04:00 , Faré wrote: > [...] > > >> the additions >> to the code base over the past few months were devoted to two areas: >> >> - configuration >> - output translations >> >> i neglect, for the moment, the configuration component of the asdf >> evolution and concentrate on questi

Re: [asdf-devel] ASDF 2.0 requirements : simplify the output locations mechanism

On 2010-04-21, at 12:12 , Juan Jose Garcia-Ripoll wrote: On Wed, Apr 21, 2010 at 11:50 AM, james anderson wrote: further experiments demonstrated that - with changes to the scripts to account for functions which would be removed, all regression tests pass, and that with appropriate

Re: [asdf-devel] ASDF 2.0 requirements : simplify the output locations mechanism

On 2010-04-21, at 10:56 , Juan Jose Garcia-Ripoll wrote: On Wed, Apr 21, 2010 at 10:31 AM, james anderson wrote: the patch which was enclosed in the earlier message[2] demonstrated an implementation which modifies the three functions - component- pathname, input-files, and output-files

Re: [asdf-devel] ASDF 2.0 requirements : simplify the output locations mechanism

On 2010-04-21, at 04:00 , Faré wrote: > Dear James, > >> before one can declare asdf 2.0 to be feature complete, one should >> have a specification of its intended function and then gauge the >> implementation in those terms. >> > I humbly disagree. The standards that I have set to myself for ASD

[asdf-devel] ASDF 2.0 requirements : simplify the output locations mechanism

On 2010-04-18, at 00:20 , Faré wrote: > Dear all, > > I think time has come to declare ASDF 2.0 in beta-test, and focus on > releasing it before we get more features into it. > > If there are any bug fixes or improvements you think should definitely > be in 2.0, please open a bug in launchpad and

Re: [asdf-devel] :ASDF-DEPENDENCIES implemented

On 2010-04-20, at 19:57 , Juan Jose Garcia-Ripoll wrote: On Tue, Apr 20, 2010 at 6:17 PM, james anderson wrote: that there is such difficulty to select a stable term indicates that the form of the expression is wrong. Not really. It simply shows that some concepts are difficult to fit in

Re: [asdf-devel] :ASDF-DEPENDENCIES implemented

good afternoon; On 2010-04-20, at 15:26 , Faré wrote: > I think defsystem-depends-on fits the current interface better indeed. > If no one complains today, I'll commit that as 1.705. please understand this note as a complaint. > > [ François-René ÐVB Rideau | Reflection&Cybernethics | http://

Re: [asdf-devel] ASDF 2.0 and beyond.

good afternoon; On 2010-04-18, at 00:20 , Faré wrote: > If there are any bug fixes or improvements you think should definitely > be in 2.0, please open a bug in launchpad and tag them as such > (milestone: version 2), or otherwise make it prominent in your message > on this mailing-list. > [ ...

Re: [asdf-devel] :in-order-to

On 2010-04-16, at 10:33 , Juan Jose Garcia-Ripoll wrote: On Fri, Apr 16, 2010 at 12:01 AM, james anderson wrote: you will need to elaborate on why this matters. the primary dependencies are all in a list which is bound to the in-order-to slot. the :in-order-to initarg is just

Re: [asdf-devel] ASDF 1.700

ethics | http:// > fare.tunes.org ] > Ontogeny recapitulates phylogeny. > — Ernst Haeckel > > > > > On 15 April 2010 19:42, james anderson wrote: >> >> On 2010-04-16, at 01:19 , Faré wrote: >> >>> I did a big rewrite of TRAVERSE and a bunch of other

Re: [asdf-devel] ASDF 1.700

On 2010-04-16, at 01:19 , Faré wrote: > I did a big rewrite of TRAVERSE and a bunch of other fixes. Can you > try out ASDF 1.700 ? http://lab.setf.de/metadata/reports/2010/04/15/ http://lab.setf.de/metadata/lib/html/build-20100415T233724Z00.html ___

Re: [asdf-devel] :in-order-to

On 2010-04-15, at 23:30 , Juan Jose Garcia-Ripoll wrote: On Thu, Apr 15, 2010 at 10:40 PM, james anderson wrote: On 2010-04-15, at 22:26 , Juan Jose Garcia-Ripoll wrote: > Who uses it? depends on what one means by "uses it"? the value in the respective slot is more-or-less c

Re: [asdf-devel] :in-order-to

On 2010-04-15, at 22:59 , Faré wrote: > Interestingly, I wanted to get rid of it and/or refactor how this > thing is done, particularly so to make ASDF and POIU play nicer with > each other. Sigh. > > Note that I'm currently refactoring TRAVERSE. Because it was taking 2 > minutes to process the q

Re: [asdf-devel] :in-order-to

On 2010-04-15, at 22:26 , Juan Jose Garcia-Ripoll wrote: > Who uses it? depends on what one means by "uses it"? the value in the respective slot is more-or-less central to the dependency computation and is initialized in the instantiation process[1]. once it plays that role, is there any r

Re: [asdf-devel] Hoist by my own petard: problem with asdf-binary-locations compatibility.

good evening; On 2010-04-15, at 03:04 , Robert Goldman wrote: One of my own systems got blown up by ASDF-OUTPUT-TRANSLATIONS recently, and the case may be an interesting one: [ ... ] We have a pont-file which ISA cl-source-file. But there is no .lisp file to begin with. Instead, we have th

Re: [asdf-devel] ASDF 1.671: feature complete - please test!

good afternoon; i have used asdf version 1.673 to build much of the clbuild population [0] with the usual suspects.[1] in the process i observed two problems relevant to asd directly and entered them as launchpad bugs.[2,3] - (setf component-property) should return the property - clisp require

Re: [asdf-devel] new asdf does not like matlisp.asd

On 2010-04-11, at 21:57 , Robert Goldman wrote: > On 4/11/10 Apr 11 -2:51 PM, Mario S. Mommer wrote: >> >> Hi, >> >> The error with the fd-stream is ignorable. In slime just let the >> buffer >> with C-x 1 while in the repl, and that's it. As far as I know, >> that is a >> gfortran bug that i

Re: [asdf-devel] new asdf does not like matlisp.asd

good evening; On 2010-04-11, at 18:04 , Robert Goldman wrote: > On 4/11/10 Apr 11 -10:28 AM, james anderson wrote: >> good afternoon; >> >> reading traverse is not my idea of a good time, but when i persevere, >> i do not arrive at the same conclusion. > > Her

Re: [asdf-devel] new asdf does not like matlisp.asd

sal on the system tree. > > I could not figure out how to fix this while maintaining any > semblance of backward compatibility. > > On Apr 11, 2010, at 8:09, james anderson > wrote: > >> good afternoon; >> >> if one invoked load-system with the factors tra

Re: [asdf-devel] new asdf does not like matlisp.asd

good afternoon; if one invoked load-system with the factors traced which contribute to done-ness, it reads as if operation-done-p needs to be specialized for modules to delegate to the constituents. of the asdf/test/*module*.asd examples, there is one which has a similar structure. it is not

[asdf-devel] 1.671 compiles in abc, acl, ccl, ecl, cmucl, sbcl, lw

a...@ip-10-251-122-82:/development/source/library$ /development/bin/ abcl --load build-init.lisp Armed Bear Common Lisp 0.19.1 Java 1.6.0_0 Sun Microsystems Inc. OpenJDK Client VM Low-level initialization completed in 0.963 seconds. Startup completed in 2.205 seconds. ; Compiling /ebs/source/libra

[asdf-devel] translate-jar-pathname : The value NIL is not of type (OR PATHNAME STRING FILE-STREAM).

given: [1] CL-USER(69): (lisp-implementation-type) "Armed Bear Common Lisp" [2] CL-USER(70): (lisp-implementation-version) "0.19.1" [3] CL-USER(73): asdf::*asdf-version* "1.666" asdf fails to compile alexandria. translate-jar-pathname applies namestring to the null device component of a pathnam

Re: [asdf-devel] ? interaction between asdf and cmucl on the matter of "home:"

On 2010-04-05, at 21:36 , Faré wrote: > Looks like a bug in CMUCL. Sigh. > > Does it work better if all occurrences of (user-homedir-pathname) are > replaced with > (truename (user-homedir-pathname)) ? > yes it does. ___ asdf-devel mailing list asdf-

[asdf-devel] ? interaction between asdf and cmucl on the matter of "home:"

good evening; an attempt to use asdf in cmucl to build alexandria fails in connection with operations on a pathname designator which begins with "home:". one observes, that it is not only commercial vendors who know what is best for us. is cmu 20* expected to work with asdf 1.6*? is there

Re: [asdf-devel] :logical-hostname

On 2010-03-31, at 20:00 , Juan Jose Garcia-Ripoll wrote: On Wed, Mar 31, 2010 at 4:39 PM, james anderson wrote: i simply don't understand your requirements. on one hand both with and without asdf, but then it is objected, that a mechanism which requires asdf does not work witho

Re: [asdf-devel] The future of ASDF (was logical pathnames)

good evening; On 2010-03-31, at 19:25 , Juan Jose Garcia-Ripoll wrote: On Wed, Mar 31, 2010 at 3:46 PM, Robert Goldman wrote: Lisp development --- at least for people like me --- is primarily an interactive process, and this is why building and loading/executing are /inextricably/ linked.

Re: [asdf-devel] The future of ASDF (was logical pathnames)

On 2010-03-31, at 15:46 , Robert Goldman wrote: > By and large I agree with Juanjo's statement of principles, but I > would > like to discuss the reason /why/ ASDF is different from tools like > Autoconf. > > Lisp development --- at least for people like me --- is primarily an > interactive p

Re: [asdf-devel] :logical-hostname

On 2010-03-31, at 14:07 , Juan Jose Garcia-Ripoll wrote: On Tue, Mar 30, 2010 at 11:32 PM, james anderson wrote: a. put logical hosts on asdf's search path and unify the pathnames for found system definitions with them. Sorry, but from the paragraph that you wrote I do not f

Re: [asdf-devel] :logical-hostname

On 2010-03-31, at 05:31 , Robert Goldman wrote: > On 3/30/10 Mar 30 -4:32 PM, james anderson wrote: >> >> On 2010-03-30, at 21:36 , Robert Goldman wrote: >> >>> [ ... ] >>> Can you explain how to do this? >> >> i have found two ways to do thi

Re: [asdf-devel] :logical-hostname

On 2010-03-30, at 21:36 , Robert Goldman wrote: > On 3/30/10 Mar 30 -1:48 PM, james anderson wrote: >> >> On 2010-03-30, at 20:36 , Juan Jose Garcia-Ripoll wrote: >> >>> >>> I think I know roughly what Juanjo means here. In particular: >>> >

Re: [asdf-devel] :logical-hostname

On 2010-03-30, at 20:36 , Juan Jose Garcia-Ripoll wrote: > > I think I know roughly what Juanjo means here. In particular: > > 1. I don't like to have my systems use the ASDF API internally. > E.g., > I will set up variables with pathnames, or use logical pathnames in my > ASDF system defini

Re: [asdf-devel] :logical-hostname

I believe what Juanjo wants here is an ability to have the LOADING of the ASDF file generate some logical pathnames. So that after I asdf-load my system FOO, then code /inside/ foo could use a logical pathname like "FOO:SRC;DATAFILES;DATA1.DAT" with the guarantee that ASDF has set up the log

Re: [asdf-devel] :logical-hostname

On 2010-03-30, at 19:13 , Robert Goldman wrote: [...] my experience is that it depends entirely on whether the runtime supports versions at all. if one intended a logical host translation spec to behave "the same" on a runtime which supports file versions as on one which does not, one has to exp

Re: [asdf-devel] :logical-hostname

On 2010-03-30, at 19:12 , Robert Goldman wrote: > On 3/30/10 Mar 30 -11:52 AM, james anderson wrote: >> >> On 2010-03-30, at 16:25 , Robert Goldman wrote: >> >>> On 3/30/10 Mar 30 -5:00 AM, Juan Jose Garcia-Ripoll wrote: >>>> [...] >>> >&

Re: [asdf-devel] :logical-hostname

good evening; On 2010-03-30, at 12:00 , Juan Jose Garcia-Ripoll wrote: Some considerations: [...] * Including logical pathnames in defsystem instead of just the name of the host is going to be problematic. I know at least one implementation (SBCL) that complains when we try to build a log

Re: [asdf-devel] :logical-hostname

On 2010-03-30, at 16:25 , Juan Jose Garcia-Ripoll wrote: On Tue, Mar 30, 2010 at 4:19 PM, Robert Goldman wrote: On 3/29/10 Mar 29 -6:42 PM, Faré wrote: > One site per system looks like it will quickly pollute the host > namespace. What about we instead use a single logical host with > subdir

Re: [asdf-devel] :logical-hostname

On 2010-03-30, at 16:42 , Robert Goldman wrote: > On 3/30/10 Mar 30 -9:29 AM, Juan Jose Garcia-Ripoll wrote: >> On Tue, Mar 30, 2010 at 4:25 PM, Robert Goldman > > wrote: >> >> >> Question: should we raise a style warning if the user supplies a >> logical path

Re: [asdf-devel] :logical-hostname

On 2010-03-30, at 16:25 , Robert Goldman wrote: > On 3/30/10 Mar 30 -5:00 AM, Juan Jose Garcia-Ripoll wrote: >> [...] > > Question: are we going to create a logical pathname translation for > just the system sources? Or should we create also something like > > CL-PPCRE;FASLS;*.*.* if asdf deci

Re: [asdf-devel] :logical-hostname

On 2010-03-30, at 01:42 , Faré wrote: > One site per system looks like it will quickly pollute the host > namespace. It depends on the use-case, as that determines the granularity one needs when re-mapping. While one could arrange the host mapping to each system independently, that would req

Re: [asdf-devel] :logical-hostname

On 2010-03-29, at 23:00 , Juan Jose Garcia-Ripoll wrote: One of the common problems that ASDF users faced when introducing the new binary location system is finding out where things reside. Another problem we will eventually find is locating the resources associated to an ASDF system which

Re: [asdf-devel] ANU, or changes which should be backported to ASDF 1.0 [ Re: Enforcing pure *.asd files (1)

On 2010-03-24, at 00:08 , Robert Goldman wrote: > On 3/23/10 Mar 23 -8:35 AM, james anderson wrote: >> good morning; >> >> On 2010-03-18, at 21:41 , Juan Jose Garcia-Ripoll wrote: >> > >> >> Contributing to this problem is that the system and compon

[asdf-devel] ANU, or changes which should be backported to ASDF 1.0 [ Re: Enforcing pure *.asd files (2)

[ ... continued ] It was a simple experiment. Define a restricted package and interpret .asd files with a restricted read-eval loop. (defpackage :asdf-prototype (:use ) (:documentation "A constrained package to use for loading asdf system prototypes.") (:export :intern) (:import-fr

[asdf-devel] ANU, or changes which should be backported to ASDF 1.0 [ Re: Enforcing pure *.asd files (1)

good morning; On 2010-03-18, at 21:41 , Juan Jose Garcia-Ripoll wrote: This is an idea that has been long floating in the back of my mind, and was brought back to life by these comments http://groups.google.com/group/comp.lang.lisp/msg/f99a69797eda1caf The problem is that many people use

Re: [asdf-devel] Package manipulation [ was ASDF traverse changed behavior? ]

On 2010-03-18, at 19:44 , Faré wrote: >>> : fare >> : janderson > [...] > >> wrt. methods on the basis of 1.648, there are very few methods which >> are not already fully specialized and as such amenable to such rules. >> > I don't get it. > >> perform-with-restarts has a default method as the

Re: [asdf-devel] Package manipulation [ was ASDF traverse changed behavior? ]

good afternoon; On 2010-03-18, at 16:23 , Faré wrote: > [ ...] > > But I think ASDF ought to make a best effort, so that you can at > the very > least upgrade ASDF when installed as part of Common-Lisp-Controller > and > similar management layers (that do use package ASDF). as a step in that

[asdf-devel] Fwd: ASDF traverse changed behavior?

classes will be specialized. the recent point, about intended base methods, which defined instead - likely unintentionally, as default methods, expresses similar concerns. --- [0] : http://github.com/lisp/de.setf.asdf.x/blob/master/asdf- x.lisp#L1992 Begin forwarded message: From: james

Re: [asdf-devel] ASDF traverse changed behavior?

good afternoon. On 2010-03-18, at 15:02 , Juan Jose Garcia-Ripoll wrote: On Thu, Mar 18, 2010 at 2:55 PM, james anderson wrote: if asdf were to adopt an 11.1.2.1.2-rule, asdf-ecl.lisp would require a change. it would not be supported for an extension to extend 'asdf:load-op such

Re: [asdf-devel] ASDF traverse changed behavior?

good afternoon; On 2010-03-18, at 00:03 , Juan Jose Garcia-Ripoll wrote: On Wed, Mar 17, 2010 at 11:54 PM, Juan Jose Garcia-Ripoll wrote: Oh, there is nothing with TRAVERSE's output _right now_. Let me clarify this again: - The fact that TRAVERSE now adds the same operation for all compo

Re: [asdf-devel] ASDF traverse changed behavior?

On 2010-03-18, at 00:03 , Juan Jose Garcia-Ripoll wrote: On Wed, Mar 17, 2010 at 11:54 PM, Juan Jose Garcia-Ripoll wrote: Oh, there is nothing with TRAVERSE's output _right now_. Let me clarify this again: - The fact that TRAVERSE now adds the same operation for all components was new. T

Re: [asdf-devel] ECL testing issue

On 2010-03-17, at 15:58 , james anderson wrote: > > On 2010-03-17, at 15:05 , Faré wrote: > >> http://ec2-174-129-63-37.compute-1.amazonaws.com/test/log/ >> 20100316T233422/ecl-output.txt >> >> On 17 March 2010 10:01, james anderson >> wrote: >>&

Re: [asdf-devel] ABCL testing issue

On 2010-03-17, at 16:04 , Mark Evenson wrote: On Mar 17, 2010, at 3:55 PM, ] wrote: http://ec2-174-129-63-37.compute-1.amazonaws.com/test/log/ 20100316T233422/abcl-output.txt [...] abcl-0.18.1 is not going to work with ASDF2. You currently need to compile ABCL from a post svn r12551 commi

[asdf-devel] abcl testing issue [ was Re: ECL testing issue

On 2010-03-17, at 15:05 , Faré wrote: > http://ec2-174-129-63-37.compute-1.amazonaws.com/test/log/ > 20100316T233422/ecl-output.txt > > On 17 March 2010 10:01, james anderson wrote: >> what might the error in the cited transcript indicate as the cause >> for the probl

Re: [asdf-devel] Question about use of :unspecific

On 2010-03-17, at 14:46 , Faré wrote: > On 17 March 2010 05:20, james anderson wrote: >> >> On 2010-03-17, at 02:50 , Faré wrote: >> >>> ECL & LispWorks work for me, >> >> that's nice. ecl has some sort of problem with the test mechanism

Re: [asdf-devel] ASDF traverse changed behavior?

good morning; On 2010-03-17, at 14:12 , Robert Goldman wrote: > On 3/17/10 Mar 17 -4:04 AM, Juan Jose Garcia-Ripoll wrote: >> This brings back one of the things I discussed long ago. TRAVERSE's >> behavior has to be documented and its behavior has to be specified >> and >> fixed. Either that or

Re: [asdf-devel] Question about use of :unspecific

On 2010-03-16, at 04:32 , Faré wrote: >>> [ ... ] > >> It seems like either these pathnames are never subjected to >> MERGE-PATHNAMES, in which case we can just always return NIL, or they >> /are/ sometimes subjected to MERGE-PATHNAMES, in which case sometimes >> the use of NIL instead of :unspec

Re: [asdf-devel] pathname test

good morning On 2010-03-16, at 11:20 , Nikodemus Siivola wrote: [ ... ] (make-pathname :name "foo.tar" :type "gz") (make-pathname :name "foo" :type "tar.gz") are wrought with difficulty. For Common Lisp these are two non-equal pathnames, so the namestrings --if they exist-- should be non

Re: [asdf-devel] 1.636

-204-236-204-89.compute-1.amazonaws.com/test/ 20100315T231205.txt On 2010-03-15, at 22:53 , Faré wrote: > I tagged ASDF 1.636. > * Can some ABCL user try it? It doesn't have asdf-method-combination > and magic asdf:around anymore. > * James Anderson, can you re-test it, particul

Re: [asdf-devel] pathname test

good morning; [ the context for this message is not clear. ] On 2010-03-16, at 06:33 , Faré wrote: > This is invalid as a pathname to an actual file, only valid as > something that you can merge with a pathname that has a type: > (make-pathname :directory directory :name "typed-file.type" :type

Re: [asdf-devel] 1.636 -> 1.639

On 2010-03-16, at 01:26 , Faré wrote: > On 15 March 2010 19:14, james anderson wrote: >> >> On 2010-03-16, at 00:46 , Faré wrote: >> >>> On 15 March 2010 18:10, james anderson >>> wrote: >>>> abcl has a distinct dislike for :unspecific pathn

Re: [asdf-devel] 1.636 -> 1.639

On 2010-03-16, at 00:46 , Faré wrote: > On 15 March 2010 18:10, james anderson wrote: >> abcl has a distinct dislike for :unspecific pathname components. > I have disabled :unspecific for clisp and abcl. > > Can you try again with 1.639? with pseudo namestrings : http://

Re: [asdf-devel] 1.636

of the other implementations. --- [1] : http://ec2-204-236-204-89.compute-1.amazonaws.com/test/ 20100315T221624/ On 2010-03-15, at 22:53 , Faré wrote: > I tagged ASDF 1.636. > * Can some ABCL user try it? It doesn't have asdf-method-combination > and magic asdf:around anymore. > * J

Re: [asdf-devel] 1.636

the stack trace is opaque. anyway... --- [1] : http://ec2-204-236-204-89.compute-1.amazonaws.com/test/ 20100315T221624/ On 2010-03-15, at 22:53 , Faré wrote: > I tagged ASDF 1.636. > * Can some ABCL user try it? It doesn't have asdf-method-combination > and magic asdf:around anymo

Re: [asdf-devel] 1.636

it? It doesn't have asdf-method-combination > and magic asdf:around anymore. > * James Anderson, can you re-test it, particularly with allegro? > * Juanjo, does it satisfy you wrt output-files protocol? > > [ François-René ÐVB Rideau | Reflection&Cybernethics | http:// > f

Re: [asdf-devel] never ending component relative pathnames

On 2010-03-15, at 21:07 , Faré wrote: On 14 March 2010 21:04, james anderson wrote: On 2010-03-15, at 01:36 , Faré wrote: Dear James, is there a tarball I can download with enough stuff to replace those tests or yours? ? the tests are all in the one asdf-pathname-test.lisp file. The

Re: [asdf-devel] Cache? Translations? How to get rid of them?

good afternoon; this does not sound like a case for specialization. it sounds more like delegation. what about hooking an output translator into the components. if it is there, it is used. if it is not, no translation happens. (as much as i may regret this) the "standard" output translation is

Re: [asdf-devel] never ending component relative pathnames

On 2010-03-15, at 01:36 , Faré wrote: > Dear James, > > is there a tarball I can download with enough stuff to replace those > tests or yours? ? the tests are all in the one asdf-pathname-test.lisp file. > I don't understand which cases exactly fail on which implementations. the respective out

Re: [asdf-devel] never ending component relative pathnames

good evening; here is yet another update.[0] where no string values are permitted for :pathname arguments - not even those which i had understood should be supported, the results are almost uniform. 20100314T224221/alisp/output.txt: (:RESULT :TYPE "International Allegro CL Free Express Edi

Re: [asdf-devel] never ending component relative pathnames

good evening; On 2010-03-11, at 15:37 , Robert Goldman wrote: > If this gets loaded into the asdf git repo, I'll test on ACL linux > and Mac. Might manage windows, too not yet in the asdf repo, but now reformulated to follow faré's advise in recent correspondence: http://ec2-174-129-13

Re: [asdf-devel] never ending component relative pathnames

good afternoon; On 2010-03-11, at 15:37 , Robert Goldman wrote: > If this gets loaded into the asdf git repo, I'll test on ACL linux > and Mac. Might manage windows, too. it's in the asdf-x repo. in the test folder.[1] the link in my earlier message was to a directory with results from the f

Re: [asdf-devel] never ending component relative pathnames [2]

On 2010-03-10, at 15:00 , Faré wrote: >>> These are not currently portably valid: >>> * module "./" >> >> => remove these entries. >> elsewhere it is described that "." should work. >> ? add entries for "." to the module and system lists? >> > As rpg says, I don't know where that "somewhere" is,

Re: [asdf-devel] never ending component relative pathnames [2]

good afternoon; On 2010-03-10, at 14:47 , Robert Goldman wrote: > On 3/10/10 Mar 10 -3:40 AM, james anderson wrote: >> >> On 2010-03-10, at 00:49 , Faré wrote: >> >>> Dear James, > >>> These are not currently portably valid: >>> * module &qu

Re: [asdf-devel] never ending component relative pathnames [2]

On 2010-03-10, at 00:49 , Faré wrote: > Dear James, > >> [ ... ] > >> 2. the description of the interaction between a :pathname >> specification and a default file type was not clear. >>i added various combinations to the tests. >>please advise as to which ones are intended to be supporte

Re: [asdf-devel] never ending component relative pathnames [2]

On 2010-03-10, at 04:46 , Faré wrote: >>> [ ... ] >> > I'd vote against this rule you propose, because > > 1- I am in charge of building a large system, where some components > have names such as foo-V1.1/ or bar/baz-V1.200.lisp that reflect the > fact that we must deal with compatibility with va

Re: [asdf-devel] never ending component relative pathnames [2]

On 2010-03-09, at 19:00 , james anderson wrote: > good evening; > > i have reformulated the test cases and run them through several > implementations.[0] i have pushed these tot eh asdf-x repository[1] in case anyone wants to suggest changes. --- [1] : http://github.com/lisp/de

Re: [asdf-devel] never ending component relative pathnames [2]

good evening; i have reformulated the test cases and run them through several implementations.[0] 1. i had thought (eg. [1]) that abcl and asdf were compatible. is there some special version involved? the cl.net release failed to load.[2] 2. the description of the interaction between a :pa

Re: [asdf-devel] never ending component relative pathnames [2]

good evening; On 2010-03-08, at 17:53 , Faré wrote: > Dear James, > > On 8 March 2010 11:08, james anderson wrote: >> please find referenced below, a suggestion as to the use cases which >> the component pathname computation should support.[1] > > specifying

Re: [asdf-devel] never ending component relative pathnames [2]

good afternoon; [the first version of this message tripped on the size threshold for attachments. this copy is with links] On 2010-03-05, at 21:35 , Robert Goldman wrote: > On 3/5/10 Mar 5 -2:18 PM, james anderson wrote: >> i would be as well. >> >> that's why i s

Re: [asdf-devel] never ending component relative pathnames

On 2010-03-05, at 23:56 , Faré wrote: > I darcs pull'ed from http://common-lisp.net/~crhodes/clx which > compiled fine with ASDF 1.627. clx.asd says it's 0.7.2, NEWS says it's > 0.7.3, and stassats says it's 0.7.4 (after using diff to confirm). > > In any case, I don't have any problem with (:rel

[asdf-devel] clx-0-7-4 fails to compile if the system pathname is logical

if the system pathname is logical, the component for the file "shape.lisp" fails to locate the intended file. * (asdf:operate 'asdf:load-op :de.setf.graphics.clx) ... ; loading system definition from ; /Development/Source/dev/Library/de/setf/graphics/clx/clx.asd into ... ;; loading #P"/Users/ja

Re: [asdf-devel] never ending component relative pathnames

obert Goldman wrote: > On 3/5/10 Mar 5 -12:06 PM, james anderson wrote: >> good evening; >> >> on the occasion of pushing de.setf.graphics down the wire, when i >> built it for ccl/sbcl i did an obligatory pull on asdf and observe >> that something changed in the treat

[asdf-devel] never ending component relative pathnames

good evening; on the occasion of pushing de.setf.graphics down the wire, when i built it for ccl/sbcl i did an obligatory pull on asdf and observe that something changed in the treatment of modules' component relative pathnames. with the effect that it was no longer possible possible to bu

Re: [asdf-devel] ASDF testing [2]

On 2010-03-01, at 21:39 , Faré wrote: > On 1 March 2010 15:08, james anderson wrote: >> good morning, gentlemen; >> >> [...] >> >> so, the basic logistics are clear. >> >> thoughts? >> > Wonderful. The big question is: > who's volu

Re: [asdf-devel] Changes to ASDF for LW6

good evening; On 2010-02-26, at 17:46 , David McClain wrote: > Hi Guys, > > I think I'm beginning to glean your sense of confusion here. Let me > just have you try loading ASDF.lisp in a freshly booted LW6 image > and see for yourselves. send me one, and i will. > > The ASDF.lisp that I am

Re: [asdf-devel] Changes to ASDF for LW6

hmmm... On 2010-02-26, at 17:42 , Robert Goldman wrote: > On 2/26/10 Feb 26 -10:17 AM, james anderson wrote: >> good evening; >> >> as an aside, in light of these changes. >> >> ? is there some reason that they are not coded to expand at compile >> time int

Re: [asdf-devel] Changes to ASDF for LW6

good evening; as an aside, in light of these changes. ? is there some reason that they are not coded to expand at compile time into a second phase of operations in terms of strings. that two-phase method gets the symbols out of the image earlier as they're not needed in fasls. as a side-effec

Re: [asdf-devel] Changes to ASDF for LW6

On 2010-02-26, at 16:17 , Robert Goldman wrote: > On 2/26/10 Feb 26 -9:00 AM, David McClain wrote: >> No, I take a stock LW6 system and want to load up the ASDF package >> as soon as possible, so that I can then use ASDF to load in >> systems. When I take a look at the PACKAGE-USE-LIST of CL-

Re: [asdf-devel] [PATCH] add &allow-other-keys to LOAD-SYSTEM, COMPILE-SYSTEM, TEST-SYSTEM

On 2010-02-24, at 16:42 , Robert Goldman wrote: > [...] the documentation generation code - as i've read and written it, crawls packages and/or live images, so there's a lot it can do without the markup hints. given that information, it is possible to recognize almost eve

Re: [asdf-devel] [PATCH] add &allow-other-keys to LOAD-SYSTEM, COMPILE-SYSTEM, TEST-SYSTEM

On 2010-02-24, at 16:19 , Robert Goldman wrote: > On 2/24/10 Feb 24 -9:09 AM, james anderson wrote: >> >> i wondered that. looks like markdown link-w/o-the-reference-id >> syntax. (is supported by docudown?) >> but then, it's not clear were it finds it

Re: [asdf-devel] [PATCH] add &allow-other-keys to LOAD-SYSTEM, COMPILE-SYSTEM, TEST-SYSTEM

i wondered that. looks like markdown link-w/o-the-reference-id syntax. (is supported by docudown?) but then, it's not clear were it finds it's definition. (work-in- progress?) which brings up larger questions. as i was writing docstrings for de.setf.amqp, i wondered, while markdown is most d

Re: [asdf-devel] upgradability with ECL

not only this, if the symbol constituency changes, the notion of 'undefined' frequently yields results far from the intended. not to mention the (perhaps continuable) errors. yes, one needs an operator with ensure-like semantics, which is intended to operate on packages which may already exist

Re: [asdf-devel] patch for component-relative-pathname

good morning; On 2010-02-22, at 01:41 , Robert Goldman wrote: > On 2/21/10 Feb 21 -6:35 PM, james anderson wrote: >> a question: >> > >>> [...] >>> > >> >> why is this better than to leave names atomic and provide a standard >> syntax to p

Re: [asdf-devel] patch for component-relative-pathname

a question: On 2010-02-22, at 00:46 , Robert Goldman wrote: > On 2/19/10 Feb 19 -2:19 PM, Faré wrote: >>> 2. SPLIT-PATH-STRING --- this is the one I think might need a >>> ticket. >>> I confess I'm bamboozled by this one. It's called on (component- >>> name >>> component), not on a pathname.

Re: [asdf-devel] patch for component-relative-pathname

On 2010-02-19, at 21:47 , Faré wrote: > On 19 February 2010 06:49, james anderson > wrote: >> this problem has been in asdf "forever". >> i have always just patched it locally, but as i've now thrown a few >> things in the net which other folks shou

Re: [asdf-devel] patch for component-relative-pathname

this problem has been in asdf "forever". i have always just patched it locally, but as i've now thrown a few things in the net which other folks should be able to build, i suggested the correction. it might make sense to consider an entirely different protocol for constructing the component

[asdf-devel] patch for component-relative-pathname

good morning; if a system definition root pathname contains a logical host, component-relative-pathname fails to produce pathnames which are relative in the sense that the combination with their parent's component pathname produces the intended location. this patch corrects that failing fo

Re: [asdf-devel] Trying again

good afternoon; > > That whole mess needs to be teased apart before we can get a > version of > ASDF that will do the right thing there. when one has a moment, one might look at asdf.x[1]. it suggests a model for a teased-apart asdf, as well as a concrete reconstruction, which closely rese

  1   2   >