asdf-devel

asdf-devel@common-lisp.net

5 participants
1375 discussions

Re: PATCH: SIGNAL a condition on test failures, for use with ASDF:TEST-SYSTEM
by Robert Goldman 16 Sep '19

16 Sep '19

Vladimir -- maybe compare this suggestion with what is in the fiveam-asdf contrib in the ASDF repo? Also (and we should probably move this to ASDF-DEVEL) it would be good to have *all* of the tests run to completion even if one or more fail by default, and have the option to exit after the first failure. This could be done by having an `ASDF-SINGLE-TEST-FAILURE` and an `ASDF-TEST-FAILURE` and raising the first at each failure, but by default trapping them and bundling them into the `ASDF-TEST-FAILURE` condition. It might make sense to bundle FiveAM's test report *into* the `ASDF-TEST-FAILURE` (or subclass thereof), so that it can be printed at an appropriate time. On 14 Sep 2019, at 20:48, Vladimir Sedach wrote: > Hello! > > I have a proposed patch to FiveAM on GitHub: > https://github.com/sionescu/fiveam/pull/58 > > I recently wrote a script to run FiveAM tests for one of my > libraries on many different implementations on your own machine: > https://gitlab.common-lisp.net/uri-template/uri-template2/blob/master/run-t… > > I do not want to copy-paste that script for all of my libraries. It > would be nice to contribute a generalized version of the script to > Roswell (on which the script is based), and just be able to say "ros > test my-system in all installed implementations" for any system. > > The first step to doing that is to get ASDF:TEST-SYSTEM to report > errors using a common interface. > > Because of the way ASDF is designed, ASDF:TEST-SYSTEM needs to use > conditions to signal test failures. I like this idea. Since you do > not have to handle conditions raised by SIGNAL, the functionality can > be added without impacting existing use or interfaces of FiveAM (the > use of WARNING instead of ERROR as the parent condition of > TEST-SPEC-FAILURE also ensures this, as many people tend to abuse > HANDLER-CASE to indiscriminately catch ERRORs). > > With this patch, all projects that use FiveAM and define ASDF test-op > should be testable from a generic version of the Roswell script > without any changes. > > The basic mechanism for test automation with FiveAM is then very > simple: > > (handler-case (asdf:test-system "system") > (fiveam:test-spec-failure (condition) > (princ condition uiop:*stderr*) > (uiop:quit 1))) > > Other test libraries can have supported added as well: > > (handler-case (asdf:test-system "system") > ((or fiveam:test-spec-failure prove:test-failure) (condition) > (princ condition uiop:*stderr*) > (uiop:quit 1))) > > The goal is to introduce a parent condition in ASDF that FiveAM, etc., > will then inherit from: > > (handler-case (asdf:test-system "system") > (asdf:test-failure (condition) > (princ condition uiop:*stderr*) > (uiop:quit 1))) > > Ultimately, any system using any test library should be testable this > way, ensuring that test automation becomes trivial to build. > > I am going to propose adding the parent condition to ASDF, but in the > meantime (until the ASDF patch makes it to the repository, another > release comes out, release becomes widely available…), I would like > to get this code into FiveAM. > > Vladimir

4 5

trouble with upgrade of asdf and versions
by adam 06 Sep '19

06 Sep '19

In attempting to upgrade ASDF, I have broken its operation. This work-around has not been helpful. https://stackoverflow.com/q/45043190/8770050 Here is the problem, (and Quicklisp seems to be working OK) CL-USER> (ql:quickload :quickproject) ; Evaluation aborted on #<ASDF-2.26:LOAD-SYSTEM-DEFINITION-ERROR #x213E199E>. CL-USER> (asdf:asdf-version) "3.3.2" CL-USER> *features* (:SWANK :ASDF3.3 :ASDF3.2 :ASDF3.1 :ASDF3 :OS-UNIX :QUICKLISP :ASDF2 :ASDF-UNICODE :CM :SAL :METACLASSES :ASDF :READLINE :REGEXP :SYSCALLS :I18N :LOOP :COMPILER :CLOS :MOP :CLISP :ANSI-CL :COMMON-LISP :LISP=CL :INTERPRETER :SOCKETS :GENERIC-STREAMS :LOGICAL-PATHNAMES :SCREEN :FFI :GETTEXT :UNICODE :BASE-CHAR=CHARACTER :PC386 :UNIX) My Lisp and Emacs versions, on Ubuntu 16.04, are $ clisp --version GNU CLISP 2.49 (2010-07-07) (built on allspice.buildd [127.0.1.1]) Emacs version GNU Emacs 24.5.1 (i686-pc-linux-gnu, GTK+ Version 3.18.9) of 2017-09-21 on lgw01-amd64- 050, modified by Debian Any suggestions on repairing or upgrading my ASDF, gratefully received.

5 9

slime meta-dot in ASDF sources
by Mark H. David 19 Jul '19

19 Jul '19

How do ASDF developers using emacs with SLIME deal with doing meta-dot (meta-.) on function names in ASDF sources. Out of the box, mostly when I meta-. just goes to one big top-level form that starts like this (with-upgradability () (define-condition invalid-source-registry (invalid-configuration warning) Thanks for clues, -Mark

2 2

uiop:directory-files doesn't behave on paths without a trailing slash
by Neil Lindquist 26 Jun '19

26 Jun '19

Hello, I recently noticed that uiop's DIRECTORY-FILES does not ensure that the path is always interpreted as a directory. On sbcl (and presumably other implementations), if the path does not have a trailing slash, the files in the parent directory are instead returned. This does not appear to be the indented behavior, given that SUBDIRECTORIES ensures that the path is a directory. A patch for this new behavior and current/proposed results are below. Neil Lindquist ## Patch ## --- a/uiop/filesystem.lisp +++ b/uiop/filesystem.lisp @@ -209,7 +209,7 @@ Subdirectories should NOT be returned. override the default at your own risk. DIRECTORY-FILES tries NOT to resolve symlinks if the implementation permits this, but the behavior in presence of symlinks is not portable. Use IOlib to handle such situations." - (let ((dir (pathname directory))) + (let ((dir (ensure-directory-pathname directory)))) (when (logical-pathname-p dir) ;; Because of the filtering we do below, ;; logical pathnames have restrictions on wild patterns. ## Current behavior ## CL-USER> (uiop:directory-files "doc") (#P"C:/Users/Neil/Documents/coding/lisp/asdf/uiop/README.md" #P"C:/Users/Neil/Documents/coding/lisp/asdf/uiop/asdf-driver.asd" #P"C:/Users/Neil/Documents/coding/lisp/asdf/uiop/backward-driver.lisp" #P"C:/Users/Neil/Documents/coding/lisp/asdf/uiop/common-lisp.lisp" #P"C:/Users/Neil/Documents/coding/lisp/asdf/uiop/configuration.lisp" #P"C:/Users/Neil/Documents/coding/lisp/asdf/uiop/driver.lisp" #P"C:/Users/Neil/Documents/coding/lisp/asdf/uiop/filesystem.lisp" #P"C:/Users/Neil/Documents/coding/lisp/asdf/uiop/image.lisp" #P"C:/Users/Neil/Documents/coding/lisp/asdf/uiop/launch-program.lisp" #P"C:/Users/Neil/Documents/coding/lisp/asdf/uiop/lisp-build.lisp" #P"C:/Users/Neil/Documents/coding/lisp/asdf/uiop/os.lisp" #P"C:/Users/Neil/Documents/coding/lisp/asdf/uiop/package.lisp" #P"C:/Users/Neil/Documents/coding/lisp/asdf/uiop/pathname.lisp" #P"C:/Users/Neil/Documents/coding/lisp/asdf/uiop/run-program.lisp" #P"C:/Users/Neil/Documents/coding/lisp/asdf/uiop/stream.lisp" #P"C:/Users/Neil/Documents/coding/lisp/asdf/uiop/uiop.asd" #P"C:/Users/Neil/Documents/coding/lisp/asdf/uiop/utility.lisp" #P"C:/Users/Neil/Documents/coding/lisp/asdf/uiop/version.lisp") ## Proposed Behavior ## COMMON-LISP-USER> (uiop:directory-files "doc") (#P"C:/Users/Neil/Documents/coding/lisp/asdf/uiop/doc/.gitignore" #P"C:/Users/Neil/Documents/coding/lisp/asdf/uiop/doc/Makefile" #P"C:/Users/Neil/Documents/coding/lisp/asdf/uiop/doc/docstrings.lisp" #P"C:/Users/Neil/Documents/coding/lisp/asdf/uiop/doc/template.texinfo")

4 7

What replaced the files contained in *systems-being-operated*
by Mirko Vukovic 05 Jun '19

05 Jun '19

Hello, I am hitting a bug when loading lisp-unit2 as it (still) depends on the depreciated variable *systems-being-operated* (I did submit a ticket <https://github.com/AccelerationNet/lisp-unit2/issues/10>, but it is as yet not addressed). So I am trying to fix it myself. The *system-being-operated* variable was replaced by the boolean *in-operate* in 7c3f979c <https://gitlab.common-lisp.net/asdf/asdf/commit/7c3f979c0db4ac5f224ca634ce9…> . *systems-being-operated* was a hash with a list of systems or NIL, while *in-operate* is a boolean (T or NIL). Does some other variable contain the information that *systems-being-operated* held? Thank you, Mirko

2 2

Re: asdf | Can't generate the documentation (#7)
by Hugo Ishimaru 16 May '19

16 May '19

Hi. Is it enough to begin the Makefile with `all' instead of `website'? Currently typing `make' leads to the deployment of docs. <---diff.patch begins---> diff --git a/uiop/doc/Makefile b/uiop/doc/Makefile index 265307b8..8b0ae952 100644 --- a/uiop/doc/Makefile +++ b/uiop/doc/Makefile @@ -10,11 +10,11 @@ webfiles = ${output} .PHONY: clean html pdf include clean-include clean-crap info doc texinfo website +all: pdf html info clean-crap + website: all rsync -lt --no-g ${webfiles} ${website} -all: pdf html info clean-crap - clean-include: rm -rf include <----diff.patch ends---> Regards, Hugo Ishimaru 2019年5月17日(金) 0:38 Pascal <gitlab(a)common-lisp.net>: > > When I type make in asdf/uiop/doc, the process fails like this: > > […] > > rsync -lt --no-g uiop.html uiop.pdf common-lisp.net:/project/asdf/public_html/ > > The authenticity of host 'common-lisp.net (148.251.248.130)' can't be established. > > ECDSA key fingerprint is SHA256:ztRL/T8tKsmjW1Ao6pvGcxg4o035wKg2k8rLuG9W3yU. > > Are you sure you want to continue connecting (yes/no)? yes > > Warning: Permanently added 'common-lisp.net,148.251.248.130' (ECDSA) to the list of known hosts. > > pascal(a)common-lisp.net: Permission denied (publickey). > > rsync: connection unexpectedly closed (0 bytes received so far) [sender] > > rsync error: error in rsync protocol data stream (code 12) at /BuildRoot/Library/Caches/com.apple.xbs/Sources/rsync/rsync-52.200.1/rsync/io.c(453) [sender=2.6.9] > > make: *** [website] Error 12 > > I've tried with the version of rsync included with Mac OS X 10.14.4 and also installed the most recent one from Homebrew, but should it even try to connect to the server to generate the documentation? > > — > Reply to this email directly or view it on GitLab. > You're receiving this email because of your account on gitlab.common-lisp.net. If you'd like to receive fewer emails, you can unsubscribe from this thread or adjust your notification settings.

2 1

ASDF 3.3.3 is Released
by Robert Goldman 29 Mar '19

29 Mar '19

In honor of the impending 2019 European Lisp Symposium, today we release ASDF 3.3.3, the third bugfix release for the 3.3 release series. We urge implementations that are currently bundling previous versions of ASDF -- and especially those bundling 3.3.0 or 3.3.1 -- to upgrade to 3.3.3 at their earliest convenience. Immense thanks, as always, to Faré Rideau. Also thanks to the many bug reporters and patch submitters including (alphabetically): * Marius Gerbershagen * Hugo Ishimaru * Attila Lendvai * Jan Moringen * P. Neidhardt * François-René Rideau * Eric Timmons * Didier Verna * "privet-kitty" The Changelog: ``` Bug fix release: * Dependency tracking: fix bugs in handling misnamed secondary systems. We now distinguish between "syntactic" and "semantic" primariness, properly warn in case a secondary system is misnamed, yet properly recompile or avoid spurious recompilation depending on whether there or not is a conflict or redefinition. Similarly handle package-inferred-system (thanks to Eric Timmons). Better warning in a fishy case of compute-action-stamp. * UIOP: Fix loading, allow the user to specify UIOP location from which to load. * SBCL compatibility: Fix issue with deferred warnings on SBCL. * Allegro compatibility: Fix issue detecting "modern" lisp. * Genera compatibility: Fix minor issues. Not fully tested. * ECL compatibility: Bundling fixes. * Fiveam-ASDF: Added to contrib/ example system for integrating FiveAM tests with ASDF's test-op. * Miscellaneous fixes: Avoid an infinite loop parsing :perform options, quash warnings for known bad system names that won't be fixed. * Documentation: Multiple user-contributed documentation fixes. * Tests: Miscellaneous improvements. -- Francois-Rene Rideau <fare(a)tunes.org> Wed, 27 Mar 2019 17:33:42 -0400 ```

3 3

Extracting a UIOP's manual
by Hugo Ishimaru 26 Mar '19

26 Mar '19

Hi all, I have extracted a UIOP's manual from docstrings: https://privet-kitty.github.io/etc/uiop.html It's not perfect in any means as docstring isn't written in a markup langugage, but will be at least a comprehensive reference. The relevant fork of ASDF is in Github: https://github.com/privet-kitty/asdf/tree/uiop-man/uiop/doc The greater part of the generation conforms to that of Alexandria, which depends on SBCL (sb-texinfo). I send this mail as it states > Help wanted extracting working documentation from UIOP's docstrings. in README.md though I might not understand a historical context. Regards Hugo Ishimaru

5 5

long-description
by Faré 26 Feb '19

26 Feb '19

I've seen the pattern of using :long-description #.(uiop:read-file-string (uiop:subpathname *load-pathname* "README.md")) spread among CL libraries. I see it only as a waste of kilobytes of data (quadrupled on 32-bit unicode lisps such as SBCL). I'm told it's because Quickdocs likes it this way. Since there is not (yet?) any type enforcement on the value of that field, can we instead agree for an alternate format, wherein the field would instead contain the pathname of the long-description file, relative to the (asdf:system-source-directory) ? Thus you'd use: :long-description #p"README.md" And Quickdocs and other documentation tools would do the right thing from there. Maybe I'm just an old-school code bummer but I'm always saddened by a waste of bytes. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org I have never killed any one, but I have read some obituary notices with great satisfaction. — Clarence Darrow

7 11

Shims for old systems
by 73budden 20 Feb '19

20 Feb '19

Hi! Every time I read "asdf", I feel a pain. I've read that there is an attempt to gain resources to improve asdf. I have a sort of plan. 1. Shims. Recent tightening of rules for system definitions is ok, but there are old systems with no maintainers. If such system does not obey the rules, one can introduce "shim" concept. I've met them in JS culture where they serve as third-party adapters to connect two mismatching things. In the simplest way shim is just an alternative directory hierarchy with shim asd files, isomorphic to local lisp directory structure. When looking for system, asdf must search in shims directory first, and only then in the directory of the file itself. Also things like quicklisp might take care of installing shims where they exist. Maintanence of shims for all popular systems can be done within a separate git repository. 2. Get rid of upgrade. Upgrade feature requires to maintain a 3d array of possible cases, where dimensions are "old asdf version", "new asdf version" and "lisp implementation". It is hard to maintain and it will get harder and harder to maintain as the time goes on. Also upgrade is a good test of CLOS, but running tests at the very beginning of image bootstrap is not a good idea because there is no e.g. SLIME to work with convenience. 3. Last, but most important actually. Prioritize manual, FAQ, Wiki and all like this. Instead, when loading asdf, allow the user to pass the parameter that fills asdf database with the initial loaded system information. It would be also good to have an utility to extract this database from some old asdf versions. This way we have a slight chance to make things easier, upgrade process explicit and under user's control.

4 5

← Newer
1
...
9
10
11
12
13
14
15
...
138
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel