May 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Basic tricks for improving a serializer?

by Mariano Martinez Peck

On Tue, May 17, 2011 at 3:34 PM, Sven Van Caekenberghe <sven(a)beta9.be>wrote: > Mariano, > > On 17 May 2011, at 15:21, Mariano Martinez Peck wrote: > > > Now Igor told us for example, to use a buffer like this: > > > > | bufferStream | > > bufferStream := ByteArray new writeStream. > > > > (FLSerializer on: bufferStream) > > serialize: anArrayToSerialize. > > > > aFileStream nextPutAll: bufferStream contents. > > > > and that it at least 2 times faster than we were doing.... I guess it is > because it goes to the disk only once. But MultiByteFileStream uses a > buffer, doesn't it ? > > The disadvantage of the above is that you buffer everything before you > write. Furthermore you are growing the buffer all the time (recopying > contents) which is not too efficient. > > Some time ago we had a discussion about this and then I implemented > ZnBufferedWriteStream (it should be in Core 1.3), have a look. It was just a > quick hack, but it worked in speeding up writing. > > Thanks Sven, what a great point you gave me. I tried it a little and I found a couple of methods missing which I used to use for a normal WriteStream. I will play a little more when I have time and I will ask you again!! -- Mariano http://marianopeck.wordpress.com

May 17, 2011

Re: [Pharo-project] Basic tricks for improving a serializer?

by Mariano Martinez Peck

On Tue, May 17, 2011 at 3:51 PM, <csrabak(a)bol.com.br> wrote: > Mariano, > > It is early in the morning right here and I might have read too hastily to > your post, but from the diagonal reading I gave it seems you're going > quickly to reinvent the wheel! > > Hi. Good evenening. In fact, we are not reinventing the whele. As I said, Fuel takes the concepts of Parcels. > Those issues you rise are typical of database (engine) programming. Database programming are just ONE usage of serializacion. But there are much more: - persistance. - session management in a webframework. - remote messages and whatever remote. - code versioning In summary, whenever you need to take a subgraph and get a chunk of bytes from it and vice-versa. Also, IIRC Smalltalk has another approach to persistence of objects called > BOSS, have you given a look at it and check if a mix of Fuel + BOSS would > accomplish your intent? > Yes. It is in VW. I promise we have analyzed all serializers available: Magma serializer, MC2 serializer, BOSS, ReferenceStream, ImageSegment, etc. Some of them, like BOSS focus on portability. I don't care at all in portability. Some other do not even support class reshape or they are too slow. If it works in other dialects, perfect. But I won't loose performance just because of that. The main focus of Fuel is to be FAST. And even more, be fast at deserializacion time (like Parcels). The idea is that at serializacion time you can do some calculus and groups objects some way so that the deserializacion is really fast. > > -- > Cesar Rabak > > > Em 17/05/2011 10:21, Mariano Martinez Peck < marianopeck(a)gmail.com > > escreveu: > Hi guys. Together with Martin we are developing a fast object graph > serializer called Fuel. The idea is to use a pickle format similar to VW > Parcels. Right now we are able to correctly serialize (almost) all kind of > objects (from different classes and so on). The algorithm is working quite > well and we are already quite fast. We also know how to encode more or less > efficient some of the "primitive" classes like Floats, SmallIntegers, > ByteString, ByteArray, etc, etc. > > What we really don't know anything about streams. For example, until now, > we were using just a MultiByteFileStream and doing all the time things like > #next: #nextPutAll: #nextWordPut: etc... > > Now Igor told us for example, to use a buffer like this: > > | bufferStream | > bufferStream := ByteArray new writeStream. > > (FLSerializer on: bufferStream) > serialize: anArrayToSerialize. > > aFileStream nextPutAll: bufferStream contents. > > and that it at least 2 times faster than we were doing.... I guess it is > because it goes to the disk only once. But MultiByteFileStream uses a > buffer, doesn't it ? > > For reading (deserialization) we are not doing nothing special. We just > open the file stream and we read with #next #nextString ... etc. > > Another thing is which kind of file stream should we use. > MultiByteFileStream ? StandardFileStream ? > > So...before spending time in some optimizations, are there "known" things > that we should check? > > Thanks in advance, > > > -- > Mariano > http://marianopeck.wordpress.com > > > > -- Mariano http://marianopeck.wordpress.com

May 17, 2011

Re: [Pharo-project] Filesystem-cwp.120 is broken

by StÃ©phane Ducasse

I have to check if we update the configurationOfFS. Now I should say that I lost energy in the FS story so we will see how we sort that out. Stef On May 17, 2011, at 5:15 PM, Esteban Lorenzano wrote: > ouch! :) > > El 17/05/2011, a las 9:47a.m., Lukas Renggli escribiÃ³: > >>> I just downloaded Filesystem-cwp.120... it is empty, and that makes ConfigurationOfFilesystem to not load correctly. >> >> If you read the comment of Filesystem-cwp.120 you see that this is >> intentional. The package was split quite some time ago into various >> independent ones. >> >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > >

May 17, 2011

Re: [Pharo-project] Basic tricks for improving a serializer?

by StÃ©phane Ducasse

>> Mariano, >> >> It is early in the morning right here and I might have read too hastily to your post, but from the diagonal reading I gave it seems you're going quickly to reinvent the wheel! >> >> Those issues you rise are typical of database (engine) programming. Also, IIRC Smalltalk has another approach to persistence of objects called BOSS, have you given a look at it and check if a mix of Fuel + BOSS would accomplish your intent? >> > I think its implemented from scratch for one big reason: devil is > always in details. > Object format, streams, protocol and dozen of various things may > differ from one smalltalk dialect to another one. > > Also, i assume most of us are never heard about BOSS. Just googled it > and found couple citations which related to VW world, but not to > Squeak/Pharo. Is it runs on Pharo? What its license? boss is a library in VW. > > But by saying that, i'm a of course in favor of having more and more > cross-dialect solutions. for me larger autonomy. We do not invent by being forced to be compatible. If we are successful people will copy. Stef

May 17, 2011

Re: [Pharo-project] RDF Framework and Pharo

by CÃ©drick BÃ©ler

I try to remove the dependency of VWXML package (which has been replaced with XMLSupport). For that purpose, I had to use Rikaiko.jb.8 instead of Rikaiko.jb.10 wich is empty for me... I don't think it works (it was a work under progress in 2006 so...) but at least, it should load and it may help you. I attached the .mcz. It also generated a XML package as a dependancy but this is only XML-Support so you don't need to load it I guess... hth, CÃ©drick > This is quite old. > You should ask Julien Bourdon (in CC), one of my former student who do > this work. > > Regards, > > On Tue, May 17, 2011 at 12:50 AM, Laszlo Zsolt Kiss <lzskiss(a)dublin.ie> wrote: >> Aloha. >> The status: I can't install it. >> The short story: >> 1., >> I installed XMLSupport , >> 2, >> Next probally install VWXML package , the VWXML package didn't finding the >> XML package ahah, Great. >> Rikaiko using the VWXML parser, this is the only dependencies. >> What is the next good step?:) >> Best regards >> Laszlo Zsolt Kiss >> >> ----- Original Message ----- >> From: >> "Mariano Martinez Peck" <marianopeck(a)gmail.com> >> To: >> <Pharo-project(a)lists.gforge.inriafr>, "Laszlo Zsolt Kiss" >> <lzskiss(a)dublin.ie> >> Cc: >> Sent: >> Mon, 16 May 2011 19:32:47 +0200 >> Subject: >> Re: [Pharo-project] RDF Framework and Pharo >> >> >> Hello. http://www.squeaksource.com/Rikaiko.html >> >> But I have no idea of the status... >> >> mariano >> >> On Mon, May 16, 2011 at 7:12 PM, Laszlo Zsolt Kiss <lzskiss(a)dublin.ie> >> wrote: >>> >>> Hello. >>> How can I using Rikaiko RDF framework with Pharo 1.2 or 1.3? >>> Anybody working with this stuff? >>> Best regards >>> Laszlo Zsolt Kiss >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > > > > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ >

May 17, 2011

Re: [Pharo-project] [Esug-list] [ANN] SmallHarbour project

by laurent laffont

On Tue, May 17, 2011 at 5:29 PM, Bernat Romagosa < tibabenfortlapalanca(a)gmail.com> wrote: > Just a short question, will there be support for other frameworks besides > seaside? > Yes, that's why we haven't called it SeasideSomething. We want the project to be open and support several web frameworks. We will start with Seaside though. Laurent. > > 2011/5/17 Romain Verduci <contact(a)romain-verduci.com> > >> We actually have www.seasidehosting.st which can only be used for >> non-commercial applications. >> >> I am Romain Verduci, a french student in Information System (Master >> degree) who likes smalltalk since I have discovered it last year through >> Pharo. >> Today, I participate to weekly coding-dojos with other smalltalk fans ( >> http://cara74.seasidehosting.st/) >> I am lucky to participate to ESUG SummerTalk this year with Laurent >> Laffont as mentor to develop SmallHarbour project. >> >> With the support of ESUG and under the ESUG SummerTalk 2011, we want to >> provide: >> - a simple platform to host commercial smalltalk web applications. >> - an easy way for everyone (and enterprise) to deploy their own hosting >> platform. >> - for the non-smalltalkers, provide ready Pier images to deploy basic >> blogs, event presentations and more. >> >> SmallHarbour has started from the actual Seaside Hosting code base. Our >> first objective is to port it to Pharo / Cog / Seaside 3 and document. >> >> For more informations about the project, you can follow us on >> www.smallharbour.org. >> >> If you have any needs or ideas in order to improve our project vision, we >> will be happy to collect them. We will setup community tools (issue tracker, >> public repositories, doc ....) when the exams period is over :) >> >> Best regards >> >> >> >> Romain Verduci >> Student in Information System (Master degree) - IMUS, IAE Savoie >> Mont-Blanc - Annecy >> >> Tel. : +33659892353 >> Mail : contact(a)romain-verduci.com >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> Esug-list mailing list >> Esug-list(a)lists.esug.org >> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >> >> > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > >

May 17, 2011

Re: [Pharo-project] [Esug-list] [ANN] SmallHarbour project

by Bernat Romagosa

Just a short question, will there be support for other frameworks besides seaside? 2011/5/17 Romain Verduci <contact(a)romain-verduci.com> > We actually have www.seasidehosting.st which can only be used for > non-commercial applications. > > I am Romain Verduci, a french student in Information System (Master degree) > who likes smalltalk since I have discovered it last year through Pharo. > Today, I participate to weekly coding-dojos with other smalltalk fans ( > http://cara74.seasidehosting.st/) > I am lucky to participate to ESUG SummerTalk this year with Laurent Laffont > as mentor to develop SmallHarbour project. > > With the support of ESUG and under the ESUG SummerTalk 2011, we want to > provide: > - a simple platform to host commercial smalltalk web applications. > - an easy way for everyone (and enterprise) to deploy their own hosting > platform. > - for the non-smalltalkers, provide ready Pier images to deploy basic > blogs, event presentations and more. > > SmallHarbour has started from the actual Seaside Hosting code base. Our > first objective is to port it to Pharo / Cog / Seaside 3 and document. > > For more informations about the project, you can follow us on > www.smallharbour.org. > > If you have any needs or ideas in order to improve our project vision, we > will be happy to collect them. We will setup community tools (issue tracker, > public repositories, doc ....) when the exams period is over :) > > Best regards > > > > Romain Verduci > Student in Information System (Master degree) - IMUS, IAE Savoie Mont-Blanc > - Annecy > > Tel. : +33659892353 > Mail : contact(a)romain-verduci.com > > > > > > > > > > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > >

May 17, 2011

[Pharo-project] [ANN] SmallHarbour project

by Romain Verduci

We actually have www.seasidehosting.st which can only be used for non-commercial applications. I am Romain Verduci, a french student in Information System (Master degree) who likes smalltalk since I have discovered it last year through Pharo. Today, I participate to weekly coding-dojos with other smalltalk fans (http://cara74.seasidehosting.st/) I am lucky to participate to ESUG SummerTalk this year with Laurent Laffont as mentor to develop SmallHarbour project. With the support of ESUG and under the ESUG SummerTalk 2011, we want to provide: - a simple platform to host commercial smalltalk web applications. - an easy way for everyone (and enterprise) to deploy their own hosting platform. - for the non-smalltalkers, provide ready Pier images to deploy basic blogs, event presentations and more. SmallHarbour has started from the actual Seaside Hosting code base. Our first objective is to port it to Pharo / Cog / Seaside 3 and document. For more informations about the project, you can follow us on www.smallharbour.org. If you have any needs or ideas in order to improve our project vision, we will be happy to collect them. We will setup community tools (issue tracker, public repositories, doc ....) when the exams period is over :) Best regards Romain Verduci Student in Information System (Master degree) - IMUS, IAE Savoie Mont-Blanc - Annecy Tel. : +33659892353 Mail : contact(a)romain-verduci.com

May 17, 2011

Re: [Pharo-project] Filesystem-cwp.120 is broken

by Esteban Lorenzano

ouch! :) El 17/05/2011, a las 9:47a.m., Lukas Renggli escribiÃ³: >> I just downloaded Filesystem-cwp.120... it is empty, and that makes ConfigurationOfFilesystem to not load correctly. > > If you read the comment of Filesystem-cwp.120 you see that this is > intentional. The package was split quite some time ago into various > independent ones. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

May 17, 2011

[Pharo-project] Should we flag this as inconsistency? (using thisContext)

by Igor Stasenko

Consider following: case a) | a b | a := thisContext. [ b := thisContext ] value. a == b case b) | a b | a := thisContext. true ifTrue [ b := thisContext ]. a == b what you think, should those two cases evaluate to same value? not really matter if true or false (i prefer false, or course ;), but what matters is t hat if case a) evaluating to true, then case b) should also evaluate to true and if a) is false, then b) should be false as well. (The potential fix is to never inline blocks who referencing to thisContext variable). -- Best regards, Igor Stasenko AKA sig.

May 17, 2011