asdf-devel

asdf-devel@common-lisp.net

5 participants
1375 discussions

Re: [asdf-devel] has ":depends-on ((:version ...))" semantics changed?
by Anton Vodonosov 08 Apr '15

08 Apr '15

18.11.2013, 08:02, "Robert P. Goldman" <rpgoldman(a)sift.info>: > Anton Vodonosov wrote: > >> 18.11.2013, 07:50, "Robert P. Goldman" <rpgoldman(a)sift.info>: >>> Are you saying now that version 1.0.0 of Closer-MOP will satisfy the >>> requirement of 0.55, and that Anton should *not* be having this build >>> failure. >> Robert, build failures happen on older ASDF, and not happen on newer ASDF. > > Well this certainly was not an ASDF change I was consulted about or approved of. It has happened right before ASDF maintenance was transferred to you, maybe even during the transition. See the mailing thread mentioned by Xach: http://thread.gmane.org/gmane.lisp.asdf.devel/3062/focus=3066 >From this thread I understand that ASDF uses the same version-satisfies for determining compatibility between ASDF versions, and for determining if an ASDF system satisfies the :depends-on ((:version ...)).

1 2

[asdf-devel] :DBG
by Faré 08 Apr '15

08 Apr '15

In ASDF 3.1.0.14, I introduced a macro :DBG (in uiop/utility.lisp). Yes, it's in the keyword package. Why? Because it's the one and only macro I want to be accessible from everywhere without a prefix, yet without modifying existing defpackage forms to make it accessible — because it's only used temporarily for debugging. :DBG is a macro for print-debugging. The syntax is (:DBG tag forms... last-form) The semantics is that if tag is true, print the tag, then for each form, write its source and its values; return the values of the last form. If tag is false, just evaluate the last form and return its values. (Tag is typically a constant keyword or string, identifying the point where values are printed.) The expansion is rather space and time efficient, as far as the semantics permit. I find :DBG soooo useful for print-debugging. I've seen tens of variants of it, but every time with something not quite right in the syntax, semantics or implementation. I just wanted one variant that got everything right, and make it ubiquitous. Because when you need it, you need it now, and there's no time to modify things to load an additional library. And when you're done, you want minimal cleanup, too: just delete the form, except maybe keep the last subform. Previously, I was using (uiop:uiop-debug) from uiop/utility which allows you to load a magic file of your choice that defines a debug mode. The default one I provided was mine, which define :DBG as DBG in your current package (thereby avoiding symbol import issues). But that still adds a new definition everytime and an extra line or form to cleanup. I was recently convinced that using the keyword package instead makes perfect sense: on the one hand, that's using a shared namespace that it is polite to not pollute, but on the other hand, such a temporary print-debugging macro the only use case I imagine of otherwise wanting something to be immediately accessible without package prefixing yet without modifying the package definition form. It's still time to remove that macro before the next release, but I believe it's the right thing to include it, and maybe some of you will agree with me and start using it, if not from the yet unrelease ASDF 3.1.1, perhaps from a copy in your .sbclrc. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The common argument that crime is caused by poverty is a kind of slander on the poor. — H. L. Mencken

12 19

All tests passing for ASDF 3.0.2.32 on my installed platforms (was: Re: [asdf-devel] Fwd: ASDF testing for LWW)
by Dave Cooper 08 Apr '15

08 Apr '15

On Sun, Oct 20, 2013 at 9:37 PM, Faré <fahree(a)gmail.com> wrote: > > So... is there any obstacle left to release? > > All 48 ASDF test-suite tests are passing for me on ASDF 3.0.2.32 on all platforms which i'm currently testing, which consist of: Linux: allegro allegro8 allegromodern allegromodern8 ccl sbcl Mac: ccl lispworks sbcl Windows: allegro allegro8 allegromodern allegromodern8 ccl-1.10-dev sbcl I think this is also true now even when the build/ directory is not cleared before every test run (but still with separate test directories for each OS). I'll confirm this and report by tomorrow morning if this turns out not to be true. -- My Best, Dave Cooper, Genworks Support david.cooper(a)genworks.com, dave.genworks.com(skype)

1 1

[asdf-devel] keeping versioning information externally
by Anton Vodonosov 08 Apr '15

08 Apr '15

I want to highlight another tool to deal with versioning. 19.11.2013, 23:41, "Robert P. Goldman" <rpgoldman(a)sift.info>: > two versions of the same library on the same machine is quite feasible, > and indeed I do this myself, every day. I have different > source trees for different projects, and with each source tree > is associated a different ASDF configuration. > > This is not a futuristic "wouldn't it be nice if..." situation, either: > it's a simple requirement of my daily work environment. E.g., I have > projects that rely on different versions of FiveAM (they are hosted > differently, so it's not just a matter of demanding that everyone > upgrade -- some I run, some I don't). I did that too. I had a config file vermap.lisp which puts directories of the libary versions I need to ASDF central registry. So, when we say :depends-on (#:fiveam) we have an external configuration which specifies then exact version of fiveam to be loaded. The external configuration is a flat mapping: (:name :chunga :ver "0.4.3") (:name :cl-base64 :ver "3.3.2") (:name :cl-cont :ver "0.3.4") (:name :cl-containers :ver "0.9.10") (:name :cl-fad :ver "0.6.2") (:name :cl-html-parse :ver "1.0") I called such a mapping a "vermap" or a "libworld". I used different vermaps for different applications. And Quicklisp uses this approach. Quicklisp dist version is a collection of releases, it specifies what exact release of fiveam is used by asdf:load-op "fiveam". This approach is different from the case where each libary author specifies constrains for the library dependencies, and the library loader tries to find some versions which satisfy the constrains. With the exact mapping we have a reproducible configuration. For example, my application startup script does (require-quicklisp :version "2013-01-28"), so that when the application is deployed on server, it works with exactly same library versions as it was tested on the development machine. Developers can collaborate to assemble library version and share vermaps which are consistent and tested to work well together. They can be shared inside a company, or globally, like Quicklisp does. Best regards, - Anton

3 2

[asdf-devel] Make the CL syntax predictable
by Faré 08 Apr '15

08 Apr '15

Dear Anton, can you (1) run cl-test-grid on all implementations with 3.1.0.94, our release candidate? can you run the cl-test-grid on at least SBCL with the latest ASDF and the attached patch? In writing my article "ASDF3, or Why Lisp is Now an Acceptable Scripting Language", one of the limitations I list is the mess of uncontrollable syntax. This would fix it... but might break dirty files that side-effect the current syntax without first creating and using a new readtable. Breaking these files is actually desired, but we need to check how large is the issue before we do it (if we do). I figure that, like any other potentially disruptive change, it is best done just before a release that defines a new features, in this case, #+asdf3.1 Of course, I won't commit any such thing to master without maintainer approval. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Ontogeny recapitulates phylogeny. — Ernst Haeckel

13 89

[asdf-devel] Re: My current coverage of CL platforms for ASDF and cl-test-grid testing
by Robert P. Goldman 08 Apr '15

08 Apr '15

Genworks Support wrote: > > Dear All, > > For reference I've attached our current ASDF toplevel test script, which > contains our current list of CL implementations, in case you want to > look for volunteers to fill the gaps for the combinations we are missing. > > I think the major commercial implementations which are missing are: > > LispWorks Windows > LispWorks Linux > Allegro MacOS > Scieneer CL > Genera > Any commercial Unices. > Anything for Android, iOS, Raspberry Pi, ARM, etc. I am testing Allegro on Mac OS and LispWorks on Linux. Best, r

1 0

[asdf-devel] bundle-test is failing on both ECL and ABCL for me on Mac OS X Lion
by Robert Goldman 08 Apr '15

08 Apr '15

It may be that there is some configuration that is missing on my laptop for correctly using these, but I would like to be confident that the current ASDF is not broken on these implementations. Also, if there is special configuration required for these bundle tasks, I would prefer that we check for it, instead of providing busted functionality. I have put bugs for these on the ASDF launchpad tracker. Input would be welcome. Best, r

1 0

[asdf-devel] Loading an .asd file directly using its pathname
by Luís Oliveira 08 Apr '15

08 Apr '15

Hello, Given a pathname to an .asd file, I sometimes load it using this hack: (defun load-asd (path &rest options) (let ((asdf:*system-definition-search-functions* (cons (lambda (system) (when (string= (asdf::coerce-name system) (pathname-name path)) path)) asdf:*system-definition-search-functions*))) (apply #'asdf:load-system (pathname-name path) options))) Other times I use: (let ((asdf:*central-registry* (cons <directory-where-my-asd-lives> asdf:*central-registry*))) (asdf:load-system :some-system)) Also, I see that the slime-asdf contrib uses this definition: (defun load-asd (pathname &key name &allow-other-keys) (asdf::load-sysdef (or name (string-downcase (pathname-name pathname))) pathname)) I wonder if ASDF could export LOAD-SYSDEF or perhaps have ASDF:LOAD-SYSTEM accept a pathname in addition to what it currently accepts. Cheers, -- Luís Oliveira http://kerno.org/~luis/

5 9

[asdf-devel] cl-launch 4.0.0
by Faré 08 Apr '15

08 Apr '15

Dear lispers, I've just released cl-launch 4.0.0: so you can invoke CL programs from the command-line. My classic demo for cl-launch is as follows: for l in allegro ccl clisp sbcl ecl lispworks abcl cmucl xcl gcl ; do cl-launch -l $l -i '(format t "'$l' ~S ~%" `#5(1 ,@`(2 3)))' 2>&1 | grep "^$l " ; done As compared to the cl-launch 3 series, cl-launch 4.0.0: * cl-launch now accepts Unix scripting language invocation: cl-launch [options...] script [arguments...] * Therefore cl-launch can be used as a script interpreter: #!/usr/bin/cl No more need for -X ... -- options anymore (still kept for compatibility). * cl-launch has a more unrestricted model for building software, more like buildapp, executing build commands in sequence, rather than having a fixed skeleton of one file then one system. cl --lisp sbcl --require sb-posix --system foo --file file.lisp --eval '(some form)' --output myscript.sh cl --lisp sbcl --require sb-posix --system foo --file file.lisp --eval '(some form)' --output mybinary --dump '!' * cl-launch accepts --eval --load --load-system --entry like buildapp, in addition to its own --restart --init --print --write, etc. * cl-launch accepts an argument starting with an open parenthesis in any position as if it were following a --print. * cl-launch can now use quicklisp * cl-launch was tweaked to work better on ABCL, GCL, ECL cl-launch 4 is thus mostly compatible with cl-launch 3 and earlier, but: * it requires asdf 3.0.1 or later to be provided by your implementation, configured to be found by an earlier asdf provided by your implementation, or in ~/cl/asdf/ or /usr/share/common-lisp/source/cl-asdf/ * cl-launch used to have a more constrained model for building software with only one --file and one --system; if you were relying on that and/or on putting the --file after the --system, you will suffer from the incompatibility. PS: there is already a 4.0.0.1 for LispWorks, which requires a patch just pushed to ASDF 3.1.0.78. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Wealth, like happiness, is never attained when sought after directly. It comes as a by-product of providing a useful service. — Henry Ford

1 0

[asdf-devel] Problems with asdf:load-system :force
by Stelian Ionescu 08 Apr '15

08 Apr '15

While working on the test suite of swap-bytes on SBCL(you'll need >=1.1.6 I think), I noticed two unexpected results in using :force : 1) (asdf:load-system :swap-bytes/test :force t) does not recurse into :defsystem-depends-on deps. Is this intentional ? 2) (asdf:load-system :swap-bytes/test :force '(:swap-bytes/test)) needlessly compiles files from :swap-bytes on which it depends. I've attached a log that traces PERFORM and COMPUTE-ACTION-STAMP and shows that two files from :swap-bytes get recompiled even though they haven't changed. I'm wondering if the problem lay with the ASDF extension in Madeira-port, but that's so simple I can't find any obvious fault. Ideas ? If you want to test for yourselves clone https://github.com/sionescu/madeira-port.git and https://github.com/sionescu/swap-bytes.git -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib

2 12

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel