July 2013 - Pharo-users - lists.pharo.org

[ann] a snappier snapshotcello

by Tudor Girba

Hi, A new version of Snapshotcello is now reachable from your Pharo 2.0 image. Besides snapshotting the current version, you now get the possibility of: - marking the new version as stable, - committing the configuration package, and - pushing the package to the official Pharo repository. Here is an example: Snapshotcello new configurationClass: ConfigurationOfSnapshotcello; sourceVersion: #development; targetVersion: '1.4-snapshot'; snapshot; makeStableFor: #'pharo2.x'; commit; pushToPharo20Repository A more detailed description can be found here: http://www.tudorgirba.com/blog/snappier-snapshotcello We can certainly improve this, and it would be great to have a similar mechanism integrated into Metacello. But, in the meantime, I find myself for the first time literally one do-it away from distributing projects that are developed without much constraints. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

July 30, 2013

Re: [Pharo-users] Little tutorial on customizing zero conf scripts

by StÃ©phane Ducasse

We could add this as part of the ZeroConf chapter :) But I guess that first the book should get out :) Stef > Hey guys! > > inspired by the work of Camillo and Andrei customizing the ZeroConf scripts for moose, I did the same for my phd project and wrote a little tiny shy tutorial about it. > > http://playingwithobjects.wordpress.com/2013/07/30/customizing-zeroconf-scr… > > Hope it's helpful for somebody :) > > Guille

July 30, 2013

Re: [Pharo-users] Git filetree workflow

by StÃ©phane Ducasse

We know that changing version can be painful but just consider that you are working with a nearly 3 years old system. stef On Jul 30, 2013, at 4:41 PM, joerick <joerick(a)mac.com> wrote: > Oh, I'm having trouble adding a gitfiletree repository, do you support Pharo > 1.4? > > > > -- > View this message in context: http://forum.world.st/Git-filetree-workflow-tp4701465p4701541.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

July 30, 2013

Re: [Pharo-users] Garbage collector & Memory Profiling

by Esteban Lorenzano

probably because the whole idea of having a GC is to forget/not having to think in when it is collected :) On Tue, Jul 30, 2013 at 10:27 PM, ClÃ©ment Bera <bera.clement(a)gmail.com>wrote: > There is the StrongPointerExplorer in the image that can help... > > But it is not easy to know when an object is GC. > > > 2013/7/30 Alejandro Infante <alejandroinfante91(a)gmail.com> > >> Hello, >> We are currently working on memory profiling and we are having troubles >> to detect when an object is garbage collected. >> >> Any ideas? >> >> Thanks for the help, >> Alejandro Infante >> > >

July 30, 2013

Re: [Pharo-users] Garbage collector & Memory Profiling

by ClÃ©ment Bera

There is the StrongPointerExplorer in the image that can help... But it is not easy to know when an object is GC. 2013/7/30 Alejandro Infante <alejandroinfante91(a)gmail.com> > Hello, > We are currently working on memory profiling and we are having troubles to > detect when an object is garbage collected. > > Any ideas? > > Thanks for the help, > Alejandro Infante >

July 30, 2013

Garbage collector & Memory Profiling

by Alejandro Infante

Hello, We are currently working on memory profiling and we are having troubles to detect when an object is garbage collected. Any ideas? Thanks for the help, Alejandro Infante

July 30, 2013

Re: [Pharo-users] Pharo performance

by Chris

It was 60000 doubles from the double precision[] type. Having had a very small look, it's possible that it isn't even supported and someone at our end has hacked the float converter to parse each one out, so I think it must be coming in as a string. > Hi Yanni, > > On 30 Jul 2013, at 05:17, Yanni Chiu <yanni(a)rogers.com> wrote: > >> On 29/07/13 7:08 PM, Sven Van Caekenberghe wrote: >>> The explanation for the slowdown must be in the PgV2 driver. >> The PgV2 protocol is described at: >> http://www.postgresql.org/docs/7.1/static/protocol-message-formats.html >> >> Have a glance at the "AsciiRow" and "BinaryRow" message formats. The driver reads the data off the socket, parsing the the data, as described as described by the message format. With the V2 protocol design, you have to read the result row, one field at a time. >> >> IIUC, in the newer V3? protocol, the AsciiRow/BinaryRow message is replaced by a DataRow message. The DataRow message has the message size included, which could allow the driver to read the entire set of fields for one data row, using a single socket read (or a few buffer sized reads). >> >> I recall seeing an experimental V3 protocol implementation, a few years back - sorry, no links handy. It would be nice to see some benchmarks. >> >> Hope that helps. > Thanks for the response. > > I believe the V3 project is here http://www.squeaksource.com/PostgresV3.html. > > Now, I probably spoke too fast and should have taken Mariano's advice to never speculate and first measure. Here is my quick test that, for me, shows that PostgresV2 seems more than fast enough (something that I had experienced before without doing benchmarks). > > [ self execute: 'select longitude,latitude from log_data limit 10000;' ] timeToRun. > > => 76 ms > > [ self execute: 'select longitude,latitude from log_data limit 100000;' ] timeToRun. > > => 765 ms > > This is querying for 2 floats from a huge table, over the network. Pretty fast ;-) > > So, back to Chris: what exactly are you doing that is (so) slow ? > > Anyway, thanks Yanni for all your work on the existing driver ! > > Sven > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > > > > > >

July 30, 2013

Re: [Pharo-users] Pharo performance

by Esteban A. Maringolo

2013/7/30 Igor Stasenko <siguctua(a)gmail.com>: >> [ self execute: 'select longitude,latitude from log_data limit 10000;' ] timeToRun. >> >> => 76 ms >> > 76 ms for 10000 records? > that's quite good throughput i would say. That will depend on the cursor type being used for the query. If it's just opening the cursor is one thing, but if you have to fetch all the data through the network it is a different story. 76ms to 10K rows is fast for a static cursor or for a forward only cursor + data fetch. Regards!

July 30, 2013

Re: [Pharo-users] Pharo performance

by Igor Stasenko

On 30 July 2013 10:42, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Yanni, > > On 30 Jul 2013, at 05:17, Yanni Chiu <yanni(a)rogers.com> wrote: > >> On 29/07/13 7:08 PM, Sven Van Caekenberghe wrote: >>> >>> The explanation for the slowdown must be in the PgV2 driver. >> >> The PgV2 protocol is described at: >> http://www.postgresql.org/docs/7.1/static/protocol-message-formats.html >> >> Have a glance at the "AsciiRow" and "BinaryRow" message formats. The driver reads the data off the socket, parsing the the data, as described as described by the message format. With the V2 protocol design, you have to read the result row, one field at a time. >> >> IIUC, in the newer V3? protocol, the AsciiRow/BinaryRow message is replaced by a DataRow message. The DataRow message has the message size included, which could allow the driver to read the entire set of fields for one data row, using a single socket read (or a few buffer sized reads). >> >> I recall seeing an experimental V3 protocol implementation, a few years back - sorry, no links handy. It would be nice to see some benchmarks. >> >> Hope that helps. > > Thanks for the response. > > I believe the V3 project is here http://www.squeaksource.com/PostgresV3.html. > > Now, I probably spoke too fast and should have taken Mariano's advice to never speculate and first measure. Here is my quick test that, for me, shows that PostgresV2 seems more than fast enough (something that I had experienced before without doing benchmarks). > > [ self execute: 'select longitude,latitude from log_data limit 10000;' ] timeToRun. > > => 76 ms > 76 ms for 10000 records? that's quite good throughput i would say. > [ self execute: 'select longitude,latitude from log_data limit 100000;' ] timeToRun. > > => 765 ms > > This is querying for 2 floats from a huge table, over the network. Pretty fast ;-) > > So, back to Chris: what exactly are you doing that is (so) slow ? > > Anyway, thanks Yanni for all your work on the existing driver ! > > Sven > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > > > > > -- Best regards, Igor Stasenko.

July 30, 2013

Re: [Pharo-users] Git filetree workflow

by Goubier Thierry

Sorry no, only 2.0. I wonder if, however, it could work... What are the errors you're getting? Thierry Le 30/07/2013 16:41, joerick a Ã©crit : > Oh, I'm having trouble adding a gitfiletree repository, do you support Pharo > 1.4? > > > > -- > View this message in context: http://forum.world.st/Git-filetree-workflow-tp4701465p4701541.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > -- 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

July 30, 2013