TL;DR: ASDF currently doesn't play so well with logical pathnames. I'm seeking advice on how to make things better — or on whether it's worth the trouble.
Dear all,
Pascal's recent plight with logical pathnames on SBCL once again rises the issue of how much ASDF (or SBCL) should support logical pathname users, and how they should behave to make logical pathname users happy.
With case-sensitivity issues, things only get worse!
(Note: personally inviting James Anderson to the discussion, since he's the only strong proponent and user of logical pathnames I know.)
REMINDER ABOUT LOGICAL PATHNAMES (LPNs)
So, the CLHS says LPNs are case-converted to upper-case, portably restricted to such upper-case characters, and get translated to physical pathnames in an implementation-dependent way. On Unix, with its case-sensitive filesystems and lower-case conventions, the useful thing is then downcasing names.
At least SBCL and CLISP follow both the standard and the useful pathname mapping convention. SBCL goes on to length to throw an error when non-portable code tries to break the standard restrictions on logical-pathnames; CLISP will let you manually make-pathname a LPN with lower-case or mixed-case characters, but will still downcase them at the end (the latest CLISP 2.49 also seems to not want to create a logical pathname with parse-namestring). CCL tries to make users happy by leaving the logical pathname host case-insensitive (per the standard) but case-preserving, and being case-sensitive in the rest of the pathname (if you want upper-case, you know where to find it). To collect and analyze the behavior of each of 14 implementations is left as an exercise to the logical-pathname loving reader [M20]. To devise, document and get implementations to adopt a common behavior that would be universally accepted by all is left as another exercise [50].
ASDF NAMING OF SYSTEMS
Similarly, when naming an ASDF system, to allow to designate systems with symbols (CL legacy), which are case-converted, yet map them to a unixy lower-case name, and still allow systems with all kind of cases, symbols are downcased whereas strings preserved. Then the filesystem is queried with the resulting normalized string name (see function coerce-name).
Now with its good old central-registry, ASDF used to query each directory every time a system was requested. This works great with logical pathnames, as it defers all case handling to the last minute, and allows .asd files to be loaded with a LPN as the *load-pathname*. However, this was somewhat slow, and it didn't scale to recursively searching directories, and so came the habit of creating "link farms", single directories with plenty of symlinks to adequate .asd files. Of course, symlinks are both not so portable (not very well supported in Windows, if at all, though later versions of ASDF recognize Windows shortcuts as a substitute), and a maintenance nightmare (unlike Macintosh aliases, they are not automatically updated when a system is installed, moved or deleted). Therefore link farms were not a good interface to end-users.
For ASDF 2, I implemented a new way to manage system files: the source-registry. It allows you to specify trees to search recursively as well as single directories. Whether the registry is searched lazily (when a system is requested) or eagerly (one the first time around) or yet something else, was left unspecified. In my first implementation of it, I built upon the previous central-registry, and at initialization time I was looking for which subdirectories in the specified trees did contain .asd files, then saved these in a list that I consulted in the very same way as the central-registry. (Note: the central registry is still there, and consulted first.)
However, DIRECTORY returns fully resolved TRUENAMEs, and any portable way of searching inside subdirectories is doomed to squash away logical pathnames. Currently, any use of :tree in source-registry will resolve into physical pathnames (PPNs) on most implementations, and always did.
However, entries with :directory used to preserve LPNs. Not so with 2.014.7, where, prompted by a Quicklisp feature request, I implemented eager caching of ASDF systems. So I query DIRECTORY and save the results in a hash-table indexed by pathname-name. The table is case-sensitive, to reflect the case-sensitive names of ASDF. One consequence is that :directory entries do not preserve LPNs anymore.
Another more subtle consequence is that things may go wrong if your filesystem is case-insensitive but case-preserving. In the old way of doing things (still available with the central-registry), you'd typically be looking for the file with lower-case name, and you would find it even if named in different cases on disk. With the old way, you'll record the name in its case mix, and will never match it against the (lowercase) name. So some systems that depend on this behavior will disappear.
POTENTIAL SOLUTIONS
An easy way out is to declare that ASDF from now on shall be case-insensitive, using EQUALP to compare system names and in hash-tables that cache system files. Another way out is to declare that ASDF is still case sensitive, and that the only case allowed is lower-case for physical filenames. Any system that doesn't work with this new interpretation probably didn't work portably with the old one, anyway.
A harder way out would be to assume case-sensitivity in the filesystem (since some filesystems are case-sensitive, and any asd file that depends on case-insensitivity is non-portable and deserves to lose), and make extra effort when using DIRECTORY against logical pathnames to always reconstitute LPNs from the PPNs given by directory, and drop the reconstituted results if they don't resolve to the same thing. But is it worth the pain?
Finally, I could do nothing, and assume that people who go through the pain of setting up logical pathnames before they run ASDF can just as well setup the *central-registry* and have LPNs be recognized in the good old way. If you use the source-registry, your LPNs will be squashed, and nothing will break in the code since code works fine with PPNs, just like most everyone use it, but your debug information will be stored according to the PPN, not the LPN. Meh.
Zach (if you're still reading), do any systems in the wild use anything but lower-case names for system files?
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Two members of the Political Police salute a giant portrait of our Great Leader - Comrade, do you think the same as I do? inquires the first one, with a sincere gaze pleeing into his colleagues' eyes. - Comrade, the second one replies and returns the same gaze: yes, I do. - In that case, comrade, you're under arrest! concludes the first one.
good morning, faré, gentlemen;
On 2011-06-12, at 02:25 , Faré wrote:
TL;DR: ASDF currently doesn't play so well with logical pathnames. I'm seeking advice on how to make things better — or on whether it's worth the trouble.
Dear all,
[...]
POTENTIAL SOLUTIONS
[...]
Finally, I could do nothing, and assume that people who go through the pain of setting up logical pathnames before they run ASDF can just as well setup the *central-registry* and have LPNs be recognized in the good old way. If you use the source-registry, your LPNs will be squashed, and nothing will break in the code since code works fine with PPNs, just like most everyone use it, but your debug information will be stored according to the PPN, not the LPN. Meh.
less might well be better.
a bit over twenty years ago, when i had sent a library to john mallory to be included among cl-http contributions, he pointed out to me, that, as my apparent intent was to implement portable systems for others' use, it was not a good idea to have used mixed case pathnames. i trusted him, renamed several dozen files and directories, and have adhered to that restriction ever since. over the years, i have seen nothing to contract his advice. furthermore, over these years, as my requirements for lisp system management tools have remained limited to those related to building those aspects of larger systems which comprise just lisp source code, i have observed that portability and maintainability are improved by adopting the logical pathname naming restrictions for system description components. that is, in distinction to experience reported elsewhere, it has been possible to use asdf system declarations which contain just logical pathname components with all lisp implementation which purported to support logical pathnames. the pathname regression test which i implemented during the "asdf 2" testing process demonstrated this to have been true for all of the variations of runtime and pathname expression which were known at that time.
my particular build process - even prior to "asdf 2", involves variations on the two alternatives discussed in faré's original message [cf. https://github.com/lisp/de.setf.utility/blob/master/asdf/ hierarchical-names.lisp]: - it searches for system definition files recursively from the set of root directories specified in *central-registry*. for my own systems, a method to interpret system names as hierarchic paths speeds the process. this means that the *central-registry* is sufficient. - it takes the "hard way out", as that serves maintainability. where possible, an additional step in the system initialization protocol derives and asserts a logical pathname root for the system, which (at least at last check) yields logical source pathnames for all system components.
this approach does limit the mechanisms available to include external libraries in my own builds. that is ok. for example, while i may use something like quicklisp to obtain source code, i have seen the difficulties which even advanced dependency-based build systems, such as ruby's, introduce into production environments. it is a nightmare to which i do not intend to submit. i prefer, that production systems always include self-curated source code. in this case, it is a minor issue to normalize system names.
given this use case, there has been no advantage to rely on that aspect of the "asdf 2" effort which re-implemented the logical pathname mapping facility. the system i have in production [www.dydra.com] comprises 80 systems. many of them open-source. all of which manage under these restrictions. as do the libraries which i have made available as open source [github.com/lisp/]. so long as the *central-registry* and the mechanisms which depend on it continue to support logical pathnames, it will be possible to use asdf. in particular, it is a really good thing that component pathnames for a system which has a logical pathname root remain logical pathnames, as that makes it possible to use standard language operators to remap file trees for built systems during release and/or maintenance.
best wishes for your continued efforts.
On 6/12/11 Jun 12 -4:34 AM, james anderson wrote:
good morning, faré, gentlemen;
On 2011-06-12, at 02:25 , Faré wrote:
TL;DR: ASDF currently doesn't play so well with logical pathnames. I'm seeking advice on how to make things better — or on whether it's worth the trouble.
Dear all,
[...]
POTENTIAL SOLUTIONS
[...]
Finally, I could do nothing, and assume that people who go through the pain of setting up logical pathnames before they run ASDF can just as well setup the *central-registry* and have LPNs be recognized in the good old way. If you use the source-registry, your LPNs will be squashed, and nothing will break in the code since code works fine with PPNs, just like most everyone use it, but your debug information will be stored according to the PPN, not the LPN. Meh.
less might well be better.
a bit over twenty years ago, when i had sent a library to john mallory to be included among cl-http contributions, he pointed out to me, that, as my apparent intent was to implement portable systems for others' use, it was not a good idea to have used mixed case pathnames. i trusted him, renamed several dozen files and directories, and have adhered to that restriction ever since. over the years, i have seen nothing to contract his advice. furthermore, over these years, as my requirements for lisp system management tools have remained limited to those related to building those aspects of larger systems which comprise just lisp source code, i have observed that portability and maintainability are improved by adopting the logical pathname naming restrictions for system description components. that is, in distinction to experience reported elsewhere, it has been possible to use asdf system declarations which contain just logical pathname components with all lisp implementation which purported to support logical pathnames. the pathname regression test which i implemented during the "asdf 2" testing process demonstrated this to have been true for all of the variations of runtime and pathname expression which were known at that time.
This is an interesting bit of explanation and somewhat dovetails with my experience. One of the problems I have had with logical pathnames is working on projects where lisp code is /not/ in systems "compris[ing] just lisp source code." Larger systems on which I have worked often contain large hunks of Java, C++ or scripting language code. Sometimes this software has been written across multiple companies. It has been difficult to limit those systems' use of pathnames; in practice it's not worth the trouble. It's not helpful when trying to get people to tolerate your use of CL to have to tell them that you want them to give up TheirCamelCase and_underscores.
Another thing that has led me to give up on logical pathnames is that it has forced me to debug multiple colleagues' lisp configurations.
I have found it less work to simply put in our source code repository load files that use *load-truename* to populate asdf:*central-registry*. This even hides ASDF configuration, and minimizes time lost in debugging others' configurations.
These experiences may differ from much of this audience's experience, which may be more related to individual hackers working on their own software, or working on open source systems in a distributed way.
my particular build process - even prior to "asdf 2", involves variations on the two alternatives discussed in faré's original message [cf. https://github.com/lisp/de.setf.utility/blob/master/asdf/hierarchical-names....]:
- it searches for system definition files recursively from the set of
root directories specified in *central-registry*. for my own systems, a method to interpret system names as hierarchic paths speeds the process. this means that the *central-registry* is sufficient.
I use a variant of this, a portable "asd-finder" system that does a special, portable CL version of 'find' that is tailored to find .asd files. The asd-finder is used to populate asdf:*central-registry*. Using the asd-finder is similar to using Faré's :tree directive, except it does not rely on knowing the user's absolute install pathname: you can invoke the asd-finder using *load-truename*.
My desire to replicate this kind of configuration (the asd-finder used in a load file) is what led me to introduce the :here directive into Faré's DSL for configuring input file search.
- it takes the "hard way out", as that serves maintainability. where
possible, an additional step in the system initialization protocol derives and asserts a logical pathname root for the system, which (at least at last check) yields logical source pathnames for all system components.
I used to do this myself, but gave up on it. If you are working relative to some root directory found through *load-truename* (or a similar mechanism), introducing the logical pathname didn't seem like a big win to me. If my systems need to find some files, it's just as easy to store a copy of the directory portion of *load-truename* in a global variable, and use merge-pathnames on the global variable. In practice, I have found this more reliable than wrestling with logical pathnames (e.g., there's no need to worry that someone has installed the working directory in some location that will break logical pathnames).
(merge-pathnames "data-file.csv" *my-system-root*)
doesn't seem a lot harder than
"my-system-root:data-file.csv"
YMMV.
this approach does limit the mechanisms available to include external libraries in my own builds. that is ok. for example, while i may use something like quicklisp to obtain source code, i have seen the difficulties which even advanced dependency-based build systems, such as ruby's, introduce into production environments. it is a nightmare to which i do not intend to submit. i prefer, that production systems always include self-curated source code. in this case, it is a minor issue to normalize system names.
My experience lines up with James's here. If a project I work on needs an external library, we blow that into our "lisp-utils" repository, and incorporate that. No more problems with API-breaking mods to libraries. Also, in my experience, CL libraries very often have corner cases which break them. After a bunch of times downloading a library using ASDF-install, finding I had to patch it, and /then/ having to blow it into a source code repository, I find that it's better to just cut to the chase and push all library dependencies into the repository. Again, YMMV. If you want to set up a web server with hunchentoot, for example, you may find that library has been used enough that it can be collected with quicklisp or asdf-install and simply used. OTOH, if you are using, say, and XML-wrangling library, a DAG-manipulation library, etc., the chances are good that you will end up using a piece of its functionality that has not been adequately tested and debugged. The CL community doesn't have enough eyeballs in it yet for its utility libraries to be bulletproof, in my experience.
Best regards, R
Hi,
This is all very frustrating. With ASDF 1.x, everything worked fine and I have never encountered any issues. Since CL implementations "upgraded" to ASDF 2.x, things run into problems on a regular basis.
What is really annoying is that the ASDF 2.x documentation is misleading. *central-registry* is described as old-style and deprecated that is hopefully going away in the future, and logical pathnames are also described as old-style and better to be avoided. If I read the recent messages by Fare and James correctly, it turns out that if I had sticked to *central-registry* and switched to logical pathnames, everything would be fine and I wouldn't have had to waste time on a very frustrating experience.
Please take one or two steps back and try to see the global picture: Logical pathnames and *central-registry* have their quirks and complications, that is correct. But all you're doing is to replace this with an alternative that has again their own quirks and complications. So overall you're not making things easier, you're just replacing one difficult-to-use system with another difficult-to-use system. This is not a win, not for anybody.
ASDF is not the central focus of my work. It's a tool that is supposed to make my life easier, not harder. I want to contribute to the Common Lisp community by providing my own libraries, not by fighting a build tool.
I will try to switch to *central-registry* again. It seems promising that this could actually work in the mid run and not cause any further problems down the line. Please make sure that it stays that way.
Best, Pascal
On 12 Jun 2011, at 02:25, Faré wrote:
TL;DR: ASDF currently doesn't play so well with logical pathnames. I'm seeking advice on how to make things better — or on whether it's worth the trouble.
Dear all,
Pascal's recent plight with logical pathnames on SBCL once again rises the issue of how much ASDF (or SBCL) should support logical pathname users, and how they should behave to make logical pathname users happy.
With case-sensitivity issues, things only get worse!
(Note: personally inviting James Anderson to the discussion, since he's the only strong proponent and user of logical pathnames I know.)
REMINDER ABOUT LOGICAL PATHNAMES (LPNs)
So, the CLHS says LPNs are case-converted to upper-case, portably restricted to such upper-case characters, and get translated to physical pathnames in an implementation-dependent way. On Unix, with its case-sensitive filesystems and lower-case conventions, the useful thing is then downcasing names.
At least SBCL and CLISP follow both the standard and the useful pathname mapping convention. SBCL goes on to length to throw an error when non-portable code tries to break the standard restrictions on logical-pathnames; CLISP will let you manually make-pathname a LPN with lower-case or mixed-case characters, but will still downcase them at the end (the latest CLISP 2.49 also seems to not want to create a logical pathname with parse-namestring). CCL tries to make users happy by leaving the logical pathname host case-insensitive (per the standard) but case-preserving, and being case-sensitive in the rest of the pathname (if you want upper-case, you know where to find it). To collect and analyze the behavior of each of 14 implementations is left as an exercise to the logical-pathname loving reader [M20]. To devise, document and get implementations to adopt a common behavior that would be universally accepted by all is left as another exercise [50].
ASDF NAMING OF SYSTEMS
Similarly, when naming an ASDF system, to allow to designate systems with symbols (CL legacy), which are case-converted, yet map them to a unixy lower-case name, and still allow systems with all kind of cases, symbols are downcased whereas strings preserved. Then the filesystem is queried with the resulting normalized string name (see function coerce-name).
Now with its good old central-registry, ASDF used to query each directory every time a system was requested. This works great with logical pathnames, as it defers all case handling to the last minute, and allows .asd files to be loaded with a LPN as the *load-pathname*. However, this was somewhat slow, and it didn't scale to recursively searching directories, and so came the habit of creating "link farms", single directories with plenty of symlinks to adequate .asd files. Of course, symlinks are both not so portable (not very well supported in Windows, if at all, though later versions of ASDF recognize Windows shortcuts as a substitute), and a maintenance nightmare (unlike Macintosh aliases, they are not automatically updated when a system is installed, moved or deleted). Therefore link farms were not a good interface to end-users.
For ASDF 2, I implemented a new way to manage system files: the source-registry. It allows you to specify trees to search recursively as well as single directories. Whether the registry is searched lazily (when a system is requested) or eagerly (one the first time around) or yet something else, was left unspecified. In my first implementation of it, I built upon the previous central-registry, and at initialization time I was looking for which subdirectories in the specified trees did contain .asd files, then saved these in a list that I consulted in the very same way as the central-registry. (Note: the central registry is still there, and consulted first.)
However, DIRECTORY returns fully resolved TRUENAMEs, and any portable way of searching inside subdirectories is doomed to squash away logical pathnames. Currently, any use of :tree in source-registry will resolve into physical pathnames (PPNs) on most implementations, and always did.
However, entries with :directory used to preserve LPNs. Not so with 2.014.7, where, prompted by a Quicklisp feature request, I implemented eager caching of ASDF systems. So I query DIRECTORY and save the results in a hash-table indexed by pathname-name. The table is case-sensitive, to reflect the case-sensitive names of ASDF. One consequence is that :directory entries do not preserve LPNs anymore.
Another more subtle consequence is that things may go wrong if your filesystem is case-insensitive but case-preserving. In the old way of doing things (still available with the central-registry), you'd typically be looking for the file with lower-case name, and you would find it even if named in different cases on disk. With the old way, you'll record the name in its case mix, and will never match it against the (lowercase) name. So some systems that depend on this behavior will disappear.
POTENTIAL SOLUTIONS
An easy way out is to declare that ASDF from now on shall be case-insensitive, using EQUALP to compare system names and in hash-tables that cache system files. Another way out is to declare that ASDF is still case sensitive, and that the only case allowed is lower-case for physical filenames. Any system that doesn't work with this new interpretation probably didn't work portably with the old one, anyway.
A harder way out would be to assume case-sensitivity in the filesystem (since some filesystems are case-sensitive, and any asd file that depends on case-insensitivity is non-portable and deserves to lose), and make extra effort when using DIRECTORY against logical pathnames to always reconstitute LPNs from the PPNs given by directory, and drop the reconstituted results if they don't resolve to the same thing. But is it worth the pain?
Finally, I could do nothing, and assume that people who go through the pain of setting up logical pathnames before they run ASDF can just as well setup the *central-registry* and have LPNs be recognized in the good old way. If you use the source-registry, your LPNs will be squashed, and nothing will break in the code since code works fine with PPNs, just like most everyone use it, but your debug information will be stored according to the PPN, not the LPN. Meh.
Zach (if you're still reading), do any systems in the wild use anything but lower-case names for system files?
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Two members of the Political Police salute a giant portrait of our Great Leader
- Comrade, do you think the same as I do? inquires the first one, with
a sincere gaze pleeing into his colleagues' eyes.
- Comrade, the second one replies and returns the same gaze: yes, I do.
- In that case, comrade, you're under arrest! concludes the first one.
EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Sbcl-devel mailing list Sbcl-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sbcl-devel
-- Pascal Costanza
On 12 June 2011 11:49, Pascal Costanza pc@p-cos.net wrote:
Hi,
This is all very frustrating. With ASDF 1.x, everything worked fine and I have never encountered any issues. Since CL implementations "upgraded" to ASDF 2.x, things run into problems on a regular basis.
I'm sorry you're running into problems. I could have done things better. Yet, I believe ASDF 2 is a clear improvement over ASDF 1. I also believe a lot of your problems come from your rash attitude in dealing with adversity.
What is really annoying is that the ASDF 2.x documentation is misleading. *central-registry* is described as old-style and deprecated that is hopefully going away in the future, and logical pathnames are also described as old-style and better to be avoided. If I read the recent messages by Fare and James correctly, it turns out that if I had sticked to *central-registry* and switched to logical pathnames, everything would be fine and I wouldn't have had to waste time on a very frustrating experience.
I still believe central-registry and logical pathnames are old style, since they necessitate implementation-dependent configuration (i.e. more buck) for results of more limited applicability (i.e. less bang). I am unwilling to dig into each implementation's details and document the 14 different ways to get things working this way.
For a less frustrating experience, you could communicate better and earlier about your problems.
For instance, you apparently switched to logical pathnames after you experienced a bug in the ASDF support for RMCL. If only you had reported that my previous series of fixes to RMCL support still didn't solve your issues, and kept pressing the issues, I would have provided a solution then, rather than when Binghe reported the issue again a few months afterwards.
Please take one or two steps back and try to see the global picture: Logical pathnames and *central-registry* have their quirks and complications, that is correct. But all you're doing is to replace this with an alternative that has again their own quirks and complications. So overall you're not making things easier, you're just replacing one difficult-to-use system with another difficult-to-use system. This is not a win, not for anybody.
I believe I made things easier: no more per-implementation configuration, no more attempts to badly documentation half of them.
ASDF is not the central focus of my work. It's a tool that is supposed to make my life easier, not harder. I want to contribute to the Common Lisp community by providing my own libraries, not by fighting a build tool.
I will try to switch to *central-registry* again. It seems promising that this could actually work in the mid run and not cause any further problems down the line. Please make sure that it stays that way.
Best, Pascal
On 12 Jun 2011, at 02:25, Faré wrote:
TL;DR: ASDF currently doesn't play so well with logical pathnames. I'm seeking advice on how to make things better — or on whether it's worth the trouble.
Dear all,
Pascal's recent plight with logical pathnames on SBCL once again rises the issue of how much ASDF (or SBCL) should support logical pathname users, and how they should behave to make logical pathname users happy.
With case-sensitivity issues, things only get worse!
(Note: personally inviting James Anderson to the discussion, since he's the only strong proponent and user of logical pathnames I know.)
REMINDER ABOUT LOGICAL PATHNAMES (LPNs)
So, the CLHS says LPNs are case-converted to upper-case, portably restricted to such upper-case characters, and get translated to physical pathnames in an implementation-dependent way. On Unix, with its case-sensitive filesystems and lower-case conventions, the useful thing is then downcasing names.
At least SBCL and CLISP follow both the standard and the useful pathname mapping convention. SBCL goes on to length to throw an error when non-portable code tries to break the standard restrictions on logical-pathnames; CLISP will let you manually make-pathname a LPN with lower-case or mixed-case characters, but will still downcase them at the end (the latest CLISP 2.49 also seems to not want to create a logical pathname with parse-namestring). CCL tries to make users happy by leaving the logical pathname host case-insensitive (per the standard) but case-preserving, and being case-sensitive in the rest of the pathname (if you want upper-case, you know where to find it). To collect and analyze the behavior of each of 14 implementations is left as an exercise to the logical-pathname loving reader [M20]. To devise, document and get implementations to adopt a common behavior that would be universally accepted by all is left as another exercise [50].
ASDF NAMING OF SYSTEMS
Similarly, when naming an ASDF system, to allow to designate systems with symbols (CL legacy), which are case-converted, yet map them to a unixy lower-case name, and still allow systems with all kind of cases, symbols are downcased whereas strings preserved. Then the filesystem is queried with the resulting normalized string name (see function coerce-name).
Now with its good old central-registry, ASDF used to query each directory every time a system was requested. This works great with logical pathnames, as it defers all case handling to the last minute, and allows .asd files to be loaded with a LPN as the *load-pathname*. However, this was somewhat slow, and it didn't scale to recursively searching directories, and so came the habit of creating "link farms", single directories with plenty of symlinks to adequate .asd files. Of course, symlinks are both not so portable (not very well supported in Windows, if at all, though later versions of ASDF recognize Windows shortcuts as a substitute), and a maintenance nightmare (unlike Macintosh aliases, they are not automatically updated when a system is installed, moved or deleted). Therefore link farms were not a good interface to end-users.
For ASDF 2, I implemented a new way to manage system files: the source-registry. It allows you to specify trees to search recursively as well as single directories. Whether the registry is searched lazily (when a system is requested) or eagerly (one the first time around) or yet something else, was left unspecified. In my first implementation of it, I built upon the previous central-registry, and at initialization time I was looking for which subdirectories in the specified trees did contain .asd files, then saved these in a list that I consulted in the very same way as the central-registry. (Note: the central registry is still there, and consulted first.)
However, DIRECTORY returns fully resolved TRUENAMEs, and any portable way of searching inside subdirectories is doomed to squash away logical pathnames. Currently, any use of :tree in source-registry will resolve into physical pathnames (PPNs) on most implementations, and always did.
However, entries with :directory used to preserve LPNs. Not so with 2.014.7, where, prompted by a Quicklisp feature request, I implemented eager caching of ASDF systems. So I query DIRECTORY and save the results in a hash-table indexed by pathname-name. The table is case-sensitive, to reflect the case-sensitive names of ASDF. One consequence is that :directory entries do not preserve LPNs anymore.
Another more subtle consequence is that things may go wrong if your filesystem is case-insensitive but case-preserving. In the old way of doing things (still available with the central-registry), you'd typically be looking for the file with lower-case name, and you would find it even if named in different cases on disk. With the old way, you'll record the name in its case mix, and will never match it against the (lowercase) name. So some systems that depend on this behavior will disappear.
POTENTIAL SOLUTIONS
An easy way out is to declare that ASDF from now on shall be case-insensitive, using EQUALP to compare system names and in hash-tables that cache system files. Another way out is to declare that ASDF is still case sensitive, and that the only case allowed is lower-case for physical filenames. Any system that doesn't work with this new interpretation probably didn't work portably with the old one, anyway.
A harder way out would be to assume case-sensitivity in the filesystem (since some filesystems are case-sensitive, and any asd file that depends on case-insensitivity is non-portable and deserves to lose), and make extra effort when using DIRECTORY against logical pathnames to always reconstitute LPNs from the PPNs given by directory, and drop the reconstituted results if they don't resolve to the same thing. But is it worth the pain?
Finally, I could do nothing, and assume that people who go through the pain of setting up logical pathnames before they run ASDF can just as well setup the *central-registry* and have LPNs be recognized in the good old way. If you use the source-registry, your LPNs will be squashed, and nothing will break in the code since code works fine with PPNs, just like most everyone use it, but your debug information will be stored according to the PPN, not the LPN. Meh.
Zach (if you're still reading), do any systems in the wild use anything but lower-case names for system files?
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Two members of the Political Police salute a giant portrait of our Great Leader
- Comrade, do you think the same as I do? inquires the first one, with
a sincere gaze pleeing into his colleagues' eyes.
- Comrade, the second one replies and returns the same gaze: yes, I do.
- In that case, comrade, you're under arrest! concludes the first one.
EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Sbcl-devel mailing list Sbcl-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sbcl-devel
-- Pascal Costanza
On 13 Jun 2011, at 06:29, Faré wrote:
On 12 June 2011 11:49, Pascal Costanza pc@p-cos.net wrote:
Hi,
This is all very frustrating. With ASDF 1.x, everything worked fine and I have never encountered any issues. Since CL implementations "upgraded" to ASDF 2.x, things run into problems on a regular basis.
I'm sorry you're running into problems. I could have done things better. Yet, I believe ASDF 2 is a clear improvement over ASDF 1. I also believe a lot of your problems come from your rash attitude in dealing with adversity.
What is really annoying is that the ASDF 2.x documentation is misleading. *central-registry* is described as old-style and deprecated that is hopefully going away in the future, and logical pathnames are also described as old-style and better to be avoided. If I read the recent messages by Fare and James correctly, it turns out that if I had sticked to *central-registry* and switched to logical pathnames, everything would be fine and I wouldn't have had to waste time on a very frustrating experience.
I still believe central-registry and logical pathnames are old style, since they necessitate implementation-dependent configuration (i.e. more buck) for results of more limited applicability (i.e. less bang). I am unwilling to dig into each implementation's details and document the 14 different ways to get things working this way.
For a less frustrating experience, you could communicate better and earlier about your problems.
For instance, you apparently switched to logical pathnames after you experienced a bug in the ASDF support for RMCL. If only you had reported that my previous series of fixes to RMCL support still didn't solve your issues, and kept pressing the issues, I would have provided a solution then, rather than when Binghe reported the issue again a few months afterwards.
Your reactions to bug reports are either null, or very discouraging. I usually only get fixes or workarounds by people other than you. Instead I repeatedly hear from you that either I am doing something wrong, or that what I'm trying to do is deprecated, or legacy, or old-style, or whatever. Or you don't react at all (like with my _bug_ report that the documentation is misleading, which is the main reason why I switched from a working setup to a setup that doesn't work). Or like here, you react by saying that I'm not reporting problems properly, or not early enough, or whatever.
I don't get such reactions from any other library/tool maintainer!
You either support a feature, or you don't. Don't do this mixed bag of "I support it, but you're a loser if you use it."
The main reason why I'm having problems with ASDF 2.x is because it's alpha-quality software at best (you're still trying to figure out some very basic concepts, it seems to me), yet you don't even call it beta quality, but instead choose to call it 2.x, push it down everybody's throats, and turn a whole community into alpha testers who didn't volunteer to be guinea pigs in the first place.
I have used ASDF 1.x and it's central registry approach for years in almost all CL implementations available, and I have never encountered any problems with it. I have also used logical pathnames to some limited extent years ago, and my experience with those weren't even remotely as bad as with ASDF 2.x. When using them recently, for a few weeks they actually made something work that ASDF 2.x claims to support, but actually didn't really, until ASDF screwed it up again.
I'm not sure how to proceed from here. Communicating with you and reporting bugs doesn't seem to buy anything. If I had the choice I would just drop ASDF 2.x and go back to ASDF 1.x, but this doesn't seem a viable option. Or is it?
Pascal
Please take one or two steps back and try to see the global picture: Logical pathnames and *central-registry* have their quirks and complications, that is correct. But all you're doing is to replace this with an alternative that has again their own quirks and complications. So overall you're not making things easier, you're just replacing one difficult-to-use system with another difficult-to-use system. This is not a win, not for anybody.
I believe I made things easier: no more per-implementation configuration, no more attempts to badly documentation half of them.
ASDF is not the central focus of my work. It's a tool that is supposed to make my life easier, not harder. I want to contribute to the Common Lisp community by providing my own libraries, not by fighting a build tool.
I will try to switch to *central-registry* again. It seems promising that this could actually work in the mid run and not cause any further problems down the line. Please make sure that it stays that way.
Best, Pascal
On 12 Jun 2011, at 02:25, Faré wrote:
TL;DR: ASDF currently doesn't play so well with logical pathnames. I'm seeking advice on how to make things better — or on whether it's worth the trouble.
Dear all,
Pascal's recent plight with logical pathnames on SBCL once again rises the issue of how much ASDF (or SBCL) should support logical pathname users, and how they should behave to make logical pathname users happy.
With case-sensitivity issues, things only get worse!
(Note: personally inviting James Anderson to the discussion, since he's the only strong proponent and user of logical pathnames I know.)
REMINDER ABOUT LOGICAL PATHNAMES (LPNs)
So, the CLHS says LPNs are case-converted to upper-case, portably restricted to such upper-case characters, and get translated to physical pathnames in an implementation-dependent way. On Unix, with its case-sensitive filesystems and lower-case conventions, the useful thing is then downcasing names.
At least SBCL and CLISP follow both the standard and the useful pathname mapping convention. SBCL goes on to length to throw an error when non-portable code tries to break the standard restrictions on logical-pathnames; CLISP will let you manually make-pathname a LPN with lower-case or mixed-case characters, but will still downcase them at the end (the latest CLISP 2.49 also seems to not want to create a logical pathname with parse-namestring). CCL tries to make users happy by leaving the logical pathname host case-insensitive (per the standard) but case-preserving, and being case-sensitive in the rest of the pathname (if you want upper-case, you know where to find it). To collect and analyze the behavior of each of 14 implementations is left as an exercise to the logical-pathname loving reader [M20]. To devise, document and get implementations to adopt a common behavior that would be universally accepted by all is left as another exercise [50].
ASDF NAMING OF SYSTEMS
Similarly, when naming an ASDF system, to allow to designate systems with symbols (CL legacy), which are case-converted, yet map them to a unixy lower-case name, and still allow systems with all kind of cases, symbols are downcased whereas strings preserved. Then the filesystem is queried with the resulting normalized string name (see function coerce-name).
Now with its good old central-registry, ASDF used to query each directory every time a system was requested. This works great with logical pathnames, as it defers all case handling to the last minute, and allows .asd files to be loaded with a LPN as the *load-pathname*. However, this was somewhat slow, and it didn't scale to recursively searching directories, and so came the habit of creating "link farms", single directories with plenty of symlinks to adequate .asd files. Of course, symlinks are both not so portable (not very well supported in Windows, if at all, though later versions of ASDF recognize Windows shortcuts as a substitute), and a maintenance nightmare (unlike Macintosh aliases, they are not automatically updated when a system is installed, moved or deleted). Therefore link farms were not a good interface to end-users.
For ASDF 2, I implemented a new way to manage system files: the source-registry. It allows you to specify trees to search recursively as well as single directories. Whether the registry is searched lazily (when a system is requested) or eagerly (one the first time around) or yet something else, was left unspecified. In my first implementation of it, I built upon the previous central-registry, and at initialization time I was looking for which subdirectories in the specified trees did contain .asd files, then saved these in a list that I consulted in the very same way as the central-registry. (Note: the central registry is still there, and consulted first.)
However, DIRECTORY returns fully resolved TRUENAMEs, and any portable way of searching inside subdirectories is doomed to squash away logical pathnames. Currently, any use of :tree in source-registry will resolve into physical pathnames (PPNs) on most implementations, and always did.
However, entries with :directory used to preserve LPNs. Not so with 2.014.7, where, prompted by a Quicklisp feature request, I implemented eager caching of ASDF systems. So I query DIRECTORY and save the results in a hash-table indexed by pathname-name. The table is case-sensitive, to reflect the case-sensitive names of ASDF. One consequence is that :directory entries do not preserve LPNs anymore.
Another more subtle consequence is that things may go wrong if your filesystem is case-insensitive but case-preserving. In the old way of doing things (still available with the central-registry), you'd typically be looking for the file with lower-case name, and you would find it even if named in different cases on disk. With the old way, you'll record the name in its case mix, and will never match it against the (lowercase) name. So some systems that depend on this behavior will disappear.
POTENTIAL SOLUTIONS
An easy way out is to declare that ASDF from now on shall be case-insensitive, using EQUALP to compare system names and in hash-tables that cache system files. Another way out is to declare that ASDF is still case sensitive, and that the only case allowed is lower-case for physical filenames. Any system that doesn't work with this new interpretation probably didn't work portably with the old one, anyway.
A harder way out would be to assume case-sensitivity in the filesystem (since some filesystems are case-sensitive, and any asd file that depends on case-insensitivity is non-portable and deserves to lose), and make extra effort when using DIRECTORY against logical pathnames to always reconstitute LPNs from the PPNs given by directory, and drop the reconstituted results if they don't resolve to the same thing. But is it worth the pain?
Finally, I could do nothing, and assume that people who go through the pain of setting up logical pathnames before they run ASDF can just as well setup the *central-registry* and have LPNs be recognized in the good old way. If you use the source-registry, your LPNs will be squashed, and nothing will break in the code since code works fine with PPNs, just like most everyone use it, but your debug information will be stored according to the PPN, not the LPN. Meh.
Zach (if you're still reading), do any systems in the wild use anything but lower-case names for system files?
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Two members of the Political Police salute a giant portrait of our Great Leader
- Comrade, do you think the same as I do? inquires the first one, with
a sincere gaze pleeing into his colleagues' eyes.
- Comrade, the second one replies and returns the same gaze: yes, I do.
- In that case, comrade, you're under arrest! concludes the first one.
EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Sbcl-devel mailing list Sbcl-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sbcl-devel
-- Pascal Costanza
EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Sbcl-devel mailing list Sbcl-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sbcl-devel
-- Pascal Costanza
Your reactions to bug reports are either null, or very discouraging.
Which bug did you report that I didn't address? There are archives, please show me.
I usually only get fixes or workarounds by people other than you.
I'm glad you're getting support from others. Unhappily, you won't get any from me unless you communicate with me.
Instead I repeatedly hear from you that either I am doing something wrong, or that what I'm trying to do is deprecated, or legacy, or old-style, or whatever.
I never said anything was "deprecated". central-registry and logical pathnames are very much supported. I did say legacy and old-style indeed. Which means they continue to work as they always did. Robert Goldman and I even took pains to maintain and extend the documentation on how to use them, to include common usage, known pitfalls and some advanced features. While it's not a lot of documentation, it's still more than was before.
Or you don't react at all (like with my _bug_ report that the documentation is misleading, which is the main reason why I switched from a working setup to a setup that doesn't work). Or like here, you react by saying that I'm not reporting problems properly, or not early enough, or whatever.
As far as I can tell, the reason your setup didn't work is because the MCL support had bitrotten. My excuse for that is that I never had a chance to use a Mac. As far as I know, I fixed all the issues I am aware of — based on binghe's bug reports. I never had a clear bug report from you.
I don't get such reactions from any other library/tool maintainer!
My apologies. I obviously fail to communicate with you. But communication is a two-way thing. Maybe you can come down to my level.
You either support a feature, or you don't. Don't do this mixed bag of "I support it, but you're a loser if you use it."
I support central-registry and logical pathnames within my limits. I didn't touch the legacy configuration system. It's working, it's stable. You can keep using it as you always did before. It takes priority over the new source-registry. If you're using these features, though, you're not a loser: you're an advanced user; your curse is that you have to take responsibility for that, because lesser people such as I are unable to do it. You already know more about logical pathnames than I do; I'm ready to learn from you everything you'll tell me about how to do things right about them.
The main reason why I'm having problems with ASDF 2.x is because it's alpha-quality software at best (you're still trying to figure out some very basic concepts, it seems to me), yet you don't even call it beta quality, but instead choose to call it 2.x, push it down everybody's throats, and turn a whole community into alpha testers who didn't volunteer to be guinea pigs in the first place.
I called it 2.x to make it clear that there had been significant changes since the first 1.x series, and that while compatibility is our goal, we warn that there might be breakage in a few formerly underspecified or non-portable corner cases, or on platforms we don't have access to.
I indeed am trying to "push it down everybody's throats", in other words I aim to satisfy everyone enough that they will adopt it. I apologize if you're experiencing trouble and encourage you to pick whichever legacy version you're more satisfied with, if you're experiencing issues with mine. I certainly didn't install ASDF 2.x on your machine. Why did you even try to upgrade? If you needed a bug fix or new feature, then maybe it's not totally useless. If you just wanted to test it, then I thank you for testing: you were the very first to try ASDF 2 on RMCL.
I have used ASDF 1.x and it's central registry approach for years in almost all CL implementations available, and I have never encountered any problems with it. I have also used logical pathnames to some limited extent years ago, and my experience with those weren't even remotely as bad as with ASDF 2.x. When using them recently, for a few weeks they actually made something work that ASDF 2.x claims to support, but actually didn't really, until ASDF screwed it up again.
My only claim of support is that I will fix bugs that are reported to me. I can't fix bugs that are not reported. If you have an unusual setup, you have to explain what you are doing, what is breaking, and how it is breaking. I'm not going to remotely hack into your computer at night to find out whether things are wrong and why. I unhappily can't run batteries of test on an implementation I don't have access to.
That said, yes, it might be useful to write unit tests for the support of logical pathnames by the source-registry. Patches welcome.
I'm not sure how to proceed from here. Communicating with you and reporting bugs doesn't seem to buy anything. If I had the choice I would just drop ASDF 2.x and go back to ASDF 1.x, but this doesn't seem a viable option. Or is it?
I don't see why you believe that ASDF 1.x isn't a viable option. Certainly, if you believe that ASDF 2.x doesn't bring anything valuable, you should stick to ASDF 1.x. Of course, I won't be able to provide support for it, but that shouldn't be an issue for you, since my support seems of little value to you.
Best regards,
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Fascists divide in two categories: the fascists and the anti-fascists — Ennio Flaiano
OK, people, please clam down ...
I suggest we putting our efforts on solving real issues but arguing. Today I heard that Faré just bought his first Mac computer, I believe he will take care of RMCL better than before.
I understand that Faré are trying to make ASDF2 perfect: supporting all available CL platforms so that other ASDF-based packages could have chances to run. From my personal view in these months, maybe ASDF2 grows too fast, as a build tool it grows even faster than other CL packages which do real world function. As a common Lisper using CL on work and maintain some CL packages, I think I just need:
1) asdf:*central-registry* works the same way as before, 2) Quicklisp works, 3) All my previous written valid .asd files won't fail.
other things, I don't care. I think Faré is a very good Lisp programmer, I can see this from ASDF2 source code, I hope Faré could help us (MCL users) solving necessary issues which is caused by ASDF2 development when Faré don't have a Mac, and no doubt all MCL users will say thanks. And I think every ASDF user should want it stable than feature-rich, maybe Faré could consider this option someway in the future.
Best Regards,
Chun Tian (binghe)
Your reactions to bug reports are either null, or very discouraging.
Which bug did you report that I didn't address? There are archives, please show me.
I usually only get fixes or workarounds by people other than you.
I'm glad you're getting support from others. Unhappily, you won't get any from me unless you communicate with me.
Instead I repeatedly hear from you that either I am doing something wrong, or that what I'm trying to do is deprecated, or legacy, or old-style, or whatever.
I never said anything was "deprecated". central-registry and logical pathnames are very much supported. I did say legacy and old-style indeed. Which means they continue to work as they always did. Robert Goldman and I even took pains to maintain and extend the documentation on how to use them, to include common usage, known pitfalls and some advanced features. While it's not a lot of documentation, it's still more than was before.
Or you don't react at all (like with my _bug_ report that the documentation is misleading, which is the main reason why I switched from a working setup to a setup that doesn't work). Or like here, you react by saying that I'm not reporting problems properly, or not early enough, or whatever.
As far as I can tell, the reason your setup didn't work is because the MCL support had bitrotten. My excuse for that is that I never had a chance to use a Mac. As far as I know, I fixed all the issues I am aware of — based on binghe's bug reports. I never had a clear bug report from you.
I don't get such reactions from any other library/tool maintainer!
My apologies. I obviously fail to communicate with you. But communication is a two-way thing. Maybe you can come down to my level.
You either support a feature, or you don't. Don't do this mixed bag of "I support it, but you're a loser if you use it."
I support central-registry and logical pathnames within my limits. I didn't touch the legacy configuration system. It's working, it's stable. You can keep using it as you always did before. It takes priority over the new source-registry. If you're using these features, though, you're not a loser: you're an advanced user; your curse is that you have to take responsibility for that, because lesser people such as I are unable to do it. You already know more about logical pathnames than I do; I'm ready to learn from you everything you'll tell me about how to do things right about them.
The main reason why I'm having problems with ASDF 2.x is because it's alpha-quality software at best (you're still trying to figure out some very basic concepts, it seems to me), yet you don't even call it beta quality, but instead choose to call it 2.x, push it down everybody's throats, and turn a whole community into alpha testers who didn't volunteer to be guinea pigs in the first place.
I called it 2.x to make it clear that there had been significant changes since the first 1.x series, and that while compatibility is our goal, we warn that there might be breakage in a few formerly underspecified or non-portable corner cases, or on platforms we don't have access to.
I indeed am trying to "push it down everybody's throats", in other words I aim to satisfy everyone enough that they will adopt it. I apologize if you're experiencing trouble and encourage you to pick whichever legacy version you're more satisfied with, if you're experiencing issues with mine. I certainly didn't install ASDF 2.x on your machine. Why did you even try to upgrade? If you needed a bug fix or new feature, then maybe it's not totally useless. If you just wanted to test it, then I thank you for testing: you were the very first to try ASDF 2 on RMCL.
I have used ASDF 1.x and it's central registry approach for years in almost all CL implementations available, and I have never encountered any problems with it. I have also used logical pathnames to some limited extent years ago, and my experience with those weren't even remotely as bad as with ASDF 2.x. When using them recently, for a few weeks they actually made something work that ASDF 2.x claims to support, but actually didn't really, until ASDF screwed it up again.
My only claim of support is that I will fix bugs that are reported to me. I can't fix bugs that are not reported. If you have an unusual setup, you have to explain what you are doing, what is breaking, and how it is breaking. I'm not going to remotely hack into your computer at night to find out whether things are wrong and why. I unhappily can't run batteries of test on an implementation I don't have access to.
That said, yes, it might be useful to write unit tests for the support of logical pathnames by the source-registry. Patches welcome.
I'm not sure how to proceed from here. Communicating with you and reporting bugs doesn't seem to buy anything. If I had the choice I would just drop ASDF 2.x and go back to ASDF 1.x, but this doesn't seem a viable option. Or is it?
I don't see why you believe that ASDF 1.x isn't a viable option. Certainly, if you believe that ASDF 2.x doesn't bring anything valuable, you should stick to ASDF 1.x. Of course, I won't be able to provide support for it, but that shouldn't be an issue for you, since my support seems of little value to you.
Best regards,
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Fascists divide in two categories: the fascists and the anti-fascists — Ennio Flaiano
asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
On 6/13/11 Jun 13 -8:51 AM, Chun Tian (binghe) wrote:
OK, people, please clam down ...
I suggest we putting our efforts on solving real issues but arguing. Today I heard that Faré just bought his first Mac computer, I believe he will take care of RMCL better than before.
I very much agree with this. Please also make allowances --- RMCL is an obscure implementation of an already (regrettably) obscure programming languages. Those of us trying to maintain ASDF may need very clear assistance in replicating bugs related to this implementation.
[As a point of process, it might help us somewhat if these bugs would appear on launchpad, instead of only on the mailing list.]
I understand that Faré are trying to make ASDF2 perfect: supporting all available CL platforms so that other ASDF-based packages could have chances to run. From my personal view in these months, maybe ASDF2 grows too fast, as a build tool it grows even faster than other CL packages which do real world function. As a common Lisper using CL on work and maintain some CL packages, I think I just need:
- asdf:*central-registry* works the same way as before,
I use asdf:*central-registry* as before, and have had no troubles with it. I have done so on Mac, Linux and Windows, SBCL, ACL and (a little) CCL.
- Quicklisp works,
I don't use this, but Xach seems to be actively monitoring the state of ASDF, and I believe the record shows that bugs he reports have been fixed promptly.
- All my previous written valid .asd files won't fail.
I don't believe this should ever be a problem, with the proviso that behavior may change as bugs are fixed (see below).
As Fare has said before, it would /really/ help if people would contribute test cases that exercise the asdf:*central-registry*.
other things, I don't care. I think Faré is a very good Lisp programmer, I can see this from ASDF2 source code, I hope Faré could help us (MCL users) solving necessary issues which is caused by ASDF2 development when Faré don't have a Mac, and no doubt all MCL users will say thanks. And I think every ASDF user should want it stable than feature-rich, maybe Faré could consider this option someway in the future.
There has been some feature addition, but there has been no substantial revision of existing functionality, except in cases which were clearly bug fixes (e.g., the badly broken module dependencies; the erratic behavior of the :pathname initargs).
I would also point out that there are still some known bugs in ASDF /that we did not put there/. We have not meddled with them precisely because of concern for stability, and despite the fact that some of these are clearly bugs, and even critical bugs. Chief among these is the fact that ASDF does not notice changes in upstream systems.
ASDF 2 is, in fact, quite conservative in its changes. The primary changes have been in attempts to make configuration more reliable across implementations and operating systems. The DEFSYSTEM API has been quite stable.
Attentive readers of this mailing list should be able to assess this claim themselves. Reviewing their memory or mailing list archives, they will find that a number of changes to the API, even such changes that appeared to be clearly improvements, have been rejected on the grounds of backwards compatibility and stability.
Indeed, if anything I would like to see a move to start an ASDF 3 branch where some issues like the aforementioned system dependencies could be addressed. I understand and respect Fare's lack of desire to operate such a branch in favor of XCVB, however.
Yours sincerely, r
The main reason why I'm having problems with ASDF 2.x is because it's alpha-quality software at best (you're still trying to figure out some very basic concepts, it seems to me), yet you don't even call it beta quality, but instead choose to call it 2.x, push it down everybody's throats, and turn a whole community into alpha testers who didn't volunteer to be guinea pigs in the first place.
as people with positive opinion speak up much less, let me point out here that i'm a happy user of ASDF2 from its early days.
it did require some work to follow it, but it made many things simpler and more reliable in our dev setup and production environment (the load order with underspecified dependencies using ASDF1 used to be influenced by the filesystem order, seemingly not even randomly, because errors consistently appeared when changes were pulled to another computer. rmfasl didn't influence it. a real pain in the ass when build fails on the production system after an upgrade...)
any form of backwards incompatibility, and upgrading in general, is a pain, but we need to live with it because for now it's part of being a software developer (it's solvable on the language/vm/devtool level, but our ideas are mere vapour). i regularly unpull problematic patches of random libraries, and ASDF is just one of them. luckily ASDF2 can even properly upgrade itself now!
to me it's certainly an improvement over ASDF1.
thanks for all the work put into ASDF, both v1 and v2!
El 17/06/11 00:31, Attila Lendvai escribió:
as people with positive opinion speak up much less, let me point out here that i'm a happy user of ASDF2 from its early days.
+1
-
Attila Lendvai -
Chun Tian (binghe) -
Faré -
Francisco Vides Fernández -
james anderson -
Pascal Costanza -
Robert Goldman