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 9:46 PM, Yanni Chiu <yanni(a)rogers.com> wrote: > On 28/02/12 2:48 PM, Mariano Martinez Peck wrote: > >> >> 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. >> > > It not a speed issue. It's about how big the image gets if all the on-disk > objects get pulled into memory. The Glorp cache had a max cache size and > LRU policy, IIRC. > > > If I understand you correctly, then what you are talking about is not caching objects but rather lazy loading. You mean when Glorp lets some proxies of the loaded graph so that they can load the rest of the graph later on? -- Mariano http://marianopeck.wordpress.com

Feb. 28, 2012

Re: [Pharo-project] shorten petitparser expressions

by Fabrizio Perin

2012/2/28 Igor Stasenko <siguctua(a)gmail.com> > 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? > No but it is more consistent :) > > > > 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" :) > I was just providing an example as you did. Btw I do create most of the time really small productions all the time. I mean, if I think a parser deserve to be created let's make it good. Otherwise I can solve my problems with regular expressions and string comparisons. > With this change i could write same code as before, but you can't do > write like me. > I don't want to write like you otherwise I wouldn't reply in the first place ;) Anyway, mine it is just an opinion. I simply prefer to have it explicit, that's all. Best regards, Fabrizio > > > 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

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

by Yanni Chiu

On 28/02/12 3:30 PM, Norbert Hartl wrote: > > I'm sorry that's all. I just started to do deployments with pharo > lately. I was doing everything in gemstone until 2 month ago. That's interesting. Have you moved everything to Pharo, or is some part still in GemStone? Can you outline why GemStone was not the better solution for your use case? (I suspect that your dataset was naturally partitioned on user boundaries).

Feb. 28, 2012

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

by Sven Van Caekenberghe

On 28 Feb 2012, at 21:30, Norbert Hartl wrote: > Am 28.02.2012 um 20:35 schrieb 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 ? >> > yes > >> I am very interested in the practical limits on image size (not necessarily saving it). >> > Ah, I was just talking. The latest image grew to 280MB on disk. I just experienced a corrupted image after a few days. I did a more or less clean procedure by stopping all threads while saving. But sometime the image seems to be not fully written on disk making it unloadable on next start. The only limit that I tested is a maximum of threads of 1100 or 1400, can't remember right now. The image is stuck then. But that's no problem to me. > >> What vm switches did you apply ? >> > -encoding latin1 -nodisplay -nosound -mmap 512m > >> I played a bit with some tests, and I could allocate about 1Gb in a 1.5GB heap VM. >> > I had only the save experience but there could be a huge amount of reasons why it failed. My feeling is that my images are getting worse the longer they run. But I have nothing real to base this assumption on. > >> What is your experience ? > > I'm sorry that's all. I just started to do deployments with pharo lately. I was doing everything in gemstone until 2 month ago. > > Norbert Thx for the reply. Some time ago, I tried this: http://forum.world.st/Big-Image-Tests-td4188045.html#a4188548 Sven

Feb. 28, 2012

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

by Yanni Chiu

On 28/02/12 2:48 PM, Mariano Martinez Peck wrote: > > 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. It not a speed issue. It's about how big the image gets if all the on-disk objects get pulled into memory. The Glorp cache had a max cache size and LRU policy, IIRC.

Feb. 28, 2012

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

by Norbert Hartl

Am 28.02.2012 um 20:35 schrieb 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 ? > yes > I am very interested in the practical limits on image size (not necessarily saving it). > Ah, I was just talking. The latest image grew to 280MB on disk. I just experienced a corrupted image after a few days. I did a more or less clean procedure by stopping all threads while saving. But sometime the image seems to be not fully written on disk making it unloadable on next start. The only limit that I tested is a maximum of threads of 1100 or 1400, can't remember right now. The image is stuck then. But that's no problem to me. > What vm switches did you apply ? > -encoding latin1 -nodisplay -nosound -mmap 512m > I played a bit with some tests, and I could allocate about 1Gb in a 1.5GB heap VM. > I had only the save experience but there could be a huge amount of reasons why it failed. My feeling is that my images are getting worse the longer they run. But I have nothing real to base this assumption on. > What is your experience ? I'm sorry that's all. I just started to do deployments with pharo lately. I was doing everything in gemstone until 2 month ago. Norbert

Feb. 28, 2012

Re: [Pharo-project] It would be me first

by StÃ©phane Ducasse

Ok Excellent! what we should do is to make sure that the participants get information information and information about doing more business with pharo :). Stef > Yes, I know :) I promised it to you, didn't I? I can do two as well. I could repeat my FOSDEM presentation on REST services with Seaside-Rest in concerto with using Magritte3 for content handling in XML and Json. It is about routing of services, content negation (Accept/Content-Type headers) and meta model assistance. > As a second one I could present the mentioned web api tester we are doing. This includes serialization as well with Magritte3 in JSON and BSON, MongoTalk to talk to MongoDB and single page UI with seaside and jquery. If that's not all to similar to what Nicolas is doing. Well, if Esteban is presenting as well there might be a bigger intersection between Esteban, Nicolas and me (web stack wise). :)

Feb. 28, 2012

Re: [Pharo-project] It would be me first

by Norbert Hartl

Am 28.02.2012 um 21:01 schrieb StÃ©phane Ducasse: > I would love to get some presentations for our cool forthcoming conference: if you see what I want to say norbert :) Yes, I know :) I promised it to you, didn't I? I can do two as well. I could repeat my FOSDEM presentation on REST services with Seaside-Rest in concerto with using Magritte3 for content handling in XML and Json. It is about routing of services, content negation (Accept/Content-Type headers) and meta model assistance. As a second one I could present the mentioned web api tester we are doing. This includes serialization as well with Magritte3 in JSON and BSON, MongoTalk to talk to MongoDB and single page UI with seaside and jquery. If that's not all to similar to what Nicolas is doing. Well, if Esteban is presenting as well there might be a bigger intersection between Esteban, Nicolas and me (web stack wise). :) Norbert > Nicolas will do two I guess > one on riak > one of the application he is developing for a german company. > > Stef > > On Feb 28, 2012, at 10:38 AM, Norbert Hartl wrote: > >> >> Am 28.02.2012 um 10:13 schrieb GÃ¶ran Krampe: >> >>> Hi folks! >>> >>> Nicolas will of course reply - I think he was planning to write a post the other day but might have forgotten - but I can chip in some info: >>> >>> SmalltalkHub has gone through some technical evolution which has taken some time. Especially various persistence schemes were tested and most of them ended up problematic, Nicolas tested a LOT of variations I think. >>> >>> The latest stack looks very promising though - and the reason I can describe it is because I am trying to help out a bit with it - though haven't had much time yet. >>> >>> The client is a full Amber app built with Bootstrap 2 from Twitter. It is very nice looking and responsive. It communicates with the backend using plain jQuery REST. >>> >>> The server side is built with Seaside-REST which then uses a domain model described with Magritte 3 (Nicolas just switched) which is persisted using RiakDocument + Phriak for persistency. An interesting twist here is that Magritte is being used to produce the JSON RiakDocuments to store. >>> >>> End result? A very strong and interesting architecture and the performance looks outstanding so far. Riak also buys us really strong robustness since it has redundancy built in. >>> >>> All questions regarding availability, time schedule etc I will leave for Nicolas to answer. :) >>> >> Sounds good. I work with Seaside-Rest and Magritte3 on a daily base. This time with MongoDB using MongoTalk. So I'm quite confident that the choice of the stack is superb :) I decided to use MongoDB because it did not want to be content agnostic. My client approach however is the opposite using seaside with jquery extension. Using amber with Rest style access is surely the better approach for a site like SmallHub. >> What puzzles me is what RiakDocument is doing in this mix. Is it published somewhere? >> >> Norbert >> >> >> > >

Feb. 28, 2012

[Pharo-project] [update 1.4] #14366

by Marcus Denker

14366 ----- Issue 5418: compressedSourceCodeAt: is not used http://code.google.com/p/pharo/issues/detail?id=5418 Issue 5414: class FormStub is unused and undocumented http://code.google.com/p/pharo/issues/detail?id=5414 Issue 5417: FlatMessageListBrowser error on method removal http://code.google.com/p/pharo/issues/detail?id=5417 Issue 5160: sourceCodeAt: vs. sourceMethodAt: http://code.google.com/p/pharo/issues/detail?id=5160 -- Marcus Denker -- http://marcusdenker.de

Feb. 28, 2012

Re: [Pharo-project] It would be me first

by StÃ©phane Ducasse

I would love to get some presentations for our cool forthcoming conference: if you see what I want to say norbert :) Nicolas will do two I guess one on riak one of the application he is developing for a german company. Stef On Feb 28, 2012, at 10:38 AM, Norbert Hartl wrote: > > Am 28.02.2012 um 10:13 schrieb GÃ¶ran Krampe: > >> Hi folks! >> >> Nicolas will of course reply - I think he was planning to write a post the other day but might have forgotten - but I can chip in some info: >> >> SmalltalkHub has gone through some technical evolution which has taken some time. Especially various persistence schemes were tested and most of them ended up problematic, Nicolas tested a LOT of variations I think. >> >> The latest stack looks very promising though - and the reason I can describe it is because I am trying to help out a bit with it - though haven't had much time yet. >> >> The client is a full Amber app built with Bootstrap 2 from Twitter. It is very nice looking and responsive. It communicates with the backend using plain jQuery REST. >> >> The server side is built with Seaside-REST which then uses a domain model described with Magritte 3 (Nicolas just switched) which is persisted using RiakDocument + Phriak for persistency. An interesting twist here is that Magritte is being used to produce the JSON RiakDocuments to store. >> >> End result? A very strong and interesting architecture and the performance looks outstanding so far. Riak also buys us really strong robustness since it has redundancy built in. >> >> All questions regarding availability, time schedule etc I will leave for Nicolas to answer. :) >> > Sounds good. I work with Seaside-Rest and Magritte3 on a daily base. This time with MongoDB using MongoTalk. So I'm quite confident that the choice of the stack is superb :) I decided to use MongoDB because it did not want to be content agnostic. My client approach however is the opposite using seaside with jquery extension. Using amber with Rest style access is surely the better approach for a site like SmallHub. > What puzzles me is what RiakDocument is doing in this mix. Is it published somewhere? > > Norbert > > >

Feb. 28, 2012