asdf-devel April 2015

asdf-devel@common-lisp.net

54 participants
184 discussions

Re: [asdf-devel] Alternate default lisp system location
by Faré 08 Apr '15

08 Apr '15

>>: Faré >: janderson >> Daniel, if you want changes only every 5 to 10 years, do like >> janderson: try an upgrade every 5 years, find that it breaks your code >> somehow and downgrade back to the old version without further >> investigation. Then maybe 10 years from now you'll get the system >> dependency bug fixed. > > if one wishes to ascribe expectations to my actions, allow me to correct the > presumption, as more accurate would be the hope, in ten years to have the > luxury to work with a build system which leaves my dependency descriptions > alone and uses them to do what it should, without failing for unrelated > reasons. > Well, after 5 to 10 years, some amount of bitrot is to be expected, especially for software that wasn't abandoned but saw active development. It is very unfair of you to complain without ever submitting a bug report: we get no chance to defend ourselves. Did we do something stupid? Did you? Was the issue a known backward incompatibility? Was there a trivial fix, whether already documented or not yet? We'll never know. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org You can of course keep using any old ASDF 1 you like, or whichever or even MK-DEFSYSTEM, which is quite stable. Only if you ever want to use recent libraries that depend on new ASDF features or bug fixes, will you have to upgrade your ASDF.

1 0

[asdf-devel] Re: cl-quakeinfo and asdf3
by Faré 08 Apr '15

08 Apr '15

Dear Kevin, as I'm handing out my ASDF duties to my successor Robert Goldman, I gave this a brief look again, and it looks like the issue is (1) your doing everything in cl-user, and (2) your assuming cl-user has allegro extensions such as if* This confuses SBCL, that warns about the suspicious undefined function if*, and other such things. Some dependencies #-allegro :acl-compat and package use #+allegro :excl #-allegro acl-compat.excl could help. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The only way to have a friend is to be one. — Ralph Waldo Emerson On Thu, Feb 21, 2013 at 11:37 AM, Faré <fahree(a)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 function that isn't defined by the end of the system. > > Using cl-test-grid to compile all the systems in quicklisp, > we found the following failure on a system we believe you maintain. > Can you please fix it? > > cl-quakeinfo > http://cl-test-grid.appspot.com/blob?key=125l61q30b > > http://common-lisp.net/project/cl-test-grid/asdf/sbcl-warning-failures.html > http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-13.html > > —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org > Freedom transforms difficulty into opportunity, danger into responsibility. > "Protection" transforms difficulty into oppression, danger into tragedy.

3 7

[asdf-devel] Tests looking good on Mac and Linux
by Robert P. Goldman 08 Apr '15

08 Apr '15

All pass on linux for me, and all but test-bundle on ECL and ABCL on Mac. The latter two seem like they need help from the implementers which is not forthcoming. I'm going to figure out how to turn these tests off and propose to ship the long-postponed 3.0.3 if everyone is in agreement. Seems like the Windows tests have taken many steps forward while I was out of town. Any objections to this plan? Best, r

1 0

[asdf-devel] ASDF, primary-system-name and Quicklisp
by Faré 08 Apr '15

08 Apr '15

Dear Common Lispers, Zach reminds me that one thing is blocking his upgrading the ASDF in Quicklisp is the fact that currently, every user-defined function in *system-definition-search-functions* currently has to be aware of ASDF 3's primary-system-name feature, or it may fail to properly extend ASDF. Here is a patch that will hopefully make things better: whenever ASDF is looking for a non-primary system, it first looks for the associated primary system, in case it defines necessary meta-data. Zach, can you test? If this satisfies you, there's a chance of getting it out of the door as part of the imminent ASDF 3.0.3 release (or else, 3.0.4 next month or so, I hope). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If Government is the solution to any alleged "failure" of free society, what is the solution to blatant failures of Government?

1 1

[asdf-devel] Installing from tarball
by David A. Cobb 08 Apr '15

08 Apr '15

1 0

[asdf-devel] Re: Some questions re new ASDF structure
by Faré 08 Apr '15

08 Apr '15

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 <rpgoldman(a)sift.net> wrote: > I'm dribbing and drabbing these out, I'm afraid.... > > FIND-OPERATION vs. MAKE-OPERATION: I'm a bit confused by this. I see > that operations are all indexed in the *OPERATIONS* hash table, but > although the names suggest that MAKE-OPERATION would make a fresh > OPERATION object, and FIND-OPERATION would require that there be a > previously existing one, it seems like they *both* address the hash > table. Nevertheless, a careful distinction is made between calls, > suggesting that I am missing an important distinction. It looks like > there's a future interest in recovering initargs by using the CONTEXT > argument, but for now that seems to be ignored (i.e., the CONTEXT > argument never provides anything). > > PERFORM: I believe that the ASDF protocol expects that PERFORM will not > return anything of interest, correct? I don't see anyone catching > return values. I figure I should probably document this as part of any > documentation overhaul. > I'm glad you ask. This is another unresolved design issues tracing back to ASDF 1, and one that I wasn't fully aware of until I wrote ASDF 3, at which point I fumbled around and ended up settling for a compromise. The problem at heart is that * on the one hand, ASDF seems to allow operations to be parametrized by user-defined slots * on the other hand, when computing the plan, ASDF drops any such parameters as it walks the graph and discards any action such that an action of same type on same component has already been visited. When rewriting ASDF, I tried to reconcile the two, by memoizing operations created with the same initargs, but eventually failed by fear of breaking backward compatibility: * users can and often do call make-instance 'some-operation, at which point you don't have the unique operation object. * I tried to have a per-traversal cache, by making the initial operation given to traverse be the "parent" of all other operations in a traversal; but this required incompatible changes in the component-operation-time / mark-operation-done protocol (not a big deal, since no one should be looking inside), this most importantly fails to work when one tries to load-system the second time around, and since no operation object is the same that second time, every action looks like it hasn't been done yet, and asdf loads everything the second time around. * I eventually settled for a global cache of *operations*, but got discouraged before to check with every user inside (and outside?!) quicklisp that I could indeed make the incompatible change in component-operation-time. Also, every single function or method that can be called with a user-provided operation object must now "canonicalize" the object before to use it in any of these comparisons (or more likely, the comparison function should be abstracted, and do the canonicalization, and for decent speed, cache the canonicalized operation in a slot of each compared operation object). * Finally, there was the issue of what it meant for two initargs to be equivalent — that totally depends on the operation class, and there's no protocol to help determine when that is or isn't the case. And this is further complicated by the fact that operate historically passes its keyword arguments to the operation, which includes things such as force, which are actually arguments to the plan, and shouldn't affect the operation — except that swank and gbbopen somehow used that slot (though they have both been weened off it recently, so we could leave a compatibility nil method in backward-interface and be done with it). So there, I did an incomplete job here, and I apologize for it. It will be your call to either fully allow operation initargs, or definitely deprecate them. Obviously, no one is relying on the feature right now, since it has never worked (not uncommon a thing for ASDF — :depends-on (:feature featr component), :force (sys1 sys2), and probably more are ASDF 1 features that never worked until I fixed them, that plus the module dependency that you fixed). PERFORM returns nothing of interest indeed — it either succeeds or signals an error. Now, my plans for an ASDF 4 (or at least 3.2) were to move ASDF towards a cross-compilation model, which would make life easier for MOCL, but would also bring to the ASDF world most of the goodies of XCVB: off-image compilation, deterministic build, parallel build, etc. This would mean deprecating PERFORM, instead having a method PERFORM-FORM or such that returns some source code to be run on the target slave (as opposed to the planning master — the slave doesn't run ASDF, only UIOP, and doesn't compute the entire plan, so can be started quickly on N machines or cpus) — and maybe a list of dependencies to be loaded on the target. When no method is defined for PERFORM-FORM, ASDF4 would check for a PERFORM method, in which case it would load ASDF on the target as well as some set of dependencies to be determined (e.g. the defsystem-depends-on of the current system), and then would either import the entire set of system definitions being used or create a fake trivial system with one entry, and then call perform on the chosen operation and component. Depending on how serious you are about it, you may or may not also adopt XCVB's model of :compile-depends-on, :load-depends-on :run-depends-on, with :depends-on foo implying a :compile-depends-on foo.cfasl (assuming you also support cfasls), and :load-depends-on foo.fasl (must be loaded before) and :run-depends-on foo.fasl (can be loaded after with circular dependencies), whereas :defsystem-depends-on foo implies :compile-depends-on foo.fasl and :load-depends-on foo.fasl. Or something more complex; cross-compilation is hard. That's also advanced hacking, and a somewhat incompatible change (modulo that fallback strategy) that requires a lot of social work for a smooth transition. But hopefully, you can convince the MOCL guy to do the social work, since it's in his interest to promote a standardized cross-compilation solution, and good marketing for him (Cc'ed). Regards, —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Live as if you were living already for the second time and as if you had acted the first time as wrongly as you are about to act now! — Viktor Frankl, "Man's Search for Meaning"

1 0

[asdf-devel] Pushed update
by Robert Goldman 08 Apr '15

08 Apr '15

This has Vladimir Dyomkin's patch for some of the version-handling code (thanks, Vladimir!). It also has a fix to failures of test.run-program on LispWorks. This is version 3.0.2.6. It is *not* a release yet! I'd like to see some more tests run, and there's one more bug in UIOP that should be fixed, before we release 3.0.3. Best, Robert -- Robert P. Goldman Principal Scientist Smart Information Flow Technologies (d/b/a SIFT, LLC) 211 N. First St., Suite 300 Minneapolis, MN 55401 Voice: (612) 326-3934 Email: rpgoldman(a)SIFT.net

2 1

[asdf-devel] Bundle tweaks, commit policy
by Faré 08 Apr '15

08 Apr '15

Dear Robert, since I'm tweaking bundle-op, what about we rename fasl-op and load-fasl-op to compile-bundle-op and load-bundle-op? For backward compatibility, we would leave the old names as trivial selfward-operation's that depend on the new ones. That's the kind of change that requires maintainer approval. NB: I've been taking the liberty to commit stuff without review when I feel it's "just bug fixes" and nothing worth of a policy decision. Also, since I've done it so much in this current release, some increment of it won't make things worse. But if I'm taking too much liberty, please tell me: I can stop now, and/or I can be more cautious after your 3.1.1 release. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Mathematicians are like Frenchmen: whatever you say to them they translate into their own language, and forthwith it is something entirely different. — Johann Wolfgang von Goethe

1 0

[asdf-devel] Fwd: ASDF testing for LWW
by Faré 08 Apr '15

08 Apr '15

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 run-program to account for this locking issue. I also pushed fixes for the issues that Fabrice mentioned. Thanks a lot, Fabrice! And thanks a lot Dave, for doing so much testing on Windows... this has led to plenty of fixes to many implementations as well as to ASDF. So... is there any obstacle left to release? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The Biggest City / Only makes you truly feel / Crushed by loneliness.

1 0

[asdf-devel] How can I intercept errors?
by Juan Jose Garcia-Ripoll 08 Apr '15

08 Apr '15

As a maintainer of a Common Lisp implementation I am really not interested on ASDF intercepting errors without allowing me to do a proper backtrace because it jumps to a different, outer context. How can I prevent this? The code right now has evolved to such a different shape that I cannot know how to do it by myself :-/ Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com

2 2

← Newer
1
...
12
13
14
15
16
17
18
19
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel April 2015