- Pharo-users - lists.pharo.org

Re: [Pharo-users] Storing test data in methods

by Norbert Hartl

Am 01.08.2013 um 15:33 schrieb Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > On Jul 23, 2013, at 5:33 , Norbert Hartl <norbert(a)hartl.name> wrote: > >> Max, >> >> Am 23.07.2013 um 17:27 schrieb Max Leske <maxleske(a)gmail.com>: >> >>> >>> On 23.07.2013, at 15:32, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >>> >>>> >>>> >>>> >>>> On Tue, Jul 23, 2013 at 9:48 AM, Norbert Hartl <norbert(a)hartl.name> wrote: >>>>> Mariano, >>>>> >>>>> Am 23.07.2013 um 14:43 schrieb Mariano Martinez Peck <marianopeck(a)gmail.com>: >>>>> >>>>>> Norbert, does the model have lots of strings? Because if so you can try using the compression. It may increase speed. There is always a trade off between the additional time of compressing/uncompressing. But if the model has quite an amount of strings, since writing to disk is also slow and the final stream would be smaller, it could be faster. >>>>> thanks. Yes, the model is a lot of Dictionaries having string keys. And there are lots more. The usage of the model is write once read many. And 30ms is good enough for me. So I might try compression only to see the difference. Well, and maybe to reduce storage size. The mcz is now 261 kb. >>>>> >>>>> Thanks, I'll see but I am already satisfied with the current approach. >>>> >>>> Mmmm I thought it was ready, sorry my bad. Seems it was not ready nor integrated: https://code.google.com/p/fuel/issues/detail?id=160 >>>> But I might be wrong. >>>> Max? >>> >>> No, that issue is still open. You're welcome to use the experimental version though (Fuel-MaxLeske.757.mcz in http://www.squeaksource.com/FuelExperiments) but keep in mind that this is a few months behind stable. >> I'm not sure the priority is high enough to try. >> >>> The other idea however, that Mariano describes in the linked issue, is available but probably not desirable: simply pass a compressing stream to Fuel (see FLGZippedBasicSerializationTest for an example on how to do that). That will compress *all* data, not only strings (which is the idea outlined in the linked issue). >> I don't think that will gain anything. A monticello package is written as zip. So I wouldn't expect much from an additional compression. >> >> thanks, >> >> Norbert > Unless MAPExampleModels tcap is something like > ^'mySerializedTCAP.bin' asFile readStream binary contents > instead of > tcap > ^#( 0 0 0 â¦ ), > compressing the fuel binary output would save you some runtime memory (method literal size) / .changes space (method source), though for test resources I guess that's a less relevant aspect than for other resources. > Right! They difference is in the image. I'll check that. It might come in handy when I have more of these methods. But then I need to try because every method is used multiple times and having it compressed in the image will add some time to every test run. And then it is measuring penalties (again) thanks, Norbert

Aug. 2, 2013

Re: [Pharo-users] [Pharo-dev] [DOC] Building and deploying your first web app with Pharo

by Sven Van Caekenberghe

Hi Sanjay, On 01 Aug 2013, at 17:58, sminni <sm(a)planage.com> wrote: > Hi Sven > > I get an error with the command > ./pharo Pharo.image eval --no-quit 'ZnServer startDefaultOn: 8080' > Syntax Error on line 1: 'Nothing more expected' > 1: --No-quit ZnServer startDefaultOn: 8080 > > > what could this be pls I think you are using an image where the --no-quit option for the eval command line handler is not (yet) implemented. You should try without the --no-quit option. But the image will probably quit after starting the server. You can keep the main thread running with a little trick, like this: ./pharo Pharo.image eval 'ZnServer startDefaultOn: 8080. [ 1 hour asDelay wait ] repeat' HTH, Sven > thanks & > regards > Sanjay > > > > ----- > --- > Regards, Sanjay > -- > View this message in context: http://forum.world.st/DOC-Building-and-deploying-your-first-web-app-with-Ph… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Aug. 1, 2013

Re: [Pharo-users] [Pharo-dev] [DOC] Building and deploying your first web app with Pharo

by sminni

Hi Sven I get an error with the command ./pharo Pharo.image eval --no-quit 'ZnServer startDefaultOn: 8080' Syntax Error on line 1: 'Nothing more expected' 1: --No-quit ZnServer startDefaultOn: 8080 what could this be pls thanks & regards Sanjay ----- --- Regards, Sanjay -- View this message in context: http://forum.world.st/DOC-Building-and-deploying-your-first-web-app-with-Ph… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 1, 2013

Re: [Pharo-users] Storing test data in methods

by Henrik Johansen

On Jul 23, 2013, at 5:33 , Norbert Hartl <norbert(a)hartl.name> wrote: > Max, > > Am 23.07.2013 um 17:27 schrieb Max Leske <maxleske(a)gmail.com>: > >> >> On 23.07.2013, at 15:32, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> >>> >>> >>> >>> On Tue, Jul 23, 2013 at 9:48 AM, Norbert Hartl <norbert(a)hartl.name> wrote: >>> Mariano, >>> >>> Am 23.07.2013 um 14:43 schrieb Mariano Martinez Peck <marianopeck(a)gmail.com>: >>> >>>> Norbert, does the model have lots of strings? Because if so you can try using the compression. It may increase speed. There is always a trade off between the additional time of compressing/uncompressing. But if the model has quite an amount of strings, since writing to disk is also slow and the final stream would be smaller, it could be faster. >>>> >>> thanks. Yes, the model is a lot of Dictionaries having string keys. And there are lots more. The usage of the model is write once read many. And 30ms is good enough for me. So I might try compression only to see the difference. Well, and maybe to reduce storage size. The mcz is now 261 kb. >>> >>> Thanks, I'll see but I am already satisfied with the current approach. >>> >>> >>> Mmmm I thought it was ready, sorry my bad. Seems it was not ready nor integrated: https://code.google.com/p/fuel/issues/detail?id=160 >>> But I might be wrong. >>> Max? >> >> No, that issue is still open. You're welcome to use the experimental version though (Fuel-MaxLeske.757.mcz in http://www.squeaksource.com/FuelExperiments) but keep in mind that this is a few months behind stable. >> > I'm not sure the priority is high enough to try. > >> The other idea however, that Mariano describes in the linked issue, is available but probably not desirable: simply pass a compressing stream to Fuel (see FLGZippedBasicSerializationTest for an example on how to do that). That will compress *all* data, not only strings (which is the idea outlined in the linked issue). >> > I don't think that will gain anything. A monticello package is written as zip. So I wouldn't expect much from an additional compression. > > thanks, > > Norbert Unless MAPExampleModels tcap is something like ^'mySerializedTCAP.bin' asFile readStream binary contents instead of tcap ^#( 0 0 0 â¦ ), compressing the fuel binary output would save you some runtime memory (method literal size) / .changes space (method source), though for test resources I guess that's a less relevant aspect than for other resources. Cheers, Henry

Aug. 1, 2013

Re: [Pharo-users] Packages ... group view example

by StÃ©phane Ducasse

Yes! Normally Nautilus should have a tree instead of the listâ¦ This is underway. On Jul 31, 2013, at 1:19 PM, Geert Claes <geert.wl.claes(a)gmail.com> wrote: > I know I have seen it somewhere but I can't seem to find it. Can someone > point me to an example where the packages are parsed by the "-"? > > e.g. Dsplayed as: > > v AST > v Core >> Matching >> Nodes >> Parser >> Pattern >> Tokens >> Visitors >> Interpreter >> Tests > > Instead of: > > AST-Core > AST-Core-Matching > AST-Core-Nodes > AST-Core-Parser > AST-Core-Pattern > AST-Core-Tokens > AST-Core-Visitors > AST-Interpreter-Core > AST-Interpreter-Extension > AST-Interpreter-Test > AST-Tests-Core > > Thanks! > > > > -- > View this message in context: http://forum.world.st/Packages-group-view-example-tp4701657.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Aug. 1, 2013

Re: [Pharo-users] Pharo performance

by StÃ©phane Ducasse

ok so we will create a private business mailing-list Stef On Jul 30, 2013, at 11:41 PM, phil(a)highoctane.be wrote: > Yes, as discussed, I am pushing Pharo and discussing business in the open just doesn't work for me.

Aug. 1, 2013

Re: [Pharo-users] Pharo performance

by Mariano Martinez Peck

On Thu, Aug 1, 2013 at 4:06 AM, CHRIS BAILEY <cpmbailey(a)btinternet.com>wrote: > I think my package is based on the one from the DBX suite. It has a few > edits, some of which I'm confident should go in and others just for my > needs which probably aren't fit to. > Ok, please let me know how that goes. > Disappointly, I got the psyco test wrong and it is only taking 30m/s :( I > guess this is the difference when something is implemented on top of C and > libpq (I presume) > mmm maybe. For that you could compare OpenDBXDriver with Postgres, but you will need OpenDBX lib and FFI. > > ------------------------------ > *From:* Mariano Martinez Peck <marianopeck(a)gmail.com> > *To:* Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > *Sent:* Wednesday, 31 July 2013, 22:40 > *Subject:* Re: [Pharo-users] Pharo performance > > > > > On Wed, Jul 31, 2013 at 6:32 PM, Chris <cpmbailey(a)btinternet.com> wrote: > > It definitely seems to be because most things in the V2 driver are coming > in as strings and then being converted. Running the same query on the three > systems gives the following for a 65000 double array > > PGV2 770m/s > PGV3 200m/s > Psycopg2 130m/s > > Now I just need to find out how to get PGV3 as the backend for Glorp! > > > PLease please please use the Glorp version you get from the DBX suite. > You need to create a subclass of DatabaseDriver. You can take a look > to NativePostgresDriver and create a similar one for V3. > I would also like to have Glorp + PostgresV3 running. > > Also...we should somehow use NativePostgresPoolingDriver and > NativePostgresConnectionPool for V3... we need some refactor here... > > We should join forces!! > > > Cheers > Chris > > > 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<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 <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 > > > > > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

Aug. 1, 2013

Re: [Pharo-users] [Pharo-dev] Large images reasons [WAS] Re: Pharo 2.0 with Seaside + DBXTalk + GlorpDBX + Magritte 3 + TWBS is getting slower and slower

by Marcus Denker

On Aug 1, 2013, at 2:12 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > On Thu, Aug 1, 2013 at 4:33 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Aug 1, 2013, at 8:56 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > since years marcus is telling that MC storing ancestor information is doomed but we do not have something to really replace it. > > > > This is yet another thing. > > > Yes, I was talking about the cache, not the ancestors. > I think that removing the cache is indeed safe, isn't it? > Yes! Marcus

Aug. 1, 2013

Re: [Pharo-users] [Pharo-dev] Large images reasons [WAS] Re: Pharo 2.0 with Seaside + DBXTalk + GlorpDBX + Magritte 3 + TWBS is getting slower and slower

by Mariano Martinez Peck

On Thu, Aug 1, 2013 at 4:33 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Aug 1, 2013, at 8:56 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > > since years marcus is telling that MC storing ancestor information is > doomed but we do not have something to really replace it. > > > > This is yet another thing. > > Yes, I was talking about the cache, not the ancestors. I think that removing the cache is indeed safe, isn't it? > Monticello keep all history data of all package in image, this is not a > cache. When you delete it, your package loses > it's history and you can not merge anymore. > > MCVersionInfo allInstances do: [ :each | each instVarNamed: 'ancestors' > put: nil ]. > > We did that on Pharo2 release and it saved 8MB (nearly a third of the > image). > > Marcus > -- Mariano http://marianopeck.wordpress.com

Aug. 1, 2013

Re: [Pharo-users] Broken link for download Portable edition

by Gisela Decuzzi

Great! Thanks! 2013/8/1 Marcus Denker <marcus.denker(a)inria.fr> > > On Aug 1, 2013, at 1:25 PM, Gisela Decuzzi <giseladecuzzi(a)gmail.com> > wrote: > > Hi, I want to try the portable edition I saw in the download's page but is > pointing to http://files.pharo.org/portable/Pharo3.0-portable.zip and in > files.pharo.org seems missing the portable folder at all. > > I checked in the old server (http://pharo.gforge.inria.fr/ci/) and there > is not portable folder also. > > Someone know where I can find it? > > > Yes, this is now > > http://files.pharo.org/platform/ > > I will update the website. > > Marcus > > >

Aug. 1, 2013