When following up discussion about bug 1335323, I stumbled across the following paragraph in the manual:
When system definitions are loaded from @file{.asd} files, a new scratch package is created for them to load into, so that different systems do not overwrite each others operations. The user may also wish to (and is recommended to) include @code{defpackage} and @code{in-package} forms in his system definition files, however, so that they can be loaded manually if need be.
I believe that this is no longer accurate. Fare, you changed to loading everything into ASDF-USER, didn't you?
Also, LOCATE-SYSTEM isn't documented at all. I see that it's exposed by interface.lisp, but I'm not sure why it is. If exposed, I'd like to document it, but it looks like an outsider should always use FIND-SYSTEM.
On Tue, Jul 1, 2014 at 12:54 PM, Robert P. Goldman rpgoldman@sift.info wrote:
When following up discussion about bug 1335323, I stumbled across the following paragraph in the manual:
When system definitions are loaded from @file{.asd} files, a new scratch package is created for them to load into, so that different systems do not overwrite each others operations. The user may also wish to (and is recommended to) include @code{defpackage} and @code{in-package} forms in his system definition files, however, so that they can be loaded manually if need be.
I believe that this is no longer accurate. Fare, you changed to loading everything into ASDF-USER, didn't you?
Indeed, I changed that behavior in 2.27 to always load in ASDF-USER. The previous package trick wasn't actually helping, only making things more complex. For the sake of hygiene, you might still want to use defpackage and in-package if you're going to define new classes, methods, variables that you want to protect from clash.
Also, LOCATE-SYSTEM isn't documented at all. I see that it's exposed by interface.lisp, but I'm not sure why it is. If exposed, I'd like to document it, but it looks like an outsider should always use FIND-SYSTEM.
Outsiders should always use FIND-SYSTEM. People writing s-d-s-f extensions (including Quicklisp) might conceivably use LOCATE-SYSTEM or have to understand how it works.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Pyramid schemes are illegal. Social Security is a pyramid scheme.
Thank you, Faré.
I have updated the manual and pushed that (not bothering with a new version).
Cheers, r
On Tue, Jul 1, 2014 at 2:03 PM, Robert P. Goldman rpgoldman@sift.info wrote:
Thank you, Faré.
I have updated the manual and pushed that (not bothering with a new version).
Can you push? I don't see the change.
Also, can you make a new release to fix the embarrassing bootstrap bug?
And can you merge the minimakefile branch? Or is there more work to do in it?
Finally, what is to be done on the syntax-control branch? Should/may I add some shared-package feature to it?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The World owes you nothing. You owe everything to yourself. — Faré
Faré wrote:
On Tue, Jul 1, 2014 at 2:03 PM, Robert P. Goldman rpgoldman@sift.info wrote:
Thank you, Faré.
I have updated the manual and pushed that (not bothering with a new version).
Can you push? I don't see the change.
It went bad -- I'm at a location with a very thin and rickety connection to the intertubes.
Also, can you make a new release to fix the embarrassing bootstrap bug?
I may have to wait until I get a better connection. It's very bad here. Probably Monday.
I was going to see if we could get the fix to 1335323 in there, as well.
And can you merge the minimakefile branch? Or is there more work to do in it?
All of my attention has been consumed by the syntax-control branch, and there is little enough of that (attention, I mean).
One thing that would make this happen sooner rather than later would be a solution to the dependency tail issue. With the old makefile, the standard development platform (ok, except on Windows) needed no additional dependencies (except for version-bumping). All the tool support was either included or available on linux, Mac + Ports/brew, Windows + cygwin. What's the easiest way for someone to configure an ASDF devel or test setup now?
Also, should we simply prune the makefile now? It doesn't add anything over your CL scripts, does it?
Finally, what is to be done on the syntax-control branch? Should/may I add some shared-package feature to it?
If I understand it correctly, the shared package seems like a modest extension of syntax-control. I don't see why that feature couldn't be added.
I'm still trying to find time to figure out what's wrong with our guinea pig system, broken on syntax-control, unbroken on master. Until I can understand what's going on here, I can't reasonably merge this branch, since I can't support it.
The branches are on my to do list, but will only be merged when I'm confident in my own understanding of them.
Can you push? I don't see the change. Also, can you make a new release to fix the embarrassing bootstrap bug?
I may have to wait until I get a better connection. It's very bad here. Probably Monday.
No problem. Take your time.
I was going to see if we could get the fix to 1335323 in there, as well.
I'm not convinced there is anything there to fix. https://bugs.launchpad.net/asdf/+bug/1335323
And can you merge the minimakefile branch? Or is there more work to do in it?
All of my attention has been consumed by the syntax-control branch, and there is little enough of that (attention, I mean).
One thing that would make this happen sooner rather than later would be a solution to the dependency tail issue. With the old makefile, the standard development platform (ok, except on Windows) needed no additional dependencies (except for version-bumping). All the tool support was either included or available on linux, Mac + Ports/brew, Windows + cygwin. What's the easiest way for someone to configure an ASDF devel or test setup now?
Kambiz was suggesting a git tree with modules, which I believe is a great idea. An alternative would be to have a script to download all dependencies, like xcvb has, that itself could be generated by CL from data files. Or to rely on either clbuild or quicklisp.
Also, should we simply prune the makefile now? It doesn't add anything over your CL scripts, does it?
Well, it's already largely pruned. What it still does it concatenate the lisp files into asdf.lisp when there isn't a valid previous asdf.lisp to bootstrap from.
Finally, what is to be done on the syntax-control branch? Should/may I add some shared-package feature to it?
If I understand it correctly, the shared package seems like a modest extension of syntax-control. I don't see why that feature couldn't be added.
OK, I'll add it to the branch, at some point. I believe it's pointless to have readtable protection but no package protection.
I'm still trying to find time to figure out what's wrong with our guinea pig system, broken on syntax-control, unbroken on master. Until I can understand what's going on here, I can't reasonably merge this branch, since I can't support it.
I'm at your service if you need help with that.
The branches are on my to do list, but will only be merged when I'm confident in my own understanding of them.
Of course. Thanks!
P.S. I believe that the documentation patch is there now.
I saw it, and pushed some further tweaks. I also expanded tabs, which will make sbcl happier.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Some cause happiness wherever they go. Others whenever they go.