asdf-devel February 2019

asdf-devel@common-lisp.net

16 participants
7 discussions

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 15 Feb '19

15 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

how to distinguish public vs private (entry-point vs internal) systems
by Jim Newton 07 Feb '19

07 Feb '19

When creating an lisp application I usually have one (or several) what I call top-level asdf systems which advertise the public interface to the application, and I may have several internal systems which are used but not intended for public use. What is the convention with asdf to distinguish entry-point systems from internal/private systems?

3 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel February 2019