Hello there,
it has been a very long time since I posted here, but most recently, thanks to a couple of pesky bug reports on HEΛP by Mirko Vukovic, and because I had a couple of days relatively free, I was able to go back to do some programming, fix (some of) the bugs and post here.
Here is the story. There were two bugs which I had to deal with (there are more, of course).
The second bug was easier to diagnose, but the fix was more complicated (especially due to the NIH syndrome I suffer from). The problem is that ASDF moves the compiled code around, but not auxiliary data, like in my case, .css files. I could have followed what ASDF does, but I decided to go another way and came up with a small library I called Common Lisp Application Data (CLAD, because you need to "dress" your code).
CLAD assumes these "fixed" locations to create per-application or per-library subfolders of a "Common Lisp" one. That is, CLAD ensures the presence of the following folders in your account.
(defparameter *helambdap-data-folder*
(clad:ensure-app-or-library-data-folder "HELambdaP")
"The user HELambdaP data folder.")
On Mac OS X, this results in the folder ~/Library/Common Lisp/HELambdaP; a library or an application can now rely on a clear space where to store "common" data files. For HEΛP it solved the problem of where to find the .css files in a reliable place.
Trivial? Yes.
NIH syndrome? Of course.
Complete? No.
Useful? You be the judge of that.
(cheers)
it has been a very long time since I posted here, but most recently, thanks to a couple of pesky bug reports on HEΛP by Mirko Vukovic, and because I had a couple of days relatively free, I was able to go back to do some programming, fix (some of) the bugs and post here.
Here is the story. There were two bugs which I had to deal with (there are more, of course).
- A bug triggered by CCL and its implementation of the Common Lisp Reader algorithm.
- A buglet due to missing supporting data (.css files in this case) in the deployment of the HEΛP generated documentation.
The second bug was easier to diagnose, but the fix was more complicated (especially due to the NIH syndrome I suffer from). The problem is that ASDF moves the compiled code around, but not auxiliary data, like in my case, .css files. I could have followed what ASDF does, but I decided to go another way and came up with a small library I called Common Lisp Application Data (CLAD, because you need to "dress" your code).
CLAD
By now, at least on Windows 10 and Mac OS X (and Linux), there is a a notion of an Application and Data Folder. The user version of this folder (as opposed to the system one) is ~/Library/ on Mac OS X and %USERPROFILE%\AppData\Roaming\ (this is the "roaming" profile in W10 parlance). For Linux there are several semi-standards, one of them is the XDG base directory specification; in this case a common solution is to use the ~/.config/ folder.CLAD assumes these "fixed" locations to create per-application or per-library subfolders of a "Common Lisp" one. That is, CLAD ensures the presence of the following folders in your account.
- Mac Os X: ~/Library/Common Lisp/
- Windows 10: %USERPROFILE%\AppData\Roaming\Common Lisp\
- Linux/Unix: ~/.config/common-lisp/ (in this case, I am following ASDF lead)
- user-cl-data-folder, which returns the pathnames of the folders above.
- ensure-app-or-library-data-folder, which, as the name implies, ensures that a subfolder exists in the proper location.
- app-or-library-data-folder, which returns the pathname associated to a library or app.
(defparameter *helambdap-data-folder*
(clad:ensure-app-or-library-data-folder "HELambdaP")
"The user HELambdaP data folder.")
On Mac OS X, this results in the folder ~/Library/Common Lisp/HELambdaP; a library or an application can now rely on a clear space where to store "common" data files. For HEΛP it solved the problem of where to find the .css files in a reliable place.
Trivial? Yes.
NIH syndrome? Of course.
Complete? No.
Useful? You be the judge of that.
(cheers)