bert at freudenbergs.de
Wed May 12 20:17:36 EDT 2010
Am 12.05.2010 um 17:03 schrieb karl ramberg:
> On Thu, May 13, 2010 at 1:17 AM, Bert Freudenberg <bert at freudenbergs.de> wrote:
> Am 12.05.2010 um 15:20 schrieb karl ramberg:
>> There are some Etoy classes left in Morphic-Scripting and Morphic-Scripting tiles
>> These should be in Etoy package, right ?
> Makes sense :)
> Your update worked, if only by accident. Moving stuff from one package to another is tricky. You can see that after updating, the Morphic package is marked dirty.
> It worked because in the config map, the Etoys package comes before the Morphic package. When loading your Etoys package, classes are moved to Etoys, making the Morphic package dirty. Merging the Morphic package next does not reset that dirty mark.
> It would have been worse when moving the other way - then the classes would have been removed first, and then re-loaded later. That would have created obsolete instances.
> If we ever need to, it is possible to put a "small" config map into the update stream that just updates the two packages in the right order.
> Not sure how to reset the "dirty" bit of the Morphic package. One can do it in the MC browser by pressing "changes". We might put something similar into the update stream. Or fix MC upgrades to check for changes after merging ... that might be a better idea.
> And here is a hint for everyone submitting MC packages: before publishing, *always* check the changes (press MC's changes button) so you are sure that only changes you want to publish are included.
> - Bert -
> I saw this mess and got a little confuced :-(
> Couldn't a preamble doit for classes moving between packages work like
> AlignmentMorph subclass: #ViewerRow
> instanceVariableNames: 'elementSymbol'
> classVariableNames: ''
> poolDictionaries: ''
> category: 'Etoys-Scripting Tiles' ?
> It would be a lot cleaner at least.
Wouldn't help - that is exactly what happens when you load the new etoys package. Actually it would make it worse, because both Etoys and Morphic would have been marked dirty :)
The only real clean way would be to specify that these two packages should be loaded together. There is no good way to do this for now.
I wouldn't worry about it though, it's not a big issue, we just have to be aware of it. Here is a do-it to clean the dirty flag for some packages:
repo := MCRepositoryGroup default repositories
detect: [:r | r description = MCMcmUpdater defaultUpdateURL].
#('Morphic') do: [:pkgName |
workingCopy := (MCPackage named: pkgName) workingCopy.
(workingCopy changesRelativeToRepository: repo)
ifNotNilDo: [:patch | workingCopy modified: patch isEmpty not]].
But the right way would be to check these differences right after upgrading a package. I might add this to MCConfig.
- Bert -
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
More information about the etoys-dev