Nope, it does not work. Try it for yourself - Point MC to http://source.squeakfoundation.org/Graphics and try: * loading GraphicsCheckpointTest-ar.3.mcz will correctly complain (this is what *should* happen) * loading Graphics-ar.22.mcz will just hose your machine (this is what *does* happen) If you load things in the correct order, first Graphics-ar.21.mcz *and then* Graphics-ar.22.mcz everything shows up fine - including the (now loaded) dependency of GraphicsCheckpoint-1-ar.4.mcz.
Any ideas? Could this be related to the new "simu-load" feature?
Cheers, - Andreas
Cees De Groot wrote:
On 10/25/05, Andreas Raab andreas.raab@gmx.de wrote:
and the question here is simply: Is there *any* way of achieving this?
Make the dangerous version depend on a DangerousSituationChecker package and have a DangerousSituationChecker class>>initialize that does the check?
On 10/25/05, Andreas Raab andreas.raab@gmx.de wrote:
Any ideas? Could this be related to the new "simu-load" feature?
Probably. I'm at a customer's site now, so I'll come up with another bright idea tonight ;).
Incidentally, the customer uses VAST with ENVY/Manager. It has a whole slew of warts (more than I care to list here ;-)), but one very nice feature: loads are atomic. Which means that you can cancel a load halfway and nothing has changed in your image. AFAIK, this is missing in MC, not?
Hi!
Cees De Groot cdegroot@gmail.com wrote:
Incidentally, the customer uses VAST with ENVY/Manager. It has a whole slew of warts (more than I care to list here ;-)), but one very nice feature: loads are atomic. Which means that you can cancel a load halfway and nothing has changed in your image. AFAIK, this is missing in MC, not?
Just a sidenote:
Henrik's code for loading modules had two phases - first he loaded modules (a chunk similar format) into the image in a self contained way (not connecting it to anything really) and then a module was activated using a sweep become operation making the activation step quite atomical.
regards, Göran
On Oct 25, 2005, at 5:07 AM, Cees De Groot wrote:
Incidentally, the customer uses VAST with ENVY/Manager. It has a whole slew of warts (more than I care to list here ;-)), but one very nice feature: loads are atomic. Which means that you can cancel a load halfway and nothing has changed in your image. AFAIK, this is missing in MC, not?
Yes, we've wanted to put this in MC for a long time. As it happens, I'm working on a SystemEditor package that will allow tools to make multiple changes to the system and have them take effect atomically. When it's ready, it'll be an important part of MC2, and could be retrofitted into MC1 as well. It might even be worthwhile to think about doing an atomic ChangeSet loader.
As a simple example, Stéphane recently ran into a problem where he tried to load a package that modified Rectangle>>insetBy: so that it called #isRectangle, which is a new method in the same package. With SystemEditor, Monticello wouldn't have to know about the dependency between the two methods; it would do something like this:
"create an editor for the class we want to change." system := SystemEditor new. class := system at: #Rectangle.
"Make changes using the usual protocol." class compile: newVersionOfInsetBy class compile: newMethodIsRectangle
"commit the changes atomically." system commit.
Because the protocols for making changes are the same, updating Monticello to use SystemEditor should be pretty easy.
Colin
Am 25.10.2005 um 10:35 schrieb Andreas Raab:
Nope, it does not work. Try it for yourself - Point MC to http:// source.squeakfoundation.org/Graphics and try:
- loading GraphicsCheckpointTest-ar.3.mcz will correctly complain (this is what *should* happen)
- loading Graphics-ar.22.mcz will just hose your machine (this is what *does* happen)
If you load things in the correct order, first Graphics-ar.21.mcz *and then* Graphics-ar.22.mcz everything shows up fine - including the (now loaded) dependency of GraphicsCheckpoint-1-ar.4.mcz.
Any ideas? Could this be related to the new "simu-load" feature?
I think this behaviour is not new, a package with its dependencies was always loaded in one run.
You're trying to find a solution without config maps, is that correct? Did you try the preload script? I think this should always be executed ...
Maybe I should try myself. Are you starting with a 3.8 or 3.9a image?
- Bert -
Am 25.10.2005 um 11:33 schrieb Bert Freudenberg:
Did you try the preload script? I think this should always be executed ...
Ah, actually the package-info version in 3.9a does not support scripts. And MC has a bug that prevents scripts from being executed when the PackageInfo class does not support them (the actual error is supressed so you don't see it [*]). Actually they should still be executed on load, if you created the mcz on a system with a package- info version supporting scripts. And provided the binary snapshot loading works, as the scripts are not in the textual snapshot (which is another bug, but not that important).
[*] means, do not just throw an Error in the preamble - MC suppresses errors and presents the erroneous definitions in bulk after loading.
I fixed the first MC bug, so if you load these:
http://source.squeakfoundation.org/inbox/Monticello-bf.277.mcz http://source.impara.de/Stuff/Graphics-bf.24.mcz
you'll get an Abort notice when loading Graphics-bf.24 in an unsafe image:
(BitBlt canUnderstand: #displayString:from:to:at:kern:font:) ifFalse: [Abort new signal: 'need to load Graphics-ar.21 first!']
- Bert -
Bert Freudenberg wrote:
I fixed the first MC bug, so if you load these:
http://source.squeakfoundation.org/inbox/Monticello-bf.277.mcz http://source.impara.de/Stuff/Graphics-bf.24.mczyou'll get an Abort notice when loading Graphics-bf.24 in an unsafe image:
(BitBlt canUnderstand: #displayString:from:to:at:kern:font:) ifFalse: [Abort new signal: 'need to load Graphics-ar.21 first!']
This looks good. Can I rely on this behavior in the future? I don't know if what you say about packageinfo having scripts relates to or invalidates the above. I'd be perfectly happy with the above solution.
Cheers, - Andreas
Am 25.10.2005 um 22:12 schrieb Andreas Raab:
Bert Freudenberg wrote:
I fixed the first MC bug, so if you load these: http://source.squeakfoundation.org/inbox/Monticello-bf.277.mcz http://source.impara.de/Stuff/Graphics-bf.24.mcz you'll get an Abort notice when loading Graphics-bf.24 in an unsafe image: (BitBlt canUnderstand: #displayString:from:to:at:kern:font:) ifFalse: [Abort new signal: 'need to load Graphics-ar.21 first!']
This looks good. Can I rely on this behavior in the future? I don't know if what you say about packageinfo having scripts relates to or invalidates the above. I'd be perfectly happy with the above solution.
Well, the script is executed if you have that fixed Monticello version, or PackageInfo with script support. Republishing the package will retain the script only if you have the right PackageInfo.
Unless we decide to remove script support from MC this should continue to work.
- Bert -
Bert Freudenberg wrote:
Well, the script is executed if you have that fixed Monticello version, or PackageInfo with script support. Republishing the package will retain the script only if you have the right PackageInfo.
The "right" PackageInfo? Which one would that be?
Cheers, - A.
Am 25.10.2005 um 23:10 schrieb Andreas Raab:
Bert Freudenberg wrote:
Well, the script is executed if you have that fixed Monticello version, or PackageInfo with script support. Republishing the package will retain the script only if you have the right PackageInfo.
The "right" PackageInfo? Which one would that be?
One that implements the script accessors. This originally comes from PackageInfo-Base-avi.20.mcz. The impara version at http:// source.impara.de/mc.html does have it (PackageInfo-Base, that is, we don't have a full PackageInfo package).
The script support is not widely adopted and tested, and still has a few flaws (like, it actually stores StringHolders in PackageInfo instead of Strings, this was copied from the preamble logic in ChangeSets).
- Bert -
I wanted to push MC277 into the squeakfoundation 3.9a repository but I saw that it was based on Integrated PlusTools.zip (Mantis #1915). So is it safe for me to conclude that I should integrate all the PlusTools changes before the fix of bert in MC?
Stef
http://source.impara.de/Stuff/Graphics-bf.24.mczyou'll get an Abort notice when loading Graphics-bf.24 in an unsafe image: (BitBlt canUnderstand: #displayString:from:to:at:kern:font:) ifFalse: [Abort new signal: 'need to load Graphics-ar.21 first!']
This looks good. Can I rely on this behavior in the future? I don't know if what you say about packageinfo having scripts relates to or invalidates the above. I'd be perfectly happy with the above solution.
Well, the script is executed if you have that fixed Monticello version, or PackageInfo with script support. Republishing the package will retain the script only if you have the right PackageInfo.
Unless we decide to remove script support from MC this should continue to work.
- Bert -
Hmm? Monticello-bf.277 is a direct child of your Monticello- stephaneducasse.276 version which *is* in 3.9a, only two methods related to scripts changed.
- Bert -
Am 26.10.2005 um 15:12 schrieb stéphane ducasse:
I wanted to push MC277 into the squeakfoundation 3.9a repository but I saw that it was based on Integrated PlusTools.zip (Mantis #1915). So is it safe for me to conclude that I should integrate all the PlusTools changes before the fix of bert in MC?
Stef
http://source.impara.de/Stuff/Graphics-bf.24.mczyou'll get an Abort notice when loading Graphics-bf.24 in an unsafe image: (BitBlt canUnderstand: #displayString:from:to:at:kern:font:) ifFalse: [Abort new signal: 'need to load Graphics-ar. 21 first!']
This looks good. Can I rely on this behavior in the future? I don't know if what you say about packageinfo having scripts relates to or invalidates the above. I'd be perfectly happy with the above solution.
Well, the script is executed if you have that fixed Monticello version, or PackageInfo with script support. Republishing the package will retain the script only if you have the right PackageInfo.
Unless we decide to remove script support from MC this should continue to work.
- Bert -
Ok I got confused. With Cees 276 sorry not to read well. Stef
On 26 oct. 05, at 15:24, Bert Freudenberg wrote:
Hmm? Monticello-bf.277 is a direct child of your Monticello- stephaneducasse.276 version which *is* in 3.9a, only two methods related to scripts changed.
- Bert -
Am 26.10.2005 um 15:12 schrieb stéphane ducasse:
I wanted to push MC277 into the squeakfoundation 3.9a repository but I saw that it was based on Integrated PlusTools.zip (Mantis #1915). So is it safe for me to conclude that I should integrate all the PlusTools changes before the fix of bert in MC?
Stef
http://source.impara.de/Stuff/Graphics-bf.24.mczyou'll get an Abort notice when loading Graphics-bf.24 in an unsafe image: (BitBlt canUnderstand: #displayString:from:to:at:kern:font:) ifFalse: [Abort new signal: 'need to load Graphics-ar. 21 first!']
This looks good. Can I rely on this behavior in the future? I don't know if what you say about packageinfo having scripts relates to or invalidates the above. I'd be perfectly happy with the above solution.
Well, the script is executed if you have that fixed Monticello version, or PackageInfo with script support. Republishing the package will retain the script only if you have the right PackageInfo.
Unless we decide to remove script support from MC this should continue to work.
- Bert -
packages@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
Cees De Groot -
Colin Putney -
goran＠krampe.se -
stéphane ducasse