asdf-devel April 2015

asdf-devel@common-lisp.net

54 participants
184 discussions

[asdf-devel] (asdf:build 'foo)
by Faré 08 Apr '15

08 Apr '15

While we are bikeshedding, I feel that asdf:load-system is (1) still too long a name, and (2) not generic enough, in case I want to use ASDF for stuff that isn't loading code into the current image. Therefore I propose there be (asdf:build 'foo) as the shorthand for the new (as of ASDF3) operation build-op: (defun build (system) (operate 'build-op system)) Shorter to type, more generic, and if we commit that before 3.1.1, available under the #+asdf3.1 feature. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Your conscience never stops you from doing anything. It just stops you from enjoying it.

2 4

Re: [asdf-devel] Possible problem with check-compile-results
by Faré 08 Apr '15

08 Apr '15

You'd have to post the stack trace for us to tell. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org On Sat, Aug 24, 2013 at 5:02 PM, Robert Goldman <rpgoldman(a)sift.net> wrote: > Yes, the underlying problem was a version skew. But I was wondering if this problem tickled a problem in the way that ASDF (UIOP) bundles up errors and re-signals them. > > Best, > r >

1 0

Re: [asdf-devel] 3.1.0.75 pushed: more checking of system names
by Robert P. Goldman 08 Apr '15

08 Apr '15

james anderson wrote: > >> My main concern is that ASDF behave understandably for all users, and >> errors about illegal pathnames appearing deep in the call tree, away >> from the reason for their occurrence, won't meet that requirement. >> >> This seems like another case where trying to be nice, instead of being >> strict, leads us to a place where *someone* must lose. If ASDF 1 had >> either refused logical pathnames, or refused inconsistent module >> names, we wouldn't be in this pickle... > > to pose a somewhat rhetorical question, why are module names necessarily > incorporated into logical pathnames? > Treating your question as literal, rather than rhetorical: If the system search path contains directories specified as logical pathnames, then when we try too find <foo.asd> we must merge <foo.asd> into the logical pathname. If, unfortunately, instead of "foo" we have "cl+ssl" or "foo_bar" the results are undefined. Actually, that's probably too kind. I think in fact the results *are* defined, and they are erroneous. the grammar of logical pathnames specifically excludes the use of symbols such as "+" and "_". If we have "fOo" and "foo" as systems, we may have collisions, since logical pathnames and some other filesystems cannot distinguish "foo.asd" from "fOo.asd". Faré reminds us that this also arises if we have (defsystem foo :components (:module "my_funky_module" :components ...) ...) where the system name is compatible with logical pathnames, but the module name is not. :pathname initargs provide another challenge.

1 0

[asdf-devel] Further customization of output translations
by Stelian Ionescu 08 Apr '15

08 Apr '15

How would I go about including the git branch in the output directory name ? -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib

3 2

[asdf-devel] current failures for CCL Windows and SBCL Windows
by Dave Cooper 08 Apr '15

08 Apr '15

Here are the output text files for these platforms, currently: SBCL: https://www.dropbox.com/s/lky1wlz0o1ku7qt/sbcl.text CCL: https://www.dropbox.com/s/ptoor8nepik85by/ccl.text What else should I be testing for Windows?

1 0

[asdf-devel] 3.0.2.7 follows hot on the heels of 3.0.2.6
by Robert P. Goldman 08 Apr '15

08 Apr '15

Faré points out that /usr/bin/env can only be used on Unix.... Patch pushed!

1 0

[asdf-devel] Are there nightly builds for trunk sources? (was: Re: CCL Windows: output from ccl:fasl-concatenate is "not a FASL file")
by Genworks Support 08 Apr '15

08 Apr '15

So this has been fixed (almost immediately after I opened the Trac ticket http://trac.clozure.com/ccl/ticket/1109!) in the trunk in: http://trac.clozure.com/ccl/changeset/15892 Now I am wondering how often the binaries (e.g. wx86cl.exe) in http://svn.clozure.com/publicsvn/openmcl/trunk/windows/ccl get rebuilt? Is there a nightly build so that I can simply do an svn update on this, or is it time to get set up with gcc on Windows and perform the Windows build of the trunk myself, in order to test this? Regards, Dave On Wed, Sep 4, 2013 at 4:36 PM, Dave Cooper <david.cooper(a)genworks.com>wrote: > > So I'm trying to get the ASDF test suite running on Windows, and tracked > this down as one of the failures for CCL (32-bit and 64-bit). (there were 5 > failures out of 47 tests, I haven't looked at the rest yet). > > This can be replicated as follows (with files from > > https://www.dropbox.com/sh/jc2cqwpkp06dupm/7lgyRUdwZ5/cl/tests/simple > ): > > > [below, substitute ".../'" for your actual path to the test files]: > > > > (lisp-implementation-version) > "Version 1.9-r15765 (WindowsX8664)" > > > (compile-file ".../try1") > > > (compile-file ".../try2") > > > (ccl:fasl-concatenate ".../try.wx64fsl" (list ".../try1.wx64fsl" > ".../try2.wx64fsl")) > > > (load ".../try.wx64fsl") > > ERROR: Not a FASL file. > > > Does anyone recognize what might be going on? > > > -- > My Best, > > Dave Cooper, Genworks Support > david.cooper(a)genworks.com, dave.genworks.com(skype) > USA: 248-327-3253(o), 1-248-330-2979(mobile) > UK: 0191 645 1699 > -- My Best, Dave Cooper, Genworks Support david.cooper(a)genworks.com, dave.genworks.com(skype) USA: 248-327-3253(o), 1-248-330-2979(mobile) UK: 0191 645 1699

1 0

[asdf-devel] Quick question about the bundle op
by Robert P. Goldman 08 Apr '15

08 Apr '15

I see that the BUNDLE-PATHNAME-TYPE for :dll is "so" on all unixes. Question: should this be "dylib" on Mac OS X instead? Thanks, r

2 1

[asdf-devel] Checking system names...... NOT
by Robert P. Goldman 08 Apr '15

08 Apr '15

Faré and James Anderson have convinced me I'm tilting at windmills here. I am in the process of reverting the checks and testing the results to make sure that I haven't messed up in the reversion process. Look for a 3.1.0.76 as soon as I'm sure the tests all pass. Bloodied, but unbowed, R

1 0

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

08 Apr '15

On Wed, 12 Mar 2014, Faré wrote: > 1- I think we should proceed and add a default path anyway. > ~/cl/ and/or ~/common-lisp/ sound fine to me, and I've seen no one > complain about that. > You could make it ~/local/common-lisp/ if you're into larger paths. The computer I'm currently on uses ~/lisp for a lot of non-ASDF-related systems, including numerous files that are not source code. On some other systems, I use paths like ~/cl to distinguish from ~/racket and other dialects. I agree with others who dislike this idea. ASDF will inflict significant end-user pain for little benefit if it chooses to do a land grab on an obvious directory name. In my opinion, a lot of the complexity in ASDF, and a lot the motivation for this proposal, stems from ASDF's conflation of the "loader" with the "build system". That's the topic for another post... - Daniel

1 0

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