I committed a variant of your patch. See 3.0.2.30.
Can you send a failure log?
Touch is not part of Windows, but it's probably part of either cygwin
or msys or whichever add-on you run the test scripts with.
—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
Yield to
it got big and popular.
On Sat, Oct 19, 2013 at 10:51 PM, Dave Cooper david.coo...@genworks.com wrote:
On Sat, Oct 19, 2013 at 7:43 PM, Faré fah...@gmail.com wrote:
I committed a variant of your patch. See 3.0.2.30.
With this pulled, test-stamp-propagation started failing even more
#SYSTEM::STRING-INPUT-STREAM
41907B4873
.
neither from cmd.exe nor from bash. Whatever I tried it fails in one way or
another.
Fabrice
2013/10/20 Faré fah...@gmail.com
It looks like to me Fabrice is using CMD.EXE as his command-line, not
bash, and CMD.EXE has its own escaping algorithm
Excellent: Fabrice's testing with LispWorks revealed an issue in
with-temporary-file, that was not designed to play well with mandatory
locking, as is the default on Windows, used by LispWorks. I therefore
refactored with-temporary-file to work well in this case, added tests,
and refactored
Do you get any output?
We heavily modified run-tests.sh to be more robust with the way
Windows implementations (fil to) parse command-line arguments;
test-run-program has taken a beating, and the new
test-stamp-propagation has never worked well on ABCL. Maybe we somehow
broke something on ABCL?
On Mon, Oct 21, 2013 at 6:52 PM, Robert P. Goldman rpgold...@sift.info wrote:
Looking at the make file, I see:
# test upgrade is a very long run... This does just the regression tests
test-all-no-upgrade:
@for lisp in ${lisps} ; do \
${MAKE} test-lisp test-clean-load
On Tue, Oct 22, 2013 at 2:08 PM, Dave Cooper david.coo...@genworks.com wrote:
I solved the issue by the following bootstrap procedure:
1. compile/load adsf3
2. (remhash uiop asdf::*preloaded-systems*
3. load quicklisp's setup.lisp
Without step (2), the preloaded system of uiop occurs first
On Tue, Oct 22, 2013 at 3:55 PM, Zach Beane x...@xach.com wrote:
Faré fah...@gmail.com writes:
I suppose the solution is for search-for-system-definition to treat
sysdef-preloaded-system-search specially and put it at the end of the
search, just like it magically puts find-system-if-being
—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
On Tue, Oct 22, 2013 at 3:57 PM, Dave Cooper david.coo...@genworks.com wrote:
I suppose the solution is for search-for-system-definition to treat
sysdef-preloaded-system-search specially and put it at the end of the
On Tue, Oct 22, 2013 at 4:36 PM, Zach Beane x...@xach.com wrote:
Faré fah...@gmail.com writes:
preloaded means: the code is already in the image, though the source
might not be available.
Thanks for clarifying. Can this behavior only be changed by modifying
the internals of ASDF?
I'm
On Thu, Oct 31, 2013 at 5:32 PM, Zach Beane x...@xach.com wrote:
Faré fah...@gmail.com writes:
On Thu, Oct 31, 2013 at 2:43 PM, Zach Beane x...@xach.com wrote:
I've saved an executable SBCL image that includes asdf and calls
load-system. If the system it's loading depends-on sbcl contribs
•ReflectionCybernethics• http://fare.tunes.org
If it's not worth doing right, it's not worth doing. — Scott McKay
On Thu, Oct 31, 2013 at 5:59 PM, Faré fah...@gmail.com wrote:
On Thu, Oct 31, 2013 at 5:32 PM, Zach Beane x...@xach.com wrote:
Faré fah...@gmail.com writes:
On Thu, Oct 31, 2013 at 2:43 PM
On Fri, Nov 1, 2013 at 8:46 PM, Zach Beane x...@xach.com wrote:
I'll try to put together a small test case. In the meantime, here are my
ultimate goals:
- Load internal (e.g. ASDF) and special (e.g. SBCL contribs) systems
normally
- Strictly and explicitly map where all other
On Sat, Nov 2, 2013 at 3:53 PM, Zach Beane x...@xach.com wrote:
Speaking of which, I have a defsystem that looks like this:
(defsystem #:system
:weakly-depends-on (#:weak-dep)
:depends-on (#:dep)
:defsystem-depends-on (#:defsystem-dep)
...)
If I have the system object in
On Wed, Nov 6, 2013 at 10:51 AM, Zach Beane x...@xach.com wrote:
Mirko Vukovic mirko.vuko...@gmail.com writes:
I have a system sitting in ~/quicklisp/local-dists and a development
version sitting in ~/.../lisp-development/
I would like ASDF to open the latter one. I use asdf:load-system.
—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
On Wed, Nov 6, 2013 at 3:00 PM, Robert Goldman rpgold...@sift.net wrote:
Faré wrote:
I disrecommend pushing '*default-pathname-defaults* into the
*central-registry* — that makes system loading less predictable
(DEFUN ADD-SOURCE-DIRECTORY-TO-ASDF (DIR)
(ASDF:INITIALIZE-SOURCE-REGISTRY `(:source-registry (:DIRECTORY ,DIR)
:inherit-configuration)))
and
(ADD-SOURCE-DIRECTORY-TO-ASDF (uiop:getcwd))
?
This doesn't *add* the directory to the configuration, but each time
overwrites the previous
Maybe this test can be combined with the bundle and/or run-program
test: make a jar (in a subprocess?), load it.
—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
Sexless marriages basically force the partner that wants sex into three
outcomes (1) Misery (2) Cheating
On Thu, Nov 7, 2013 at 12:32 PM, Robert Goldman rpgold...@sift.net wrote:
Faré wrote:
On Thu, Nov 7, 2013 at 9:35 AM, Zach Beane x...@xach.com wrote:
Thanks. I started to implement this idea, but I'm concerned because ASDF
already defines an unspecialized :before method on OPERATE. Is it safe
On Thu, Nov 7, 2013 at 12:40 PM, Robert P. Goldman rpgold...@sift.info wrote:
Faré wrote:
You don't have to rewrite your source-registry.conf for something
that's temporary. Maintain your list, and tuck it into the parameter
you pass to initialize-source-registry, or push stuff to the
central
wrote:
On Nov 7, 2013, at 8:14, Faré fah...@gmail.com wrote:
Maybe this test can be combined with the bundle and/or run-program
test: make a jar (in a subprocess?), load it.
Sounds like a reasonable proposal: when I get to debugging the bundle op,
I’ll
take a stab at this.
If someone else
On Mon, Nov 11, 2013 at 2:40 AM, FAU f...@riseup.net wrote:
I'd like to find out if I can do this with ASDF.
(defun foo ()
#+foo1.0
:foo1.0
#+foo1.1
:foo1.1
)
As you can see the behaviour of the fn foo depends on version request
features (which, lets say, represents the API
Dear Lisp hackers,
I wasted quite some time today with a weird weird bug.
I was streamlining the build of Lisp code within Google, which will
now use as little of ASDF as possible to take advantage of their
massively scalable build system, blaze:
On Sat, Nov 16, 2013 at 5:21 PM, FAU f...@riseup.net wrote:
(defmethod output-files ((operation compile-op) (component foo-file))
(let ((l (multiple-value-list (call-next-method
(apply #'values (mapcar #'(lambda (p)
(make-pathname* :directory (append
Anton Vodonosov wrote:
So, my question is: how :depends-on ((:version ...))
should work, and is the change in the behavior intentional?
The change of behavior in VERSION-SATISFIES is from ASDF 3.0.1, 2013-05-16.
Since even before VERSION-SATISFIES was introduced on 20/02/2002, ASDF
had been
On Mon, Nov 18, 2013 at 2:34 AM, Pascal Costanza p...@p-cos.net wrote:
The 0.xy versions of Closer to MOP were not based on semantic versioning, but
on an ad hoc versioning scheme. 1.0.0 did not change any API at all, so is
definitely compatible with the last 0.xy versions. 1.0.0 is supposed
On Mon, Nov 18, 2013 at 10:21 AM, Pascal Costanza p...@p-cos.net wrote:
ASDF is not going to hard code an
exception for your library.
Closer to MOP already existed before asdf imposed anything on version
numbers, so asdf has to provide a way to define exceptions for such cases.
The
of software developed in a centralized way.
ASDF libraries are distributed as source,
and more and more developed in a distributed way.
Thanks to #+foo, #.(if (find-symbol FOO :bar) ...)
and (eval-when ...), CL can deal with source-level compatibility
in ways that C cannot.
When Faré wrote up
On Wed, Nov 20, 2013 at 12:54 PM, Pascal Costanza p...@p-cos.net wrote:
Just to chime in in the middle: There is no known solution to the so-called
DLL hell problem.
Yes there is.
http://nixos.org/nixos/
Libraries interact badly because of their interactions,
not because one or the other is
On Thu, Nov 21, 2013 at 3:56 PM, Anton Vodonosov avodono...@yandex.ru wrote:
Fare, I do not understand how you think about versioning.
Why do you say semantic versioning is for binary libraries?
Because that's what it was designed for: binary releases of C
libraries, such as
On Thu, Nov 21, 2013 at 12:45 PM, Robert P. Goldman rpgold...@sift.info wrote:
Faré wrote:
I'm going to take that as a vote to implement a continuation restart for
version mismatch errors. [Yes, I'm grasping at straws! ;-)]
I vote NO to that.
Usually I find myself in agreement with you
ASDF was never equipped to resolve versioning constraints, just to
check them. So yes, we need external tools to create assemblies of
mutually-compatible library versions. Quicklisp is such at tool, and
the only one being maintained at this point.
Otherwise, I agree that unless it is both
My recommendation is to not use reader conditionals, but instead use
asdf/find-system:register-preloaded-system
Quicklisp will preempt any preloaded-system, but if that's what you
want to avoid, my recommendation is to push the equivalent of the
sysdef-preloaded-system-search before quicklisp's
problem;
but it's the beginning to any long-term solution to anyone of them.
Freedom is not the end of every large-scale problem;
but it's the beginning to any long-term solution to anyone of them.
— Faré
Dear Robert,
do you think we can release this year?
All tests pass for me on Linux, and I believe all tests were passing
for Dave Cooper on Windows. There has been very light development this
past month, with no intent for further development ahead, but notable
new features and bug fixes since
On Thu, Dec 19, 2013 at 11:24 AM, Dave Cooper david.coo...@genworks.com wrote:
I had a couple failures: abcl/windows, clisp/windows, clisp/linux:
https://www.dropbox.com/sh/jc2cqwpkp06dupm/1IBEQ9XyKi/asdf-failures/3.1.0.24
OK, can you try the latest, 3.1.0.26, where undo a previous hack and
On Thu, Dec 19, 2013 at 4:58 PM, Dave Cooper david.coo...@genworks.com wrote:
Finished clisp on Linux, still the one failure for pathname, here is the
-test.text and -pathnames.text:
https://www.dropbox.com/sh/jc2cqwpkp06dupm/Jmq7a3BhtZ/asdf-failures/3.1.0.26
Windows tests still running,
OK, I'm sick and tired, but I'm even more obsessive and
procrastinating, so I hacked asdf-pathname-test some more.
This file is a big pile of fail, some of it maybe due to the
three-star programming of the original by janderson, a lot of it no
doubt due to my trying and failing to make sense of
On Fri, Dec 20, 2013 at 12:02 AM, Dave Cooper david.coo...@genworks.com wrote:
I will. I can also try with using the local filesystem instead of the
weird shared filesystem from the virtual host. Will do the 3.1.0.27 with
the current setup first, and try that next. Sticking with Linux only
The Linux CLISP failures are the same as before: all file accesses
fail, probably due to the weird filesharing setup, that doesn't
provide whatever syscalls that CLISP relies on.
The Windows CLISP failures have all directory accesses fail, with file
access working, so I suppose it's balancing the
Dear Anton,
When we tested with cl-test-grid,
ABCL, CMUCL, CCL, CLISP, ECL, SBCL were tested on 2.31.8
http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-21.html
The latest cl-test-grid cycle was for ASDF 2.32.35, it was tested
on CCL, CLISP, ECL, SBCL on Linux.
On Tue, Dec 31, 2013 at 3:36 AM, Anton Vodonosov avodono...@yandex.ru wrote:
31.12.2013, 12:32, Faré fah...@gmail.com:
Don't overdo it. I would do it with
maybe 2.26 (default from Quicklisp), 2.32.35 (previous tested),
3.0.3 (latest stable) and 3.1.0.32 (release candidate),
and that's
Yes, ASDF upgrade is completely broken on CMUCL, due to undetermined PCL issues.
I've tried punting harder on CMUCL (by having a #-cmu in headers.lisp
before ( existing-version 2.27),
but it still breaks the upgrade test, in other ways.
It would be really nice if a CMUCL hacker and/or PCL expert
On Wed, Jan 1, 2014 at 2:31 PM, Robert P. Goldman rpgold...@sift.info wrote:
Recent experience shows that changes leading to ASDF 3 have changed the
way one must specify new operation classes, in a way that is not
backward-compatible. Thanks to Faré for helping me diagnose problems in
one
On Wed, Jan 1, 2014 at 3:52 PM, Cyrus Harmon ch-l...@bobobeach.com wrote:
I have a couple of libraries that make their own operation and component
classes, asdf-dso, asdf-objects and smarkup come to mind. See
https://github.com/slyrus/asdf-objects and
https://github.com/slyrus/smarkup.
These
On Wed, Jan 1, 2014 at 5:02 PM, Robert P. Goldman rpgold...@sift.info wrote:
CCL: package-system-test.script
clisp: asdf-pathname-test.script package-system-test.script
test-sysdef-asdf.script
sbcl: package-system-test
ecl: package-system-test.script test-bundle.script (expected)
On Wed, Jan 1, 2014 at 10:54 PM, Robert P. Goldman rpgold...@sift.info wrote:
TEST ABORTED: These two expressions yield paths that are not pathname-equal
the first expression (MAKE-PATHNAME :HOST ASDFTEST :DIRECTORY
'(:ABSOLUTE system2 module4) :NAME NIL :TYPE NIL) yields this:
It turns out to be a Quicklisp bug. Indeed, quicklisp 2013-12-13
records exscribe-typeset as a dependency of exscribe.
OK, I modified exscribe to not use the :feature feature,
but quicklisp probably needs to be fixed to support it, too.
The feature was already present in late ASDF 1,
but nobody
://fare.tunes.org
Reason isn't about not having prejudices,
it's about having (appropriate) postjudices. — Faré
On Thu, Jan 2, 2014 at 11:44 PM, Robert P. Goldman rpgold...@sift.info wrote:
While there are bug fixes waiting to reach our users, I'm quite
concerned by the loss of backwards compatibility in systems that defined
their own OPERATION subclasses.
This backward incompatibility already happened
Dear Lisp hackers,
I'm considering recording a walk through the ASDF sources.
I'd like to have an interactive session over Google Hangout
with one or a few people, explaining the current code in asdf/defsystem
(i.e. not going into uiop, except to minimally explain what asdf uses).
That should
I get this, and the recoding is a HUGE improvement. Furthermore, you
have convinced me that we can't unwind this change in any way that won't
create yet more damage.
However:
a. This change is not backward-compatible
Actually, I looked again, and paren-compile-op is actually unaffected,
On Fri, Jan 3, 2014 at 10:29 AM, Robert P. Goldman rpgold...@sift.info wrote:
Per the principle of failing obviously, I propose to raise an error upon
attempts to use bundle-op with ECL or ABCL on Mac OSX. The bundle-op
tests have been failing for me on those platforms for as long as I can
Copying this conversation to asdf-devel, since these are topics of
interest to any hacker who would like to take over development of
ASDF.
On Mon, Jan 6, 2014 at 11:07 AM, Robert Goldman rpgold...@sift.net wrote:
I'm dribbing and drabbing these out, I'm afraid
FIND-OPERATION vs.
An innocuous-looking change suggested by rpgoldman,
of not providing a default initform for the selfward-operation slot,
led after testing to fixing a few innocuous bugs in asdf,
but also to a better understanding of the issues with CMUCL and upgrade.
After the innocuous change, tests failed on
On Sun, Jan 12, 2014 at 1:57 PM, Robert P. Goldman rpgold...@sift.info wrote:
Faré wrote:
1. Add warnings as appropriate wrt changes in OPERATION hierarchy for
code that extends OPERATION classes.
Not sure what you mean by add warnings: issue an official
declaration warning people that code
On Sun, Jan 12, 2014 at 6:24 PM, Anton Vodonosov avodono...@yandex.ru wrote:
Unfortunately the upgrade still fails for my CMUCL snapshot (cmucl-2013-04)
I have tried the very recent ASDF:
Weird. What version of ASDF are you upgrading from?
It should work with ASDF 2.33 and later (3.0.1, 3.0.2,
On Sun, Jan 12, 2014 at 10:50 PM, Robert P. Goldman rpgold...@sift.info wrote:
The best we can do is issue a warning whenever code defines a subclass
of OPERATION, and allow the user to indicate that s/he understands and
wishes to proceed.
I agree in principle, and I believe
that would have
What if the previous hierarchy was plain buggy?
Then going forward we have to introduce a NEW class to replace the old
class.
Yes, that breaks code, but it only breaks code VISIBLY. Redefinition of
existing classes breaks code INVISIBLY.
If we had a new name, say OPERATION-CLASS, then
On Mon, Jan 13, 2014 at 12:07 PM, Anton Vodonosov avodono...@yandex.ru wrote:
Unfortunately the upgrade still fails for my CMUCL snapshot (cmucl-2013-04)
I have tried the very recent ASDF:
Weird. What version of ASDF are you upgrading from?
It should work with ASDF 2.33 and later (3.0.1,
That might be nice, but when would we run this check? After loading
each new system? That seems a lot harder than running a check when a
new OPERATION subclass is instantiated (as Pascal's suggestion).
Actually check at instantiation time is all the better for operation since
we do our best
On Mon, Jan 13, 2014 at 8:38 PM, Luís Oliveira luis...@gmail.com wrote:
[Cc-ing asdf-devel]
On Tue, Jan 14, 2014 at 1:14 AM, Faré fah...@gmail.com wrote:
Wow. If asdf 3.0.3 loads 2.14, that's a notable bug indeed. I have a faint
how that the bug is somehow in something other than asdf itself
BTW, as of commit ea469db (3.1.0.49) on Linux x64, all tests pass for
me with no unexpected failures.
ASDF_TEST_LISPS=ccl clisp sbcl cmucl allegro allegromodern lispworks
ecl_bytecodes ecl abcl xcl gcl
PS: The code walkthrough is scheduled for Sunday January 26th 2014 at
1400 EST (1900 UTC)
—♯ƒ
So your only chance is to define an operation-class metaclass, and make sure
that operation is an instance of operation-class (or similar).
This is quite a crippling limitation, then. Adding a metaclass would
add another quite substantial amount of compatibility code to ASDF to
permit us
The big problem, however, in this case, is still how do you
distinguish between a good class that shouldn't trigger a warning,
and a bad class that should.
By deprecating the use of operation as a superclass, and providing a new
‘new-operation class (or some such) that user code has to use
On Tue, Jan 21, 2014 at 5:46 PM, Robert P. Goldman rpgold...@sift.info wrote:
If you have any systems that define their own subclasses of OPERATION,
*please* pull this update and test.
This new version checks to see if OPERATION classes have been updated to
adapt to Fare's refactoring of the
On Tue, Jan 21, 2014 at 8:45 PM, Robert P. Goldman rpgold...@sift.info wrote:
FWIW, *all* the OPERATION-redefining systems will be broken. This is
intentional. All such systems need reexamination, and potentially patching.
For the record, I still think this intentional breakage is a bad
On Wed, Jan 22, 2014 at 1:19 AM, Anton Vodonosov avodono...@yandex.ru wrote:
22.01.2014, 09:16, Faré f...@tunes.org:
PPS: Anton reports no error. Is that because the classes that are
broken are never invoked during the loading of those libraries, only
during the using of them, but no code
framework (e.g., fiveam:run!) to run
the tests that the component files have defined.
When I say I believe that to be correct, credit is due to Faré for
thinking this true and convincing me that SELFWARD is correct and
DOWNWARD is not correct.
Note that this is exactly what ASDF3 is doing
On Wed, Jan 22, 2014 at 12:40 PM, Anton Vodonosov avodono...@yandex.ru wrote:
I don't think that preserving OPERATION semantics is really ruled out.
Lets consider it a little bit more?
Is it true that old ASDF:OPERATION is semantically equivalent to the new
DOWNWARD-OPERATION? If yes, the
On Wed, Jan 22, 2014 at 4:05 PM, Robert P. Goldman rpgold...@sift.info wrote:
Faré wrote:
On Wed, Jan 22, 2014 at 2:54 PM, Robert P. Goldman rpgold...@sift.info
wrote:
I think what Faré is pointing out is that one could build, for example,
an introspection library by adding for example
On Fri, Jan 24, 2014 at 12:21 AM, Daniel Herring dherr...@tentpost.com wrote:
For those cases, I have pushed a change that checks to make sure that
all operations that are instantiated are subclasses of either
DOWNWARD-OPERATION, UPWARD-OPERATION, SIDEWAY-OPERATION,
SELFWARD-OPERATION, or a
On Sat, Jan 25, 2014 at 7:58 AM, Anton Vodonosov avodono...@yandex.ru wrote:
Theoretically, OPERATION may be the root class and keep the old semantics
(downward + selfward + other). And subclasses override this semantics
as they do now: DOWNWARD-PERATION, SELFWARD-OPERATION, etc.
This may
OK, will do. I will try to get all of the new operations written up,
but I don't believe I will have time until after the 31st (conference
deadlines, and end of contract dates mean that the ASDF manual has to
wait...).
Take your time. We're all impatient about it.
I do not yet the
details
before I go away from the project. Do not hesitate to ask more questions.
—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
So that there be reality, there must be an observer.
I am, therefore someone thinks. — Faré
Thanks to Anton's suggestion, the fix was relatively simple — see ASDF
3.1.0.56, commit eb2da723.
I also committed some improvements initiated during the walkthrough.
Anton: can you run cl-test-grid against that?
If you have time, also try with (uiop:enable-deferred-warnings-check)
and also try
Emerson
On Thu, Feb 21, 2013 at 11:37 AM, Faré fah...@gmail.com wrote:
Dear Lisp hacker(s),
ASDF3 now checks deferred warnings by default.
On SBCL, this means that it will treat as an error
any undeclared free variable, including forward references to special
variables
as well as any undefined
I'm actually not sure what the assumptions are for QL. Does it assume
that all libraries should be portable? Can contributors proclaim their
systems to be non-portable, and does that affect QL function (and if so,
how)?
The current situation is that the project must build on SBCL, and I
sbcl
(load ~/quicklisp/setup.lisp)
(asdf:INITIALIZE-OUTPUT-TRANSLATIONS)
;; So far, so good:
((#P/home/tunes/local/stow/sbcl/lib/sbcl/**/*.* T)
(#P/home/tunes/local/stow/sbcl/lib/sbcl/**/*.*
#P/home/tunes/local/stow/sbcl/lib/sbcl/**/*.*)
(T T)
I put my recording of the ASDF Walkthrough on Youtube. It's nothing
great, but oh well, it's as good an introduction to the code as you'll
get (for now). It's long, but you can watch at x1.5 speed for reduced
bore — or use youtube-dl then vlc to watch at whichever speed you
prefer.
nice to have.
Oh, such an ABCL specific test is quite easy: I guess I thought Faré was
asking
for something that ran on all implementations, which I didn’t quite
understand.
I'd prefer a general test, but
one that runs just on ABCL would be a good start.
But I must confess I dont really
It's a bug indeed. Unhappily, DIRECTORY is not portable at all. I've
added an ugly workaround in 3.1.0.63.
If you're volunteering to commit a real fix, and tests, to make sure
it works on each and every of the 10+ supported implementations,
together with a regression test, I'll be delighted to
On Sat, Feb 1, 2014 at 11:02 PM, Robert P. Goldman rpgold...@sift.info wrote:
On Mac OS X, when I try to upgrade my ASDF using the logical pathnames
home:lisp;asdf; and home:lisp;asdf;uiop; I get this error:
*** - While searching for system asdf: home:lisp;asdf;uiop;
evaluated to
On Mac OS X, when I try to upgrade my ASDF using the logical pathnames
home:lisp;asdf; and home:lisp;asdf;uiop; I get this error:
*** - While searching for system asdf: home:lisp;asdf;uiop;
evaluated to home:lisp;asdf;uiop; which is not an absolute directory.
Weird. It looks like an absolute
This is only fixable going forward, right? Because it's a bug that
affects the upgrade
Old versions of ASDF may or may not like logical pathnames so much, anyway.
I guess this means that clisp is more fussy about accepting a pathname,
rather than a pathname-designator in some
BEWARE!
ENSURE-PATHNAME uses PARSE-UNIX-NAMESTRING, not PARSE-NAMESTRING.
In this case, you want PARSE-NAMESTRING (possibly through PATHNAME).
(describe (uiop/pathname:ensure-pathname home:lisp;asdf;))
#Phome:lisp;asdf; is a pathname, with the following components:
NAME = home:lisp;asdf;
On Mon, Feb 3, 2014 at 1:40 PM, Pascal J. Bourguignon
p...@informatimago.com wrote:
Faré fah...@gmail.com writes:
On Sun, Feb 2, 2014 at 7:38 PM, Robert P. Goldman rpgold...@sift.info
wrote:
I have been grappling with my inability to upgrade clisp, and find
myself confused by the following
difficult, it has never been attempted before.
On Sun, Feb 9, 2014 at 5:28 PM, Anton Vodonosov avodono...@yandex.ru wrote:
27.01.2014, 11:04, Faré fah...@gmail.com:
Anton: can you run cl-test-grid against that?
If you have time, also try with (uiop:enable-deferred-warnings-check)
and also try
On Tue, Feb 11, 2014 at 11:56 PM, Anton Vodonosov avodono...@yandex.ru wrote:
Next I will try the deferred-warnings
enabled and :uiop in the use-list of :asdf-user.
Thanks a lot!
I assume you're doing these tests separately:
I expect ~25 failures in the first test, and hopefully 0 in the
On Wed, Feb 12, 2014 at 8:43 AM, Anton Vodonosov avodono...@yandex.ru wrote:
But let me first understand what is this no applicable method
ASDF/COMPONENT:COMPONENT-CHILDREN
error and why it wasn't detected previously.
It's a bug I introduced in 3.1.0.56 with the backward-compatible
that essentially
duplicates the function of Faré's directory traversal.]
I still use the *central-directory* in many small tests, though
I much prefer the *source-registry* for a well-managed source code.
Faré, why is it that *source-registry-parameter* is exported? It seems
like a cache
On Mon, Feb 17, 2014 at 12:07 PM, Robert P. Goldman rpgold...@sift.info wrote:
Faré wrote:
You must be confusing *source-registry* and *source-registry-parameter*.
The former is the cache after searching the various paths, and is private.
The latter is the parameter provided to initialize
On Mon, Feb 17, 2014 at 8:47 PM, Anton Vodonosov avodono...@yandex.ru wrote:
I've been testing ASDF 3.1.0.66 and unfortunately detected errors:
TL;DR: All fixed in 3.1.0.67.
Thanks a whole lot for your testing, once again!
1. Required method PERFORM not implemented for
operation
I was going to ensure first that ASDF 3.1.0.67 has no regressions,
and then test and compare ASDF 3.1.0.67 vs ASDF 3.1.0.67 + :use :uiop
so we will be sure all the differences are caused only by :use :uiop
Perfect!
—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
On Wed, Feb 19, 2014 at 10:02 AM, Robert P. Goldman rpgold...@sift.info wrote:
Jean-Claude Beaudoin wrote:
Hello ASDF maintainers,
I just completed a port of ASDF 3.0.3 to what will soon be released as
MKCL 1.1.7.
It currently passes all the 48 tests of yours on Linux (Ubuntu 12.04)
and I
Dear JCB,
while you're at it, beside making it work with the latest 3.1,
you can look at the ECL-only tests and mkcl workarounds in the tests
(grep for ecl and mkcl tests/ and subdirectories).
It would be great if you could make them work on MKCL, too.
test-bundle and test-program notably are
3.1.0.70 it is. Passes all tests for me, on Linux x64 on
ccl clisp sbcl cmucl allegro allegromodern lispworks ecl_bytecodes ecl
abcl xcl gcl
Before some patches I just committed for xcl and gcl (!)
3.1.0.68 worked on Mac for Robert Goldman.
(Any volunteer to test on Genera? Corman? MCL? Windows?)
On Fri, Feb 21, 2014 at 9:24 AM, Anton Vodonosov avodono...@yandex.ru wrote:
So, I will change asdf like this:
- (:use :uiop/common-lisp :uiop/package :asdf/interface))
+ (:use :cl :uiop))
Right?
Please make it:
(:use :uiop/common-lisp :uiop :asdf/interface)
Since uiop/package is
On Fri, Feb 21, 2014 at 3:46 PM, Robert P. Goldman rpgold...@sift.info wrote:
The latest version of ASDF contains three functions:
SYSTEM-DEFSYSTEM-DEPENDS-ON
SYSTEM-DEPENDS-ON and
SYSTEM-WEAKLY-DEPENDS-ON
that return information about defined systems. The intention is to
support
This resolve-dependency-spec returns the actual system objects for depended
on systems, doesn't it? Hence the possible side effects.
Yes.
I was thinking of the much simpler expedient of traversing the dependency
s-expressions and using COERCE-NAME on all the system names. That gives us
601 - 700 of 1393 matches
Mail list logo
