Xach brought this to my attention wrt to maxima, but it's not really about maxima and asdf2. My question is if clear-output-translations should always be called before saving a core. Is there a case where you would not want to run c-o-t before saving a core?
If c-o-t should always be run, wouldn't it make sense for asdf2 to arrange for that? I'm not familar with how other lisps do this, but cmucl does have *before-save-initializations* which is a list of functions that are run before a core is saved. Perhaps asdf2 should push #'c-o-t onto *before-save-initializations*?
Ray
On 6/10/11 Jun 10 -8:55 AM, Raymond Toy wrote:
Xach brought this to my attention wrt to maxima, but it's not really about maxima and asdf2. My question is if clear-output-translations should always be called before saving a core. Is there a case where you would not want to run c-o-t before saving a core?
If c-o-t should always be run, wouldn't it make sense for asdf2 to arrange for that? I'm not familar with how other lisps do this, but cmucl does have *before-save-initializations* which is a list of functions that are run before a core is saved. Perhaps asdf2 should push #'c-o-t onto *before-save-initializations*?
I confess to not fully understanding the ramifications here.
1. What would it mean for ASDF2 to arrange for the clearing of output translations when saving a core? Is there some way to achieve that without ASDF2 having to incorporate code that would infiltrate every lisp implementation's core-dumping process? Wouldn't it be better for the lisp implementations themselves to handle that?
2. On the flip side, are we guaranteed that every lisp implementation's core-resuming facilities would cause the output translations to be reinitialized appropriately?
Thanks, r
On 10 June 2011 10:18, Robert Goldman rpgoldman@sift.info wrote:
On 6/10/11 Jun 10 -8:55 AM, Raymond Toy wrote:
Xach brought this to my attention wrt to maxima, but it's not really about maxima and asdf2. My question is if clear-output-translations should always be called before saving a core. Is there a case where you would not want to run c-o-t before saving a core?
If c-o-t should always be run, wouldn't it make sense for asdf2 to arrange for that? I'm not familar with how other lisps do this, but cmucl does have *before-save-initializations* which is a list of functions that are run before a core is saved. Perhaps asdf2 should push #'c-o-t onto *before-save-initializations*?
I confess to not fully understanding the ramifications here.
- What would it mean for ASDF2 to arrange for the clearing of output
translations when saving a core? Is there some way to achieve that without ASDF2 having to incorporate code that would infiltrate every lisp implementation's core-dumping process? Wouldn't it be better for the lisp implementations themselves to handle that?
- On the flip side, are we guaranteed that every lisp implementation's
core-resuming facilities would cause the output translations to be reinitialized appropriately?
0- Actually, you don't want to (asdf:clear-output-translations), but instead to (asdf:clear-configuration), which will also take care of the source-registry, and any future configuration that may (hopefully not) be added.
1,2- If there were indeed a semi-standard protocol to clear things before image dumping, asdf should indeed probably register this function. However, there isn't, and I'm wary of doing the job on some implementations and not others, which will only encourage users to write sloppy code that works on one implementation and not others.
3- If someone writes a library to handle such things, this asdf cleanup would be a good thing to add there by default. I have vague plans to add such a capability to XCVB — and indeed XCVB allows you to run cleanup forms before to dump an executable — but with XCVB, this particular change doesn't matter so much, does it? [And I'm having trouble with how to do things in a way that make sense on image-linking Lisps such as ECL as well as image-dumping Lisps such as all the other ones.]
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org What you do today will cost you a day of your life.
"Robert" == Robert Goldman rpgoldman@sift.info writes:
Robert> On 6/10/11 Jun 10 -8:55 AM, Raymond Toy wrote: >> >> Xach brought this to my attention wrt to maxima, but it's not really >> about maxima and asdf2. My question is if clear-output-translations >> should always be called before saving a core. Is there a case where >> you would not want to run c-o-t before saving a core? >> >> If c-o-t should always be run, wouldn't it make sense for asdf2 to >> arrange for that? I'm not familar with how other lisps do this, but >> cmucl does have *before-save-initializations* which is a list of >> functions that are run before a core is saved. Perhaps asdf2 should >> push #'c-o-t onto *before-save-initializations*?
Robert> I confess to not fully understanding the ramifications here.
Robert> 1. What would it mean for ASDF2 to arrange for the clearing of output Robert> translations when saving a core? Is there some way to achieve that Robert> without ASDF2 having to incorporate code that would infiltrate every Robert> lisp implementation's core-dumping process? Wouldn't it be better for Robert> the lisp implementations themselves to handle that?
That is a problem. I can certainly make that happen for cmucl, but it seems that asdf should be the one to do it. Except that also makes asdf support for implementation-specific core-dumping code. Not nice.
Robert> 2. On the flip side, are we guaranteed that every lisp implementation's Robert> core-resuming facilities would cause the output translations to be Robert> reinitialized appropriately?
Don't know about that. Cmucl has *after-save-initializations* which is a list of functions to be run when the core is restarted.
Ray
On 11 June 2011 17:34, Raymond Toy toy.raymond@gmail.com wrote:
Don't know about that. Cmucl has *after-save-initializations* which is a list of functions to be run when the core is restarted.
SBCL has similar facilities -- *SAVE-HOOKS* is probably the most approriate one.
I strongly suspect that all implementations that support saving a core have something like this, and if they don't, they should.
Cheers,
-- Nikodemus
On 11 June 2011 11:00, Nikodemus Siivola nikodemus@random-state.net wrote:
On 11 June 2011 17:34, Raymond Toy toy.raymond@gmail.com wrote:
Don't know about that. Cmucl has *after-save-initializations* which is a list of functions to be run when the core is restarted.
SBCL has similar facilities -- *SAVE-HOOKS* is probably the most approriate one.
I strongly suspect that all implementations that support saving a core have something like this, and if they don't, they should.
Cheers,
-- Nikodemus
At this point, my answer is: "I accept patches!"
Is there a library that handles image dumping already? Next thing you'll tell me, the name of that library is "XCVB", and it doesn't have this feature yet.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The main reason Santa is so jolly is because he knows where all the bad girls live.
"Fare" == Far <Far> writes:
Fare> At this point, my answer is: "I accept patches!"
No patch, but this is you could add for cmucl and sbcl:
#+cmu (pushnew 'clear-configuration ext:*before-save-initializations*)
#+sbcl (pushnew 'clear-configuration sb-ext:*save-hooks*)
Ray
-
Faré -
Nikodemus Siivola -
Raymond Toy -
Robert Goldman