Hi
I pushed two items in the update stream. - the first one load some modified version of MC (including the cacheFlushing) - the second one will load the script loader and load the latest scripts. marcus and adrian told me that this is working on their machines (= no conflict after loading).
I need some people to let me know if the following work: - take 6693 http://ftp.squeak.org/3.9/Squeak3.9a-6693.zip. - do an update. - report the size of the image/changes and mention if there are conflicts after the load
Thanks
Stef
stéphane ducasse puso en su mail :
Hi
I pushed two items in the update stream. - the first one load some modified version of MC (including the cacheFlushing) - the second one will load the script loader and load the latest scripts. marcus and adrian told me that this is working on their machines (= no conflict after loading).
I need some people to let me know if the following work: - take 6693 http://ftp.squeak.org/3.9/Squeak3.9a-6693.zip. - do an update. - report the size of the image/changes and mention if there are conflicts after the load
Thanks
Stef
Stef: At this time you should know what I love testing.
I follow directives of
1)fresh download 2) tryng to do updates 3) when ready I report
OT I do same similar to your troubles and someone give me the advice to how DO NOT have the "monster size" image.
Edgar
___________________________________________________________ 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo http://correo.yahoo.com.ar
Report;
On mac 10.2.4 with Squeak 3.8.6Beta5 Vm. Fresh download 13.7 mb. Loading updates from European Mirror O updates Loading from the other inform me could tak 30 minutes so be patient, just started
___________________________________________________________ 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo http://correo.yahoo.com.ar
Ok, testing now. I was already testing the manual method with your changesets, but as Squeak doesn't eat more than half of a HT CPU I figured I might just as well fire this one up in parallel :)
Will report as soon as it's done - either one.
On 10/23/05, stéphane ducasse ducasse@iam.unibe.ch wrote:
Hi
I pushed two items in the update stream. - the first one load some modified version of MC (including the cacheFlushing) - the second one will load the script loader and load the latest scripts. marcus and adrian told me that this is working on their machines (= no conflict after loading).
I need some people to let me know if the following work: - take 6693 http://ftp.squeak.org/3.9/Squeak3.9a-6693.zip. - do an update. - report the size of the image/changes and mention if there are conflicts after the load
Thanks
Stef
Load works fine. BalloonMMFlash, EToys, FLexibleVocabularis and MorphicExtras are dirty after load, but neither package has any actual changes.
Flush reclaims 14 Meg, brings back the image to 14 Meg.
Apart from the MC things (which we do need to sort out), looks all dandy to me :)
On 10/23/05, Cees De Groot cdegroot@gmail.com wrote:
Ok, testing now. I was already testing the manual method with your changesets, but as Squeak doesn't eat more than half of a HT CPU I figured I might just as well fire this one up in parallel :)
Will report as soon as it's done - either one.
On 10/23/05, stéphane ducasse ducasse@iam.unibe.ch wrote:
Hi
I pushed two items in the update stream. - the first one load some modified version of MC (including the cacheFlushing) - the second one will load the script loader and load the latest scripts. marcus and adrian told me that this is working on their machines (= no conflict after loading).
I need some people to let me know if the following work: - take 6693 http://ftp.squeak.org/3.9/Squeak3.9a-6693.zip. - do an update. - report the size of the image/changes and mention if there are conflicts after the load
Thanks
Stef
On 23 oct. 05, at 15:10, Cees De Groot wrote:
Load works fine. BalloonMMFlash, EToys, FLexibleVocabularis and MorphicExtras are dirty after load, but neither package has any actual changes.
Flush reclaims 14 Meg, brings back the image to 14 Meg.
Apart from the MC things (which we do need to sort out), looks all dandy to me :)
Me too. This means that we will be able to go much faster for harvesting and integrating (we were a bit stalled because I was trying on my machine and tried tried tried.....).
This is amazing that I do the **same** and get conflicts. On my other mac machine (in the lab) it works arghhhhh. Tuesday I do a controlled experiment.
Stef
Hi
I also retried and (again) succeeded without conflicts and with normal image size:
- Took approximately 30 minutes, VM: mac 3.7.4beta1 - Directly after loading the updates and without saving the image (thus without GC) vmStatisticsReportString said: uptime 0h31m25s memory 51,736,520 bytes old 46,269,076 bytes (89.4%) young 696,048 bytes (1.3%) used 46,965,124 bytes (90.8%) free 4,771,396 bytes (9.2%) GCs 35,525 (53ms between GCs) full 50 totalling 31,110ms (2.0% uptime), avg 622.0ms incr 35475 totalling 295,400ms (16.0% uptime), avg 8.0ms tenures 679 (avg 52 GCs/tenure)
- saved, .image filesize: 18.5MB - evaluated MCFileBasedRepository flushAllCaches and saved image again. filesize: 14.2MB
It looks like the MC cache flushing is not yet done after loading the two scripts. Apart from that and from the issue that a couple of working copies are dirty, everything seems to have worked fine.
Adrian
On Oct 23, 2005, at 1:30 PM, stéphane ducasse wrote:
Hi
I pushed two items in the update stream. - the first one load some modified version of MC (including the cacheFlushing) - the second one will load the script loader and load the latest scripts. marcus and adrian told me that this is working on their machines (= no conflict after loading).
I need some people to let me know if the following work: - take 6693 http://ftp.squeak.org/3.9/Squeak3.9a-6693.zip. - do an update. - report the size of the image/changes and mention if there are conflicts after the load
Thanks
Stef
On Oct 23, 2005, at 7:30 AM, stéphane ducasse wrote:
I pushed two items in the update stream. - the first one load some modified version of MC (including the cacheFlushing) - the second one will load the script loader and load the latest scripts. marcus and adrian told me that this is working on their machines (= no conflict after loading).
I need some people to let me know if the following work: - take 6693 http://ftp.squeak.org/3.9/Squeak3.9a-6693.zip. - do an update. - report the size of the image/changes and mention if there are conflicts after the load
I wasn't able to load the second update. I got a walkback while MC was attempting to fetch the timestamp of SMMcInstaller>>installMcz. Apparently the filestream for the changes file answered nil to #basicNext while CompiledMethod>>getPreambleFrom:at: was reading backward from the source pointer. Didn't investigate further.
Colin
I need some people to let me know if the following work: - take 6693 http://ftp.squeak.org/3.9/Squeak3.9a-6693.zip. - do an update. - report the size of the image/changes and mention if there are conflicts after the load
It took about two hours to run: #################### -rw-r--r-- 1 atg users 13182565 Oct 23 15:22 Squeak3.9a-6693.changes -rw-r--r-- 1 atg users 30387072 Oct 23 15:23 Squeak3.9a-6693.image #####################
Great Stef!
Aside from taking over 2 hours on a 56 k modem, everything looks ok.
Image size 14.5 Mb. Changes size 12.5 Mb.
Thanks,
Juan Vuletich
----- Original Message ----- From: "stéphane ducasse" ducasse@iam.unibe.ch To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Sunday, October 23, 2005 8:30 AM Subject: [ANN] Need testers for 3.9a
Hi
I pushed two items in the update stream. - the first one load some modified version of MC (including the cacheFlushing) - the second one will load the script loader and load the latest scripts. marcus and adrian told me that this is working on their machines (= no conflict after loading).
I need some people to let me know if the following work: - take 6693 http://ftp.squeak.org/3.9/Squeak3.9a-6693.zip. - do an update. - report the size of the image/changes and mention if there are conflicts after the load
Thanks
Stef
-- Internal Virus Database is out-of-date. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.10.16/83 - Release Date: 8/26/2005
Hi,
After a 45 Min update:
image: 27,8 MB changes: 12,5 MB
No conflicts.
The only other change I made was setting it to fullscreen & 32bit depth.
-karsten
Filed this on Mantis but ...
Update ran fine, but right click on world gives a Project DNU #supressFlapsString after completion.
Eddie
stéphane ducasse wrote:
Hi
I pushed two items in the update stream. - the first one load some modified version of MC (including the cacheFlushing) - the second one will load the script loader and load the latest scripts. marcus and adrian told me that this is working on their machines (= no conflict after loading).
I need some people to let me know if the following work: - take 6693 http://ftp.squeak.org/3.9/Squeak3.9a-6693.zip. - do an update. - report the size of the image/changes and mention if there are conflicts after the load
Thanks
Stef
Am 23.10.2005 um 13:30 schrieb stéphane ducasse:
Hi
I pushed two items in the update stream. - the first one load some modified version of MC (including the cacheFlushing) - the second one will load the script loader and load the latest scripts. marcus and adrian told me that this is working on their machines (= no conflict after loading).
I need some people to let me know if the following work: - take 6693 http://ftp.squeak.org/3.9/Squeak3.9a-6693.zip. - do an update. - report the size of the image/changes and mention if there are conflicts after the load
In update 6694, why didn't you use a configuration to upgrade Monticello? The explicit load in there destroys any MC version one might have loaded in the image (even if it is newer than 267). This would have done the same:
(MCConfiguration fromArray: #( repository ('http://source.squeakfoundation.org/39a') dependency ('Monticello' 'Monticello-stephaneducasse.276' 'd0330fd9-e2b4-403d-815b-cb03db7a7256') )) upgrade
In update 6695, the "script loading" logic takes really long. I had a message tally running, the actual time spent in loading new method definitions is less than 5 percent. Of the 5600 sec total it spent 1000 sec in GC (100 full, 100,000 incr.), and 2200 sec in loadVersionFromFileNamed: (of which 800 s are spent in MCCacheRepository>>storeVersion:). It uses #loadVersionFromFileNamed: on a new repository instance every time, this circumvents any caching.
I think a better approach would be to use the loadTogether strategy (which works around all optimizations done by MCConfigurations) only when necessary, that is, in this case only for the two packages that implement and send the #isRectangle method. For the rest, a config map should be a lot more efficient.
I've attached the message tally.
This code creates a config map from a collection of version file names such as in ScriptLoader:
configurationFrom: aCollection | spec | spec := Array streamContents: [:s | s nextPut: #repository; nextPut: {self repository description}. aCollection do: [:ea | | pkg ver id | pkg := ea copyUpToLast: $- . ver := ea copyUpToLast: $. . id := UUID nilUUID asString. s nextPut: #dependency; nextPut: {pkg . ver . id}]]. ^MCConfiguration fromArray: spec.
this could be used, e.g., in
ScriptLoader>>loadOneAfterTheOther: aCollection merge: aBoolean ^(self configurationFrom: aCollection) upgrade
- Bert - 
In update 6694, why didn't you use a configuration to upgrade Monticello? The explicit load in there destroys any MC version one might have loaded in the image (even if it is newer than 267). This would have done the same:
(MCConfiguration fromArray: #( repository ('http://source.squeakfoundation.org/39a') dependency ('Monticello' 'Monticello-stephaneducasse.276' 'd0330fd9-e2b4-403d-815b-cb03db7a7256') )) upgrade
Because we could not understand how to use it and how to save a script.
In update 6695, the "script loading" logic takes really long. I had a message tally running, the actual time spent in loading new method definitions is less than 5 percent. Of the 5600 sec total it spent 1000 sec in GC (100 full, 100,000 incr.), and 2200 sec in loadVersionFromFileNamed: (of which 800 s are spent in MCCacheRepository>>storeVersion:). It uses #loadVersionFromFileNamed: on a new repository instance every time, this circumvents any caching.
I think a better approach would be to use the loadTogether strategy (which works around all optimizations done by MCConfigurations) only when necessary, that is, in this case only for the two packages that implement and send the #isRectangle method. For the rest, a config map should be a lot more efficient.
We will try to see. For us MC is a bit a black box and we do not have time to open it.
I've attached the message tally.
Ok thanks for the feedback. I did not look at any optimization. Just took what adrian wrote and use it. I was so happy that it would run. But now I have to reinstall my machine or find why I cannot check it myself.
This code creates a config map from a collection of version file names such as in ScriptLoader:
configurationFrom: aCollection | spec | spec := Array streamContents: [:s | s nextPut: #repository; nextPut: {self repository description}. aCollection do: [:ea | | pkg ver id | pkg := ea copyUpToLast: $- . ver := ea copyUpToLast: $. . id := UUID nilUUID asString. s nextPut: #dependency; nextPut: {pkg . ver . id}]]. ^MCConfiguration fromArray: spec.
this could be used, e.g., in
ScriptLoader>>loadOneAfterTheOther: aCollection merge: aBoolean ^(self configurationFrom: aCollection) upgrade
- Bert -
<SpyResults.txt>
squeak-dev@lists.squeakfoundation.org
-
Adrian Lienhard -
Alan Grimes -
Bert Freudenberg -
Cees De Groot -
Colin Putney -
Damien Cassou -
Eddie Cottongim -
Juan Vuletich -
Karsten Wolf -
Lic. Edgar J. De Cleene -
stéphane ducasse