Re: [asdf-devel] P.S. re patch...
Faré fah...@gmail.com writes: The patch was applied. I should probably use the same emacs setting to avoid tabs (what do you use?). Also, I bumped the version for good measure. I intend to release 2.27 next week. Can people test on their systems and their implementations? Xach, are things all clear with Quicklisp now? There is an unusual issue with the periods library that I can't quite puzzle out. It does not have any trouble with ASDF 2.26, but it fails to load from FASL, under some circumstances, with the latest commit to master. It seems like something in my build environment is triggering it, but I can't reproduce it reliably enough to figure it out. I'll keep you posted. Zach ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] P.S. re patch...
I intend to release 2.27 next week. Can people test on their systems and their implementations? Xach, are things all clear with Quicklisp now? There is an unusual issue with the periods library that I can't quite puzzle out. It does not have any trouble with ASDF 2.26, but it fails to load from FASL, under some circumstances, with the latest commit to master. It seems like something in my build environment is triggering it, but I can't reproduce it reliably enough to figure it out. I'll keep you posted. Do you logs of some of these failures? Maybe I can reproduce at home, or, looking at the .asd and knowing what I changed, figure a scenario that explains the failure. ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] P.S. re patch...
Faré fah...@gmail.com writes: I intend to release 2.27 next week. Can people test on their systems and their implementations? Xach, are things all clear with Quicklisp now? There is an unusual issue with the periods library that I can't quite puzzle out. It does not have any trouble with ASDF 2.26, but it fails to load from FASL, under some circumstances, with the latest commit to master. It seems like something in my build environment is triggering it, but I can't reproduce it reliably enough to figure it out. I'll keep you posted. Do you logs of some of these failures? Maybe I can reproduce at home, or, looking at the .asd and knowing what I changed, figure a scenario that explains the failure. http://report.quicklisp.org/periods/2012-12-12/failtail.txt is the typical failure log. The use of the SERIES package is conditionalized on the :PERIODS-USE-SERIES feature, and I can't find any place where that is in effect. Zach ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] P.S. re patch...
Also, I'd like to know if any package in Quicklisp relies on some ASDF internals I'd like to rename. This is especially harder when users define methods on a generic function — you can't rename the function, then. Is there an easy way to download EVERYTHING (excluding old versions) so I may grep the results? —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Democracy is a pathetic belief in the collective wisdom of individual ignorance. — H.L. Mencken On Thu, Dec 13, 2012 at 9:27 AM, Zach Beane x...@xach.com wrote: Faré fah...@gmail.com writes: I intend to release 2.27 next week. Can people test on their systems and their implementations? Xach, are things all clear with Quicklisp now? There is an unusual issue with the periods library that I can't quite puzzle out. It does not have any trouble with ASDF 2.26, but it fails to load from FASL, under some circumstances, with the latest commit to master. It seems like something in my build environment is triggering it, but I can't reproduce it reliably enough to figure it out. I'll keep you posted. Do you logs of some of these failures? Maybe I can reproduce at home, or, looking at the .asd and knowing what I changed, figure a scenario that explains the failure. http://report.quicklisp.org/periods/2012-12-12/failtail.txt is the typical failure log. The use of the SERIES package is conditionalized on the :PERIODS-USE-SERIES feature, and I can't find any place where that is in effect. Zach ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] P.S. re patch...
Faré fah...@gmail.com writes: Also, I'd like to know if any package in Quicklisp relies on some ASDF internals I'd like to rename. This is especially harder when users define methods on a generic function — you can't rename the function, then. Is there an easy way to download EVERYTHING (excluding old versions) so I may grep the results? Sure. The easiest way is this: (map nil 'ql-dist:ensure-installed (ql-dist:provided-releases t)) Then all sources currently in Quicklisp will be present in ~/quicklisp/dists/quicklisp/software/. Someone(tm) should write a search engine that can answer questions like yours instantly via offline indexing of all public CL code! Zach ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
[asdf-devel] prepare-op
I have finally fixed an essential dependency problem of ASDF by introducing a new operation parent-load-op which I'm going to rename prepare-op. This in turns opens the way for many many improvements to the internals, which will make ASDF easier to explain and extend, so expect some work there — and I'm postponing any 2.27 release until that's stable. However, any and all changes introduces potential backwards-incompatibility, and I'll be searching through packages available in quicklisp for any potential such incompatibility before I go ahead with renaming internals. Some details: In 2.26.14, I introduced an operation called parent-load-op, which ensures the dependencies of the parent are loaded before the child is compiled. This ensures the graph produced by following component-depends-on isn't missing crucial dependencies instead of relying on the specifics of the TRAVERSE algorithm (and at long last I really understand what rpgoldman was telling me while we were writing the ASDF 2 paper). I had to tweak traverse, because parent-load-op trickles upward, not downward, the component hierarchy: you depend-on the parent-load-op of your parents, but not on that of your children (that would create a circular dependency). So I had to add a check in TRAVERSE (now — 2.26.20 — in its nice and short visit-children helper) to not automatically propagate subclasses of parent-op dependencies downward. I started thinking about a theory of parent-op and child-op dependencies and how to rewrite the current hierarchy, and as I was doing it found that actually, parent-load-op is not parent-specific: it's actually a dependency-op or prepare-op, that ensures that the image is prepared to compile or load the component, by having already loaded all the dependencies, and it could do it for the normal case, too: instead of having load-op or compile-op depend on the load-op of all the dependencies, they could simply depend on prepare-op. Then, we don't need to have traverse know anything about propagating dependencies either downward or upward, it can all be done with two methods on component-depends-on! [which is one of the many misnomers in ASDF: components don't depend on anything, it's (operation . component) pairs, which I'm calling actions, like in Kent Pitman's article), that are nodes in the dependency graph]. It was all quite a revelation. And so I'll be working on drastically cutting down ASDF, and making the basic dependency graph cleaner, which will make ASDF much simpler and more reliable to extend. Some change I'd like to make if no one uses these internals (or only use them without relying on the current setup to define methods, in which case I can define an alias]: module == make it a subclass of both child-component and parent-component system == is a parent but not a child, and thus not a module. component-depends-on == rename it to action-depends-on if-component-fails == I'd like to remove it altogether, it's a crock that doesn't go well with the reified graph model. I suppose I could preserve it the hard way, but would be ugly. mark-operation-done == maybe rename to stamp-action ? Or at least mark-action-done. operation-description == action-description component-visited-p == action-visited-p component-depends-on == component-dependencies - likely not possible for backwards compatibility. component-load-dependencies == component-depends-on - same. Then component-sibling-dependencies. circular-dependencies-components == circular-dependencies-actions, it's a list of (operation . component) pairs hash-tables of symbol, component == hash-tables of operations and component, systematically using make-sub-operation make-sub-operation == find-operation, to work like find-component, and ignore the first contextual argument if the second is already an object. Canonicalizes named operations while still allowing explicitly different operations of the same class. module-components == component-children module-components-by-name == component-children-by-name load-fasl-op == load-system-fasl-op load-op == split between load-op and load-fasl-op (see below). Alternatively, for backwards compatibility, call the latter load-compiled-op My current temporary names would also be renamed: parent-load-op == prepare-op (or dependency-op?) visit-children == done away with -- replaced entirely by one component-depends-on method. parent-op == upward-operation child-op == downward-operation Chasing horizontal dependencies to siblings under the same parent would be done entirely by prepare-op, which is a subclass of upward-operation. load-op would remain a downward-operation, but would have a separate strategy for deciding whether to delegate to load-source-op, load-fasl-op or load-system-fasl-op or whatever (e.g. some load-instrumented-op extension), based on a generalization of the force / force-not mechanism that would decide the compilation strategy. These ones would NOT be downward-operations, unlike the main load-op which
