- asdf-devel - mailman3.common-lisp.net

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

ASDF upgrade script fails on cmucl/Linux
by Robert Goldman 19 Feb '19

19 Feb '19

I'm getting a failure of the ASDF upgrade tests on CMUCL since the UIOP dependencies mod: Upgrading ASDF from version 3.1.7 to version 3.3.2.13 TEST ABORTED: Error while trying to load definition for system test-asdf from pathname /var/lib/jenkins/workspace/asdf-upgrade/test/test-asdf.asd: don't recognize component type :MODULE This looks like the key bit of the backtrace: ``` 10: (ERROR ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR :NAME "test-asdf" :PATHNAME #P"/var/lib/jenkins/workspace/asdf-upgrade/test/test-asdf.asd" :CONDITION #<ASDF/SESSION:FORMATTED-SYSTEM-DEFINITION-ERROR {5A92F6A5}>) 11: ("LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. O S)" #<ASDF/SESSION:FORMATTED-SYSTEM-DEFINITION-ERROR {5A92F6A5}>) 12: (SIGNAL #<ASDF/SESSION:FORMATTED-SYSTEM-DEFINITION-ERROR {5A92F6A5}>) 13: (ERROR ASDF/SESSION:FORMATTED-SYSTEM-DEFINITION-ERROR :FORMAT-CONTROL "don't recognize component type ~S" :FORMAT-ARGUMENTS (:MODULE)) 14: (ASDF/SESSION:SYSDEF-ERROR "don't recognize component type ~S" :MODULE)[:OPTIONAL] 15: (ASDF/PARSE-DEFSYSTEM:PARSE-COMPONENT-FORM NIL (:MODULE "test-asdf" :PATHNAME NIL) :PREVIOUS-SERIAL-COMPONENT NIL)[:OPTIONAL] 16: (LISP::SLOLOAD #<Stream for file "/var/lib/jenkins/workspace/asdf-upgrade/test/test-asdf.asd">) 17: (LISP::INTERNAL-LOAD #P"/var/lib/jenkins/workspace/asdf-upgrade/test/test-asdf.asd" #P"/var/lib/jenkins/workspace/asdf-upgrade/test/test-asdf.asd" :ERROR :SOURCE :UTF-8) ``` TBH, I'm inclined to regard 3.1.7 as so old that I don't have to think about it, but I'm open to contradiction. If I don't hear any, I'll prune that from the set of origin versions to test for upgrades, and move on. Best, R

4 8

Lowercase naming requirement for systems?
by Robert Dodier 19 Feb '19

19 Feb '19

Hi, The ASDF manual says that the name of a system is a lowercase string. Is that actually a requirement? I was trying to create an .asd system which has a name with mixed upper- and lowercase characters and the system is stored in a file of the same name on a case-sensitive file system (Linux). But I get "Component Foo not found" for that. If I change the name of the system and the name of the file to lowercase, the system is found. For the record, I've pasted the would-be mixed-case named system below. It contains stuff that will make it generally unloadable since you don't have my maxima-file hackery. If it turns out we need to go into this in more detail, I will devise a more minimal example. But first maybe someone can say what the name requirement is. best, Robert Dodier PS. (defsystem "SolveSolvable2" :defsystem-depends-on ("maxima-file") :author "Yasuaki Honda" :license "GNU Lesser General Public License, version 2" :description "Program SolveSolvable2 of GaloisGroupSolver, a Maxima package for solving polynomials based on their Galois Groups" :components ((:maxima-file "Gal") (:maxima-file "FiniteGroup") (:maxima-file "ExtendedField") (:maxima-file "Stage3") (:maxima-file "Verify") (:maxima-file "SolveSolvable2")))

4 9

Please Contribute what you can to the ASDF Fundraiser (now with Doubling)
by Dave Cooper 16 Feb '19

16 Feb '19

Happy Friday Everyone! Now is your opportunity to inject some energy into your technical community by contributing what you can to the ASDF Appreciation Fundraiser going on here: https://payments.common-lisp.net/asdf Until we reach the doubling limit, your contribution will be amplified by 100% (i.e. DOUBLED), thanks to the generosity of Franz Inc and another donor who remains anonymous. If you're completely satisfied with ASDF, please contribute in order to show appreciation. If you're not completely satisfied, please also contribute, in order to show that people care and attract more energy to the project for continued improvement. Common Lisp continues to survive and even thrive in its way, largely because of incremental efforts and successes by independently-thinking individuals and small companies such as yourselves. With CL, a small amount of sincere effort can have outsized results, and the same is true with your donation, however small or large. Let's keep this awesome power in our hands, and determine our own future! All the best and have a great weekend, -- Dave Cooper Board Member, Common Lisp Foundation

1 0