Another CLC fix:
*load-truename* is assumed to point to the source directory that also contains the icons/ directory. In CLC, this isn't the case as all fasl are loaded from /var/cache/common-lisp-controller/.
I changed Apps/Listener/package.lisp to also probe in #.*compile-file-truename*, that most likely point to a directory containing the icons too.
The problem is that I used cl-fad for directory probing. I personally don't mind to have mcclim use cl-fad, as I have it installed anyway and it's pretty lightweight, but on the other hand that might not be true for the mcclim project as a whole, especially as it needs only a single function.
The CLC way of doing things seems a good idea first, but needs to be improved. Probably, CLC should introduce a new asdf class, for instance "auxilary". All files/directories that are tagged as auxilary are symlinked in /var/cache/common-lisp-controller to the original sources. So in the code, we don't have to give up the assumption that *load-truename* contains stuff from the distribution tarball.
Or probably CLC shouldn't wait for ":auxilary" and create a mirror of all files in /usr/share/common-lisp/source per default via symlinks. This doesn't seem too costly. Especially when we create symlinks for directories and only when we need to add content these symlinked /var/cache/common-lisp-controller subdirectories turn them into real directories after filling them with the respective symlinks. Kind of lazy symlinking. But err, I'm starting to get off-topic.
Here is the patch. If the list objects cl-fad, I'd suggest to copy the respective ~15 lines of code from cl-fad.
Clemens Fruhwirth clemens@endorphin.org writes:
Another CLC fix:
Is this a fix for direct users of clc, or is this a fix that is motivated by some future debian packaging?
The reason I ask is that I suspect this is the wrong answer, in general, for handling external resources and filesystem-location-independent binaries (which is kind of what we're talking about).
Cheers,
Christophe
"CF" == Clemens Fruhwirth clemens@endorphin.org writes:
CF> Another CLC fix: *load-truename* is assumed to point to the CF> source directory that also contains the icons/ directory. In CF> CLC, this isn't the case as all fasl are loaded from CF> /var/cache/common-lisp-controller/.
CF> I changed Apps/Listener/package.lisp to also probe in CF> #.*compile-file-truename*, that most likely point to a CF> #directory CF> containing the icons too.
CF> The problem is that I used cl-fad for directory probing. I CF> personally don't mind to have mcclim use cl-fad, as I have it CF> installed anyway and it's pretty lightweight, but on the other CF> hand that might not be true for the mcclim project as a whole, CF> especially as it needs only a single function.
This suggests a knot of other issues:
1. Having external dependencies is somewhat undesirable in general, but mostly because we don't have clean ways of managing coherent states across multiple systems. E.g., what happens if cl-fad or the spatial-trees systems gets out of synch with McCLIM?
As I understand ASDF, you can specify that you need >= a particular dependency system, but you can't specify = or <=.
Probably with a little care this can be overcome.
More difficult (but possibly conjectural) what happens if *another* system you want loads cl-fad or spatial-trees and the version that other system needs is not congruent with McCLIM's requirements? I know I always get a little nervous when asdf-install loads its private copy of cl-ppcre...
Would it be possible to make an internal version of these systems? E.g., would it be possible to load them into alternative packages, so that they can coexist with a different version? E.g., stuff them into clim.cl-fad? That might be the CL equivalent of statically linking against libraries...
2. CL-FAD seems desirable more generally as a component of McCLIM, because McCLIM needs file-managing gadgets, and these probably need more capable ways of getting at the file system than CL provides in its stock form.
On Wednesday 15 March 2006 09:00 am, rpgoldman@real-time.com wrote:
More difficult (but possibly conjectural) what happens if *another* system you want loads cl-fad or spatial-trees and the version that other system needs is not congruent with McCLIM's requirements? I know I always get a little nervous when asdf-install loads its private copy of cl-ppcre...
I am using McCLIM to graph cl-graph based graphs, and cl-graph requires cl-fad. So, basically, this problem is not conjectural for me.
-jm
"JM" == John Morrison jm@mak.com writes:
JM> On Wednesday 15 March 2006 09:00 am, rpgoldman@real-time.com JM> wrote: >> More difficult (but possibly conjectural) what happens if >> *another* system you want loads cl-fad or spatial-trees and the >> version that other system needs is not congruent with McCLIM's >> requirements? I know I always get a little nervous when >> asdf-install loads its private copy of cl-ppcre...
JM> I am using McCLIM to graph cl-graph based graphs, and cl-graph JM> requires cl-fad. So, basically, this problem is not JM> conjectural for me.
I should have been more clear. The problem is conjectural in the sense that we don't have a case (yet, AFAIK) where version conflict arises. E.g., where someone refactors cl-FAD, changing its API, and cl-graph adopts the bleeding-edge version of cl-fad, but McCLIM stays with cl-fad classic.
A counterargument to my claim would be "you should just always use the latest released version." I think in the large this approach is losing. But it's not clear that the CL community IS large enough for it to be a problem.
This is a problem that McCLIM experiences, because it uses ASDF, but it's really an ASDF problem, not a McCLIM problem.
We (the CL community) are using ASDF as the equivalent of make + a dynamic library loading system + something akin to rpm. It's clearly very good as a make substitute. It's not clear to me that it's all we need for the latter two functions.
best, Robert
Hello,
On Wed, Mar 15, 2006 at 08:32:04AM +0100, Clemens Fruhwirth wrote:
The problem is that I used cl-fad for directory probing. I personally don't mind to have mcclim use cl-fad, as I have it installed anyway and it's pretty lightweight, but on the other hand that might not be true for the mcclim project as a whole, especially as it needs only a single function.
I would like to use cl-fad in mcclim. Right now there is, so to speak, a partial implementation of it included in the Clim Listener; in addition to this my File Selecto [1] depends on the functionality of CL-FAD as well, and I don't quite like to just duplicate the code.
As we have now two places where CL-FAD is useful and as we could get rid of some stuff in the Listener I would like to have mcclim use cl-fad; even more as we now have already an external dependency with the spatial-trees package.
Btw, I have resisted to include the File Selector in McCLIM as it is not very nice right now, codewise. In the end it should be the default ACCEPT method for files in +gadget-view+ --- this does already partially work (see at the end of file-selector.lisp for the definition) but still the corresponding ACCEPT-PRESENT-DEFAULT method is missing. Also I would much prefor to use WITH-OUTPUT-AS-GADGET in the selector but it is not yet usable for that job in the moment.
Bye, Max
1) http://www.matroid.org/flux/file-selector.lisp There are also some screenshots of it in the same directory, see File-Selector-*.png.
-
Christophe Rhodes -
Clemens Fruhwirth -
John Morrison -
Max-Gerd Retzlaff -
rpgoldman＠real-time.com