The link in Google for the ASDF manual points to
http://common-lisp.net/project/asdf/manual.html
This is so because I convinced the person with the highest page rank in that
query to place a link to this page.
However the previous link has been arbitrarily changed to become
One of my own systems got blown up by ASDF-OUTPUT-TRANSLATIONS recently,
and the case may be an interesting one:
I am working on a system that involves taking an ontology from the
Protege tool, and interpreting it as CL.
So we have a special component type which is pont (from Protege ontology).
To prevent Lisp files from being redirected, you can add a rule such as
((:root #p**/*.lisp) t)
in your translations.
OR, you can make sure your output-file methods return T as a second
value to prevent relocation.
[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
On 4/14/10 Apr 14 -8:52 PM, Robert Goldman wrote:
On 4/14/10 Apr 14 -8:41 PM, Faré wrote:
To prevent Lisp files from being redirected, you can add a rule such as
((:root #p**/*.lisp) t)
in your translations.
OR, you can make sure your output-file methods return T as a second
value to
False alarm. A-B-L compatibility /is/ working here.
Now I need to figure out /why/ it is working for compatibility, but
fails when the compatibility is turned off (and the .lisp file gets
written in the wrong place).
Anyway, I clearly shouldn't go messing about with this until I'm sure I
know
On 4/14/10 Apr 14 -8:56 PM, Faré wrote:
On a large flat system (automatically generated by XCVB from QRes),
TRAVERSE takes a whole lot of time. More like O(n^2) or O(n^3) than
either O(n) or O(n log n).
I suspect suboptimal algorithms are used somewhere, either in
component lookup or in
Ahem. Does it work better with 1.679?
It's hard to test these things without access to a Windows machine...
Also, I realize that in Unix, I rely on absolute-pathname-p meaning
a completely qualified pathname, which breaks down on Windows,
with potentially interesting implications. Sigh.
[
