asdf-devel November 2015

asdf-devel@common-lisp.net

13 participants
16 discussions

What's the right way to extend ASDF with new symbols?
by Robert Goldman 16 Feb '16

16 Feb '16

Commonly, one wants to extend ASDF with new operation and component classes. But the support in ASDF for referencing such classes all involves automagically interpreting keyword symbols (and some unqualified symbols?) in the ASDF package. If I understand this correctly, this leaves the ASDF extender with the alternatives of either jamming their new symbols into the ASDF package late, and exporting them, or having them live in a new package, which is cleaner, but relegates these new components to second-class status. Consider the following (defpackage my-system-def (:use common-lisp asdf)) (in-package :my-system-def) (defsystem my-system :defsystem-depends-on ("my-asdf-extension") :components ((:my-new-file "file1"))) I don't seem to be able to define MY-NEW-FILE in my-asdf-extension and export it into my-system-def, because my-system-def is already defined by the time my-asdf-extension is loaded. That means I pretty much have to either muck around in the ASDF package (which doesn't scale to multiple different people extending ASDF) or use side effects: (asdf:load-system "my-asdf-extension") (defpackage my-system-def (:use common-lisp asdf my-asdf-extension)) (in-package :my-system-def) (defsystem my-system :components ((:my-new-file "file1"))) Am I right about this? If I am, is there some way to better handle this? Or do we need to rethink how :defsystem-depends-on works?

7 24

Removing load-sysdef
by Stelian Ionescu 28 Nov '15

28 Nov '15

... broke SLIME's contrib/swank-asdf.lisp -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.

2 1

[Q] figuring out a system / source file
by Didier Verna 24 Nov '15

24 Nov '15

Hello, starting from a file currently being processed (as per either *compile-file-truename* or *load-truename*), how can I retrieve the ASDF system currently being processed, and ultimately, the corresponding source file component (when *load-truename* returns a fasl) ? Thanks. -- My new Jazz CD entitled "Roots and Leaves" is out! Check it out: http://didierverna.com/records/roots-and-leaves.php Lisp, Jazz, Aïkido: http://www.didierverna.info

3 3

UIOP feature idea...
by Robert Goldman 23 Nov '15

23 Nov '15

What about adding a better FILE-LENGTH function to UIOP? I was looking at Peter Seibel's discussion of FILE-LENGTH in PCL. PiTA, and certainly unsuitable for use if one wants to write scripts in CL. What about making UIOP:FILE-LENGTH be generic and take either strings (filenames), pathnames, or streams as argument? cheers, r

3 2

Re: Suggestions for procedure going forward
by Jason Miller 20 Nov '15

20 Nov '15

> Date: Wed, 18 Nov 2015 23:55:29 -0600 > From: Robert Goldman <rpgoldman(a)sift.net> > To: Steven N??ez <steven.nunez(a)illation.com> > Cc: ASDF-devel <asdf-devel(a)common-lisp.net> > Subject: Re: Suggestions for procedure going forward > Message-ID: <564D6451.1080106(a)sift.net> > Content-Type: text/plain; charset=utf-8 On Wed, 18 Nov 2015 23:55:29 -0600 Robert Goldman said... > On 11/18/15 Nov 18 -11:33 PM, Steven N??ez wrote: > > With git you can, and usually do, have many branches, including personal ones. The pull request will be against a specific branch. I only read this message of the thread, so hope I'm answering the right question. Github has some good tutorials. > > Well the question isn't really about having many branches. The question > is what happens when you have stable and development branches, and you > want to "jump" the stable branch to mark retiring an old stable version > and starting a new one? Doesn't that involve a nasty merge or rebase? > > I can do some research, but I was hoping someone knew the answer.... I know the answer. As long as all merges go in the same direction there are little to no merge issues when you jump master to be develop. There are two major schools of thought on this. One is documented with "man 7 gitworkflows" and the other is discussed here: http://nvie.com/posts/a-successful-git-branching-model/ Since they use slightly different terminology, I'll use a theoretical repository with two branches named "stable" and "testing" in this repository a release happens when "testing" is merged back to "stable" and, aside from that, only bug fixes go into "stable"; I'll also use the terms "newer" and "older" to mean release order, so if you had a "previous-release" "current-release" "next-release" and "unstable" or some-such way of branching, that's the order from oldest to newest. They both share a single common feature: All new commits are based off of the oldest branch they might be merged into (so new features start off of the test branch, and bug fixes start off of the stable branch). If you change your mind (e.g. "this change is too risky for stable" or: "this new feature fixes a serious bug, it should go into stable too") then you rebase to the correct branch before doing a PR. The most important part is that these changes somehow get merged into the branche it was based off of and every single newer branch that might ever get merged back. With the "stable" and "testing" example this means all changes to stable must also be merged into testing. This way when it's time to merge your testing branch to your stable branch, testing is a superset of stable and a merge is guaranteed to succeed with no conflicts. -Jason

1 0

Re: Suggestions for procedure going forward
by Robert Goldman 19 Nov '15

19 Nov '15

On 11/18/15 Nov 18 -11:33 PM, Steven Núñez wrote: > With git you can, and usually do, have many branches, including personal ones. The pull request will be against a specific branch. I only read this message of the thread, so hope I'm answering the right question. Github has some good tutorials. Well the question isn't really about having many branches. The question is what happens when you have stable and development branches, and you want to "jump" the stable branch to mark retiring an old stable version and starting a new one? Doesn't that involve a nasty merge or rebase? I can do some research, but I was hoping someone knew the answer.... > > -----Original Message----- > From: asdf-devel [mailto:asdf-devel-bounces@common-lisp.net] On Behalf Of Robert Goldman > Sent: 18 November, 2015 21:17 > To: asdf-devel(a)common-lisp.net > Subject: Re: Suggestions for procedure going forward > > On 11/18/15 Nov 18 -8:35 PM, Faré wrote: >> Yeah, there's an awkward merge or rebase happening when "stable" jumps >> from 3.1 to 3.2, whereas no such jump happens if old branches have >> numbered names and are forked off a master that keeps going forward. >> > > Surely git must have a solution to this problem? There must be a ton of projects that need to have a "stable" and a "development" branch. So this must arise all over the place.... > > Anyone know? >

4 4

Suggestions for procedure going forward
by Robert Goldman 19 Nov '15

19 Nov '15

We have had a number of ASDF 3 releases that have mostly been aimed at bug-fixing (although some new features have crept in). I'd like to declare ASDF 3 feature complete and done, but I don't want to close the door to future bug fix releases as needed, nor do I want to shove incomplete new features out in order to get bug fixes out. So I'd like to split ASDF development into stable and testing or something like that. Does anyone have experience doing that? If so, please post suggestions for process to ASDF-devel. Thanks! r

4 9

Finding depended-upon systems
by Robert Goldman 18 Nov '15

18 Nov '15

This seems like it might be a good FAQ, and we had some correspondence about a related query earlier. (sort (mapcar #'asdf:component-name (mapcar #'cdr (remove-if-not #'(lambda (x) (and (typep (cdr x) 'asdf/system:system) (typep (car x) 'asdf:load-op))) (asdf::traverse (make-instance 'asdf::load-op) (asdf:find-system "hunchentoot") :force :all)))) #'string-lessp) This requires knowing a bit about the internals of ASDF and relies on an obsoleted function (TRAVERSE). Maybe we should wrap this up and provide it as part of an ASDF query API? Cheers, r P.S. Sorry about the horrible word-wrapping...

5 10

a FIND-SYSTEM inconsistency which may be a bug
by Attila Lendvai 18 Nov '15

18 Nov '15

see here: https://gitlab.common-lisp.net/asdf/asdf/blob/master/find-system.lisp#L187 CLEANUP-SYSTEM-DEFINITION-SEARCH-FUNCTIONS attempts to remove SYSDEF-PRELOADED-SYSTEM-SEARCH from the hooks, but it is never added. and right under it, SEARCH-FOR-SYSTEM-DEFINITION also assumes that it's supposed to be called explicitly after the hooks. the reason it's relevant is that this way it's not possible to add a hook as a very last hook to be called (e.g. for quicklisp integration to initiate downloading if a system cannot be found anywhere). -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “To argue with a person who has renounced the use of reason is like administering medicine to the dead.” — Thomas Paine (1737–1809)

1 1

make-pathname* and Allegro
by Kevin Layer 17 Nov '15

17 Nov '15

We were debugging some problems with an internal system and happened to run across this: (defun make-pathname* (&rest keys &key (directory nil) host (device () #+allegro devicep) name type version defaults #+scl &allow-other-keys) "Takes arguments like CL:MAKE-PATHNAME in the CLHS, and tries hard to make a pathname that will actually behave as documented, despite the peculiarities of each implementation" ;; TODO: reimplement defaulting for MCL, whereby an explicit NIL should override the defaults. (declare (ignorable host device directory name type version defaults)) (apply 'make-pathname (append #+allegro (when (and devicep (null device)) `(:device :unspecific)) keys))) which is kind of curious, adding :device :unspecific only for Allegro. Tracking it down to see if there were comments in the commit that added the change yielded nothing: commit 1e4bafdbd4200d3a19722699d6a332316b082b2b Author: Francois-Rene Rideau <tunes(a)google.com> Date: Wed Feb 6 04:23:13 2013 +0100 2.28.1: various upgrade issues 1- To make life easier on Xach, stop requiring asdf.lisp to be loaded as source before it's compiled. Instead, wrap each and every single form in an eval-when, most of the time via the with-upgradability macro that also transforms defun into defun* and defgeneric into defgeneric*. Causes massive reindentation :-( 2- Have a proper :version for fallback systems. Will make systems that check the version happier. 3- protect a condition with #+sb-eval. Fixes lp#1116408. 4- Protect warnings-file methods with dynamic when *warnings-file-type* rather than static #+. Does anyone know why this change was made and what problem it fixed? Thanks. Kevin

2 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel November 2015