2010/1/9 Miguel Enrique Cob� Martinez
<miguel.coba@gmail.com>
El s�b, 09-01-2010 a las 21:00 +0100, Mariano Martinez Peck escribi�:
>
>
> 2010/1/9 Miguel Enrique Cob� Martinez <
miguel.coba@gmail.com>
> � � � � Hi Mariano,
>
> � � � � good job. Some feedback.
>
> � � � � The installScript has unused variables and your proxy settings
> � � � � exposed.
> � � � � Maybe this should be deleted from the final build.
>
>
> hahahahah I knew I was going to forget about that :(
> Thanks. Some bash guru that help me to automatize this? I would like
> something that automatically removes that from the file if it is
> found.
> Can you help me Miguel ?
for the gofer/metacello configuration. Then before zipping the files,
delete the proxy settings one. Also, don't the settings remain
configured in the image on the snapshot:andQuit message. If so, a
post-script to clear the parameter is needed too.
Thanks Miguel. I really appreciate this kind of feedback.
It is fixed now.
�
>
> � � � � Shouldn't be this a RC 2? because there is a new build process
> � � � � and has
> � � � � nothing to do with the RC1?
>
>
> I thought about putting it RC2, actually, I was going to do that. But
> as the PharoCore was named rc1, I din't want to name it rc2 because
> maybe it was confusing.
> I am not sure, thus. What do you think ?
I think that is good to have a RC2. Also this shows progress to the
public.
Ok, next release will be rc2.
�
>
> � � � � Also, the changes files, shouldn't be compressed for each RC
> � � � � and for the
> � � � � final release?
>
> Excellent point. Do you rather to Smalltalk >> condenseChanges ? �It
> can be perfectly added. Right now, we are doing all this:
I don't know the exact message to condense changes, but if it is that
then yes, should be added near the end of the other instructions.
>
>
> � � MCFileBasedRepository flushAllCaches.
> � � MCDefinition clearInstances.
> � � Smalltalk removeEmptyMessageCategories.
> � � Utilities cleanseOtherworldlySteppers.
> � � Undeclared removeUnreferencedKeys.
> � � Categorizer sortAllCategories.
> � � Symbol compactSymbolTable.
> � � Smalltalk at: #ReleaseBuilderDeveloper ifPresent: [:builder |
> builder new fixObsoleteReferences].
> � � RequiredSelectors initialize.
> � � ProvidedSelectors initialize.
> � � LocalSends initialize.
> � � Smalltalk organization removeEmptyCategories.
> � � SystemBrowser removeObsolete.
> � � TheWorldMenu removeObsolete.
> � � AppRegistry removeObsolete.
> � � Set rehashAllSets.
> � � Smalltalk cleanOutUndeclared.
> � � Smalltalk garbageCollect.
>
Respect to this list, and maybe this should be a ticket. Shouldn't be
better to have an established message to cleanup the image on release.
Something like the cleanUpForImageRelease but generalized and then, the
classes that need to do something like this, they implement that
message.
So on release a new image version you only call something like
Smalltalk cleanUpForImageRelease.
It is already in ScriptLoader >> cleanUpForRelease
I will try to look at the differences with ImageForDevelopers >> cleanUpMemory�� and see what can I do.
�
and inside it search all the classes that implements the message and
call them. So, your post-script becomes a single line and each package
is responsible of putting inside its own cleanUpForImageRelease whatever
needed to initialize itself.
But well, just an idea for subsequent releases.
>
> Do you think something else should be addded? � Maybe we can reuse
> ScriptLoader cleanings ?
Yes, and also the GarbageCollector parameters that John McIntosh is
preparing. This must be part of Pharo 1.0 without doubts.
I am now aware of this.
�
>
>
>
>
> � � � � Also, the packages.txt file talks about PharoCore1.0 (#10505).
> � � � � Has
> � � � � someone thought about the name shown in System->About:
>
> � � � � PharoCore1.0rc1
> � � � � Latest update: #10505
>
> � � � � Because this is not a PharoCore image. Shouldn't this read
> � � � � something
> � � � � like
>
> � � � � Pharo 1.0 Dev image.
> � � � � Based on PharoCore1.0rc1
> � � � � Latest update: #10505
>
>
> Yes, that's true. I agree. At least it was not "my falt" as it was
> already like that. But I am agree we should change that. However, I
> don't know how to do it.
> Maybe something related to SystemVersion? Any help ?
>
>
> � � � � What about the disabling of software updates in the Pharo
> � � � � dev/web
> � � � � images? Will this be implemented or a careful update stream
> � � � � will be made
> � � � � in order to not break a dev image with overrides (real
> � � � � difficult I
> � � � � think).
>
>
> Maybe. But in addition, sometimes there are bugs that updating just
> fix them. I am not sure if I want to disable. I rather warn people
> about it.
Pros
- Can fix bugs after release
- Can aply improvements to the image after release.
Cons
- Can mess the image of someone by overwriting some overridden method.
- Can accidentally update more than intended in someone's image
Should we vote?
yes, send a separate email with this to hear opinions.
�
> Do you know if we break some overrrides doing an update?
>
> � � � � Maybe all this setup can be put in a post-script in the
> � � � � ConfigurationOfPharo class.
>
> It is. We have pre and post do its. So, no problem :)
>
>
> � � � � That's all for now. I'm going to use this image to work the
> � � � � following
> � � � � days.
>
> � � � � Cheers and keep the good work.
> Thanks Miguel for the excellent feedback. Let's hope to build better
> images!
>
> Mariano
>
Cheers
--