Re: Shims for old systems
> The shims idea is interesting, but isn't it a lot of trouble to make and > maintain a shim (which has to somehow indicate where to find the source files > for the library), compared to forking a system? +1 there's already the sharplispers group for taking over unmaintained systems (not to be confused with hostile systems): https://github.com/sharplispers -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Tact is a skill that can turn brutal honesty into just honesty. It's a skill that develops with practice, and one that's harder to use when emotions are running high. But you can't go towards someone with a verbal fist and expect a hug in return. When method matches intention, outcomes are much more peaceful.” — Doe Zantamata
Re: Shims for old systems
On 19 Feb 2019, at 1:18, 73budden wrote: 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. For the moment, I think the only issue related to rules tightening is that we ask people to use the proper complex system names (see my recent change to the ASDF manual, available from the page on `common-lisp.net`. Is that what you are referring to? Or are there other issues causing pain? If it's just that, insert the name of the asd file (name only -- no extension) into `*known-systems-with-bad-secondary-system-names*`. E.g., ``` (setf (gethash "terrible-legacy-system" *known-systems-with-bad-secondary-system-names*) t) ``` ... and that will suppress the warnings for you. That set has "cl-ppcre" built into it, and I'm happy to add other systems that are in common use, but unmaintained. I should put documentation of this into the manual The shims idea is interesting, but isn't it a lot of trouble to make and maintain a shim (which has to somehow indicate where to find the source files for the library), compared to forking a system? If you have a more specific idea for how this works, I'd be happy to discuss it further. 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. I don't know about doing away with upgrade, but certainly cutting **way** down on the upgrades we support is a good idea. For CMUCL, we now only test and support 3.3.0+ I'm willing to do that for many more implementations, if I can figure out what ASDF versions they are shipping on what target platforms. 3. Last, but most important actually. Prioritize manual, FAQ, Wiki and all like this. I'm ok with that, but I don't have the time for an end-to-end rewrite of the manual. Note that I am also going to integrate **everything** into the manual, because I don't have the time to support more than one documentation set (e.g., Fare's Markdown stuff will get folded into the manual). Part of the problem is that the manual doesn't have a clear structure. It shoold somehow start off by teaching only the basics, in a very brief discussion, then get to more advanced topics, then the object model, and stuff that only an extender, developer, or maintainer would want to know. But it's quite possible I will retire or die before I manage to do that level of rewrite. Restructuring is *really* not something that Texinfo makes easy, but Texinfo seems to be the worst documentation system ... except for all the other ones. A contribution I would *love* to have is an adaptation of the SBCL manual code that extracts symbols and docstrings for inclusion in Texinfo. At one point I looked into Didier's library (DecIt, I think?), but while it's good at extraction, I couldn't see how what it extracts could be moved around and integrated with large blocks of text. I'm happy to accept FAQ suggestions and get them into the manual. 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. I'm not exactly sure what is meant by the above. I have a number of different projects I work on, each with their own set of libraries. I have made simple functions for each of these projects that populates `asdf:*central-registry*`, and when I sit down to work on one of these systems, I just invoke that function. That's always been sufficient for me. So something like: ``` CL-USER> (shop2) "SHOP2 libraries available." NIL CL-USER> (asdf:test-system "shop2") ``` I still use `*central-registry*` for that because (1) I wrote it before Fare's new DSL was a
Re: ASDF upgrade script fails on cmucl/Linux
I see that 21c contains 3.3.0 Since I only test on the latest CMUCL, there is no reason for me to test upgrades from earlier versions. I will fix the test scripts; that will likely make the problem go away (it does at least on my Mac). Note that this means that we can't guarantee what happens if a user tries to load a new ASDF into an older revision of CMUCL. That's nothing new, though! We have never really been able to test more than the latest version of the lisp implementations (and sometimes not that!). Best, Robert On 18 Feb 2019, at 16:12, Raymond Toy wrote: How critical is being able to upgrade? Cmucl snapshots usually provide the very latest version of asdf. Fare has reported the issues with cmucl's pcl and I've just been really lazy to dig into the hairy pcl code. On Thu, Feb 14, 2019 at 2:16 PM Robert Goldman wrote: On 14 Feb 2019, at 4:55, Anton Vodonosov wrote: 13.02.2019, 01:44, "Robert Goldman" rpgold...@sift.info: On a happier note, both (Home)brew and Ubuntu have newish versions of clisp which, AFAICT, pass all the ASDF tests. Yay! What newish clisp it is? I have been hoping clips will release somem "refreshment" release, maybe just the same code as the previous release but new ASDF. From time to time are check the mailing list and project page - no news. Is that OS package maintainers did anything on the package level? I think it's the packaging managers, not the clisp maintainers who did this. On my Mac, with Homebrew, the version is: /usr/local/Cellar/clisp/2.49_2 (64 files, 16.2MB) According to GitHub, it was last updated 20 days ago. I don't really know how up-to-date it is with the clisp repo versus the ancient zip file. On my Ubuntu Box, I have a package whose version is listed as 1:2.49.20170913-4build1. I don't know how to tell what that corresponds to in terms of the clisp source repo. Best, R -- Ray
Re: Lowercase naming requirement for systems?
Yes, these are good points, and that's why I have pushed an update to the manual. Please have a look at the "The defsystem grammar" ASDF manual page here: https://www.common-lisp.net/project/asdf/asdf/The-defsystem-grammar.html#The-defsystem-grammar Only the first four entries have changed. Please also have a look at the subsections immediately below: 6.3.1, 6.3.2, and 6.3.3. I would welcome any comments you (or anyone receiving this message -- the more the merrier!) have. The previous discussion was not as clear as it should have been. The manual could definitely use an extensive overhaul, but this band-aid is well better than nothing. Best regards, Robert On 19 Feb 2019, at 13:30, Robert Dodier wrote: On Sun, Feb 17, 2019 at 4:08 PM Robert Goldman wrote: It's actually there, at least if you are looking for it. In my own defense: I did look for it and I did find that text, but didn't find it helpful. It says the name of a system is conventionally lowercase -- this is not the same as saying that it is required to be lowercase. I found the text about pathname specifiers as well. I didn't see a requirement there because neither the system name nor component names were specified by the grammar or the commentary on the grammar to be pathname specifiers. Thanks again for your help, Robert Dodier Robert P. Goldman Research Fellow Smart Information Flow Technologies (d/b/a SIFT, LLC) 319 N. First Ave., Suite 400 Minneapolis, MN 55401 Voice: (612) 326-3934 Email:rpgold...@sift.net
Re: Lowercase naming requirement for systems?
On Sun, Feb 17, 2019 at 4:08 PM Robert Goldman wrote: > It's actually there, at least if you are looking for it. In my own defense: I did look for it and I did find that text, but didn't find it helpful. It says the name of a system is conventionally lowercase -- this is not the same as saying that it is required to be lowercase. I found the text about pathname specifiers as well. I didn't see a requirement there because neither the system name nor component names were specified by the grammar or the commentary on the grammar to be pathname specifiers. Thanks again for your help, Robert Dodier