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

Re: [Pharo-users] Pharo as a platform for a large E-Commerce website

by Stephan Eggermont

Sanjay wrote: >Possibly the above details are sketchy but the immediate questions for him >to firm up investment plans are: >- Will a Pharo based platform be appropriate > -- Technology ? > -- Robustness & support ? Nothing you indicated in your estimates would be a bad fit for Pharo. Strong points for Pharo in a startup context are flexibility and very fast development. Not being 64-bit is a weak point, but you might be able to come up with a shared nothing architecture and lots of images running part of the problem. Do a spike integrating and deploying the technologies you need, and make sure you can do that again after each commit. >- what will be the team man year effort (ballpark estimate) for development, >testing, administration upto initial go-live ? 1, 10 or 10000. Portal is a semantics-free marketing term. Estimation at this level of fuzziness is a meaningless activity. What do you plan to have online at the end of the first week, the first month and the first quarter (at less and less detailed level)? Do you already have these users, or do you need to grow the number from zero? Create a story map and slice it. http://www.agileproductdesign.com/blog/the_new_backlog.html Stephan

Aug. 4, 2013

Re: [Pharo-users] Does zinc support server sent events?

by Sven Van Caekenberghe

Hi Andy, On 04 Aug 2013, at 04:28, Andy Burnett <andy.burnett(a)knowinnovation.com> wrote: > I was wondering about using them instead of Websockets. > > Cheers > Andy Assuming you mean http://en.wikipedia.org/wiki/Server-sent_events the answer is no or not yet. It doesn't look very complicated though, given the fact that Zinc WebSockets do already work. I will start by reading the specs. Regards, Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

Aug. 4, 2013

Does zinc support server sent events?

by Andy Burnett

I was wondering about using them instead of Websockets. Cheers Andy

Aug. 4, 2013

New version of PharoSound

by StÃ©phane Ducasse

Hi I merged Jannik clean and I commited a new version of the configuration. Now it works on Pharo 20 and also on Pharo 30 And I will produce a new System-Sound for the kernel based on Pavel work and I will produce a new configuration. Stef

Aug. 3, 2013

Pharo as a platform for a large E-Commerce website

by sminni

Hi, One of my friends is moving forward on a very serious e-commerce portal (startup). Just as an example / illustration - something like say any of the typical largest online shopping stores Initial estimates are typically average peak #no of records to search 100,000 500,000 #no of users online 1,000 5,000 #no of transactions per hour 10,000 50,000 #no of actual commerce gateway transaction per hour 1,000 5,000 Possibly the above details are sketchy but the immediate questions for him to firm up investment plans are: - Will a Pharo based platform be appropriate -- Technology ? -- Robustness & support ? - what will be the team man year effort (ballpark estimate) for development, testing, administration upto initial go-live ? Could folks just throw any pointers to help in investment estimation and evaluation Are any references of similar projects available in Pharo at this time ? regards Sanjay ----- --- Regards, Sanjay -- View this message in context: http://forum.world.st/Pharo-as-a-platform-for-a-large-E-Commerce-website-tp… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 3, 2013

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