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

Pier 3 Code exporter

by Stephan Eggermont

Hi all, Before my holidays I started on making the code exporter for pier3 work easy. I had some issues, and fixed most of the before my holidays. But now after my holidays I had time to test the entire path, so we can deploy our website www.legacycode.nl from continuous integration. We now can use the following script on a clean pharo 2.0 image: " load the configuration and from the configuration the code exporter for pier " Gofer new url: 'http://smalltalkhub.com/mc/Pier/Pier3Addons/main'; package: 'ConfigurationOfPier3AddOns'; load. ((Smalltalk at: #ConfigurationOfPier3AddOns) project version: #'stable') load: 'Code-Exporter-Pier3'. " load and start the webserver. For Pharo this we use Zinc " ((Smalltalk at: #ConfigurationOfSeaside3) project version: '3.1.0') load: 'Zinc-Seaside'. (Smalltalk at: #ZnZincServerAdaptor) startOn: 8080. " load your own exported code and perform line below to recreate the kernel PRKernelCreatorForPier register and copy the files pier created (css) to the correct folder (default .../Resources/files/* ) Note: the pier image sets the folder to a fixed location in MAExternalFileModel. To reset this: MAExternalFileModel baseDirectoryPath: nil Setting this folder is also possible if you want to use a location outside of your image for your css files. I.e. MAExternalFileModel baseDirectoryPath: '~/css' " Stephan and Diego

Aug. 19, 2013

Re: [Pharo-users] your opinion about storing FixedDecimal in Mongo

by Sabine KnÃ¶fel

Hi Henry, Esteban, Joachim, thanks for your opinion! The ranges of my data are relatively small because my application deals with travel expenses, e.g. Hotel receipts, Taxi receipts, Flights et. So, 99,99% of all my amounts are less than 10.000 Euro. So I will try it with the Float solution and use a scale of 4. ...and I will indeed add checking for range! Good point, I do not have this yet. Sabine On Mon, Aug 19, 2013 at 12:48 PM, Henrik Sperre Johansen [via Smalltalk] < ml-node+s1294792n4704124h39(a)n4.nabble.com> wrote: > > On Aug 19, 2013, at 10:38 , Sabine KnÃ¶fel <[hidden email]<http://user/SendEmail.jtp?type=node&node=4704124&i=0>> > wrote: > > > Hi, > > > > I am interested in your opinion. > > I use FixedDecimal for computing currency amounts. > > This works fine. > > > > When storing the amounts with voyage into mongo (I have a lot of > them!!!), > > normally, one currency amount would be stored into mongo as follows: > > > > "vatAmountEUR": { > > "#instanceOf": "FixedDecimal", > > "negative": false, > > "number": NumberInt(90280), > > "part1": NumberInt(9), > > "part2": NumberInt(280), > > "scale": NumberInt(4) > > } > > > > I think, this is a lot of stuff for one single value. I tend to convert > the > > FixedDecimal into a Float for storing it. In this case, it would be like > > this: > > > > "vatAmountEUR": 0.7196 > > > > When loading, I immediately re-convert it into a FixedDecimal. I would > do NO > > computing with the float(!!). > > > > What is your opinion about this (rounding issues, performance, database > size > > etc.)? > > Do you think, there is something against it? What would you do? > > > > Sabine > There are rounding issues even without doing arithmetic, conversion scaled > -> float WILL inherently be lossy due to float's fixed size. > You are only ensured 15 decimal digits of precision with 64-bit floating > point numbers like in Pharo (BSON Doubles): > 98765432109.87658s5 asFloat asScaledDecimal: 5 98765432109.87659s5 > > Though, Compared to using NumberInt ( a signed 32-bit integer, with max 9 > digits) for storing the unscaled number, it's actually the better optionâ¦ > > I guess the morale is, either way, as long as you are storing values in > fixed size data fields (and not say, a String), you need some checks in > place to ensure the numbers you are saving are within valid ranges. ;) > > Cheers, > Henry > > > *signature.asc* (859 bytes) Download Attachment<http://forum.world.st/attachment/4704124/0/signature.asc> > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://forum.world.st/your-opinion-about-storing-FixedDecimal-in-Mongo-tp47… > To unsubscribe from your opinion about storing FixedDecimal in Mongo, click > here<http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&no…> > . > NAML<http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> > -- View this message in context: http://forum.world.st/your-opinion-about-storing-FixedDecimal-in-Mongo-tp47… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 19, 2013

Re: [Pharo-users] your opinion about storing FixedDecimal in Mongo

by Henrik Johansen

On Aug 19, 2013, at 10:38 , Sabine KnÃ¶fel <sabine.knoefel(a)gmail.com> wrote: > Hi, > > I am interested in your opinion. > I use FixedDecimal for computing currency amounts. > This works fine. > > When storing the amounts with voyage into mongo (I have a lot of them!!!), > normally, one currency amount would be stored into mongo as follows: > > "vatAmountEUR": { > "#instanceOf": "FixedDecimal", > "negative": false, > "number": NumberInt(90280), > "part1": NumberInt(9), > "part2": NumberInt(280), > "scale": NumberInt(4) > } > > I think, this is a lot of stuff for one single value. I tend to convert the > FixedDecimal into a Float for storing it. In this case, it would be like > this: > > "vatAmountEUR": 0.7196 > > When loading, I immediately re-convert it into a FixedDecimal. I would do NO > computing with the float(!!). > > What is your opinion about this (rounding issues, performance, database size > etc.)? > Do you think, there is something against it? What would you do? > > Sabine There are rounding issues even without doing arithmetic, conversion scaled -> float WILL inherently be lossy due to float's fixed size. You are only ensured 15 decimal digits of precision with 64-bit floating point numbers like in Pharo (BSON Doubles): 98765432109.87658s5 asFloat asScaledDecimal: 5 98765432109.87659s5 Though, Compared to using NumberInt ( a signed 32-bit integer, with max 9 digits) for storing the unscaled number, it's actually the better optionâ¦ I guess the morale is, either way, as long as you are storing values in fixed size data fields (and not say, a String), you need some checks in place to ensure the numbers you are saving are within valid ranges. ;) Cheers, Henry

Aug. 19, 2013

Re: [Pharo-users] Smalltalk frameworks that use parsers

by Mohammad Al Houssami (Alumni)

I am working on an html5 parser and I want to get ideas of how a parser can be used outside a browser. So a very simple example is something like live DOM viewer(http://software.hixie.ch/utilities/js/live-dom-viewer/ ) that shows the hierarchy of the elements in the html code. This is an application that uses a parser outside a browser. So the applications has to use the functionalities of the parser to give some output or functionality. The Moose project (I think) gives parsing services and doesn't use parsing to give some other service I hope this is clearer :) Thank you very much From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Tudor Girba Sent: Monday, August 19, 2013 11:29 AM To: Any question about pharo is welcome Subject: Re: [Pharo-users] Smalltalk frameworks that use parsers Hi, The Moose project uses PetitParser for various parsers: http://moosetechnology.org But, could you elaborate your use case? Doru On Mon, Aug 19, 2013 at 12:21 PM, Mohammad Al Houssami (Alumni) <mha53(a)mail.aub.edu<mailto:mha53@mail.aub.edu>> wrote: Hello all, Are there any frameworks or applications built in Smalltalk that use parsers ? If yes can I get the names of a few of them ? I was only able to find applications that provide parsing services but not things that use a parser to do something like sanitization for example. Any help is much appreciated :) -- www.tudorgirba.com<http://www.tudorgirba.com> "Every thing has its own flow"

Aug. 19, 2013

Re: [Pharo-users] Smalltalk frameworks that use parsers

by Tudor Girba

Hi, The Moose project uses PetitParser for various parsers: http://moosetechnology.org But, could you elaborate your use case? Doru On Mon, Aug 19, 2013 at 12:21 PM, Mohammad Al Houssami (Alumni) < mha53(a)mail.aub.edu> wrote: > Hello all,**** > > Are there any frameworks or applications built in Smalltalk that use > parsers ? If yes can I get the names of a few of them ? > I was only able to find applications that provide parsing services but not > things that use a parser to do something like sanitization for example.*** > * > > ** ** > > Any help is much appreciated J**** > > ** ** > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 19, 2013

Smalltalk frameworks that use parsers

by Mohammad Al Houssami (Alumni)

Hello all, Are there any frameworks or applications built in Smalltalk that use parsers ? If yes can I get the names of a few of them ? I was only able to find applications that provide parsing services but not things that use a parser to do something like sanitization for example. Any help is much appreciated :)

Aug. 19, 2013

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

by Esteban Lorenzano

Hi, sorry for the very delayed answer :) Some years ago I made a massive ecommerce, it was developed on pharo and deployed on gemstone. that works pretty well and you have infinite scaling. now, you could do the same with pharo + some db backend (I'd recommend mongo) + a load balancing strategy. this gives you some advantages (like not needing to deploy in a different platform) and some disadvantages (like have to doing the balancing stuff by your self). but... certainly, nowadays there is nothing that could stop you to use pharo for your site. cheers, Esteban On Aug 7, 2013, at 1:01 AM, Cameron Sanders <camsanders(a)aol.com> wrote: > Are you definitely going the smalltalk path and your question is Which One platform? Or are you not yet committed to smalltalk? > > If you go with Pharo, you may be able to migrate to something like Gemstone should the need arise. Or to one of the other flavors. > - > > I recently interviewed a kid with CompSci degree from a small school here in the States. He showed me his Senior Project. And I was nearly floored in shock. It was a whole mess of PHP... that did nothing more than present three DB tables to the user, which they could edit. In Pharo, using Seaside, and working through the tutorial to construct your login system (which was one of the tables of this project), and ... and using SQL calls directly (not learning Glorp), it would probably just take a few days to do as-you-learn. The amount of functional code/behavior seemed really small for a senior project... at least when compared to the productivity of Pharo+Seaside. > > The moral of this story: if you are considering PHP as your alternative... DON'T! Instead work with classes/objects, in an environment that supports OO programming. Smalltalk scales really well in terms of programming time -- one of the most productive environments you will find. > > That said... there are more java programmers than smalltalkers. ... of course... you need more java programmers for the same functionality! ;) > - > > How many different dialogs/widgets presented to the User? How many unique attributes/fields for user to select? Navigation is standardized? Etc. Obviously, sizing a project takes time. > > ... In smalltalk, one can often lay out crude class definitions as fast as you can type them into a project management system. It was made for rapid prototyping, and the ('type') evolution that comes with such development. > - > > I have a project that I would like to scale beyond your specs. But we can grow more slowly, giving us time to grapple with questions about DB mirroring, and how many Virtual images do we need, and how many Pharo images running on each... load balancing, etc. There are several people on this board who know more about this than I do. (Several offering consulting services too.) > > Good luck! > > -Cam > > > On Sun, Aug 4, 2013 at 7:25 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: > 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. 19, 2013

Re: [Pharo-users] your opinion about storing FixedDecimal in Mongo

by Esteban Lorenzano

Hi, yes, looks like too much :) I would go with the float representation... for the conversion, I do not have an experience or opinion about performance or db footprint. You have to check that in the old empirical fashion way :) Esteban On Aug 19, 2013, at 10:38 AM, Sabine KnÃ¶fel <sabine.knoefel(a)gmail.com> wrote: > Hi, > > I am interested in your opinion. > I use FixedDecimal for computing currency amounts. > This works fine. > > When storing the amounts with voyage into mongo (I have a lot of them!!!), > normally, one currency amount would be stored into mongo as follows: > > "vatAmountEUR": { > "#instanceOf": "FixedDecimal", > "negative": false, > "number": NumberInt(90280), > "part1": NumberInt(9), > "part2": NumberInt(280), > "scale": NumberInt(4) > } > > I think, this is a lot of stuff for one single value. I tend to convert the > FixedDecimal into a Float for storing it. In this case, it would be like > this: > > "vatAmountEUR": 0.7196 > > When loading, I immediately re-convert it into a FixedDecimal. I would do NO > computing with the float(!!). > > What is your opinion about this (rounding issues, performance, database size > etc.)? > Do you think, there is something against it? What would you do? > > Sabine > > > > > > > > -- > View this message in context: http://forum.world.st/your-opinion-about-storing-FixedDecimal-in-Mongo-tp47… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Aug. 19, 2013

Re: [Pharo-users] your opinion about storing FixedDecimal in Mongo

by jtuchel＠objektfabrik.de

Am 19.08.13 10:46, schrieb jtuchel(a)objektfabrik.de: > Am 19.08.13 10:38, schrieb Sabine KnÃ¶fel: >> I think, this is a lot of stuff for one single value. I tend to >> convert the >> FixedDecimal into a Float for storing it. In this case, it would be like >> this: >> >> "vatAmountEUR": 0.7196 >> >> When loading, I immediately re-convert it into a FixedDecimal. I >> would do NO >> computing with the float(!!). >> >> What is your opinion about this (rounding issues, performance, >> database size >> etc.)? >> Do you think, there is something against it? What would you do? >> >> > Hi Sabine, > > my misinformed opinion on storing fixed decimals is to completely > avoid floats and keep it as simple as possible. Floats smell like > problems to me. > Why not store two integers: one for the integer part and one for the > digits and implement some kind of converter for storing/retrieving. > with "digits" I mean the part after the decimal point. Would decimal part be a better term? not sure... > > Joachim > > > -- -- â¨----------------------------------------------------------------------- â¨Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de â¨Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Aug. 19, 2013

Re: [Pharo-users] your opinion about storing FixedDecimal in Mongo

by jtuchel＠objektfabrik.de

Am 19.08.13 10:38, schrieb Sabine KnÃ¶fel: > I think, this is a lot of stuff for one single value. I tend to convert the > FixedDecimal into a Float for storing it. In this case, it would be like > this: > > "vatAmountEUR": 0.7196 > > When loading, I immediately re-convert it into a FixedDecimal. I would do NO > computing with the float(!!). > > What is your opinion about this (rounding issues, performance, database size > etc.)? > Do you think, there is something against it? What would you do? > > Hi Sabine, my misinformed opinion on storing fixed decimals is to completely avoid floats and keep it as simple as possible. Floats smell like problems to me. Why not store two integers: one for the integer part and one for the digits and implement some kind of converter for storing/retrieving. Joachim -- -- â¨----------------------------------------------------------------------- â¨Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de â¨Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Aug. 19, 2013