asdf-devel June 2010

asdf-devel@common-lisp.net

9 participants
16 discussions

[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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel June 2010