Le 02/04/2014 16:33, phil@highoctane.be a écrit :

On Wed, Apr 2, 2014 at 4:06 PM, Goubier Thierry <thierry.goubier@cea.fr <mailto:thierry.goubier@cea.fr>> wrote:

Le 02/04/2014 15:59, Sebastian Sastre a écrit :

Advice:

Never save a “big" package using monticello (lets say ~2000 classes)

and then save the image

Why?

Because while you don’t have feedback of saving progress* it will be doing something on background (forked save?) and if for any reason you are tempted to do an image save or save and quit, it will save in a state that will prevent the image from opening again

You have no option but to go to your previous image version or something of the kind

:(

*saving a package actually provides /some/ feedback on progress but when the progress bar finishes, the saving doesn’t actually finish and it still have something going on, so you get "silence” (no-feedback) until you get the little monticello window with your new package version

Does this mean that once we get the little window, we are safe? I am saving a package with containing a lot of Pack-XXX Pack-YYY Pack-ZZZ in a 2.0 image as a single Pack-PhilippeBack-nn.mcz thing.

What is the moves to make to be safe?

I already got my image locked at some points in a way that resembles what you describe.

I'm looking at the code and I don't understand everything, but, yes, it seems there are a few ways to keep doing things while saving the package (and maybe locking up things). MCWorkingCopyBrowser>>basicSaveVersionIn: basicSaveVersionIn: aRepository | newVersion waitForVersion | waitForVersion := Semaphore new. UIManager default defer: [ newVersion := workingCopy newVersionIn: aRepository. waitForVersion signal ]. Processor activeProcess == UIManager default uiProcess ifFalse: [ waitForVersion wait ]. newVersion ifNil: [ ^ self ]. Cursor wait showWhile: [[ self storeVersion: newVersion in: aRepository; storeDependencies: newVersion in: aRepository.] ensure: [ (MCVersionInspector new version: newVersion) show ]] It seems asynchronous, but I'm unsure of what it is doing. Progress bar is only displayed when doing newVersionIn:, but this is sent to the UIManager. And this is done in a fork (see saveVersion), so it's probably allways possible to interrupt the thing half-way (or save). Anybody to explain what is the objective when writing code like that? Thierry

Phil

I'll profile that to see what's happening.

Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 <tel:%2B33%20%280%29%201%2069%2008%2032%2092> / 83 95

-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Could it be that one of the processes called from this code is specifically setting the cursor back to normal? That would defeat the whole Cursor wait showWhile: process. Progress bars or other non-shared state do seem safer to utilize for core activities like this. -cbc On Thu, Apr 3, 2014 at 12:18 PM, Sebastian Sastre < sebastian@flowingconcept.com> wrote:

On Apr 2, 2014, at 12:10 PM, Goubier Thierry <thierry.goubier@cea.fr> wrote:

MCWorkingCopyBrowser>>basicSaveVersionIn: basicSaveVersionIn: aRepository | newVersion waitForVersion | waitForVersion := Semaphore new.

UIManager default defer: [ newVersion := workingCopy newVersionIn: aRepository. waitForVersion signal ].

Processor activeProcess == UIManager default uiProcess ifFalse: [ waitForVersion wait ]. newVersion ifNil: [ ^ self ].

Cursor wait showWhile: [[ self storeVersion: newVersion in: aRepository; storeDependencies: newVersion in: aRepository.] ensure: [ (MCVersionInspector new version: newVersion) show ]]

It seems asynchronous, but I'm unsure of what it is doing. Progress bar is only displayed when doing newVersionIn:, but this is sent to the UIManager. And this is done in a fork (see saveVersion), so it's probably allways possible to interrupt the thing half-way (or save).

Anybody to explain what is the objective when writing code like that?

Good question Thierry.

I'm sure the cursor was normal during this episode. Suggesting that either it wasn't storing the version or it was but not displaying the wait cursor as the code suggests.

Functionally, what sounds to me it should be doing, is overwriting the files which is reasonable to take a little. It takes reasonable time, that's not the problem. Lack of feedback is the problem.

So one solution would be to provide a progress bar for that file writing process or whatever is doing.

Having one progress bar for the whole process would be the best solution. Plan B would be having 2 progress bars, ending when it really finishes. BTW, note that *not* giving control to the user while is saving would also prevent this kind of accidents.