April 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Bug while updating PharoCore

by Marcus Denker

fixed. (by uploading the missing versions to squeaksource) On Apr 27, 2011, at 8:46 PM, Marcus Denker wrote: > > I added a tracker entry: > > http://code.google.com/p/pharo/issues/detail?id=4104 > > I will see how to fix that. > > On Apr 27, 2011, at 5:59 PM, Casimiro de Almeida Barreto wrote: > >> While loading 13171-Pha-CleanupsFinderSearch debugger is raised with >> Message not understood: Receiver of "load" is nil >> >> and: >> >> DoIt >> | t1 | >> t1 := MCHttpRepository >> location: 'http://www.squeaksource.com/Pharo/' >> user: '' >> password: ''. >> (t1 loadVersionFromFileNamed: 'ScriptLoader13-MarcusDenker.191.mcz') >> load. >> ^ ScriptLoader new update13171 >> >> Meaning ScriptLoader13-MarcusKender.191.mcz is not there or squeaksource >> is down... >> > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 28, 2011

Re: [Pharo-project] [ANN] PharoDev-1.3-13173

by Mariano Martinez Peck

On Thu, Apr 28, 2011 at 5:56 AM, Serge Stinckwich < serge.stinckwich(a)gmail.com> wrote: > On Wed, Apr 27, 2011 at 3:21 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: > > Hi. IMPORTANT: This is not the final 1.3 release, it just one simple > > snapshot and one point. We all want a rock-solid Pharo 1.3 release, but > that > > doesn't happens automagically. We all need to start using and testing the > > image before they are release. It is for the better of all of us. The > more > > we test the more stable will be the release. So...we need your help. What > > you can do? > > > > 1) test test test test test. Use it. Take this image and use it for your > > regular work. > > 2) report bugs: http://www.pharo-project.org/community/issue-tracking > > 3) propose fixes: http://code.google.com/p/pharo/wiki/HowToContribute > > 4) Fix errors/failures tests > > 5) Load your OWN packages and projects now. Don't wait until Pharo1.3 is > > released and then ask "uuhh what happened to XXX? you removed? ohhh but I > > use it". > > 6) Do you maintain Metacello configurations? ok, if you test your > project > > and works correctly in Pharo 1.3, please update (or create if you don't > yet > > have it) the #stable, > > 7) Do you maintain packages included in Pharo? please check we are using > > the correct versions > > 8) I would like to see people testing AidaWeb, Magma, Fuel, Moose, > DBXTalk, > > Seaside and all its friends, Zinc, FileSystem, etc, etc, etc. > > > > Pharo-1.3-13173 should work with Interpreter VM and with Cog. For Cog I > > recommend to download the last one from Eliot's page: > > http://www.mirandabanda.org/files/Cog/VM/ > > I try with VM Squeak 4.2.5beta1U on mac os x 10.6.7 but the image is > not launch at all. > No problem to launch the image with last cog VM. > > grrrr sorry my bad. I opeed the image (with cog) to re-save it with another name. If you take the one from hudson (same image) it should work: https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%201.3/111/ > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > > -- Mariano http://marianopeck.wordpress.com

April 28, 2011

Re: [Pharo-project] Preallocation behavior

by Andres Valloud

As a side comment, I do not know if an atAllPut: method I wrote back in about 2000 or so is still in the image... but if it is not, keep in mind that you can use something like replaceFrom:to:with:startingAt: using the receiver as the source of data, duplicating the amount of data copied each time. Back then, if you had to write the same object more than 26 or so times, it was faster to use the duplicating "block copy" method. The key is to avoid multiple primitive calls (which have expensive overhead compared to what is actually done), and replace them with a single primitive call that does a bunch of writes. With the duplication method, you could get away with doing 9000 writes in no more than 15 primitive calls. I wrote about this in much more detail in the Fundamentals volume 2 book. On 4/27/11 23:35 , jannik.laval wrote: > Hi all, > > I am playing with MessageTally, and I have a strange result with > prealocation. > Here is my example. I am working on a PharoCore1.3, with a VM4.2.5 > > First of all, I spy this source code: > ==== > MessageTally spyOn: > [ 500 timesRepeat: [ > | str | > *str := ''*. > 9000 timesRepeat: [ str := str, 'A' ]]]. > ==== > > The result appears after *24 961 ms*. > An optimization is to use a Stream. Here is my source code: > === > MessageTally spyOn: > [ 500 timesRepeat: [ > | str | > *str := WriteStream on: (String new)*. > 9000 timesRepeat: [ str nextPut: $A ]]]. > === > > The result appears after *812 ms*, which is a large improvement. > Now, we could optimize again using the preallocation. Here is my source > code: > > ==== > MessageTally spyOn: > [ 500 timesRepeat: [ > | str | > *str := WriteStream on: (String new: 10000)*. > 9000 timesRepeat: [ str nextPutAll: 'A' ]]]. > ==== > > And the result is strange: it makes 2 times slower to display the result. > The result appears after 1656 ms. > > Here is the spy result: > === > - 1656 tallies, 1656 msec. > > **Tree** > -------------------------------- > Process: (40s) 464519168: nil > -------------------------------- > > **Leaves** > *22.9% {380ms} UndefinedObject>>DoIt* > 22.5% {373ms} SmallInteger(Integer)>>timesRepeat: > 22.2% {368ms} WriteStream>>nextPutAll: > === > > There is the call of UndefinedObject>>DoIt which is added and takes time. > Does anyone know what is done during the preallocation ? > Why is it slower than non-preallocation ? > > Thanks for your answers. > Jannik

April 28, 2011

Re: [Pharo-project] Preallocation behavior

by Andres Valloud

Maybe in the last case you also need to send nextPut: instead of nextPutAll:... On 4/27/11 23:35 , jannik.laval wrote: > Hi all, > > I am playing with MessageTally, and I have a strange result with > prealocation. > Here is my example. I am working on a PharoCore1.3, with a VM4.2.5 > > First of all, I spy this source code: > ==== > MessageTally spyOn: > [ 500 timesRepeat: [ > | str | > *str := ''*. > 9000 timesRepeat: [ str := str, 'A' ]]]. > ==== > > The result appears after *24 961 ms*. > An optimization is to use a Stream. Here is my source code: > === > MessageTally spyOn: > [ 500 timesRepeat: [ > | str | > *str := WriteStream on: (String new)*. > 9000 timesRepeat: [ str nextPut: $A ]]]. > === > > The result appears after *812 ms*, which is a large improvement. > Now, we could optimize again using the preallocation. Here is my source > code: > > ==== > MessageTally spyOn: > [ 500 timesRepeat: [ > | str | > *str := WriteStream on: (String new: 10000)*. > 9000 timesRepeat: [ str nextPutAll: 'A' ]]]. > ==== > > And the result is strange: it makes 2 times slower to display the result. > The result appears after 1656 ms. > > Here is the spy result: > === > - 1656 tallies, 1656 msec. > > **Tree** > -------------------------------- > Process: (40s) 464519168: nil > -------------------------------- > > **Leaves** > *22.9% {380ms} UndefinedObject>>DoIt* > 22.5% {373ms} SmallInteger(Integer)>>timesRepeat: > 22.2% {368ms} WriteStream>>nextPutAll: > === > > There is the call of UndefinedObject>>DoIt which is added and takes time. > Does anyone know what is done during the preallocation ? > Why is it slower than non-preallocation ? > > Thanks for your answers. > Jannik

April 28, 2011

Re: [Pharo-project] [ANN] PharoDev-1.3-13173

by StÃ©phane Ducasse

>> >> >> -> some small migration guide would be nice, maybe even a Lint rule that >> checks for removed globals ;-) >> > > Yes.. now I have no time to do this. Who wants? We will start with andre to work on SmallLint rules and learn how it works. Stef

April 28, 2011

Re: [Pharo-project] [ANN] PharoDev-1.3-13173

by StÃ©phane Ducasse

But Zinc will be soon part of core. Probably even later today :) On Apr 27, 2011, at 6:41 PM, Sven Van Caekenberghe wrote: > > On 27 Apr 2011, at 18:27, Philippe Marschall wrote: > >> - ZnServer class >> #initialize references AutoStart > > Zn is not a standard part of this image, so it must have come with Seaside ? > If so, that would be cool, that is something that I want ! > > Anyway, > > ZnServer class>>initialize > Smalltalk addToStartUpList: self after: AutoStart. > Smalltalk addToShutDownList: self > > Indeed AutoStart seems to be gone. > I just picked that code up somewhere, what should it have to be then ? > > Apart from that loading error, all Zn tests are green. > > Thx, > > Sven > >

April 28, 2011

[Pharo-project] Preallocation behavior

by jannik.laval

Hi all, I am playing with MessageTally, and I have a strange result with prealocation. Here is my example. I am working on a PharoCore1.3, with a VM4.2.5 First of all, I spy this source code: ==== MessageTally spyOn: [ 500 timesRepeat: [ | str | str := ''. 9000 timesRepeat: [ str := str, 'A' ]]]. ==== The result appears after 24 961 ms. An optimization is to use a Stream. Here is my source code: === MessageTally spyOn: [ 500 timesRepeat: [ | str | str := WriteStream on: (String new). 9000 timesRepeat: [ str nextPut: $A ]]]. === The result appears after 812 ms, which is a large improvement. Now, we could optimize again using the preallocation. Here is my source code: ==== MessageTally spyOn: [ 500 timesRepeat: [ | str | str := WriteStream on: (String new: 10000). 9000 timesRepeat: [ str nextPutAll: 'A' ]]]. ==== And the result is strange: it makes 2 times slower to display the result. The result appears after 1656 ms. Here is the spy result: === - 1656 tallies, 1656 msec. **Tree** -------------------------------- Process: (40s) 464519168: nil -------------------------------- **Leaves** 22.9% {380ms} UndefinedObject>>DoIt 22.5% {373ms} SmallInteger(Integer)>>timesRepeat: 22.2% {368ms} WriteStream>>nextPutAll: === There is the call of UndefinedObject>>DoIt which is added and takes time. Does anyone know what is done during the preallocation ? Why is it slower than non-preallocation ? Thanks for your answers. Jannik

April 28, 2011

Re: [Pharo-project] squeaksource is down - a different perspective

by StÃ©phane Ducasse

I was thinking about migration from SS to SS3 On Apr 27, 2011, at 10:16 PM, Dale Henrichs wrote: > Since you mention GemStone:) > > We have customers who have migrated repositories created 10+ years ago with our 32 bit product to the latest current version of our 64 bit product. > > We have changed our Smalltalk class-library over the years and customers have had to upgrade their own class libraries if they chose to continue taking advantage of our newer releases ... then there are some who have chosen not to migrate: I think there are still production applications running GemStone on a version 20 years old:) ... as long as their hardware holds out they are fine:) > > Production customers don't tend to move very fast in upgrading their hardware and software so we end up supporting older versions of oSes for quite awhile...But when the os vendor announces and end of life of an os, it becomes difficult for us to continue to support that version... > > For the older versions we backport critical bugfixes to the older versions as long as their are active customers (read paying maintenance dollars) using the older versions. > > Dale > > > On 04/27/2011 10:23 AM, StÃ©phane Ducasse wrote: >> >>>> squeaksource.com is down a lot. People get frustrated at times. >>> >>> Yes, and unfortunately it looks like people love to be frustrated. >>> >>> Otherwise people would give Tobias more feedback on SqueakSource3 (see [1]) which IMHO could overtake the job in the future and replace the >>> problematic image? >> >> I do not know. >> Do SS3 has a migration process? >> How easy is it to install on an old machine? >> Does gemstone run on a old mac g3? >> Should we install glass? >> I do not know. >> >> You see nothing looks simple when we want to do it. >> >>> Or is the outage a traffic problem and may >>> happen with SS3 too? >>> >>> Is the (daily?) restart the only option we have or is a migration >>> to a newer SS version possible? >> >> No idea. >> Do you know? >> >>> And yes - SmalltalkHub is on the way, but we still dont know >>> how well it fits our needs/works/scales. Yes, this sounds negative but >>> I think it can replace Squeaksource only in a long term... >> >> we will see and learn. >> >>> Bye >>> T. >>> >>> >>> [1] http://lists.gforge.inria.fr/pipermail/pharo-project/2011-April/047780.html >>> -- >>> NEU: FreePhone - kostenlos mobil telefonieren und surfen! >>> Jetzt informieren: http://www.gmx.net/de/go/freephone >>> >> >> >

April 28, 2011

Re: [Pharo-project] [ANN] PharoDev-1.3-13173

by Serge Stinckwich

On Wed, Apr 27, 2011 at 3:21 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi. IMPORTANT: This is not the final 1.3 release, it just one simple > snapshot and one point. We all want a rock-solid Pharo 1.3 release, but that > doesn't happens automagically. We all need to start using and testing the > image before they are release. It is for the better of all of us. The more > we test the more stable will be the release. So...we need your help. What > you can do? > > 1) test test test test test. Use it. Take this image and use it for your > regular work. > 2) report bugs: http://www.pharo-project.org/community/issue-tracking > 3) propose fixes: http://code.google.com/p/pharo/wiki/HowToContribute > 4) Fix errors/failures tests > 5) Load your OWN packages and projects now. Don't wait until Pharo1.3 is > released and then ask "uuhh what happened to XXX? you removed? ohhh but I > use it". > 6) Do you maintain Metacello configurations?Â ok, if you test your project > and works correctly in Pharo 1.3, please update (or create if you don't yet > have it) the #stable, > 7) Do you maintain packages included in Pharo?Â please check we are using > the correct versions > 8) I would like to see people testing AidaWeb, Magma, Fuel, Moose, DBXTalk, > Seaside and all its friends, Zinc, FileSystem, etc, etc, etc. > > Pharo-1.3-13173Â should work with Interpreter VM and with Cog. For Cog I > recommend to download the last one from Eliot's page: > http://www.mirandabanda.org/files/Cog/VM/ I try with VM Squeak 4.2.5beta1U on mac os x 10.6.7 but the image is not launch at all. No problem to launch the image with last cog VM. -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

April 28, 2011

Re: [Pharo-project] GitFs / MCGit

by Serge Stinckwich

On Thu, Apr 28, 2011 at 3:37 AM, Stefan Marr <pharo(a)stefan-marr.de> wrote: > Hi Camillo: > > > On 27 Apr 2011, at 22:09, Camillo Bruni wrote: > >> Lukas once implemented a small MC Repository type that simple stores the source.st in a git repository. Due to changes in the recent pharo versions some of the git code didn't work anymore. So that's fixed now and you can use git for storing monticello versions. >> >> The following uses a local git repos as a monticello repository: >> >> Â Â Â MCGitRepository directory: 'test_git' Maybe you should document how do that. Some people might be interested in order to mitigate the problems related to SqueakSource unstabilities. > What are the dependencies for that? Would it be likely that it works with a Squeak 3.8/3.9ish image? > >> Of course it is not fully useful since it uses a single file to store everything, rendering normal git tools unusable. Hence I will experiment tomorrow a bit on how to split up methods and classes into something more representable. I guess the trickiest part will be to tell git how methods and classes changed when they are renamed, but even that should not be such a problem.. > If you can handle EPL licensed code, I could make our Transporter scripts available. > It is a bit more than just a file out that uses one file per class, and a folder per package. > Beyond that, we also have some support for ordering, since often we have dependencies that need to be load first, etc, as well as pre/post scripts. > > Unfortunately, it is EPL licensed and not MIT. So, let me know whether that would be useful/acceptable for you. Eclipse Public Licence (EPL) is a bit strange for Smalltalk code :-) but there is no problem if the code is not integrated in Pharo. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

April 28, 2011