February 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Pharo-users] Who is using Fuel?

by Mariano Martinez Peck

On Tue, Feb 28, 2012 at 7:15 PM, Yanni Chiu <yanni(a)rogers.com> wrote: > On 28/02/12 11:03 AM, Norbert Hartl wrote: > >> >> I first used image persistence but the image grow to large. Then I added >> fuel as journal to be written before image save in order to be able to >> recover from an emergency. >> Now we redo the persistence part. An account object graph is dissected >> into configuration part and payload part. The payload is written >> directly to mongo db in a Json format. The configuration part will be >> written as fuel blob to mongo. Planned is that at startup a configured >> amount of account fuel blobs are loaded and started. Those >> configurations have their own proces ses that write back payload to >> mongo. Etc. >> > > That's similar to what I do, except no image save and no mongo db. > > Here's how it goes: > - on restart the image reconstructs a Pier kernel saved via Fuel to a file > - included in the Pier kernel is what you're calling the "configuration > part" - there are custom (non-std Pier) components here. > - the components in the reconstructed image can read/write a "payload" > part, which is serialized to files using Fuel and SandstoneDb. > WOW. I didn't know there was a real user about that ;) > - additionally, a "sub-tree" of the Pier kernel can be exported to a file > using Fuel serialization, and later imported using Fuel deserialization. > > That's interesting! > No URL available at the moment. > > Ok, let me know if you have one at some point in the future and I add it. > Aside - before Fuel/SandstoneDb, I was using Glorp/PostgreSQL. I've gained > a lot of simplicity, but lost sequence numbers Sequence numbers are the less thing you should care about since you can alwasy do it in image side ;) and object caching (and maybe more things, that have not been a problem so > far). I've written a seqno replacement, but the lack of object caching is > not a problem at the moment (i.e. small data sets, so far). > > Yes, object caching is NOT a problem itself, it is a feature of Glorp or whatever. If what you use (like Fuel) is slow, then it may require some tunning. It can be caching object or not. What I suggest is that you stress your system with big data sets and you will see if you really miss object caching or not. -- Mariano http://marianopeck.wordpress.com

Feb. 28, 2012

Re: [Pharo-project] can this be done via modification to the Squeak/Pharo IDE?

by Tudor Girba

You mean to innovate on principle? I thought this is what Pharo is all about :) Doru On 28 Feb 2012, at 00:46, Lawson English wrote: > http://vimeo.com/36579366 > > Lawson > -- www.tudorgirba.com "Some battles are better lost than fought."

Feb. 28, 2012

Re: [Pharo-project] [Pharo-users] Who is using Fuel?

by Sven Van Caekenberghe

Norbert, On 28 Feb 2012, at 17:32, Norbert Hartl wrote: > I experience image corruption with big images. I am assuming you are using a normal image on a 32-bit Cog VM on Linux ? I am very interested in the practical limits on image size (not necessarily saving it). What vm switches did you apply ? I played a bit with some tests, and I could allocate about 1Gb in a 1.5GB heap VM. What is your experience ? Thx, Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Feb. 28, 2012

Re: [Pharo-project] [Pharo-users] Who is using Fuel?

by Norbert Hartl

Am 28.02.2012 um 19:15 schrieb Yanni Chiu: > On 28/02/12 11:03 AM, Norbert Hartl wrote: >> >> I first used image persistence but the image grow to large. Then I added >> fuel as journal to be written before image save in order to be able to >> recover from an emergency. >> Now we redo the persistence part. An account object graph is dissected >> into configuration part and payload part. The payload is written >> directly to mongo db in a Json format. The configuration part will be >> written as fuel blob to mongo. Planned is that at startup a configured >> amount of account fuel blobs are loaded and started. Those >> configurations have their own proces ses that write back payload to >> mongo. Etc. > > That's similar to what I do, except no image save and no mongo db. > As soon as the fuel blobs are in mongo (or on disk) no image save is needed then and I will start fresh everytime which is more reliable. Mongo is quite nice because I have a few hundred megabytes of data. And via cron it runs a map/reduce task to create the statistics about the data that has been fetched. The statistical data is displayed in charts on the web site again. Norbert > Here's how it goes: > - on restart the image reconstructs a Pier kernel saved via Fuel to a file > - included in the Pier kernel is what you're calling the "configuration part" - there are custom (non-std Pier) components here. > - the components in the reconstructed image can read/write a "payload" part, which is serialized to files using Fuel and SandstoneDb. > - additionally, a "sub-tree" of the Pier kernel can be exported to a file using Fuel serialization, and later imported using Fuel deserialization. > > No URL available at the moment. > > Aside - before Fuel/SandstoneDb, I was using Glorp/PostgreSQL. I've gained a lot of simplicity, but lost sequence numbers and object caching (and maybe more things, that have not been a problem so far). I've written a seqno replacement, but the lack of object caching is not a problem at the moment (i.e. small data sets, so far). > >

Feb. 28, 2012

Re: [Pharo-project] [squeak-dev] can this be done via modification to the Squeak/Pharo IDE?

by Chris Muller

There's a program for Squeak that does that -- it's called Etoys...

Feb. 28, 2012

Re: [Pharo-project] [Pharo-users] Who is using Fuel?

by Yanni Chiu

On 28/02/12 11:03 AM, Norbert Hartl wrote: > > I first used image persistence but the image grow to large. Then I added > fuel as journal to be written before image save in order to be able to > recover from an emergency. > Now we redo the persistence part. An account object graph is dissected > into configuration part and payload part. The payload is written > directly to mongo db in a Json format. The configuration part will be > written as fuel blob to mongo. Planned is that at startup a configured > amount of account fuel blobs are loaded and started. Those > configurations have their own proces ses that write back payload to > mongo. Etc. That's similar to what I do, except no image save and no mongo db. Here's how it goes: - on restart the image reconstructs a Pier kernel saved via Fuel to a file - included in the Pier kernel is what you're calling the "configuration part" - there are custom (non-std Pier) components here. - the components in the reconstructed image can read/write a "payload" part, which is serialized to files using Fuel and SandstoneDb. - additionally, a "sub-tree" of the Pier kernel can be exported to a file using Fuel serialization, and later imported using Fuel deserialization. No URL available at the moment. Aside - before Fuel/SandstoneDb, I was using Glorp/PostgreSQL. I've gained a lot of simplicity, but lost sequence numbers and object caching (and maybe more things, that have not been a problem so far). I've written a seqno replacement, but the lack of object caching is not a problem at the moment (i.e. small data sets, so far).

Feb. 28, 2012

Re: [Pharo-project] [squeak-dev] can this be done via modification to the Squeak/Pharo IDE?

by S Krish

My two tiny cents: I have always demoed the liveness of Smalltalk with an inspector open on a window and dynamically add / delete/ modify its contents as you wish.. While the talk is all about animating a simple graphic, the thought and effort indeed is powerful. The real world applications are lot more complex and onerous than projected in this video. Given that I believe Smalltalk should be the first to have this liveness built in.. Not just as in live coding to dynamically impact a graphic but as in Etoys and the rest that respond live to change in the code parameters live just in time. the trouble with EToys has been its finesse, the applesque touch/ elegance is missing. Contrast that with morpho-physics.. its really cool, just needs a neater well rendered balls ( i mean with elegant image rendered morphs.. ) and you can show even more powerful liveness.. Scratch I believe takes the metaphor even further saying, you do not code, but drag and drop.. Its just that it has been video presented this effectively or viral.. Little tweaks I am sure it can be lot more interesting than this.. when we pick the inspector and play with its attributes, the one aspect that is missing is the modification to code.. but otherwise it is lot more fun than this.. But nontheless I believe the underlying principle is what I saw a striking parallel to for the Enterprise World: Coding needs to be fun, not the dreary code, complle , run cycle.. even in Smalltalk: code, debug, fix, it auto compiles, modifies cycle.. sometimes we do get caught in.. a) I began with the premises that there should be two Worlds and more: Development and runtime in the same Pharo image. So you code in one.. run in another and then experiment / inspect - modify have fun in another.. but come back to the dev panel to finish the code.. b) For Spec - UI Builder.. I was thinking in these lines: One panel has the code that you write and modify and the other panel reflects the change ( but for me as it compiles.. instantly.. ) Lots of stuff we do even for enterprise should get split and rendered visually like Lumiere in openGL on top.. linked to the table of data below.. rather than drab.. two D display of forms and data.. There is a great potential.. I just see js .. taking the credits for something Smalltalk has had for 30 + yrs.. On Tue, Feb 28, 2012 at 9:03 PM, Dave Mason <dmason(a)mason-rose.ca> wrote: > I was wondering exactly the same thing! > > On 2012-Feb-27, at 18:46 , Lawson English wrote: > > > http://vimeo.com/36579366 > >

Feb. 28, 2012

Re: [Pharo-project] shorten petitparser expressions

by Frank Shearar

On 28 February 2012 17:43, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 28 February 2012 18:40, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> On 28 February 2012 16:50, Fabrizio Perin <fabrizio.perin(a)gmail.com> wrote: >>> Hi, >>> I think the reason is for consistency. >>> If fact I like as it is now for that reason. >>> >>> $a asParser / $b asParser / #foo asParser "It looks clear to me and is >>> consistent." >>> >>> a asParser / $b / #foo "it looks odd because it is inconsistent." >>> >>> Anyway, for such simple parsers you loose consistency and you don't gain >>> much. If you have to deal with longer statements, if you have to make your >>> parsers reusable or simply to make your simple example cleaner for real, you >>> should have separate methods: >>> a >>> ^$a asParser >>> >>> b >>> ^$b asParser >>> >>> foo >>> ^#foo asParser >>> >>> a / b / foo " this is cleaner and consistent" >>> >>> I hope I made my point. >>> >>> Cheers, >>> Fabrizio >>> >>> "Consistency, Consistency, Consistency" >> >> I've often used #anyOf: - >> >> anyOf: someTokens >> Â "Writing without a compiler; may actually still work!" >> Â ^ someTokens allButFirst >> Â Â inject: someTokens first >> Â Â into: [:acc :each | acc / each asParser] >> >> self anyOf: #($a $b #foo). >> > so, talking about consistency, where is consistency, when here you > have implicit #asParser, while in rest methods not? :) > maybe we should write it like that: > > Â self anyOf: {$a asParser. Â $b asParser. Â #foo asParser }. > > Â "Consistency, Consistency, Consistency" > > :) Well, I do like consistency, but I wasn't the one to say "Consistency, Consistency, Consistency" :) Still, at least #anyOf: indicates that something's happening, so it's not like it's magically adding #asParser. I don't have it open, but Cutie (from LanguageBoxes) has a parser that does vaguely magical stuff to say "a / b / c", something like a PPCompositeParser. frank >> frank >> >>> 2012/2/28 Igor Stasenko <siguctua(a)gmail.com> >>>> >>>> Why i need to put #asParser everywhere? >>>> >>>> $a asParser / $b asParser / #foo asParser >>>> >>>> >>>> a proper implementation of #/ makes the above to just: >>>> >>>> $a asParser / $b / #foo >>>> >>>> which is much more cleaner and convenient. >>>> >>>> Or, is there a reason to not send #asParser to every argument where >>>> parser expected? >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >> > > > > -- > Best regards, > Igor Stasenko. >

Feb. 28, 2012

Re: [Pharo-project] shorten petitparser expressions

by Igor Stasenko

On 28 February 2012 18:40, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 28 February 2012 16:50, Fabrizio Perin <fabrizio.perin(a)gmail.com> wrote: >> Hi, >> I think the reason is for consistency. >> If fact I like as it is now for that reason. >> >> $a asParser / $b asParser / #foo asParser "It looks clear to me and is >> consistent." >> >> a asParser / $b / #foo "it looks odd because it is inconsistent." >> >> Anyway, for such simple parsers you loose consistency and you don't gain >> much. If you have to deal with longer statements, if you have to make your >> parsers reusable or simply to make your simple example cleaner for real, you >> should have separate methods: >> a >> ^$a asParser >> >> b >> ^$b asParser >> >> foo >> ^#foo asParser >> >> a / b / foo " this is cleaner and consistent" >> >> I hope I made my point. >> >> Cheers, >> Fabrizio >> >> "Consistency, Consistency, Consistency" > > I've often used #anyOf: - > > anyOf: someTokens > Â "Writing without a compiler; may actually still work!" > Â ^ someTokens allButFirst > Â Â inject: someTokens first > Â Â into: [:acc :each | acc / each asParser] > > self anyOf: #($a $b #foo). > so, talking about consistency, where is consistency, when here you have implicit #asParser, while in rest methods not? :) maybe we should write it like that: self anyOf: {$a asParser. $b asParser. #foo asParser }. "Consistency, Consistency, Consistency" :) > frank > >> 2012/2/28 Igor Stasenko <siguctua(a)gmail.com> >>> >>> Why i need to put #asParser everywhere? >>> >>> $a asParser / $b asParser / #foo asParser >>> >>> >>> a proper implementation of #/ makes the above to just: >>> >>> $a asParser / $b / #foo >>> >>> which is much more cleaner and convenient. >>> >>> Or, is there a reason to not send #asParser to every argument where >>> parser expected? >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> > -- Best regards, Igor Stasenko.

Feb. 28, 2012

Re: [Pharo-project] shorten petitparser expressions

by Igor Stasenko

On 28 February 2012 17:50, Fabrizio Perin <fabrizio.perin(a)gmail.com> wrote: > Hi, > I think the reason is for consistency. > If fact I like as it is now for that reason. > > $a asParser / $b asParser / #foo asParser "It looks clear to me and is > consistent." > > a asParser / $b / #foo "it looks odd because it is inconsistent." > why odd? and explicitly sending #asParser to every argument is less odd? > Anyway, for such simple parsers you loose consistency and you don't gain > much. If you have to deal with longer statements, if you have to make your > parsers reusable or simply to make your simple example cleaner for real, you > should have separate methods: > a > ^$a asParser > > b > ^$b asParser > > foo > ^#foo asParser > > a / b / foo " this is cleaner and consistent" oh please, don't call splitting single expression onto 3 separate methods "cleaning" :) With this change i could write same code as before, but you can't do write like me. > > I hope I made my point. > > Cheers, > Fabrizio > > "Consistency, Consistency, Consistency" > > > > 2012/2/28 Igor Stasenko <siguctua(a)gmail.com> >> >> Why i need to put #asParser everywhere? >> >> $a asParser / $b asParser / #foo asParser >> >> >> a proper implementation of #/ makes the above to just: >> >> $a asParser / $b / #foo >> >> which is much more cleaner and convenient. >> >> Or, is there a reason to not send #asParser to every argument where >> parser expected? >> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

Feb. 28, 2012