Re: Readtable not bound to standard around compilation
I'm also very curious because I might have a use for it soon. > I'm curious about the Bazel namespace problem. Can you elaborate a bit ... > > On Mon, Feb 26, 2024 at 4:57 PM Faré wrote: >> >> rpg:>> Given that Quicklisp and SBCL already refuse to update their >> bundled ASDF versions, because of warnings about deprecated behavior, >> I'm reluctant to donate any of my unpaid time to fixing this: it's a >> strong disincentive to making any improvements to ASDF, as opposed to >> just fixing bugs around the edges. >> On the other hand, the whole point of ASDF 2 and later was that by >> making ASDF upgradable (and with ASDF 3, it's now automatically >> self-upgradable), users shouldn't have to care as much which version >> of ASDF their implementation and package distribution system do or >> don't provide: "just" install the latest ASDF in e.g. >> ~/common-lisp/asdf/ and things will "just work". If the new ASDF is so >> much better, eventually the implementors and distributors should >> follow. >> >> si:> Is it time for ASDF 4 ? There's tons of stuff I'd like to delete or >> change. >> It's always time for ASDF 4, and never time for ASDF 4. The main >> question is: is someone crazy enough to sink in the time to do it, the >> emotional energy to fight half the community, etc. >> >> If only Bazel didn't fuck up their namespace system, the solution >> could have been "just use Bazelisp". >> >> If and when someone volunteers to do ASDF 4 (if ever), there are >> plenty of suggestions in the asdf/TODO file, in addition to the issues >> on gitlab and the old launchpad. Good luck! >> >> —♯ƒ • François-René Rideau • Chief Scientist, MuKn.com >> “With freedom, no more One True Scale to rank people. Everyone pick his own. >> Why vie for a society of equals, when everyone can be superior?” -- Stelian Ionescu
Re: Readtable not bound to standard around compilation
try again. I *believe* that this behavior >>> is still in place: Faré proposed the "syntax control" patch to fix this, >>> but we decided we had no easy path to introducing it, because it would >>> break other code (admittedly not of good style) that relies on the old >>> behavior of having the readtable setting leak out of one file into another. >>> See https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/86 >>> >>> Any non-backwards compatible modification to ASDF -- even to the extent of >>> raising a deprecation warning -- has led to temper-tantrums in the CL >>> community... >>> >>> On 21 Feb 2024, at 22:14, sc...@sympoiesis.com wrote: >>> >>>> Hi all! I just ran into something surprising. This is with ASDF 3.2.1, >>>> packaged with Quicklisp. I am using Named-Readtables. I had '*readtable*' >>>> set to a nonstandard readtable, then did quickload of a system unrelated >>>> to the one that defines and uses that readtable. The compilation failed; >>>> after I did '(in-readtable :common-lisp)' and tried again, it succeeded. >>>> >>>> A quick glance at the ASDF source code shows that it binds '*readtable*' >>>> to a standard readtable in some cases, such as to read a '.asd' file, but >>>> not in 'uiop/lisp-build/compile-file*', nor in >>>> 'asdf/lisp-action:perform-lisp-compilation'. Wouldn't it make sense to do >>>> that? >>>> >>>> -- Scott >>>> > -- Stelian Ionescu
Re: Change to allow loading linked asd files
As far as I know, Windows now supports symlinks
(https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/create-symbolic-links).
Does that not work ?
> It's probably safest and wisest to not make this change. Sorry for wasting
> time. Here are some words which may answer your questions, but are safe to
> ignore:
>
> I've only tested it on {sbcl ccl ecl clisp lispworks allegro cmu} on {linux
> bsd macos windows}. Windows doesn't have effective symbolic links, so
> unfortunately this doesn't work on it. Although it does work under POSIX
> compatibility like cygwin. Unfortunately I don't know if it works on Mezzano
> or Genera. I'm unsure about ABCL, Clasp, and Corman since I haven't yet been
> able to run on those. I think this should only happen when the link target
> base name is not ‘equal’ to the one given, so it's only dependent on the
> behaviour of pathanme-name not on any OS specific thing.
>
> I don't think there's any change to the user's configuration that can achieve
> this. Making a long set of changes to the user's ASDF configuration e.g.
> source-registry.conf, seems difficult and inappropriate.
>
> I know ASDF already supports ths case of:
>
> /some/path/foo.asd -> /a/different/path/foo.asd
>
> This change is for the cases where the base name differs:
>
> foo.asd -> bar.asd
> /the/same/path/foo.asd -> /the/same/path/bar.asd
> /some/path/foo.asd -> /a/different/path/bar.asd
>
> so when you ask to load "foo" it can load "bar". Everything else is the same
> as if you asked to load "bar".
>
>>
--
Stelian Ionescu
Re: Change to allow loading linked asd files
Hi, ASDF already allows that, so it's not clear to me how you're trying to do. I have the following in ~/.config/common-lisp/source-registry.conf (:source-registry (:directory (:home "lisp/systems")) :ignore-inherited-configuration) I symlink .asd files into ~/lisp/systems/ and ASDF loads them without issues. > Hi, > > I wonder if it possible that you would accept this change which allows > finding of a system by a symbolicly linked ".asd" file. I've been running > with this patch for about 10 years without issue. I'm sorry for not having > test cases and documentation, but it seems time passing won't help that. I > know this is probably a pointless change for everyone besides me, being the > only user of my software, so I quite understand if you don't want to add it. > Anyway, many thanks for your years of work on perhaps the most used CL > software ever. > > diff --git a/find-system.lisp b/find-system.lisp > index 0980a2cc..1a226aba 100644 > --- a/find-system.lisp > +++ b/find-system.lisp > @@ -263,11 +263,16 @@ PREVIOUS-PRIMARY when not null is the primary system > for the PREVIOUS system." > (locate-system name) > (assert (eq foundp (and (or found-system pathname previous) t > (let ((previous-pathname (system-source-file previous)) > - (system (or previous found-system))) > + (system (or previous found-system)) > + real-name) > (when (and found-system (not previous)) > (register-system found-system)) > (when (and system pathname) > (setf (system-source-file system) pathname)) > + (when (and pathname > + (setf real-name (pathname-name pathname)) > + (not (equal real-name name))) > + (setf name real-name)) > (if-let ((stamp (get-file-stamp pathname))) > (let ((up-to-date-p > (and previous previous-primary -- Stelian Ionescu
Re: Handling of readme and license files
> Hey, > > Thanks for the quick reply. > > "Stelian Ionescu" writes: > >>> I'm working with a project that bundles up CL systems, and then copies What do you mean by "bundles" ? Copying the source code as-is ? >>> them to a remote host. To avoid copying unnecessary files, we rely on >>> the components and additional-input-files to find all the files needed >>> to load the system on the remote host. >>> >>> I found some ASD files to load on the remote host. These systems are >>> expecting to read a long-description, usually a readme file. All of >>> these projects are using reader macros to load this data, and none of >>> them declare the file as a :static-file component. >>> >>> It's also often the case that the license of a project requires a copy >>> of the license be shipped with the project. Yet rarely do I see any >>> project declaring a :static-file for one in their asd file. >>> >>> Am I correct in my understanding that using :static-files is this the >>> current recommended way to declare these files? >> >> ASDF is a build system, not a software packaging system. >> The :STATIC-FILE component was meant to handle data files that might >> be required at runtime, not any metadata in general. > > OK, I can understand this when it comes to my suggestion about tracking > the location of the license file. Though I find it disappointing, since > some licenses declare statements like "Redistributions in binary form > must reproduce the above copyright". Not having a way to identify the > license file makes it difficult to ad hear to the license's of all > project dependencies. The regex "^LICEN[CS]E|COPYING(\.md)?$" should identify most license files, by convention. > > But regarding the readme file being loaded at read time in the ASD file. > This dependency is not track but it's required to build the package. This is difficult to track because of how the reader works. > This could be caught if the builds were hermetical, and this would also > help with issues related other static files that are missing from the > ASD file. At the moment it's just luck if anyone actually adds the > :STATIC-FILE components needed by their system. Is there some way to > help system authors avoid accidentally missing files? Not that I know of. > Since it looks > like a pretty common pattern to load the long-description from a readme. > > I'm perfectly happy to contribute to a solution, I would like to help if > I can. > > Cheers, > Russell -- Stelian Ionescu
Re: Handling of readme and license files
> Hey, > > I'm working with a project that bundles up CL systems, and then copies > them to a remote host. To avoid copying unnecessary files, we rely on > the components and additional-input-files to find all the files needed > to load the system on the remote host. > > I found some ASD files to load on the remote host. These systems are > expecting to read a long-description, usually a readme file. All of > these projects are using reader macros to load this data, and none of > them declare the file as a :static-file component. > > It's also often the case that the license of a project requires a copy > of the license be shipped with the project. Yet rarely do I see any > project declaring a :static-file for one in their asd file. > > Am I correct in my understanding that using :static-files is this the > current recommended way to declare these files? ASDF is a build system, not a software packaging system. The :STATIC-FILE component was meant to handle data files that might be required at runtime, not any metadata in general. -- Stelian Ionescu
Re: Versioning
> On 19 Nov 2021, at 15:25, Jason Miller wrote: > >> On Fri, 19 Nov 2021 22:02:11 +0100 Erik Huelsmann wrote: >> >>> >>> >>> On Fri, Nov 19, 2021 at 9:51 PM Anton Vodonosov >>> wrote: >>> >>> >>>> >>>> >>>> - etimmons@, rpgoldman@ >>>> >>>> "Erik Huelsmann" : >>>> >>>> >>>>> Could you elaborate a bit on "As semver does not work for Common Lisp"? >>>>> >>>> >>>> >>>> I've opened an issue in the SemVer github repo: >>>> https://github.com/semver/semver/issues/771 >>>> (Don't want to repeat this explanation over and over in many discussions). >>>> >>>> >>> >>> >>> "One bad programmer can break more than 10 good ones can fix": the issue >>> you raise is bad engineering (increasing the version number simply because >>> you can) and is not a problem semantic versioning is trying to solve. What >>> it *does* try to solve is that the engineers working on the software can >>> see the problems coming. >>> >>> >> >> >> I disagree, in the example authentication-1.1.2 upgrades a dependency of >> commons-logging from 1.x to 2.x *because* commons-logging changed its API. >> Presumably authentication did *not* change it's API because it's following >> semver and only incremented the minor version. However, upgrading from >> authentication 1.1.1 to 1.1.2 will break if any other components depend on >> commons-logging-1.* since in Lisp (and many other languages) it's not >> possible >> to load two versions of the same system. >> >> So long as two different versions of the same system cannot be used in the >> same >> image, this is a real problem with semver. How large of a problem it is can >> certainly be debated (I don't find it to be that big of an issue in >> practice). >> >> > I'm not sure that I see this as a CL-specific problem. If you have a C++ > program that uses one boost version and it uses a library that requires a > different boost version, you have the same problem. > > I also don't think that this is a problem with semantic versioning: the boost > people use what we might call "anti-semantic versioning," but they still > wreak havoc with the world. The problem isn't that semantic versioning breaks > everything, the problem is that different libraries evolve at different > rates, and that causes stuff to break. > > I would argue that this shows the *strength* of semantic versioning: no, it > doesn't magically solve the problem of version skew, but in at least some > cases it tells you that you have version skew, and tells you where to look > for a solution, instead of leaving you flailing around trying to figure out > why your code has suddenly stopped working. My personal experience is that semver is of no help because 1) authors don't really know when or how to increase the number, most have adopted semver because it's fashionable and 2) the users don't really know what the true minimum version is and just winge it by selecting whatever recent version they're working with as minimum requirement. In the end both the release version and the dep versions are nothing more than suggeestions and the only sure way to know if integrating N libraries works is to try to load them all together and run their own test suites plus your application's test suite. -- Stelian Ionescu
Re: Versioning
It shows that semantic versioning is a bad idea unless you have automatic ways of diffing an API between two versions (such tools exist for C), or the development team has the time and resources to very carefully evolve the code. What one finds in practice is that authors will wing it and increment version numbers if it "feels" like a major change or for publicity reasons (new major release, get it while it's hot!). > > > On Fri, Nov 19, 2021 at 9:51 PM Anton Vodonosov wrote: >> - etimmons@, rpgoldman@ >> >> "Erik Huelsmann" : >> > Could you elaborate a bit on "As semver does not work for Common Lisp"? >> >> I've opened an issue in the SemVer github repo: >> https://github.com/semver/semver/issues/771 >> (Don't want to repeat this explanation over and over in many discussions). > > "One bad programmer can break more than 10 good ones can fix": the issue you > raise is bad engineering (increasing the version number simply because you > can) and is not a problem semantic versioning is trying to solve. What it > *does* try to solve is that the engineers working on the software can see the > problems coming. Applications (and libraries) like Subversion have managed to > stay within the boundaries of semantic versioning for almost 20 years now, > still "stuck" at version 1.x because of it. At the same time they have > succeeded to add significant new features to the software without breaking > backward compatibility. So: it's possible. The fact that projects like e.g. > Cucumber release a new major version every few months says more about those > projects than about semver. > >> >> I will probably refine the issue description in the future, but it should be >> clear enough already. > > Regards, > > -- > Bye, > > Erik. > > http://efficito.com -- Hosted accounting and ERP. > Robust and Flexible. No vendor lock-in. -- Stelian Ionescu
Re: Next steps
> On 17 Nov 2021, at 14:03, Stelian Ionescu wrote: > >>> On 17 Nov 2021, at 12:32, Stelian Ionescu wrote: >>> >>>> >>>> You don't have to use the Quicklisp client to load dependencies, >>>> just to fetch them (as a package manager). >>>> And for that, I think it should be always used this way. >>>> >>> That only works if you are using the QL libraries unchanged. If you >>> need to patch or extend them, you need to set up a repo and handle >>> things yourself. >> >> This is definitely not true. You can configure ASDF pretty easily in >> such a way that you have a directory of local dependencies which >> override the ones in Quicklisp. I have lots of locally patched >> libraries and never had any problem with that. >> > > What I mean is that Quicklisp doesn't handle this -- you fall back on > ASDF without QL. > Specifically, if the library needs patching, you need to go out and find > it. AFAIK QL won't help you find the source and check it out, for > example. Sure, if you need a fork that is outside Quicklisp you should fetch it yourself. -- Stelian Ionescu
Re: Next steps
>> You don't have to use the Quicklisp client to load dependencies, just to >> fetch them (as a package manager). >> And for that, I think it should be always used this way. > > I work on multiple projects which do not use Quicklisp at all, for a variety > of reasons which are not worth going into here, but which are unavoidable. > And I work on other projects which use Quicklisp for some dependencies, but > have other dependencies which cannot be in Quicklisp, again for a variety of > reasons. Using one of the Quicklisp monthly distributions as a base does not preclude one from having local dependencies. -- Stelian Ionescu
Re: Next steps
> On 17 Nov 2021, at 12:32, Stelian Ionescu wrote: > >> >> You don't have to use the Quicklisp client to load dependencies, just to >> fetch them (as a package manager). >> And for that, I think it should be always used this way. >> > That only works if you are using the QL libraries unchanged. If you need to > patch or extend them, you need to set up a repo and handle things yourself. This is definitely not true. You can configure ASDF pretty easily in such a way that you have a directory of local dependencies which override the ones in Quicklisp. I have lots of locally patched libraries and never had any problem with that. -- Stelian Ionescu
Re: Next steps
> On 17 Nov 2021, at 12:26, Stelian Ionescu wrote: > >> To guarantee an old working configuration you can simply point to the >> version of the Quicklisp distribution that it was last tested with. We >> should make it easy to specify that as metadata, and it would be much >> more useful than version constraints because ASDF is not blocking >> compilation (after all, even old software might very well work with >> newer version of the dependencies). > > This would be to assume that ASDF is only used in conjunction with > Quicklisp, which is not the case. You don't have to use the Quicklisp client to load dependencies, just to fetch them (as a package manager). And for that, I think it should be always used this way. -- Stelian Ionescu
Re: Next steps
> > On 17 Nov 2021, at 11:08, Stelian Ionescu wrote: > >>> 2. I *desperately* want to add version upper bounds. There is a real >>> problem of having someone change a library under one's system, and *pace* >>> Faré, sometimes one does not have the resources to handle updates to every >>> library in one's build chain. >>> >> It's part of the social contract of open source that you get things for free >> but you need to stay up-to-date with your dependencies. >> > That simply does not work for everyone, *definitely* including me. My company > can't afford to pay me to keep every piece of software lying around updated > with all of its dependencies. When a contract is done, I often can no longer > maintain related software. Similarly, I use a lot of software written at > universities as part of some research project that will eventually end. Other > examples abound. There's a *lot* of software out there that could be useful, > but that is not useful enough to the original author that they are going to > maintain it *ad infinitum*. > > In such cases it's better that if we pull this stuff out of mothballs: (1) we > don't have to flail around trying to guess why it doesn't work any more and > (2) we can find an old working configuration. To guarantee an old working configuration you can simply point to the version of the Quicklisp distribution that it was last tested with. We should make it easy to specify that as metadata, and it would be much more useful than version constraints because ASDF is not blocking compilation (after all, even old software might very well work with newer version of the dependencies). > > In the best of all possible worlds, everything would always be up-to-date, > but that is not the world we live in -- or at least not the one that I live > in. > >>> 3. I am not that worried that we will end up in the kind of mess that >>> concerns you: right now there are an enormous number of Lisp libraries that >>> don't even have version metadata *at all* . So if people want to use >>> expressive versioning in a sub-region of the lisp development ecosystem, >>> that is unlikely to cause the problems you see, and might help *some* of us >>> manage our dependencies. >>> >> I am worried because once you make something easy, people will be tempted to >> use that feature. Authors aren't currently adding metadata because it's >> purely decorative and there's no real gain in maintaining that. >> > On the contrary, *minimum* version constraints already exist. So it's not > true that metadata is purely decorative. It's because people are slobs, or > are not aware that the metadata are available. > > -- > > The argument here is the same argument as Faré has made: all software should > always be maintained and kept-up-to-date. But Faré is a programming > superhero. I'm a mere mortal, but I *am* the ASDF maintainer, and at the end > of the day, I have decided that version constraints like `(:version > "my-unstable-library" < 3)` or something like that *will* go in to ASDF. > > The worst that will happen is that someone will put in an overly-restrictive > version constraint. Given the state of the CL software ecosystem vs., e.g., > Python, I think it's quite unlikely that there will be a lot of overly-tight > restrictions out there. And the ability to have upper bounds meets an actual > need that is under-served. > -- Stelian Ionescu
Re: Next steps
> On 17 Nov 2021, at 10:35, Stelian Ionescu wrote: > >>> >>> >>> Mostly sounds good to me. Assuming you're still interested in more >>> expressive version numbers and constraints for 3.4, I'll work on moving >>> that off the back burner. >>> >>> >> >> >> Adding fine-grained version constraints would be a big mistake. Where >> they've already been implemented (Ruby, Python, Haskell), they've invariably >> lead to authors selecting overly restrictive contraints because there's no >> automatic way to determing the minimum version required from dependencies. >> In turn, that makes even installing a package a nightmare because it often >> leads to unsatisfiable dependencies and having to (manually) backtrack until >> one can find a combination of compatible packages. The distribution model >> that Quicklisp has, by snapshotting the "world" once a month and ensuring >> that they all compile is much better so let's keep it that way. >> >> >> If you think I'm exagerating, ask people that are familiar with the process >> of having to update a Ruby webapp (or a Jekyll blog with many plugins), or >> even a Python virtualenv-based server. Especially the Ruby community went >> down this rabbit hole to far that it's no wonder they were the first to >> adopt Docker back in the days: instead of subjecting users to the dance of >> "let's see if I can even get this to install" they ended up shipping a whole >> container as a workaround. >> > I have mixed feelings about this: > > 1. I agree that the situation in Python is a hot mess. I'm not sure how much > this is due to versioning messes as opposed to the excess specificity that > one gets from `pip freeze`, and another confound is the multi-headed horror > that is Python package construction and management. Dependency freezing is yet another symptom of the problem: because the dependency hell makes it difficult to find a mutually compatible version set, authors make their own life easy by freezing deps, but that works poorly with the rest of the ecosystem. The last time the problem of incompatible versions bit me I was trying to update my blog based on Octopress+Jekyll, and found that the latest release of each of the packages that I required - including plugins - couldn't be installed together. I had to manually backtrack by tweaking the versions (since rubygems didn't do that automatically), and it took me a few hours to converge on a working install. The year after I switched to Hugo. > 2. I *desperately* want to add version upper bounds. There is a real problem > of having someone change a library under one's system, and *pace* Faré, > sometimes one does not have the resources to handle updates to every library > in one's build chain. It's part of the social contract of open source that you get things for free but you need to stay up-to-date with your dependencies. If a library changes too often, it's a social problem and shouldn't be addressed with technical means: talk to the author and ask to keep backwards-compatibility for a while longer or remove/replace the dependency. I cannot stress enough how much better the Quicklisp monthly distribution model is compared to what I see anywhere else. Once you open this Pandora's box there will be no going back (are you open to removing the feature from ASDF if it goes bad ?). > It's always better for the poor user to see an error message saying that > something won't work because of a library update, instead of seeing some kind > of horrible mess with no clue where to look. > > 3. I am not that worried that we will end up in the kind of mess that > concerns you: right now there are an enormous number of Lisp libraries that > don't even have version metadata *at all* . So if people want to use > expressive versioning in a sub-region of the lisp development ecosystem, that > is unlikely to cause the problems you see, and might help *some* of us manage > our dependencies. I am worried because once you make something easy, people will be tempted to use that feature. Authors aren't currently adding metadata because it's purely decorative and there's no real gain in maintaining that. -- Stelian Ionescu
Re: Simple use of output-translations
Add this to ~/.config/common-lisp/asdf-output-translations.conf:
(:output-translations
:inherit-configuration
((:home "src")
(:home "output")))
The translation config is pairs of absolute paths, evaluated in order. AFAIU it
doesn't allow specifying paths relative to the .asd file.
Here's my config, as a more complex example:
(:output-translations
:inherit-configuration
("/usr/share/common-lisp/source"
(:user-cache "system"))
((:home "lisp/src")
(:user-cache "src"))
((:home "lisp/quicklisp/dists/quicklisp/software")
(:user-cache "qlq"))
((:home "lisp/quicklisp/dists")
(:user-cache "ql"))
((:home "work/src")
(:user-cache "work")))
> I want to do a simple output translation and I just can't figure out what the
> sexp dsl would be for that.
>
> What I want to do. Let's say my asd file is in src/foo/proj.asd. What I
> want is when I build the project, the fasls go in output/foo. I just can't
> figure out how to set up the output translations to make this happen. I'm
> too stupid to grok the section in the manual about the sexp dsl for
> translations.
>
> Help would be appreciated. More examples in the manual (and an updated
> section?) would be really helpful too.
>
> --
>
> Ray
--
Stelian Ionescu
Re: ASDF components are brittle for backwards compatibility
On Thu, 2021-04-29 at 18:58 -0500, Robert Goldman wrote: > On 29 Apr 2021, at 13:38, Marco Antoniotti wrote: > > > Robert, it was you who suggested to use it if I remember correctly. > > > > How would it be different from what you just proposed? > > My suggestion to use the `:properties` slot was not a good > one. Looking > at the code, this slot is clearly marked as being only for ASDF 2 > backwards compatibility (it's hard for me to believe that this is > even an issue any more). Then you can safely un-deprecate it. Unless there is a clear reason to think that using that slot would break existing systems, there's no reason to add another slot. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. signature.asc Description: This is a digitally signed message part
Re: ASDF components are brittle for backwards compatibility
> On 29 Apr 2021, at 11:42, Stelian Ionescu wrote: >> How can ASDF or a developer determine that the unknown property doesn't >> change the semantics of the DEFSYSTEM, and therefore discarding it would >> have an effect that's contrary to the author's intention ? >> ASDF has no syntactic distinction between properties that affect the >> compilation process and mere annotations like author, licence, etc... > You can safely assume that the unknown property doesn't change the semantics, > because if it does, then the system must require a particular version of ASDF. Yes but you can't assume that the system author specified the minimum ASDF version correctly. Developers currently have no way of figuring out what is the actual minimum required version, and version guards are rare and the result of guesswork (including those I put in the libraries I maintain). > In other words, this does not introduce a failure mode that isn't already > present. If there's a `:use-apple-clang` property introduced in ASDF 29.7 and > you didn't put some requirement for ASDF >= 29.7 then your system is busted > whether the user discards and continues or not -- the library developer has > erred, and nothing about this new extensibility makes the problem worse. > But it *does* make it possible to extend ASDF *in safe ways* without > compromising backwards compatibility. > Note the "in safe ways" -- if we added new properties that change the > semantics, we must do something to protect people using older versions. The > proposed capability wouldn't change that one way or another. It just makes it > possible to extend metadata without excessive pain. Instead of dedicating much work to ensuring that newer DEFSYSTEMs work with old ASDF versions, we should make it clear that one should just update ASDF frequently. -- Stelian Ionescu
Re: ASDF components are brittle for backwards compatibility
> ASDF checks to make sure all of the initargs are defined when parsing a > `defsystem`. This is good for catching errors, but is terrible for > extensibility. This means that any attempt to add additional metadata will be > backwards incompatible. > I can think of two ways to fix this: > 1. Add a "garbage can" slot to `component` that will be filled with a > property list, and allow programmers to do whatever they want here. This > doesn't seem great to me. > 2. Add a new `defsystem` parsing error class that is > `unknown-component-property`, raise it when an unknown property is > encountered and allow the user to continue, discarding the initarg and > accompanying value. > The second alternative is what I favor. It isn't great, because it will only > maintain extensibility going forward, but I think it's the best we can do. How can ASDF or a developer determine that the unknown property doesn't change the semantics of the DEFSYSTEM, and therefore discarding it would have an effect that's contrary to the author's intention ? ASDF has no syntactic distinction between properties that affect the compilation process and mere annotations like author, licence, etc... > I suppose that we could also add an initarg to tell ASDF to continue such > errors silently. > I'd be inclined to suggest that this take an ASDF version expression as > value, so that the error is quietly ignored only by ASDF versions below that. > This means that the property will start to be checked when it has become > authoritative. > Note that for one's own `system` and `component` subclasses, the set of > initargs can be extended without any monkeying around. This is a recipe for maintenance nightmares. Let's not go there. -- Stelian Ionescu
Re: Apologies for slow progress...
On Sat, 2020-08-01 at 15:00 -0500, Robert Goldman wrote: > I'm afraid I have been very busy at work, but also the linux box I > have > been using as my Jenkins platform had a disk failure, taking it out > of > action. > > No data was lost, but my employer has been supplying this, and I have > to > wait in the queue, after business requirements, for the IT folks to > get > me a new server configured for this purpose. > > This has unavoidably hindered my work on ASDF. > > I'm open to suggestions about alternative resources for running > these > tests, but there are special challenges because I need to be able to > put > commercial software (Allegro CL and LispWorks) on any test server, > which > I think rules out using Travis. What are the challenges ? Allegro works well on Travis, and the limitations of Lispworks Personal are well known. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. signature.asc Description: This is a digitally signed message part
Re: Is anyone actually using the deferred warnings code?
I used to use it, then it broke months ago on my local setup so I just disabled it. > > AFAICT, it is disabled by default, and it is not documented in the > ASDF manual.> So is this code even live, except for in the test scripts? > It was pretty painful to get this to work because it relies on > unexported (and hence unstable) SBCL internals.> My *guess* is that this was > originally done as a way to dispense with > WITH-COMPILATION-UNIT and hence potentially parallelize the > compilations.> If no one is even using it, I am tempted to move it to be a > contrib > and drop it from the tests and maintenance as part of core ASDF. > Maybe it would be better as a part of a POIU extension to ASDF, and > relieve me of dealing with these SBCL compiler internals?> Cheers, > r -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.
Re: [E] new compiler error re: SET-DISPATCH-MACRO-CHARACTER
On Thu, 2017-10-12 at 13:03 -0500, Robert Goldman wrote: > That may be, but it was unfair to get angry at the ASDF maintainers > about this. This is just a pre-existing error that was *manifested* > because of a change in ASDF. It's not our fault that this error > appeared, it's not our fault that the puri library is no longer > maintained, and we can't be expected to avoid releasing improved > versions of ASDF because there exists buggy, unmaintained code in > Quicklisp. No it's not your fault, but I think it would be a very sensitive idea to avoid annoying ASDF users, simply for practical reasons, because you'll find yourself with people who fork or refuse to update ASDF. Something more useful would be to: * introduce the notion of ASDF compilation options, as a set of key- value pairs which control different compilation modes or effects * make the new strictness modes, like preserving the readtable, depend on those toggles, but upon introduction the default should be perfect backwards-compatibility, even if that is something you consider broken * blog about the fancy new way toggle and explain why it's better to use it than not * let the libraries' users nag the developers to change the code to be compatible with the new strictness checks * wait a couple of years (at least) until you see that most of Quicklisp libraries have been ported to the new way of doing things and if that happens maybe consider turning it on by default. In that case, announce it publicly * if adoption didn't happen, keep it disabled happily knowing that you can always turn it on in your company's internal projects. This is more or less how we do things at work. It has a certain amount of overhead but it gains you good will from the community; on the other hand enabling things by default, and on a short notice, only makes you seem like you're imposing your preference on everybody else just for the sake of it. I think it's better to let things sink in and allow the users of ASDF to come to a consensus, although that's a slow process. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. signature.asc Description: This is a digitally signed message part
Re: Upgrade failures for asdf-3.1.7 and later
My apologies if the misunderstanding was mine. I think there's a great need for an implementation manager that forces its own ASDF, among other things.In my smalll CL implementation .rc framework I wrote, I always load a pinned ASDF, completely ignoring the host ASDF or the one in Quicklisp - and also eschewing the ASDF upgrade mechanism. I found that it worked much better and never broke in the last 4-5 years since. > My understanding is that LispWorks PE does NOT provide any version of > ASDF whatsoever, that Quicklisp then provides the less-than-useful > ASDF 2.26, and that the user tries to load an ASDF 3 on top of that. > Which can't work.> > On Thu, May 4, 2017, 13:20 Stelian Ionescu <sione...@cddr.org> wrote:>> >>> The main thing is: do NOT use ASDF 2. >>> Please address your complaints to Xach for the disservice of >>> providing it.>> >> Fare, do try to read more thoroughly what you're replying to. The old >> ASDF here is the one bundled with LispWorks PE, not the one in >> Quicklisp.>> >> -- >> Stelian Ionescu a.k.a. fe[nl]ix >> Quidquid latine dictum sit, altum videtur. >> -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.
Re: Upgrade failures for asdf-3.1.7 and later
> The main thing is: do NOT use ASDF 2. > Please address your complaints to Xach for the disservice of > providing it. Fare, do try to read more thoroughly what you're replying to. The old ASDF here is the one bundled with LispWorks PE, not the one in Quicklisp. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.
Re: Impact on modifying the current planning code (was Re: Plans for ASDF 3.3)
> On 5/4/17 18:41, Stelian Ionescu wrote: > […] > > > ASDF currently (for Lisp) doesn't support > >> a maximum version number, only a minimum. I keep meaning to fix that, > >> but never get around to it. > > > > I believe this would be doubling down on the error of specifying versions > > in ASDF. > > But as long as we have a notion of ASDF:VERSION it should certainly have > a possible upper bound capability for its assertions, whatever your > local mapping to such assertions may be… I would rather start by deprecating it. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.
Re: Impact on modifying the current planning code (was Re: Plans for ASDF 3.3)
> On 5/4/17 May 4 -11:01 AM, Alan Ruttenberg wrote: > > Here is what I see a problem is: ASDF only resolves dependencies on a > > system by system basis. The cross-system link is that if system B > > depends on system A we can avoid loading A if it has already been > > loaded. If an identical source file happens to be in both B and A that > > isn't recognized, but also doesn't have consequence - the functions in > > it are redefined. > > That's correct. If you want to build a composite system with A and B, > you should create a system C that depends on both. > > Note that this problem you cite for Maven really exists for ASDF anyway. > If you have two lisp systems that collide with each other (e.g., > package collision), then you lose with ASDF. > > So I think what you have to do here is track the Maven dependencies, > detect incompatible versions of a single library, and throw an error for > the programmer to fix if it happens. > > Note that this reminds me that ASDF currently (for Lisp) doesn't support > a maximum version number, only a minimum. I keep meaning to fix that, > but never get around to it. I believe this would be doubling down on the error of specifying versions in ASDF. > And yes, it does happen, I have had systems > that relied on, e.g., older versions of XMLS. For now we handled that > by pinning revisions in the RCS, but that can be problematic if you get > the ASDF config wrong. Getting it wrong in what sense ? -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.
Re: Incremental defsystem dependencies
> Dear Stelian, dear Lispers, [...] > > Stelian, how sad would you be if you have to segregate > > defsystem-depends-on to refer to systems in separate files? > > > Stelian, what do you think? I would be quite sad, because from my point of view as a user the whole point of the slash-systems was to have all systems in a library in a single file. That said, it's mostly an æsthetic concern, I can live with it. I suppose this shows one more time the limits of the naively parsing .asd files using CL:EVAL. One can't easily do a two-pass evaluation of the definitions therein. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.
Re: Version 3.1.7.35 has been pushed
> I think we wait for iolib, but probably not ASDF system connections. Its > github site shows no commits for four years, so that might be a long wait IOlib fixed. I'll make a new release next week. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.
Re: Enforcing assumptions
On Fri, 2016-09-23 at 18:32 -0500, Robert Goldman wrote: > On 9/23/16 Sep 23 -6:24 PM, Stelian Ionescu wrote: > > > So, ok, what IS it about an ASD file, that is not DEFSYSTEM, that > > > > must > > > > be evaluated inside LOAD-ASD? If it's just "you could wreck the > > > > syntax > > > > behind my back," yeah, that's true, but you could wreck the > > > > syntax > > > > behind my back and wreck the library I'm loading, too, so why > > > > is it > > > > ASDF's job to fix that here? If LOAD is broken, why is it our > > > > job to > > > > make LOAD-ASD and fix a tiny corner of the problem? > > Because unless you have the resources to fix the language in a > > major > > way, you can only do small incremental improvements. Very > > pragmatic. > > Not ideal. > > But my claim is that it is NOT an improvement if you turn a language > which is incrementally compilable into a language that only works if > you > load it through LOAD-ASD. > > What we have done with LOAD-ASD is to take away code that is runnable > with compile-sexp and replace it with code that is only runnable with > LOAD-ASD. > > It's obviously exaggerating, but it's a step towards taking what > makes > CL great, and taking that away and giving us C instead. > > Now, of course, people like me can put our packages in our asd files > and > things should keep working, but what's the contract with the > programmer > here? > > Are we going to shove more stuff into LOAD-ASD, further divorcing the > ASD-dialect from mainstream CL? > > Anyway, here's my proposed solution: > > 1. Don't enforce the use of LOAD-ASD. Probably people can understand > this well enough. Enforce it but add a way to disable it, but not a simple dynamic variable. A new function, e.g. (setf (asdf:flag :enforce-load-asd) nil) And a way for the programmer to query the current set of ASDF flags. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. signature.asc Description: This is a digitally signed message part
Re: Enforcing assumptions
. And as > > > a > > > programmer, I don't want ASDF to let me evaluate a DEFSYSTEM form > > > only > > > to beat me up because some invisible context, only apparent > > > through > > > reading the code, means that it doesn't work. > > > > > > Pick one, DWIMing, or freestanding execution, but you get only > > > one. > > > > > There too I don't understand your reasoning. Who are you helping, > > and > > who are you harming? > > > > There always was a constraint on loading a .asd, and never was one > > on > > using defsystem. We can assume that all software that works fits > > those > > constraints, but might not fit tighter ones. Why make it harder to > > use > > defsystem? What would you check exactly? > > I don't get it. You are saying on the one hand "you have to have the > right context to evaluate the contents of an asd file," and on the > other > hand "don't stop me from evaluating ... the contents of the asd > file." > What is it about an ASD file reading that requires this context, if > it's > not the > > Loading an ASD is not a lisp thing, though. Loading an ASD file > involves evaluating the forms inside the file. > > > > To me, setting the syntax context is an essential service to > > provide to > > whoever writes a .asd file. The .asd maintainer cannot assume > > anything > > about the syntax context used by the user, who may not control the > > syntax context from the end-user. If you can't even trust the > > package or > > readtable, or character encoding, you can't even write code that > > has any > > guaranteed meaning. Note that it's called .asd rather than .lisp > > for a > > good reason: it's Lisp code, but supposed to run in a specific > > context. > > But that's true of EVERY Lisp file! If you just write arbitrary > code, > that relies on symbols from specific packages, and syntax from > specific > readtables, and you don't put an IN-PACKAGE and readtable > specification, > it will break. But I don't try to control what you do when you are > writing arbitrary lisp code. So clearly it's not "essential." Why do > we > do it for ASD files? What's so hard about leaving it to the > programmer > to get this right? Why did we have to make that our job instead of > the > programmer's job? Because most Lispers don't know ASDF enough to get it right. If it can be fixed in a single point, it should. > Worse, we have broken that invaluable debugging tool > of interactive execution of code, by encouraging programmers to rely > on > our use of LOAD-ASD. LOAD-ASD is still interactive execution of code, just in a saf(er) implicit environment. It's not a distinct parser. > > Actually, when I read your reasoning, I think I see that this *is* > generally true (especially your remarks about the readtable). This > suggests to me that what you are really doing here is chewing off a > tiny > corner of CL, and in that tiny corner, you are trying to fix a thing > that is broken about the language -- but only in that tiny corner. > > I concede that this ship has sailed, and there's no tearing down > LOAD-ASD, although I dearly wish I could. > > But again, I feel very frustrated, because I feel like you are saying > to > me "there's SOMETHING in every .asd file that should only be > evaluated > in the context of LOAD-ASD, but I'm telling you it's not DEFSYSTEM, > and > I'm not telling you what it is." Or even, "asd files should never be > loaded, or evaluated, except through LOAD-ASD, but any form in an asd > file can be." > > So, ok, what IS it about an ASD file, that is not DEFSYSTEM, that > must > be evaluated inside LOAD-ASD? If it's just "you could wreck the > syntax > behind my back," yeah, that's true, but you could wreck the syntax > behind my back and wreck the library I'm loading, too, so why is it > ASDF's job to fix that here? If LOAD is broken, why is it our job to > make LOAD-ASD and fix a tiny corner of the problem? Because unless you have the resources to fix the language in a major way, you can only do small incremental improvements. Very pragmatic. Not ideal. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. signature.asc Description: This is a digitally signed message part
Re: Enforcing assumptions
> I have been working on enforcing assumptions recently added to the ASDF > docs. Specifically, that OPERATION instances only be created by > MAKE-OPERATION and SYSTEMs only be parsed inside LOAD-ASD. > > I should have a merge request up for review soon, but find that it's > more tricky than I expected, because we don't even play by the rules > ourselves! Specifically, there are calls to MAKE-INSTANCE on OPERATIONs > in the ASDF codebase itself. Thank you for the work. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.
Re: Another follow-up from yesterday's doc reviews
On Thu, 2016-09-22 at 14:24 -0500, Robert Goldman wrote: > On 9/22/16 Sep 22 -2:07 PM, Stelian Ionescu wrote: > > On Thu, 2016-09-22 at 14:04 -0500, Robert Goldman wrote: > > > On 9/22/16 Sep 22 -1:56 PM, Stelian Ionescu wrote: > > > > > The comments in the file say that we *must* use load-asdf to > > > > > load > > > > > a > > > > > .asd file, but not *WHY* we must do so. > > > > > > > > > > Why is this necessary? > > > > > > > > Because asdf:load-asdf sets up the correct evaluation > > > > environment, > > > > including setting the correct *package*. > > > > > > > > > > OK, again, if this is required, why don't we ENFORCE it? > > > > Because in some specific cases it could be made to work without it > > (all > > ASDF symbols package-prefixed, etc...) and some old-timers > > complained > > that we're breaking their dev workflow if we make it impossible to > > reload an .asd using C-c C-c or cl:load > > > > I'm one of those old-timers, TBQH. I interactively compile a lot of > code, and I don't see why DEFSYSTEM forms should be different. > > I'm not a big fan of making stuff that looks like CL code, but > doesn't > *behave* like CL code. > > If we can't LOAD a file with a DEFSYSTEM form, or EVAL a DEFSYSTEM > form, > why do we READ them? Parsing DEFSYSTEM forms with CL:READ is simply convenient, especially since, as Lispers, we expact Lisp syntax. > Why don't we make DEFSYSTEM forms NOT be legal CL > forms? They are CL forms, they just require a certain implicit evaluation environment, which is set up by ASDF:LOAD-ASD. > > I don't want ASDF to turn into a minefield of assumptions that > require > its users to carefully read the source to use it properly, because > things that are otherwise sensible cause random stupid things to > happen. > > So: let's either ENFORCE the use of LOAD-ASD or let's get rid of it. > Not enforcing it if it needs enforcing is the bad midpoint on this > continuum. I agree it should be enforced. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. signature.asc Description: This is a digitally signed message part
Re: Another follow-up from yesterday's doc reviews
On Thu, 2016-09-22 at 14:04 -0500, Robert Goldman wrote: > On 9/22/16 Sep 22 -1:56 PM, Stelian Ionescu wrote: > > > The comments in the file say that we *must* use load-asdf to load > > > a > > > .asd file, but not *WHY* we must do so. > > > > > > Why is this necessary? > > > > Because asdf:load-asdf sets up the correct evaluation environment, > > including setting the correct *package*. > > > > OK, again, if this is required, why don't we ENFORCE it? Because in some specific cases it could be made to work without it (all ASDF symbols package-prefixed, etc...) and some old-timers complained that we're breaking their dev workflow if we make it impossible to reload an .asd using C-c C-c or cl:load -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. signature.asc Description: This is a digitally signed message part
Re: Another follow-up from yesterday's doc reviews
> The comments in the file say that we *must* use load-asdf to load a .asd > file, but not *WHY* we must do so. > > Why is this necessary? Because asdf:load-asdf sets up the correct evaluation environment, including setting the correct *package*. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.
Re: Question about DEFSYSTEM-DEPENDS-ON
[...]
> On 9/22/16 Sep 22 -9:25 AM, Stelian Ionescu wrote:
> > [...]
> >>> This is the problem I would most like to see solved in ASDF.
> >>>
> >> (defsystem "foo-test"
> >> :defsystem-depends-on ("fiveam") :depends-on ("foo")
> >> :class "fiveam-asdf:fiveam-tester-system"
> >> :components (("some-system:its-component-class" "myfile" ...) ...) ...)
> >>
> >> This has been working since 2.31.4.
> >>
> >> IIRC, it was Stelian who prodded me to get D-D-O working properly.
> >
> > I try to use as many ASDF features as possible and useful, and I think that
> > you can point to iolib.asd as the golden example of current best practices.
> > And yes, I had some issues with D-D-O and Fare fixed them.
> >
>
> I'm boggled. I have been complaining about this issue in the past, and
> I attach an email from February of this year, in which Faré clearly
> implies that there is no solution to the D-D-O/package bad package
> interaction issues. See his point #3.
>
> And now it's been fixed for years? It seems like if so, even Faré
> had forgotten
I think that there are sometimes misunderstandings on mailing lists and
probably the best way to avoid them is to have better documentation. Faré :) ?
Also, maybe I'll get to blogging about best practices in writing ASDF
extensions.
--
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
Re: Question about DEFSYSTEM-DEPENDS-ON
[...]
> > This is the problem I would most like to see solved in ASDF.
> >
> (defsystem "foo-test"
> :defsystem-depends-on ("fiveam") :depends-on ("foo")
> :class "fiveam-asdf:fiveam-tester-system"
> :components (("some-system:its-component-class" "myfile" ...) ...) ...)
>
> This has been working since 2.31.4.
>
> IIRC, it was Stelian who prodded me to get D-D-O working properly.
I try to use as many ASDF features as possible and useful, and I think that you
can point to iolib.asd as the golden example of current best practices.
And yes, I had some issues with D-D-O and Fare fixed them.
--
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
Re: Needed change in governance
On Fri, 2016-09-16 at 12:23 -0500, Robert Goldman wrote: > I can no longer be the maintainer of ASDF unless I gain some control > over the contents of the repository. > > Right now, I am just reacting to changes other people are making. > This > is ok if I am in the loop, but if other developers are simply wading > into the repository and committing changes that I have no idea are > coming, then I cannot do my job. > > The last straw for me was last night's 3.1.7.23 commits, which > completely blind-sided me and also invalidated work-in-progress I had > outstanding. > > So, we need to either > > 1. develop some informal means of clearing coming commits through me, > perhaps using this mailing list; > > 2. lock out other developers and change the main repository only > through > merge requests (this is not my favored alternative, as it requires > more > busy work on my part); or I think this would be the best choice. ASDF is no longer in need of quick changes so delaying commits and pondering longer by way of a code review would be better. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. signature.asc Description: This is a digitally signed message part
Re: set variables before executing the "test-op"
> It's probably wrong to set those settings from your .asd file, since they may > be set or reset before your project runs, or in between two runs. > If you actually care about those variables, define a function that sets them, > and call it at the beginning of those files. > > If you have a lot of files, define a class for those files that does it in > its perform method for basic-load-op. > > As for defining accessors before the packages are interned, > to be executed by a function run *after* they are interned, > you can use such idioms as: > (setf (symbol-value (find-symbol* :*enable-colors* :prove.color) nil) > Note that find-symbol* is defined by uiop, which is :use'd by :asdf-user. > > Alternatively, you could (load-system :prove) in your .asd file, > but it's ugly. This sounds like a good moment to come up with an interface between test-system and the test suite runner, so that you can pass arguments to the test runner directly through asdf:test-system. Using dynamic variables for this use case is a bad idea. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.
Re: :FEATURE dependency-def
> Robert Goldman <rpgold...@sift.net> écrivait: > > > I stubbed my toe on this absent-mindedly compiling Didier's decLt > > system on Allegro Common Lisp. That system doesn't, and cannot, > > function on ACL, but ASDF tells us it has compiled successfully. > > Following up to our private conversation on this... > > I think there's an error on my part to begin with. The core system of > Declt has an :if-feature :sbcl, which prevents it from being loaded > outside SBCL. This is mostly what's needed, but I hadn't realized that > it /silently/ does so, instead of throwing an error if the feature is > absent. > > So the question is: can I declaratively state that a system (or maybe > more generally a component) depends on a feature, so that loading fails > with an error otherwise ? I don't currently see a way. #-feature (error "FEATURE missing") at toplevel, so you get an error on reading the .asd file. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.
Error loading SBCL contribs
I think SBCL commit 25c1769e30ff7404b52a9be663626d87f8ff75bc broke the use of deferred warnings. If I compile SBCL and exec ./run-sbcl.sh, I get this error during Quicklisp initialization: ; file: /home/hechee/lisp/quicklisp/quicklisp/impl.lisp ; in: DEFINE-IMPLEMENTATION-PACKAGE :SBCL ; (REQUIRE 'QL-IMPL::SB-POSIX) ; ; caught WARNING: ; completing compilation for # completed without its output file #P"/home/hechee/work/src/sbcl/obj/sbcl-home/contrib/sb-posix.build-report" ; ; caught WARNING: ; completing load for # completed without its input file #P"/home/hechee/work/src/sbcl/obj/sbcl-home/contrib/sb-posix.build-report" ; (REQUIRE 'QL-IMPL::SB-BSD-SOCKETS) ; ; caught WARNING: ; completing compilation for # completed without its output file #P"/home/hechee/work/src/sbcl/obj/sbcl-home/contrib/sb-bsd-sockets.build-report" ; ; caught WARNING: ; completing load for # completed without its input file #P"/home/hechee/work/src/sbcl/obj/sbcl-home/contrib/sb-bsd-sockets.build-report" While evaluating the form starting at line 129, column 0 of #P"/home/hechee/lisp/quicklisp/setup.lisp": While evaluating the form starting at line 57, column 0 of #P"/home/hechee/.cl-init/asdf-init.lisp": debugger invoked on a UIOP/LISP-BUILD:COMPILE-FILE-ERROR in thread #: COMPILE-FILE-ERROR while compiling # Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [RETRY] Retry compiling #. 1: [ACCEPT ] Continue, treating compiling # as having been successful. 2: Retry ASDF operation. 3: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting the configuration. 4: [RETRY] Retry EVAL of current toplevel form. 5: [CONTINUE ] Ignore error and continue loading file "/home/hechee/lisp/quicklisp/setup.lisp". 6: [ABORT] Abort loading file "/home/hechee/lisp/quicklisp/setup.lisp". 7: Retry EVAL of current toplevel form. 8: Ignore error and continue loading file "/home/hechee/.cl-init/asdf-init.lisp". 9: Abort loading file "/home/hechee/.cl-init/asdf-init.lisp". 10: Retry EVAL of current toplevel form. 11: Ignore error and continue userinit file "/home/hechee/.sbclrc". 12: Abort userinit file "/home/hechee/.sbclrc". 13: Skip to toplevel READ/EVAL/PRINT loop. 14: [EXIT ] Exit SBCL (calling #'EXIT, killing the process). (UIOP/LISP-BUILD:CHECK-LISP-COMPILE-RESULTS NIL T T "~/asdf-action::format-action/" ((# . #))) source: (ERROR 'COMPILE-FILE-ERROR :CONTEXT-FORMAT CONTEXT-FORMAT :CONTEXT-ARGUMENTS CONTEXT-ARGUMENTS) There's no obj/sbcl-home/contrib/sb-posix.build-report, or any build -report file, just several test-passed.test-report under obj/asdf -cache/ Funny though that I don't get this error if I exec sbcl through an absolute path, e.g. ~/work/src/sbcl/run-sbcl.sh, it's only when I call it from the source directory as ./run-sbcl.sh -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. signature.asc Description: This is a digitally signed message part
Re: Is it possible to load multiple versions of the same system?
Maybe, under rare circumstances. With my QA hat on, I say better not to try. > > I've been reading the manual, papers, and slides on ASDF and XCVB. As > a frame of reference, I prefer the qualities exhibited by Racket's > implementation of modules. I was disappointed both to see XCVB > bitrot, and then to see that a major ASDF overhaul would be necessary. > > That said, ignoring Racket/ASDF/XCVB, I'm curious about how loading > multiple versions of the same system could possibly be implemented in > Common Lisp (CL). I'm sure people have thought about it, but I'm > having a hard time finding references. I'm afraid I've been skimming > some of the material linked off of the ASDF and XCVB pages, so forgive > me if I missed something. > > On the JVM, there's the notion of "classloader" that can be used to > load multiple versions of the same class. Unfortunately, the only > approach I can imagine is to use some form of package renaming. There > appear to be several variations floating around [1], and the trade- > offs aren't clear to me. > > If I think about how it might be done in ASDF, it seems like it would > require a series of things: > > * intercept package definition to rename with version > * :around-compile to handle some kind of per-system aliasing so code > doesn't have to change > * teaching dependency resolution how to find the renamed, versioned > packages/systems > > But that's a wild guess. And the more I think about it, I wonder what > to do about some code that uses strings to put together a symbol - I > don't think symbol-macrolet can help there. > > [1] implementation-specific package-local-nicknames, :around-compile > in ASDF, "pseudonyms" > > -- > Ian Tegebo -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.
Re: A modest proposition: DEFSYSTEM-DEPENDS-ON should die [was Re: What's the right way to extend ASDF with new symbols?]
On Mon, 2016-02-15 at 11:13 -0600, Robert Goldman wrote: > On 2/15/16 Feb 15 -10:26 AM, Stelian Ionescu wrote: > >> On 2/12/16 Feb 12 -3:15 PM, Stelian Ionescu wrote: > >>> On Fri, 2016-02-12 at 16:07 -0500, Faré wrote: > >>>> I'm OK with declaring DEFSYSTEM-DEPENDS-ON a failure, and load-system > >>>> (or load-systems) the official way to go. But > >>>> > >>>> 1- This of course requires heads up, updating all users before > >>>> retiring the feature, etc. From my experience, if you start seriously > >>>> deprecating today and sending patches to all authors who use it in > >>>> quicklisp, you can expect to be removing that part of the code in two > >>>> years or so. > >>>> > >>>> 2- To make these dependencies work properly still requires modifying > >>>> ASDF to add explicit plan nodes for loading ASD files, that will > >>>> contain the systems loaded by load-system. The same trick will also > >>>> automatically make the :defsystem-depends-on work, since it itself > >>>> calls load-system. > >>>> > >>>> 3- Yes, defining things in the ASDF package is ugly, but extensions > >>>> are few enough, and using a prefix is a good enough namespace > >>>> management strategy. Not the most horrible thing that working with CL > >>>> does to you. > >>> > >>> Please don't. It's a net improvement compared to the previous situation. > >>> It's easy to simply name your class with a keyword :package/foo-file. > >>> > >> > >> With all due respect, no, it is not. It is a net *negative* with > >> respect to the previous situation. Here are the reasons why, briefly > >> reiterated: > >> > >> 1. It effectively forces you to stick new symbols into the ASDF namespace. > > > > Technically yes, but that's not the essential requirement. Because the CL > > reader interns eagerly, ASDF extension classes need to be interned into a > > package that is owned by ASDF. Currently that's the ASDF package itself, > > but it would be a good idea to add a special package for extensions, and > > start encouraging people to use that by showing appropriate deprecation > > messages. > > This doesn't do anything to resolve the underlying problem, AFAICT. > I.e., instead of getting name collisions in ASDF (I believe that's > ASDF/INTERFACE), we get name collisions in ASDF/EXTENSIONS. I don't see this as a problem. A few times there were collisions in Quicklisp, so somebody had to rename the project/package, etc... If two different authors want to use asdf/extensions::foo/file then one will have to give up. This is a technical problem(the design of the CL reader) that is best solved socially. Also, it's not like people write new ASDF extensions everyday. > > Am I missing something about this suggestion? > > > > > >> I don't understand your proposed rebuttal, involving slash-named > >> packages. I don't see any evidence of this being legal ASDF syntax, > >> looking at FIND-CLASS*, and trying an experiment. If it works, it needs > >> documentation. If it does not work, it will not be added -- ASDF must > >> get simpler, not more complex. Please amplify, thanks! > > > > It's not "syntax", it's just manual namespacing. The symbol > > 'asdf::pkg/class is symply a legal symbol. And I don't agree that ASDF must > > get simpler at all costs, rather that it should have as simple an > > implementation as possible, while still allowing the use cases that its > > users require. > > With all due respect, I believe ASDF to be unmaintainable now, except > for a Hail Mary Pass to Faré at regular intervals. Again, you are > welcome to have a whack at it. I won't be upset if you prove me wrong! > > > > > >> 2. If you are arguing that we can just solve this with a naming > >> convention, I don't buy it. Consider different libraries, each of which > >> hook ASDF to normal "make" by creating MAKE-FILE and MAKE-OP classes. > >> This is not a far-fetched example; I have seen it. They both try to jam > >> these symbols into ASDF. > > > > See my previous reply. > > > > > >> This behavior should be *strongly* discouraged, even to the extent of > >> (as I said earlier) package-locking ASDF when possible. Currently, it > >> is actively *ENCOURAGED* -- close to mandated, in fact. > > > > By dedicating a package for naming extension classes, we
Removing load-sysdef
... broke SLIME's contrib/swank-asdf.lisp -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. signature.asc Description: This is a digitally signed message part
Re: Suggestions for procedure going forward
On Tue, 2015-11-17 at 11:11 -0600, Robert Goldman wrote: > We have had a number of ASDF 3 releases that have mostly been aimed at > bug-fixing (although some new features have crept in). > > I'd like to declare ASDF 3 feature complete and done, but I don't want > to close the door to future bug fix releases as needed, nor do I want to > shove incomplete new features out in order to get bug fixes out. One suggestion I have before doing that is to remove the whole upgrading mechanism. The purpose of it was to allow loading ASDF3 over ASDF 1/2 when the various implementations were only shipping with the latter, but IMO it's now just a burden. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. signature.asc Description: This is a digitally signed message part
Re: monolithic-lib-op
> On Tue, Oct 6, 2015 at 2:30 AM, Florian Margaine <flor...@margaine.com> wrote: > > After speaking a bit with jackdaniel on irc, it seems that the issue is > > correctly writing the .a files? If so, since it's a simple ar archive, this > > could be done in Lisp. I wrote an ar writer in less than 100 lines with some > > hard coded values: > > https://github.com/ralt/deb-packager/blob/master/src/ar.lisp > > > > The format is basically: a global header followed by the entries. (Entries > > format is relatively straightforward, I invite you to look at the code.) > > > > I think it would be pretty straightforward to implement the reader in Lisp > > to manually add .o files to the end of the .a archive. (Basically, add new > > entries at the end of the archive.) > > > > Maybe I haven't fully understood the issue though. In that case, you can > > fully ignore me :-) > > > Well, *if* we move that code from CFFI (my current branch of it) to > ASDF (post 3.1.6 release), > that's about 300 more lines to add to ASDF (and probably even more > lines to support 10 additional implementations). > I don't know whether or not we want that, and if we do, whether 100 or > 200 additional lines for ar support are OK. > Maybe we could require libtool when running on BSD. Meh. Maybe it's not such a bad idea to bundle libtool with CFFI. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib
Re: Understanding UIOP/RUN-PROGRAM
> In a potentially memory constrained environment, I need to portably > (across sbcl and ccl at least) process a potentially large (multiple > GiB) stream of bytes output from a Linux command. For the curious, > "process" here means encrypt with a block cipher and push to the > network; whereas the UNIX command is the output of "btrfs send". > > I wanted to confirm with ASDF developers that as far as I can tell from > wrangling with UIOP:RUN-PROGRAM, it isn't going to do what I want > because there is no "asynchronous" mode. UIOP:RUN-PROGRAM cannot be > "run in the background" like SBCL's SB-EXT:RUN-PROGRAM with :wait nil > that allows the output of the sub-process to be gathered and processed > in blocks. So, it would always be the case that > UIOP/RUN-PROGRAM::SLURP-INPUT-STREAM has "gone through" all the > (potentially huge) output of the sub-process before UIOP:RUN-PROGRAM can > return. Yes, UIOP:RUN-PROGRAM is synchronous. For an asynchronous and portable function I suggest IOLIB/OS:CREATE-PROCESS. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib
Re: [asdf-devel] Make the CL syntax predictable
On Sat, 2014-03-29 at 19:59 +0100, Pascal Costanza wrote: [...] That's not how it works, unless you include a bit for *rdff* in the name of the fasl cache directory — and since the planning is done based on pathnames before the compilation happens, that should still be *rdff* at the beginning of compilation. Otherwise, the build is not deterministic, and two different toplevel programs will poison each other's builds. …not even if you :force t? If you make :force t the default, you lose incrementality, and fast startup time for end-user scripts. If you say things are unsafe by default, you lose modularity and you make it impossible to distribute scripts to end users. Either way, if you don't have a deterministic build *by default*, easy deployment of scripts to end-users is not possible anymore. I understand your desire for deterministic builds. I don’t understand your desire for deterministic builds being the default. Utterances like this is what makes academic an insult in certain circles. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. signature.asc Description: This is a digitally signed message part
Re: [asdf-devel] optimization settings
On Wed, 2014-03-19 at 17:22 -0500, Robert Goldman wrote: Robert Brown wrote: Does ASDF set compiler optimization settings before compiling each file when building? I'm concerned that changing the optimization setting inside one source file could cause the change to stick and be used for other files. I don't think the CL standard mandates that (declaim (optimize ... )) applies only to the current file. The issue is similar to that of readtables ... To the best of my knowledge (i.e., I'm not looking it up again right now!) you are right that the standard does not mandate file-scope for DECLAIM, and I have a *vague* memory that some implementation does allow it to leak. I am reluctant to add this to the set of things that ASDF (mis)manages for the programmer. E.g, I think SBCL has a policy setting that is intended to provide a default setting for the optimization parameters. However, you COULD do this yourself, I believe, by writing an :AROUND method for PERFORM COMPILE-OP on your own system. I'm actually not sure what the right mechanism is. Would it be: (defmethod perform :around ((op compile-op) (c my-optimized-files)) (locally (declare (optimize (speed 3) (good-looking 11))) (call-next-method))) LOCALLY has lexical scope. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. signature.asc Description: This is a digitally signed message part
Re: [asdf-devel] Alternate default lisp system location
On Wed, 2014-03-12 at 23:30 -0400, Daniel Herring wrote: On Wed, 12 Mar 2014, Faré wrote: Major changes like that happen less than once a year (ASDF 2 in 2010, ASDF 3 in 2013, ASDF 3.1 soon in 2014), and while backward-compatibility has always been a huge priority, improvements sometimes do mean the recommended way of using ASDF changes, for the better. For essential infrastructure like what ASDF claims to be, I expect major changes to happen less than once every 5 to 10 years. You can expect whatever you want, but unless somebody is paid full-time to work on ASDF, it's not going to happen. The more backwards compatibility, the better. Projects like glibc have developed significant infrastructure to enable transparent improvements (see the ABI compliance checker, DSO symbol versioning, etc.). See above. That kind of backwards-compatibility is very difficult and burdensome. Every breaking change inflicts cost on a fraction of the existing userbase, in exchange for some proposed benefit to future users. Every time I have to debug breakage and change something or redesign my workflow to maintain existing capability, it encourages me to explore other, more stable or better designed options... Sometimes good ideas fade after a month or two of reflection. Some survive the test because the benefit truly outweighs the cost. When that is the case, it is often helps to give the community time to prepare and minimize the number of times the community must change. So propose the change, allow a long RFC window, allow users to obtain test implementations (while still promoting the stable branch), wait a while for several changes to collect before pushing them into major new releases, etc. I agree that an RFC-like process would be useful, instead of jumping in and implementing new features, as long as it's not too lengthy. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. signature.asc Description: This is a digitally signed message part
Re: [asdf-devel] Alternate default lisp system location
On Thu, 2014-03-13 at 13:42 -0400, Faré wrote: [...] force and force-not were done well. The interaction between the two was not well thought out, but obviously no one relied on the interaction before force-not was implemented, so that was backward compatible, and the recent change keeps the previously useful uses working, so it is arguably, too. It's not like my changes were done in secret. They weren't done in secret, but many of them were just commits with no discussion on the list. [...] Every release comes with release notes that mention changes to the API. I haven't announced changes with every commit, because that would be verbose, and people who're interested can already read the git log. Where are the release notes ? asdf-3.0.3.tar.gz(a tar bomb) contains no such thing, nor the git repository. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. signature.asc Description: This is a digitally signed message part
[asdf-devel] Re: Release notes
On Thu, 2014-03-13 at 13:30 -0500, Robert P. Goldman wrote: Stelian Ionescu wrote: [...] Every release comes with release notes that mention changes to the API. I haven't announced changes with every commit, because that would be verbose, and people who're interested can already read the git log. Where are the release notes ? asdf-3.0.3.tar.gz(a tar bomb) contains no such thing, nor the git repository. That's a good point. There is a pretty comprehensive changelog, but it's buried in the debian/ subdirectory. There's always been a release announcement emailed out, but that isn't included in the tarball. I'll try to improve our practice here. Proposal: before releasing I will put release notes into the top ASDF directory. These will be the same as what goes in the email message. I'll also make sure there's a copy of the changelog at the top level, with a cross-reference. Subscribers to ASDF-devel will be urged to review these and suggest improvements, before the release is made official. Does this sound like a reasonable process? It's a good idea. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. signature.asc Description: This is a digitally signed message part
Re: [asdf-devel] BUILD-OP
On Thu, 2014-03-13 at 13:40 -0500, Robert P. Goldman wrote: I'm a little concerned about making BUILD-OP be the default operation. It seems to me that BUILD is not a good synonym for LOAD, which is how BUILD-OP is currently interpreted. I agree. I think the conventional interpretation of the word build would suggest to the user that (build foo-system) would compile and NOT load foo-system, instead of performing LOAD-OP as now. To me build does not connote load. Is this just me? What's the sense of the community? Should we use a different term? I realize that LOAD is taken, and shadowing CL:LOAD would be a big PITA. Is there a synonym we can use? Not necessarily a PITA. Does any package :use ASDF ? Otherwise you'd get away with qualifying cl:load in uiop-build/load* and shadowing it in a few packages. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. signature.asc Description: This is a digitally signed message part
Re: [asdf-devel] Alternate default lisp system location
On Thu, 2014-03-13 at 14:52 -0400, Faré wrote: It's not like my changes were done in secret. They weren't done in secret, but many of them were just commits with no discussion on the list. As long as the change hasn't been released, it's up for discussion. Do you seriously expect people to review the commit stream for potentially harmful changes/addition ? -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. signature.asc Description: This is a digitally signed message part
Re: [asdf-devel] BUILD-OP
On Thu, 2014-03-13 at 14:59 -0400, Zach Beane wrote: Stelian Ionescu sione...@cddr.org writes: On Thu, 2014-03-13 at 13:40 -0500, Robert P. Goldman wrote: I'm a little concerned about making BUILD-OP be the default operation. It seems to me that BUILD is not a good synonym for LOAD, which is how BUILD-OP is currently interpreted. I agree. I think the conventional interpretation of the word build would suggest to the user that (build foo-system) would compile and NOT load foo-system, instead of performing LOAD-OP as now. To me build does not connote load. Is this just me? What's the sense of the community? Should we use a different term? I realize that LOAD is taken, and shadowing CL:LOAD would be a big PITA. Is there a synonym we can use? Not necessarily a PITA. Does any package :use ASDF ? It's not uncommon to see a given system file define a package like: (defpackage foo-system (:use cl asdf) ...) Good point. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. signature.asc Description: This is a digitally signed message part
Re: [asdf-devel] Alternate default lisp system location
On Thu, 2014-02-27 at 22:30 -0600, Robert P. Goldman wrote: How would you all feel about an alternate default location for lisp systems, in addition to ~/.local/share/common-lisp/source/ I'm sure that .local was chosen out of the (in)finite wisdom of XDG, but it just seems odd to me to hide the lisp systems from the user, which we are doing by putting them in a location that requires ls -a. After all, these are systems, not configuration files. What about ~/asdf-systems which doesn't make the poor user play peekaboo? I came across this while editing the manual. I don't use this directory myself; maybe everyone loves it. Or maybe no one uses the standard default, and I shouldn't care. I would ask you not to add any more hard-coded directories to ASDF, and remove the already existing ones. If what you want is making life easy for newcomers, make an additional tool that initializes a work environment with convenient values, but separate the configuration of ASDF from the core. The only reason why ~/.local/share/common-lisp/source/ hasn't caused complaints is because nobody was already using it. In my case, ~/lisp has large numbers of duplicate .asd files and other systems I don't want to expose so a :tree recursion there would be very annoying. And please don't tell me to :ignore-inherited-configuration, for what's the point of the default configuration if so many people either don't use it or have to explicitly ignore it ? -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. signature.asc Description: This is a digitally signed message part
Re: [asdf-devel] Alternate default lisp system location
On Wed, 2014-03-12 at 09:20 -0500, Robert P. Goldman wrote: Stelian Ionescu wrote: 1) install Quicklisp, it's easy and painless 2) put your projects in $QUICKLISPDIR/local-projects/ done. I get you, but I don't like it. That's like saying I want to make my first C program. OK, let me teach you how to use apt-get. Yes, and it's a very good idea to do just that because either you want to use ASDF to load other libraries in which case you need QL, or a simple file will suffice. Maybe this is the right answer, but it's not a path to getting a minimal understandable config for ASDF. All that's happening here is that Quicklisp is hiding the complexity. Which is very good. People that write .asd files aren't beginners. I am reminded of Clojure: I want to write my first Clojure program, what do I do? First learn how Leiningen works. Yes. Want to learn node.js ? Use npm. Want to learn ruby ? Use gems. Want to learn python ? Use pip. etc... I am happy for people to tell novices to start with Quicklisp, don't get me wrong. And if that's their path into programming, instead of starting through ASDF, I'm fine with that, too. But it doesn't remove the need for a trivial path into ASDF. Your email does suggest that ~/asdf-local-projects/ might be a suitable location... Similarly, it's unacceptable to have as the first instruction in our manual go off, find and install a script that configures our tool. That means that we have failed to provide an easily configurable tool. What you want to provide is not an easily configurable tool, but an already-configured tool. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. signature.asc Description: This is a digitally signed message part
Re: [asdf-devel] Alternate default lisp system location
On Wed, 2014-03-12 at 10:04 -0500, Robert P. Goldman wrote: Stelian Ionescu wrote: It's very easy not to have a default directory at all. I'm sorry, I don't agree that this claim is correct. You don't agree that it's always easier not to do anything ? Really ? I have just pushed my current draft of the ASDF manual, and I urge you to read it. I've read it. I think you will find that the configuration of the source search path is *very* complex, indeed too complex for a beginner. If it's complex, simplify it. You'd piling more stuff on top of the current behaviour. It's great for hackers with complex requirements, but there's too much to be read if you just want to make one or two simple systems. Nowadays, it's very rare to want to make one or two simple systems and not need additional dependencies, in which case better use QL. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. signature.asc Description: This is a digitally signed message part
Re: [asdf-devel] Tests completed
On Mon, 2014-01-13 at 10:05 -0600, Robert P. Goldman wrote: Faré wrote: I need to look into a means to identify these problematic cases. Ugh. MOP not standardized. Ugh ugh ugh ugh. I'll see if I can pilfer code from Closer-MOP to render ENSURE-CLASS accessible. Is this the moral of this story: code that wishes to be backwards compatible and portable can NEVER change the class hierarchy above an API-visible class, because there is no *portable* way to detect when someone's code will be affected. What if the previous hierarchy was plain buggy? Then going forward we have to introduce a NEW class to replace the old class. I hope you're only referring to new changes, not the ones that already happened. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. signature.asc Description: This is a digitally signed message part
Re: [asdf-devel] cmucl upgrade of asdf works (somewhat)
On Wed, 2014-01-08 at 01:10 -0500, Faré wrote: An innocuous-looking change suggested by rpgoldman, of not providing a default initform for the selfward-operation slot, led after testing to fixing a few innocuous bugs in asdf, but also to a better understanding of the issues with CMUCL and upgrade. It also broke Clozure, but it works now. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. signature.asc Description: This is a digitally signed message part
Re: [asdf-devel] In defense of ASDF Semantic versioning
On Wed, 2013-11-20 at 18:54 +0100, Pascal Costanza wrote: Just to chime in in the middle: There is no known solution to the so-called DLL hell problem. Libraries interact badly because of their interactions, not because one or the other is bad. Even with the best of intentions, a library author cannot predict what changes will break existing clients and what changes won't, because that author doesn't know about all possible interactions. When APIs change, telling clients that they are now incompatible may be a lie, because they may not depend on the specific change. (For example, is the addition of a keyword argument an incompatible change or not? It may, or it may not be...) Given the flexibility of CL, there are innocuous changes that might break dependent code. For example, adding a new return value to a function is backwards-compatible if the latter is used via multiple-value-bind not if the user employs multiple-value-list plus destructuring-bind. That's perfectly legal CL and, in some cases, might be justifiable as the best solution; even simply adding a function is not backwards-compatible if the dependent code uses boundp at runtime. If you want to give control to developers, you could provide a way that depends-on specifications are list designators, with some form of declarative way of precisely specifying which versions are compatible and which aren't. (Then you could describe situations like, compatible with everything up to and including 0.9.x, and everything above 1.0.0, but excluding 1.0.0 - a situation that actually occurred when Closer to MOP was incompatible with SBCL 1.0.0 for a brief moment in history... ;) The Haskell people tried that with cabal but their experience was that too stringent dependency specs make upgrades a hell. Example: FOO 1.5 depends on BAR = 1.2 = 1.0 QUUX 0.7 depends on FOO = 1.5 = 1.0 and BAR = 1.2 = 1.0 FOO 1.6 is released with dependency on BAR = 1.5 = 1.3 Now one cannot install QUUX any more because its dependencies cannot be met. It directly depends on BAR = 1.2 and indirectly on BAR = 1.3 Users of QUUX will have to modify it locally and contact its developer to update the definition of QUUX or fix it. In practice it seems that the best thing to do is have relaxed dependencies and rely on an integrator/distributor to put together packages and developers have to make sure that when they make a release, their library works with the most recent release of its dependencies. In other words, work with snapshots of the development world and never try to mix libraries from different ages. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. signature.asc Description: This is a digitally signed message part
Re: [asdf-devel] In defense of ASDF Semantic versioning
On Thu, 2013-11-21 at 17:51 +0400, Anton Vodonosov wrote: The proposal to put new, incompatible version into new package does not imply any additional maintenance of old versions. And BTW, other versioning approaches do not prevent from support of previous versions. These two questions are completely orthogonal. If speak about old versions maintenance (in whatever versioning). People using old versions should understand that development focus is shifted to the latest versions. OTOH if someone has large application depending on say hunchentoot 0.13.0 and it is easier to accept his patch that for him to migrate to hunchentoot 1.2.18 - why not, create a branch from 0.13.0 and commit his patch. 21.11.2013, 15:01, Stelian Ionescu sione...@cddr.org: Since CL library development isn't subsidized by generous companies - like in the Java, Python Ruby world - the best we can do with limited resources is break an API, maintain the project name and simply require all users to forward-port their code. How the requirement for additional work in clients (which are probably other open source libraries) is a resource saving? Because the library developers' time is much more precious that the users' time, with few exceptions. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. signature.asc Description: This is a digitally signed message part
Re: [asdf-devel] Possible problem with check-compile-results
On Fri, 2013-08-23 at 13:40 -0500, Robert Goldman wrote: I would be grateful if someone could confirm this for me. I see this in quickloading BABEL on a relatively recent SBCL 1.1.7.112.master.104-d62278d Babel crashes on compiling: caught ERROR: ; (during macroexpansion of (DEFINE-UCS :UCS-2LE ...)) ; #:~A-CODE-POINT-COUNTER fell through ETYPECASE expression. ; Wanted one of (STRING SIMPLE-STRING). ; in: DEFINE-UCS :UCS-2BE ; (BABEL-ENCODINGS::DEFINE-UCS :UCS-2BE 2 :BE 65536) See https://github.com/cl-babel/babel/issues/9#issuecomment-5545077 -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part
Re: [asdf-devel] Problems with asdf:load-system :force
On Fri, 2013-07-26 at 23:48 +0200, Stelian Ionescu wrote: [...] Which files do or don't get compiled twice? :swap-bytes/test depends on :swap-bytes. When I (asdf:load-system :swap-bytes/test :force '(:swap-bytes/test)), some files from :swap-bytes get recompiled too, namely the last two, network.lisp and endianness.lisp Now that I switched to using cl-source-file and :if-feature it no longer happens, so it must have been caused by madeira-port's extension. It's interesting that the two files that were getting spuriously recompiled were the two following the last :madeira-port file in the defsystem. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part
Re: [asdf-devel] Problems with asdf:load-system :force
On Fri, 2013-07-26 at 18:05 -0400, Faré wrote: This is ASDF3. Dependencies are propagated correctly, unlike with ASDF 12. If you want to catch a macro redefinition, just define a dependency, as you should. When I develop interactively and change stuff without saving files, perhaps because I'm working in a scratch buffer, I still want the suite to be recompiled. If you recompiled a file but did not recompile some files that depend on it, ASDF3 will correctly recompile them when you (test-system :swap-bytes). No need to force anything. This is not ASDF 12. If I edit a macro in a scratch buffer ASDF cannot possibly detect it because no file on disk has changed. Maybe I'm being a little too cautious here but for the moment I'll keep forcing the reload of the test suite. Which files do or don't get compiled twice? :swap-bytes/test depends on :swap-bytes. When I (asdf:load-system :swap-bytes/test :force '(:swap-bytes/test)), some files from :swap-bytes get recompiled too, namely the last two, network.lisp and endianness.lisp Indeed, this is a subtle bug in madeira-port: when you depend on a component that is excluded from the build by madeira-port, the component fails to declare an empty set of output-files, while its perform method fails to create the declared output-files, and therefore ASDF while planning decides that this build step is incomplete, as well as anything that depends on it directly or indirectly. The solution is for madeira-port to also provide a :around method for output-files. That's subtle: I didn't think of it when reading the source code. Thanks, fixed. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part
Re: [asdf-devel] Ordering of system :depends-on elements
On Tue, 2013-07-09 at 23:12 +0400, Anton Vodonosov wrote: [...] But the best solution is separation of these ASDF systems into different .asd files. Right now everyone seems to prefer dealing with systems written that way - separate .asd files per ASDF system. Not me: https://github.com/sionescu/iolib/blob/master/iolib.asd -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part
Re: [asdf-devel] Loading an .asd file directly using its pathname
On Tue, 2013-06-25 at 09:57 -0500, Robert Goldman wrote: Luís Oliveira wrote: On Tue, Jun 25, 2013 at 1:44 PM, Faré wrote: In ASDF 3, there is already a function ASDF/FIND-SYSTEM:LOAD-ASD Oh, cool! Thanks! I suppose it could be usefully exported from the ASDF/INTERFACE package. I will leave that to the new maintainer, Robert Goldman. FWIW, I think it's somewhat useful, yes. I will certainly see about exporting it in the next release. Follow-up question: should we be checking to make sure that .asd files are /only/ loaded in the proper context? I.e., should we do something like issue a warning if one tries to load a DEFSYSTEM form when /not/ using this function? Yes. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part
Re: [asdf-devel] Buggy release
On Wed, 2013-05-15 at 21:25 -0400, Faré wrote: Uh? Is it a bad upgrade issue? From what version? How exactly are you loading ASDF? On what implementation? Or, did my tweak in file concatenation order somehow cause this failure? Calling compile-file on asdf.lisp tag 3.0.0 using latest sbcl and without upgrading(asdf isn't previously loaded). Code: https://github.com/sionescu/skel/blob/master/.cl-init/asdf-init.lisp -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part
Re: [asdf-devel] Buggy release
On Thu, 2013-05-16 at 12:54 -0400, Faré wrote: Works for me on asdf 3.0.0 and the latest sbcl on linux/x64 Did you use make to build a new asdf.lisp? Is there an old asdf.fasl polluting the build? Which version is it from? You can load it manually then query (asdf:asdf-version). I figured out what's happening: I load ASDF before quicklisp, and quicklisp doesn't recognize 3.0.0 as being recent enough so it tries to load 2.26 which fails during upgrade. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part
Re: [asdf-devel] Buggy release
On Thu, 2013-05-16 at 13:57 -0400, Faré wrote: Oh shit, that's right: it uses version-satisfies instead of version= (which didn't exist at the time), and of course, 3.0.0 doesn't satisfy 2.26 because of the major version mismatch. Ouch. One solution would be that quicklisp be patched to accept asdf if #+asdf3 or (member :asdf3 *features*). Another solution that quicklisp itself be updated to use asdf3 and possibly version= rather than version-satisfies, or not: I've added a minor version number that allows to have version branches that don't involve a new major version number. The last solution would be that ASDF be stuck forever in using 2 as its major version number. Maybe I should have done just that, because that's the only 100% backward compatible way. Then I should promptly rename ASDF 3.0.0 into ASDF 2.34.0 or some such. The latter is what I did, changed the version to 2.33.11 -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part
[asdf-devel] Source registry configuration files
How do I inhibit ASDF from reading any configuration file whatsoever ? I found that while compiling SBCL, ASDF reads /etc/common-lisp/source-registry.conf and that interferes with the contribs. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] testing ASDF with cl-test-grid
On Thu, 2013-02-21 at 08:00 -0500, Faré wrote: On Thu, Feb 21, 2013 at 6:44 AM, Anton Vodonosov avodono...@yandex.ru wrote: Comparision for building with (setf asdf:*default-encoding* :utf-8): http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-14.html Wow, it's all positive! Not that surprising, when you think about it. Maybe I should just do it, and change the default. I've been warning people for a year already. Go ahead, please. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] ASDF-USER ?
On Sat, 2013-01-26 at 23:11 -0500, Faré wrote: Because the package was delete-package'd in an unwind-protect form after loading the .asd file, and its symbols are thereafter uninterned. Then keep it, store it somewhere and perhaps delete it only when no longer referenced. I have no way to know when the package is not referenced. Keep a list of all temporary packages created and keep a mapping system-temporary-package. After each find-system, run a garbage collection. ASDF currently assumes nothing useful will be done with it after the asd is done loading. That's just wrong. I say stop trying to shield users from the responsibility of namespace management by making things more complex. They already need to create private packages for private uses, anyway, and they already can create all the clashes they want, anyway. I think ASDF should be as DWIM-ish as possible, which benefits everybody; or, in other words, better avoid responsibility and concentrate it into a central place(ASDF). Unnecessary responsibility just causes headaches. I respect the *central-registry* feature and will keep supporting it. It's great for advanced developers like you. Don't want no caching? Keep using the *central-registry*, it's not going away any time soon. However, the caching is a big win for those of us who use :tree, especially on implementations on which scanning is slow. And that means most end-users and newbies, who want things to just work with minimal configuration (i.e. none at all if possible). That's fine, but I'd like to be able to disable caching. And I'm not using *central-registry* but this configuration: (:source-registry (:directory (:home lisp/systems)) :inherit-configuration) Maybe what you want is this: (defmethod asdf:operate :before (o c key allow-other-keys) (declare (ignorable o c)) (unless asdf::*system-being-operated* (asdf:initialize-source-registry))) Thanks, I'll try it. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] ASDF-USER ?
On Sat, 2013-01-26 at 19:12 -0500, Faré wrote: I think the whole temporary package thing is a failure, and we What problems does it actually cause ? -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] ASDF-USER ?
On Sat, 2013-01-26 at 20:48 -0500, Faré wrote: On Sat, Jan 26, 2013 at 7:58 PM, Stelian Ionescu sione...@cddr.org wrote: I think the whole temporary package thing is a failure, and we What problems does it actually cause ? It causes having to maintain this weird system, having functions and classes the symbols of which become inaccessible, etc. It causes users having the wrong expectations and/or having to learn some magic semantics that do not apply to other cases. Why inaccessible ? Because the package was delete-package'd in an unwind-protect form after loading the .asd file, and its symbols are thereafter uninterned. Then keep it, store it somewhere and perhaps delete it only when no longer referenced. * Using TRUENAME to simplify .asd management with a link farm. Big win at the time, though ultimately not scalable. I still use this and love it. Actually, I'd like to be able to be allowed to return to the old behavior where ASDF re-initializes the source registry on every find-system. Given that I only use quicklisp and a symlink directory on an SSD, that's preferable(I don't use the :directory scanning thing). I respect the *central-registry* feature and will keep supporting it. It's great for advanced developers like you. Don't want no caching? Keep using the *central-registry*, it's not going away any time soon. However, the caching is a big win for those of us who use :tree, especially on implementations on which scanning is slow. And that means most end-users and newbies, who want things to just work with minimal configuration (i.e. none at all if possible). That's fine, but I'd like to be able to disable caching. And I'm not using *central-registry* but this configuration: (:source-registry (:directory (:home lisp/systems)) :inherit-configuration) -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] ASDF 2.26 in Quicklisp
On Wed, 2012-11-28 at 08:28 -0600, rpgold...@sift.info wrote: As far as I can tell, this is a misfeature of texinfo. The links only work to the node level (at least in the info browser). So we would need to reactor the document into smaller nodes to fix that. Unfortunately, in addition to requiring some work, that would also give us a document with very small pages, that would be a nuisance when attempting to read in chunks (as opposed to jumping to a very specific item). You might want to switch documentation format, and in that case Pandoc(http://johnmacfarlane.net/pandoc/) might help with the initial conversion. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] mailing list admin...
On Sat, 2012-07-07 at 13:35 -0500, Robert Goldman wrote: I responded to the earlier message about the ASDF system recompilation, but from an alternative email address, so the email went to the moderator. Does anyone know who IS the moderator these days? Last time I checked it was Gary King That's correct -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] Various issues
On Thu, 2012-05-24 at 11:13 +0200, Tobias C Rittweiler wrote: Hi there! Thanks to the ASDF maintainers. I just visited ASDF's website on common-lisp.net since a long time, and it makes a nicely maintained impression! Well done. I have the following issues: * The rather old ASDF version that I'm using (2.010) does not seem to be able to cope with multiple :depends-on clauses. (Only one clause seems to be used.) Is this intended behaviour? More or less, since a module's properties is parsed using destructuring-bind, which has undefined consequences in case of duplicate keywords Might it be fixed in more recent versions? No * :STATIC-FILE (and :FILE for that matter) are not discussed or explained in the manual. Static files are simply ignored. Usually used for assets: images, css files, etc... :file is an alias for the current DEFSYSTEM's :default-component-class, which if absent defaults to asdf:cl-source-file. Example of non-standard default class: https://github.com/sionescu/iolib/blob/master/src/iolib.os.asd * We generate a 'version.lisp' with a (DEFPARAMETER ...) form in it when using make to build a Lisp binary using buildapp. Is there a component that loads a file if it exists and if it does not exist just skips the clause? Maybe :if-component-dep-fails could be used to that purpose, or madeira-port -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
[asdf-devel] Reloading a .asd
I'm using the elisp snippet below(courtesy of Stas Boukarev with some modifications) to reload a .asd file. Is asdf::load-sysdef the best way to trigger a reload(but not recompilation) ? Use case: I want to work on a system that isn't in the ASDF path, it being one of the many development trees I have around(e.g. CFFI), so I want to be able to say that this cffi.asd is the CFFI to use during this session. Any ideas ? (defvar slime-custom-file-loaders '((asd . slime-load-asdf) (lisp . slime-load-file))) (defun slime-load-asdf (filename) (slime-eval-with-transcript `(asdf::load-sysdef ,(file-name-sans-extension filename) ,(slime-to-lisp-filename (expand-file-name filename) (defun slime-custom-load-file () (interactive) (unless buffer-file-name (error Buffer %s is not associated with a file. (buffer-name))) (check-parens) (when (and (buffer-modified-p) (y-or-n-p (format Save file %s? (buffer-file-name (save-buffer)) (let* ((type (file-name-extension buffer-file-name)) (loader (cdr (assoc-string type slime-custom-file-loaders t (funcall (or loader 'slime-load-file) buffer-file-name))) (define-key slime-mode-map (kbd C-c C-l) 'slime-custom-load-file) -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] Reloading a .asd
On Sun, 2012-05-06 at 16:05 -0400, Faré wrote: On Sun, May 6, 2012 at 3:27 PM, Stelian Ionescu sione...@cddr.org wrote: I'm using the elisp snippet below(courtesy of Stas Boukarev with some modifications) to reload a .asd file. Is asdf::load-sysdef the best way to trigger a reload(but not recompilation) ? Yes, with a catch: IF there's a system in your central-registry, source-registry, quicklisp registry, or wherever locate-system will find it, then that OTHER system will be found by the next find-system, as called whenever you try to compile it. So load-sysdef will only help you define a system that CANNOT be found by locate-system. I only want to put a system into manual mode, and make sure that find-system never overrides that no matter what. How about adding an optional third parameter to load-sysdef that sets a definitivep flag in the system, which makes find-system to never search it on the file-system any more ? -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] Reloading a .asd
On Sun, 2012-05-06 at 17:08 -0400, Faré wrote: I only want to put a system into manual mode, and make sure that find-system never overrides that no matter what. How about adding an optional third parameter to load-sysdef that sets a definitivep flag in the system, which makes find-system to never search it on the file-system any more ? As I explained in my previous mail, it would more be something like what follows (wholly untested), where in your code you'd (1) call the register function initially (2) use load-slime-override-sysdef instead of load-sysdef in your code. (in-package :asdf) (defvar *slime-override-systems* (make-hash-table :test 'equal)) (defun sysdef-slime-override (name) (values (gethash (coerce-name system) *slime-override-systems*))) (defun register-slime-override () (setf asdf:*system-definition-search-functions* (cons 'sysdef-slime-override (remove 'sysdef-slime-override *system-definition-search-functions* (defun load-slime-override-sysdef (name pathname) (let ((name (coerce-name name))) (setf (gethash name *slime-override-systems*) pathname) (load-sysdef name pathname))) Yes, but I'd like to push this as Slime contrib and there's no guarantee that this will work in any case -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] Testing with RMCL.... [OT]
On Sun, 2012-04-22 at 11:01 -0500, Robert Goldman wrote: Sadly, FiveAM seems to have been abandoned and is in need of a new maintainer. None of the bese projects darcs repos has been modified in almost 2 years Somebody complained about that on bordeaux-threads-devel, so I picked it up: http://fenlix.dreamwidth.org/2255.html That's great. Any chance of you taking over the fiveam page on common-lisp.net and fixing it so it's no longer misleading? Right now it's a decoy pointer to bad stuff. You mean http://common-lisp.net/project/bese/FiveAM.html ? I'll change it to point to http://common-lisp.net/project/fiveam/ -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] New test and windows
On Fri, 2010-12-24 at 09:38 -0600, Robert Goldman wrote: I pushed a new test for asdf:run-shell-command that I believe will not work on Windows. The first step should be to use reader switches to remove the test contents when running on Windows, but ideally we should supply some windows code to take the place of the posix code where appropriate. The current test relies on /usr/bin/true and /usr/bin/false to test how asdf:run-shell-command checks exit codes. AFAIK POSIX requires «true» and «false» to reside in /bin not /usr/bin -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part ___ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] New test and windows
On Fri, 2010-12-24 at 10:40 -0600, Robert Goldman wrote: On 12/24/10 Dec 24 -10:31 AM, Robert Goldman wrote: On 12/24/10 Dec 24 -9:55 AM, Stelian Ionescu wrote: On Fri, 2010-12-24 at 09:38 -0600, Robert Goldman wrote: I pushed a new test for asdf:run-shell-command that I believe will not work on Windows. The first step should be to use reader switches to remove the test contents when running on Windows, but ideally we should supply some windows code to take the place of the posix code where appropriate. The current test relies on /usr/bin/true and /usr/bin/false to test how asdf:run-shell-command checks exit codes. AFAIK POSIX requires «true» and «false» to reside in /bin not /usr/bin OK, now checking both POSIX and Mac positions for these files. Pushed a new version. Thanks, Stelian. Actually, I am not sure I did the right thing here. I am looking at the POSIX standard now (which I'm not good at navigating). It seems like what POSIX mandates is only that I be able to say true or false to any compliant shell, and it will do the right thing. I don't /believe/ that it dictates a location. So perhaps I have done the wrong thing here by giving a full pathname, and I should simply be using true and false without directory specifiers. That's even better, especially since most shells have them as built-ins -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part ___ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] create temporary Lisp files in fasl directory
On Thu, 2010-08-05 at 18:58 -0400, Robert Brown wrote: I've defined a new component type that allows developers to include protobuf message definition files in their Lisp ASDF files: (defclass protobuf-source-file (cl-source-file) ((relative-proto-pathname ... ) (search-path ... ) (:documentation A protocol buffer definition file.)) When used like this in a system definition: :components ((:protobuf-source-file foo)) executing the ASDF:LOAD-OP operation causes the file called foo.proto to be translated into foo.lisp by a C++ program, and then compiled into foo.fasl and loaded. Note that foo.lisp is created in the same directory as the system definition, but I would prefer it to be created in the same directory as foo.fasl, which for me is in a subdirectory of ~/.cache/common-lisp. What's the easiest way to accomplish this? I initially tried overriding INPUT-FILES when applied to CL-SOURCE-FILE instances, but ASDF::PERFORM is defined like this: (defmethod perform ((operation compile-op) (c cl-source-file)) (let ((source-file (component-pathname c)) ... ) ... ) Since it calls COMPONENT-PATHNAME to find Lisp source, it will always look in the system definition directory. Try something like this: (defmethod asdf:perform ((op asdf:compile-op) (c protobuf-source-file)) (let* ((output-defaults (pathname (car (asdf:output-files op c (generated-source-file (make-pathname :name (pathname-name (asdf:component-pathname c)) :type lisp :defaults output-defaults))) )) You need to call OUTPUT-FILES which will apply the output translations you've configured -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part ___ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] a hair in :pathname specifications
On Sat, 2010-06-12 at 07:37 -0400, Faré wrote: Looking at Stelian's recent patches to iolib, I saw that he uses things like: (asdf:defsystem :iolib.syscalls ... :pathname #-asdf2 (merge-pathnames syscalls/ *load-truename*) #+asdf2 syscalls/ ...) This shocked me, as I new (for having been hit badly by the issue at ITA and having read the code) that you can't use (merge-pathnames ...) like that in a component and need #. instead, since there is no EVAL in parse-component-form. ITA used to have lots of #.(merge-pathnames ...) before I implemented / parsing in our local ASDF (now merged into ASDF 2). Well, it turns out that the defsystem macro itself treats :pathname specially and lets that argument be evaluated unlike other arguments and unlike :pathname for other forms. This interacts badly with some code I've written recently that cleans up the way we normalize specified pathnames for components, my code assuming we were always provided a valid specifier. So the question is: what to do? 1- Should I do nothing, thus having more uniform semantics but breaking compatibility with ASDF 1 and requiring users of defsystem to use #. in such occasions? 2- Should I issue an ASDF 2.0 minor release that re-allows pathname evaluation just for defsystem forms (excluding other forms), thus providing better backwards compatibility? 3- Should I issue an ASDF 2.0 minor release that does pathname evaluation inside parse-component-form, thus providing better backwards compatibility AND extending the semantics so that it be more uniform? I would leave things as they are. The upgrade to ASDF2 is trivial so I see no point in trying to be backwards-compatibile here -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part ___ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] [PATCH 1/2] Fix error in parsing configuration directives
On Mon, 2010-06-07 at 20:47 -0400, Faré wrote: It was initially on purpose that I inserted this restriction, because I felt that 1- there was no clearly good default that I could see. 2- if such a default is identified, we can enable it later. 3- if no default is initially provided, we can provide one later with backwards compatibility; but if we provide one, we can't change it with backwards compatibility. 4- I'd rather error out early with an annoying error message than do something silently that will be the wrong thing for many users. Do you really think there should be a default? Which, and for what reason? Is there a compelling reason to think that everyone will agree to same default? After actually using the configuration system, I came to the conclusion for the sake of simplicity, ASDF should always inherit configuration, that :inherit-configuration and :ignore-inherited-configuration should not exist, and be replaced with a function such as, for example: asdf:initialize-source-registry-from-defaults rest conf-sources by default, upon initialization ASDF would call (asdf:initialize-source-registry-from-defaults :system :user :env). Users could override that in the initfiles if needed. The reason for this is that I want users who install distro-provided packages to be able to start and use ASDF2 without having to create a local configuration file. OTOH, people who don't use distro packages wouldn't care about inheriting the system configuration because they wouldn't have it, so no harm done -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part ___ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
[asdf-devel] [PATCH 1/2] Fix error in parsing configuration directives
Signed-off-by: Stelian Ionescu sione...@cddr.org --- asdf.lisp |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/asdf.lisp b/asdf.lisp index 859d93c..0b4ba6c 100644 --- a/asdf.lisp +++ b/asdf.lisp @@ -2508,8 +2508,8 @@ located. (incf inherit) (funcall directive-validator directive)) :finally -(unless (= inherit 1) - (error One and only one of ~S or ~S is required +(unless (= inherit 1) + (error At most one of ~S or ~S is allowed :inherit-configuration :ignore-inherited-configuration))) form) -- 1.7.1 ___ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
[asdf-devel] [PATCH 2/2] Remove last place where CL-SOURCE-FILE was harcoded: use *DEFAULT-COMPONENT-CLASS* instead
Signed-off-by: Stelian Ionescu sione...@cddr.org --- asdf.lisp |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/asdf.lisp b/asdf.lisp index 0b4ba6c..805e32b 100644 --- a/asdf.lisp +++ b/asdf.lisp @@ -2082,7 +2082,7 @@ details. (or class (and (eq type :file) (or (module-default-component-class parent) - (find-class 'cl-source-file))) + (find-class *default-component-class*))) (sysdef-error ~@don't recognize component type ~A~@: type (defun maybe-add-tree (tree op1 op2 c) -- 1.7.1 ___ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
[asdf-devel] (no subject)
The first patch fixes the parsing of the configuration file that I use: (:source-registry :default-registry (:directory /usr/share/common-lisp/systems) (:directory /home/hechee/lisp/systems)) Currently I get One and only one of :INHERIT-CONFIGURATION or :IGNORE-INHERITED-CONFIGURATION is required, even though none is present. ___ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] [armedbear-devel] Patch for ASDF2 to use arbitrary output translation function
On Thu, 2010-03-25 at 09:17 -0700, Alan Ruttenberg wrote: Sorry, haven't had a chance to look closely at asdf2, but wanted to point out that in certain contexts, like running applets, writing to any file system is prohibited. For those cases, it would be nice if it was super-easy to set a flag that says: if there isn't a compiled version, or if it is stale, don't try to compile - just load source. That is already possible: just use LOAD-SOURCE-OP instead of LOAD-OP. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part ___ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] Please test: merged ECL support, created asdf.asd
On Mon, 2009-11-30 at 16:17 -0500, Faré wrote: Dear ASDF developers, I've committed to *a new repo* a few ASDF hacks that I wrote. I'd like some of you to review and/or test it. I'd like to get it reviewed before I push those changes to the official repo. git clone http://common-lisp.net/project/xcvb/git/asdf.git cd asdf git diff -u -a -b 1f7690b49b73b499ff2bd2ad77ec23c273941814 60165185516e699d0daebd0b653e61b83e72d4e6 The main changes are: * Merged the ECL patch. Had to remove a #+ecl in a slot declaration, because the slot is used afterwards without #+ecl. * Limited support to upgrade from a previous installation (if you have old installations, please try to upgrade!). * Notably created an asdf.asd so you can try to (require :asdf) (pushnew /path/to/asdf/ asdf:*central-registry*) (asdf:oos 'asdf:load-op :asdf) I'm not sure that this is a good idea. When evaluating (asdf:oos 'asdf:load-op :asdf) you'd be redefining asdf:load-op from inside the old asdf:load-op. I'd be surprised if it didn't cause problems in some (perhaps old) compilers. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part ___ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] loading a standalone lisp file
On Wed, 2009-10-28 at 15:00 +0100, Tamas Papp wrote: Hi, If I have an ASDF system that :depends-on various other ones _and_ some other library that does not have and .asd file (eg it is a standalone .lisp file), what is the standard way of loading the latter? I am looking for something that eg automates manually executing (load (compile-file /path/foo.lisp)) and how to incorporate this into a defsystem. Caveat lector: the following is untested. (defsystem :foo :depends-on (:asdf-system-1 :asdf-system-2) :in-order-to ((compile-op () (compile-file /path/foo.lisp))) :in-order-to ((load-op () (load /path/foo -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part ___ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] trac?
On Mon, 2009-10-19 at 09:42 -0500, Robert Goldman wrote: Not for me, because I've never used launchpad, and don't know how to use it or set it up ;-) Seriously, I'd be happy to help with trac if we want to use that as a ticket system. But I don't know anything about launchpad, and I wouldn't be doing anyone any favors by volunteering to help set up and maintain a system about which I'm ignorant. If you or someone else want to get launchpad set up, I am all for it; it may well be the best solution. But I think trac would be a better solution than no ticket system, if we don't have anyone who will take ownership of the launchpad approach. You need only subscribe to launchpad.net and register ASDF as project. If you intend to use the email interface, you must also register a GPG key. This entire process took me less than 5 minutes. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part ___ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] Guard against (push /foo/bar asdf:*central-registry*)
On Tue, 2009-07-07 at 12:31 +0200, Tobias C. Rittweiler wrote: I think it's bitten pretty much all of us that we at least once tried to push a non-directory-designating filename to *CENTRAL-REGISTRY*. It's a common pitfalls for newcomers. Couldn't ASDF signal a warning when it encounters such a thing while grovelling through the registry? Why not simply deprecate(or unexport *CENTRAL-REGISTRY*) and add a function REGISTER-ASDF-DIRECTORY that does all necessary checks ? -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part ___ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
