asdf-devel

asdf-devel@common-lisp.net

5 participants
1375 discussions

Re: [asdf-devel] [Sbcl-devel] ASDF in SBCL
by Faré 24 Jun '10

24 Jun '10

On 24 June 2010 09:41, Attila Lendvai <attila.lendvai(a)gmail.com> wrote: > is this a bug, or am i doing something wrong? > > if a bug, shall i record it as ASDF bug or SBCL bug? > > > alendvai@ed101:/usr/share/common-lisp/source$ rlwrap > ~/workspace/sbcl/run-sbcl.sh --no-userinit > (running SBCL from: /home/alendvai/workspace/sbcl) > This is SBCL 1.0.39.21, an implementation of ANSI Common Lisp. > More information about SBCL is available at <http://www.sbcl.org/>. > > SBCL is free software, provided as is, with absolutely no warranty. > It is mostly in the public domain; some portions are provided under > BSD-style licenses. See the CREDITS and COPYING files in the > distribution for more information. > * (require :asdf) > > ("ASDF") > * (asdf:load-system :asdf) > > ; registering #<SYSTEM :ASDF> as ASDF > INFO: Control stack guard page unprotected > Control stack guard page temporarily disabled: proceed with caution > > fatal error encountered in SBCL pid 17617(tid 140737353979648): > Control stack exhausted > > Welcome to LDB, a low-level debugger for the Lisp runtime environment. > ldb> > > > > > > the backtrace while the rather slow endless recursion is running: > > > 988: (SB-INT:SIMPLE-EVAL-IN-LEXENV > (ASDF:DEFSYSTEM :ASDF > :PATHNAME > NIL > :DEPENDS-ON > NIL > :COMPONENTS > NIL) > #<NULL-LEXENV>) > 989: ((LAMBDA (#:G[SYSTEM-DEFINITION-PATHNAME]1191)) ASDF::SYSDEF-FIND-ASDF) > 990: (SB-IMPL::%MAP-FOR-EFFECT-ARITY-1 > #<CLOSURE (LAMBDA #) {10031662F9}> > (ASDF::SYSDEF-CENTRAL-REGISTRY-SEARCH ASDF::SYSDEF-SOURCE-REGISTRY-SEARCH > ASDF::SYSDEF-FIND-ASDF)) > 991: (ASDF:SYSTEM-DEFINITION-PATHNAME "asdf") > 992: (ASDF:FIND-SYSTEM "asdf" NIL) > 993: (ASDF:FIND-COMPONENT "asdf" NIL) > 994: (ASDF::PARSE-COMPONENT-FORM > NIL > (:MODULE "asdf" :PATHNAME #P"/usr/share/common-lisp/source/" :PATHNAME > NIL :DEPENDS-ON NIL :COMPONENTS NIL)) > 995: (SB-INT:SIMPLE-EVAL-IN-LEXENV > (ASDF::PARSE-COMPONENT-FORM NIL > (LIST* :MODULE > (ASDF-UTILITIES:COERCE-NAME ':ASDF) > :PATHNAME > #P"/usr/share/common-lisp/source/" > '(:PATHNAME NIL :DEPENDS-ON NIL > :COMPONENTS NIL))) > #<NULL-LEXENV>) > 996: (SB-INT:SIMPLE-EVAL-IN-LEXENV > (ASDF:DEFSYSTEM :ASDF > :PATHNAME > NIL > :DEPENDS-ON > NIL > :COMPONENTS > NIL) > #<NULL-LEXENV>) > > -- > attila > Oops, this is an embarrassing bug in ASDF 2.002 and 2.102. I fixed it in 2.103, that also fixes two other bugs. I wonder whether I should merge 2.103 wholesale as 2.003 in the release branch. Probably. The only controversial feature would be the compile-file* change. If I don't hear any objection to including it in 2.003, I will include it. Otherwise, I'll try to include everything from 2.103 but the compile-file* change. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] "How many libertarians does it take to change a lightbulb?" A- "None, the market will take care of it." B- "Every one of them and non-libs too, because we all *are* the market." C- "*I*'ll do it, for a dollar."

1 0

[asdf-devel] ASDF from git and lispworks Personal Edition on windows 7/Vista
by Alessandro Piras 19 Jun '10

19 Jun '10

Hi, The latest ASDF doesn't work well on Windows Vista/7 and Lispworks. LispWorks regards pathnames such as #P"C:/a-dir//anotherdir" as illegal because of the double slashes in it. I could fix it but it's a really ugly kludge not worth sharing. Anyway, I could understand where the problem lies: asdf is creating pathnames where (pathname-directory some-path) contains empty strings. This happens for output fasl files, that ASDF is placing in %APPDATA%\common-lisp\<implementation-name>\C\\path\to\source\file - note the double \\ after the drive letter. Hope this helps, __ Alessandro

2 3

[asdf-devel] GIT branching [was Re: [Bug 587889] Re: bad fasls can poison future build]
by Robert Goldman 17 Jun '10

17 Jun '10

On 6/16/10 Jun 16 -11:13 AM, Faré wrote: .... > > Robert: any thoughts re: branching? > I am so far from being a git expert, that I will not venture any suggestions. A while ago I read the following article which proposes a branching policy for use with git. It seemed, to my limited understanding, reasonable. Perhaps we could adopt some variant of this policy? http://www.newartisans.com/2009/10/branch-policies-with-git.html He seems to have many more branches than I would have thought necessary. I don't know that we need a "released," "stable devel," and "bleeding edge" as he does. Perhaps some sort of variant where we have a maint branch --- 2.0 with patches for bug fixes devel branch --- moving towards 2.1 ? I'm inclined to think that we could further minimize/simplify by having the devel branch be master. We could also have topic branches, like the one I built in order to do the first TRAVERSE mods for module dependencies. Does that sound reasonable? Feel free to say "no," since I'm making this up as I go along based on half-remembered blog posts. best, r

2 2

[asdf-devel] a hair in :pathname specifications
by Faré 12 Jun '10

12 Jun '10

Looking at Stelian's recent patches to iolib, I saw that he uses things like: (asdf:defsystem :iolib.syscalls ... :pathname #-asdf2 (merge-pathnames "syscalls/" *load-truename*) #+asdf2 "syscalls/" ...) This shocked me, as I new (for having been hit badly by the issue at ITA and having read the code) that you can't use (merge-pathnames ...) like that in a component and need #. instead, since there is no EVAL in parse-component-form. ITA used to have lots of #.(merge-pathnames ...) before I implemented / parsing in our local ASDF (now merged into ASDF 2). Well, it turns out that the defsystem macro itself treats :pathname specially and lets that argument be evaluated unlike other arguments and unlike :pathname for other forms. This interacts badly with some code I've written recently that cleans up the way we normalize specified pathnames for components, my code assuming we were always provided a valid specifier. So the question is: what to do? 1- Should I do nothing, thus having more uniform semantics but breaking compatibility with ASDF 1 and requiring users of defsystem to use #. in such occasions? 2- Should I issue an ASDF 2.0 minor release that re-allows pathname evaluation just for defsystem forms (excluding other forms), thus providing better backwards compatibility? 3- Should I issue an ASDF 2.0 minor release that does pathname evaluation inside parse-component-form, thus providing better backwards compatibility AND extending the semantics so that it be more uniform? [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] A common man marvels at uncommon things; a wise man marvels at the commonplace. — Confucius

3 3

[asdf-devel] (no subject)
by Stelian Ionescu 12 Jun '10

12 Jun '10

The first patch fixes the parsing of the configuration file that I use: (:source-registry :default-registry (:directory "/usr/share/common-lisp/systems") (:directory "/home/hechee/lisp/systems")) Currently I get "One and only one of :INHERIT-CONFIGURATION or :IGNORE-INHERITED-CONFIGURATION is required", even though none is present.

2 8

[asdf-devel] circular dependencies
by Seth Burleigh 11 Jun '10

11 Jun '10

Every once in a while when im creating an asd file and it fails to load, when i change it and attempt to load again it signals ASDF could not load script because Condition ASDF:CIRCULAR-DEPENDENCY was signalled.. Now, i know there is no circular dependency, but I cant yet successfully reproduce it consistently, so can someone maybe explain what I should do when that bug occurs so i can track down the source; i.e., how circularity is detected, etc.

2 1

[asdf-devel] Question about defsystem
by Robert Goldman 07 Jun '10

07 Jun '10

I was just looking over Scott's bugreports and I am wondering a bit about a snippet in defsystem: (defmacro defsystem (name &body options) (destructuring-bind (&key (pathname nil pathname-arg-p) (class 'system) defsystem-depends-on &allow-other-keys) options (let ((component-options (remove-keys '(:defsystem-depends-on :class) options))) `(progn ;; system must be registered before we parse the body, otherwise ;; we recur when trying to find an existing system of the same name ;; to reuse options (e.g. pathname) from ,@(loop :for system :in defsystem-depends-on :collect `(load-system ,system)) (let ((s (system-registered-p ',name))) *** (cond ((and s (eq (type-of (cdr s)) ',class)) (setf (car s) (get-universal-time))) (s (change-class (cdr s) ',class)) (t (register-system (quote ,name) (make-instance ',class :name ',name)))) (%set-system-source-file (load-pathname) (cdr (system-registered-p ',name)))) (parse-component-form nil (list* :module (coerce-name ',name) :pathname ,(determine-system-pathname pathname pathname-arg-p) ',component-options)))))) Look at the cond that's starred -- the first and third branches both cause the DEFINED-SYSTEMS entry for NAME to be updated to the current value of GET-UNIVERSAL-TIME. But the *second* branch does not seem to (unless it happens by some complex chain as a side-effect of CHANGE-CLASS). Can anyone explain why we shouldn't update the DEFINED-SYSTEMS entry in the case where S already exists but of a different type? Or does this happen as a side-effect of CHANGE-CLASS? Perhaps this is worthy of a comment.... best, r

1 0

[asdf-devel] ASDF 2.000 released!
by Faré 31 May '10

31 May '10

Dear Common Lispers, I have finally released ASDF 2, officially starting with release 2.000. http://common-lisp.net/project/asdf/ ASDF 2 is an evolution of ASDF that tries to be backwards compatible with previous releases and their many extensions, while at the same time improving the user experience in many important ways. I have worked hard towards reaching the current state, which I believe is now suitable for release and for inclusion in all Common Lisp implementations. I thank all those who helped develop and test this release, including Robert P. Goldman, James Anderson, Juan-Jose Garcia-Ripoll, and many more. We welcome bug reports on our launchpad site: https://launchpad.net/asdf I'm using ASDF 2 at ITA. Recent versions are already included in ABCL, CCL, CMUCL, ECL. Several hackers have tried building plenty of packages with it. While it's far from my ideal of perfection, and admittedly only a relatively small limited of previous code, I believe it's enough of an advance over the previous generation of ASDF that I'd like to get it out to the world. The code has been extensively cleaned up while preserving previous semantics everywhere that it was well-defined. Our testing has revealed no regressions from ASDF 1. What has changed since ASDF 1 is documented at the following page: http://common-lisp.net/project/asdf/asdf/FAQ.html Improvements include: * portable naming of files wrt directory, type, host/device, etc. * a builtin user-configurable output translation mechanism, superseding asdf-binary-locations and previous hacks in common-lisp-controller and cl-launch. * a user-configurable source registry system for finding systems (the old *central-registry* is still available). * improved portability to many implementations. * improved support for Windows. * many bug fixes * better documentation * the test suite, while still largely incomplete, covers more cases and is more robust across implementations. * substantial performance improvements when processing large systems with thousands of components. * API improvements: load-system, system-relative-pathname, etc. * a sensible versioning system for ASDF 2 itself. * ASDF can be now be upgraded in a running lisp image. Using this in-place upgrade, ASDF releases can be decoupled from implementation releases. * better support for various extensions used by ECL and ABCL, and also by POIU, ASDF-DEPENDENCY-GROVEL. Pitfalls include: * Output translations is enabled by default. This may surprise some users, most of them in pleasant way (we hope), a few of them in an unpleasant way. It is trivial to disable output translations. Simply put (ASDF:DISABLE-OUTPUT-TRANSLATIONS) in a Lisp startup file. * Some systems in the large have been known not to play well with asdf output translations. They were easy to fix. The most likely issue is to have chaining of operations (e.g., a preprocessing before a load) where the INPUT-FILES of one operation are related to the OUTPUT-FILES of another. In this case many issues can be avoided by simply making the OUTPUT-FILES primary, and having later operations' INPUT-FILES be defined in terms of the OUTPUT-FILES of other operations instead of directly defining the INPUT-FILES. It is also easy to disable output translations or override its configuration. * ASDF 2 output translations do not work with ASDF-Binary-Locations. They replace A-B-L, and include a compatibility mode to emulate your previous A-B-L configuration. See ENABLE-ASDF-BINARY-LOCATIONS-COMPATIBILITY. But you shouldn't load ABL on top of ASDF 2. * A notable performance bug on SBCL (and possibly other implementations, too): the recursive search of configured paths in your source-registry with (DIRECTORY "/configured/path/**/*.asd") can waste a few seconds when initially searching for asd files (depending on your configuration). If it is essential for you to avoid this pause, you should override the default source-registry and only use non-recursive :DIRECTORY options (or shallow trees). Or just keep the default directory hierarchies being searched empty. * Windows support may have been insufficiently well tested. As to how to best include ASDF in your implementation, here is an excerpt from the FAQ section of our manual: 12.3.2 "I'm a Common Lisp implementation vendor. When and how should I upgrade ASDF?" Starting with current candidate releases of ASDF 2, it should always be a good time to upgrade to a recent version of ASDF. You may consult with the maintainer for which specific version they recommend, but the latest RELEASE should be correct. We trust you to thoroughly test it with your implementation before you release it. If there are any issues with the current release, it's a bug that you should report upstream and that we will fix ASAP. In order to report bugs, please use the launchpad bug tracker. Information about launchpad is contained in the manual. As to how to include ASDF, we recommend the following: * If ASDF isn't installed yet, then (require :asdf) should load the version of ASDF that is bundled with your system. You may have it load some other version configured by the user, if you allow such configuration. * If your system provides a mechanism to hook into CL:REQUIRE, then it would be nice to add ASDF to this hook the same way that SBCL, ECL, CMUCL, CCL and ABCL do. * You may, like SBCL, have ASDF be implicitly used to require systems that are bundled with your Lisp distribution. If you do have a few magic systems that come with your implementation in a precompiled way such that one should only use the binary version that goes with your distribution, like SBCL does, then you should add them in the beginning of wrapping-source-registry. Please consult with the ASDF maintainers about that. * If you have magic systems as above, then we explicitly ask you to NOT distribute asdf.asd as part of those magic systems. You should still include the file asdf.lisp in your source distribution and precompile it in your binary distribution, but asdf.asd if included at all, should be secluded from the magic systems, in a separate file hierarchy, or you may otherwise rename the system and its file to e.g. asdf-ecl and asdf-ecl.asd, or sb-asdf and sb-asdf.asd. If you make asdf.asd a magic system, then users will no longer be able to upgrade ASDF using ASDF itself. It is helpful to be able to do this in order for users to be able to use an ASDF version of their own choosing that they maintain independently from your Lisp distribution. * If you do not have any such magic systems, or have other non-magic systems that you want to bundle with your implementation, then you may add them to the default-source-registry, and you are welcome to include asdf.asd amongst them. * Please send us upstream any patches you make to ASDF itself, so we can merge them back in for the benefit of your users when they upgrade to the upstream version. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Chuangtse and Hueitse had strolled onto the bridge over the Hao, when the former observed, ``See how the small fish are darting about! That is the happiness of the fish.'' ``You are not a fish yourself,'' said Hueitse. ``How can you know the happiness of the fish?'' ``And you not being I,'' retorted Chuangtse, ``how can you know that I do not know?'' — Chuangtse, circa 300 B.C.

1 0

[asdf-devel] question about relative pathname to point to parent directory
by Robert Goldman 26 May '10

26 May '10

What's the right syntax for specifying a relative pathname for a module whose files should live in the parent directory instead of in a subdirectory? E.g., if I have (:module foo :components ((:file "bar") (:file "baz")) :pathname ???? ) what goes in there if I do NOT want the files to live in foo/, but with all the other files? I could put a FAQ about this in the manual... best, r

2 6

[asdf-devel] Question about pathnames discussion in the manual
by Robert Goldman 26 May '10

26 May '10

Currently, the manual's discussion about logical pathnames states: "Moreover, the `asdf-output-translation' layer will avoid trying to resolve and translate logical-pathnames, so you can define yourself what translations you want to use with the logical pathname facility." IIUC, since a-o-t does not handle logical pathnames, it's not so much that you /can/ define the translations you want to use with the l-p facility as that you /must/ define the translations, or your binaries will go untranslated. Do I understand this correctly? If so, any objection to my strengthening the wording here? I am making some minor tweaks to this section, which I was just in because I was on irc the other day helping Stellian and Raymond with some pathname issues in ASDF 2 compatibility. Best, r

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel