- Pharo-dev - lists.pharo.org

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

by Igor Stasenko

On 18 May 2011 09:21, Martin Dias <tinchodias(a)gmail.com> wrote: > > > On Tue, May 17, 2011 at 7:16 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 17 May 2011 22:58, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> > >> > >> > On Tue, May 17, 2011 at 10:31 PM, Sven Van Caekenberghe <sven(a)beta9.be> >> > wrote: >> >> >> >> On 17 May 2011, at 21:57, Mariano Martinez Peck wrote: >> >> >> >> > Sven, I want to make it work :) >> >> > >> >> > so....the missing methods I told you that I need are: >> >> > >> >> > #nextStringPut: >> >> > #nextNumber:put: >> >> > #nextInt32Put: >> >> > #nextWordPut: >> >> >> >> I guess these are pretty easy. But I think they clutter the interface >> >> of >> >> ZnBufferedWriteStream, so maybe you should make a subclass. >> >> >> > >> > Yeah, don't worry. I can even duplicate the class hehehe >> > >> >> >> >> > #contents >> >> > >> >> > Implement #contents I guess it is something like: >> >> > >> >> > ZnBufferedWriteStream >> contents >> >> > ^ stream contents >> >> >> >> Why to you need #contents ? >> > >> > becasue I am an idiot. No, I don't need it. You are correct. Thanks for >> > asking. >> > >> >> >> >> I would say that it goes a bit against the concept of a stream as a >> >> sink >> >> of data. >> >> I haven't looked, but I would guess that saying #contents to a >> >> FileStream >> >> is not efficient. >> >> >> >> > Those missing methods I need are implemented PositionableStream. I >> >> > took >> >> > the implementation from there and Â put it in ZnBufferedWriteStream. >> >> > I just added to them a first line " Â Â self flushBufferIfFull." >> >> >> >> That is probably OK, except when your string becomes larger than the >> >> buffer. Have a look at #nextPutAll: >> >> >> > >> > I am not sure if I understood. The following are correct for sure then: >> > Â #nextNumber:put: >> > Â #nextInt32Put: >> > Â #nextWordPut: >> > >> > >> > And #nextStringPut:Â Â is like this: >> > >> > nextStringPut: s >> > Â Â Â "Append the string, s, to the receiver.Â Only used by DataStream. >> > Max >> > size of 64*256*256*256." >> > >> > Â Â Â | length | >> > Â Â Â self flushBufferIfFull. >> > Â Â Â (length := s size) < 192 >> > Â Â Â Â Â Â ifTrue: [self nextPut: length] >> > Â Â Â Â Â Â ifFalse: >> > Â Â Â Â Â Â Â Â Â [self nextPut: (length digitAt: 4)+192. >> > Â Â Â Â Â Â Â Â Â self nextPut: (length digitAt: 3). >> > Â Â Â Â Â Â Â Â Â self nextPut: (length digitAt: 2). >> > Â Â Â Â Â Â Â Â Â self nextPut: (length digitAt: 1)]. >> > Â Â Â self nextPutAll: s asByteArray. >> > Â Â Â ^s >> > >> >> Sorry, but i can't resist commenting on that. >> Why, if you demand from stream to implement #nextInt32Put: >> a the same time, you writing code like this >> >> self nextPut: (length digitAt: 4)+192. >> Â Â Â Â Â Â self nextPut: (length digitAt: 3). >> Â Â Â Â Â Â self nextPut: (length digitAt: 2). >> Â Â Â Â Â Â self nextPut: (length digitAt: 1) >> >> ? >> Then just extend your serializer with a notion of 'length' field, >> which you can use for anything where you need to encode length/size value, >> but not just for Strings. >> So, then the above method could be as short as: >> >> nextStringPut: s >> Â self putLength: s size. >> Â self nexPutAll: s asByteArray. >> >> and here you have a potential caveat because your string could be >> WideString .. muhahaha. >> >> So, i suggest you to reconsider the way how you serializing strings. >> Instead what you could do is to extend ByteString and WideString (and >> perhaps similarily do for ByteSymbol and WideSymbol), >> the methods which is responsible to turning a receiver in a sequence >> of bytes, and then simply put it into output stream, >> whatever it might be. >> >> Then you don't need #nextStringPut: because its >> a) not polymorphic, because apparently serializing ByteString should >> be different from serializing WideString >> b) instead you implementing this in >> Byte/WideString>>serializeToFuelStream: aStream and you done. > > Yes, I am not sure if #nextStringPut: is not polymorphic, but I think that > with #serializeToFuelStream: we can avoid converting the WideString to > ByteArray just to write the ByteArray to the stream, and instead just write > the WideString to the stream. Right? > > I'm not sure how you doing that, but i think you could just implement Object>>serializeToFuelStream: where you can handle everything, without bothering implementing separate specific methods for ByteString or WideString. You can just implement a generic serializer which serializing object according to its format (variable bytes, variable pointers or variable words etc). -- Best regards, Igor Stasenko AKA sig.

May 18, 2011

Re: [Pharo-project] A lil simplification of MorphTreeNodeMorph

by Tudor Girba

Hi, On 18 May 2011, at 17:53, Igor Stasenko wrote: > On 18 May 2011 17:43, Tudor Girba <tudor.girba(a)gmail.com> wrote: >> Hi, >> >> On 18 May 2011, at 17:28, Igor Stasenko wrote: >> >>> On 18 May 2011 17:15, Tudor Girba <tudor.girba(a)gmail.com> wrote: >>>> I just tried to load Glamorous Toolkit and run "GTCoder open" in a Pharo 1.3 and the tree does not fill the space horizontally. This prompted my mail. >>>> >>> >>> We just checked it with Marcus, and yes, this stuff are already >>> integrated into 1.3. >>> >>> About bugs you mentioning, it is hard to say. I remember there was a >>> little piece of code which i forced to remove because it worked well >>> in 1.2 images >>> but caused complete layout mess in 1.3. >>> Maybe it is because of it. >>> >>> Can you send a screenshot? >> >> I attached the screenshot here. >> > Okay.. looks not very good :) > Can you give a description (or screenshot) of appearance which you > expected to see. The rows with text with a gray background should span the entire horizontal space. Actually, the reason why there is the gray background is to reveal the bounds of the morphs for debugging :). Also the text morphs that are the children of the gray root items should also span the horizontal space (now you see from the border that it has a very small extent) Cheers, Doru > The problem with these things, that it is hard to make it fit for > every possible use of different kinds of layout. > Mainly i was making sure that Settings and other treemorph examples in > 1.3 are looking ok. > >> To reproduce it: >> 1. Download the Glamorous Toolkit based on Pharo 1.3 #13204 >> http://ci.moosetechnology.org/job/glamorous-toolkit-latest-dev/lastSuccessf… >> 2. Run >> GTCoder open >> > > Thanks, Doru i will check it. > >> Cheers, >> Doru >> > > > -- > Best regards, > Igor Stasenko AKA sig. > -- www.tudorgirba.com "Value is always contextual."

May 18, 2011

Re: [Pharo-project] A lil simplification of MorphTreeNodeMorph

by Igor Stasenko

On 18 May 2011 17:43, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Hi, > > On 18 May 2011, at 17:28, Igor Stasenko wrote: > >> On 18 May 2011 17:15, Tudor Girba <tudor.girba(a)gmail.com> wrote: >>> I just tried to load Glamorous Toolkit and run "GTCoder open" in a Pharo 1.3 and the tree does not fill the space horizontally. This prompted my mail. >>> >> >> We just checked it with Marcus, and yes, this stuff are already >> integrated into 1.3. >> >> About bugs you mentioning, it is hard to say. I remember there was a >> little piece of code which i forced to remove because it worked well >> in 1.2 images >> but caused complete layout mess in 1.3. >> Maybe it is because of it. >> >> Can you send a screenshot? > > I attached the screenshot here. > Okay.. looks not very good :) Can you give a description (or screenshot) of appearance which you expected to see. The problem with these things, that it is hard to make it fit for every possible use of different kinds of layout. Mainly i was making sure that Settings and other treemorph examples in 1.3 are looking ok. > To reproduce it: > 1. Download the Glamorous Toolkit based on Pharo 1.3 #13204 > http://ci.moosetechnology.org/job/glamorous-toolkit-latest-dev/lastSuccessf… > 2. Run > GTCoder open > Thanks, Doru i will check it. > Cheers, > Doru > -- Best regards, Igor Stasenko AKA sig.

May 18, 2011

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

by Dale Henrichs

On May 18, 2011, at 4:02 AM, Nick Ager wrote: Hi, We are in the process of adding support for deploying GLASS applications into the Cloud Foundry, but I wouldn't mind helping folks who are interested in adding support for other Smalltalks into the Cloud Foundry ... The Cloud Foundry is written largely in ruby, so you'll need to be wearing your ruby dancing shoes:) There certainly a lot of (justified) buzz around CloudFoundry at the moment. Building CloudFoundry infrastructure for Smalltalk deployment would appear to be a great approach - married with a hosting service that provides that infrastructure as a service. Nick <ATT00001..txt> Nick, VMware will/is providing a hosting service based on cloud foundry, but there is an open source variant of cloud foundry that can be used by others to provide hosting services ... Dale

May 18, 2011

Re: [Pharo-project] Branded Cog for Win32 for Build slave (Was: [TODO] 1.3)

by Igor Stasenko

On 18 May 2011 14:14, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On May 18, 2011, at 10:44 AM, Torsten Bergmann wrote: > >>> provide a "Pharo Cog $VersionNumber" vm. >>> >>> The good news is that we now have a window build slave, so we will soon have >all 3 major architectures covered >> >> Nice - the windows build slave arrived! Who maintains it? >> > The server is maintained by INRIA it services... the build infrastructure by Igor and the rest who has > access (i.e. me, but I stopped using windows *before* win95 was released...) > Yes, it would be me who will set up Hudson slave on windows. The delay with Windows, was that we had they already installed, but it was french version, and then we asked to install english version instead, because i'm not too good in french and moreover, since we want a community to participate in future, apparently we don't like to introduce an unnecessary language barrier to those who not knowing french :) >> So I expect the build slave to >> 1. get the code from Eliots svn repository >> 2. patch the code to "brand" the vm with custom Pharo icon and label >> 3. Replace the name of the VM to build in the Makefile >> 4. build it for use in OneClick or installer or to provide a zip >> > > yes. > > Â Â Â Â Marcus > > -- > Marcus Denker Â -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > -- Best regards, Igor Stasenko AKA sig.

May 18, 2011

Re: [Pharo-project] A lil simplification of MorphTreeNodeMorph

by Tudor Girba

Hi, On 18 May 2011, at 17:28, Igor Stasenko wrote: > On 18 May 2011 17:15, Tudor Girba <tudor.girba(a)gmail.com> wrote: >> I just tried to load Glamorous Toolkit and run "GTCoder open" in a Pharo 1.3 and the tree does not fill the space horizontally. This prompted my mail. >> > > We just checked it with Marcus, and yes, this stuff are already > integrated into 1.3. > > About bugs you mentioning, it is hard to say. I remember there was a > little piece of code which i forced to remove because it worked well > in 1.2 images > but caused complete layout mess in 1.3. > Maybe it is because of it. > > Can you send a screenshot? I attached the screenshot here. To reproduce it: 1. Download the Glamorous Toolkit based on Pharo 1.3 #13204 http://ci.moosetechnology.org/job/glamorous-toolkit-latest-dev/lastSuccessf… 2. Run GTCoder open Cheers, Doru > >> Cheers, >> Doru >> >> > > -- > Best regards, > Igor Stasenko AKA sig. > -- www.tudorgirba.com "One cannot do more than one can do."

May 18, 2011

Re: [Pharo-project] Circle is gone

by Igor Stasenko

There is an EllipseMorph and CircleMorph. Also, if you wanna draw circles directly using canvas you can use #fillOval: fillStyle: borderWidth: borderColor: message sent to canvas. On 18 May 2011 17:04, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Wed, May 18, 2011 at 4:59 PM, Tudor Girba <tudor.girba(a)gmail.com> wrote: >> Hmm, I did not see the discussion. > > Can't find any thread or issue about it. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > -- Best regards, Igor Stasenko AKA sig.

May 18, 2011

Re: [Pharo-project] [Vm-dev] Re: out of memory - cog on windows

by Igor Stasenko

On 18 May 2011 17:08, Tudor Girba <tudor.girba(a)gmail.com> wrote: > > Hi, > > On 18 May 2011, at 16:51, Levente Uzonyi wrote: > >> On Wed, 18 May 2011, Tudor Girba wrote: >> >>> >>> Hi, >>> >>> On 18 May 2011, at 16:30, Levente Uzonyi wrote: >>> >>>> On Wed, 18 May 2011, Tudor Girba wrote: >>>> >>>>> >>>>> Hi, >>>>> >>>>> Is there a possibility to have any sort of answer on this topic? >>>>> >>>>> It looks to me like this bug is critical given that it prevents us to work with images larger than some 200M. >>>> >>>> IMHO it's a problem on the image side. Change the behavior of #lowSpaceWatcher to fix the problem. >>> >>> How would you do it? :) >> >> According to Igor's mail, the UI process is suspended by the low space watcher, which prevents you from seeing the cause of the problem. So, for example you could wake up the UI process if that was suspended by the VM and/or log some info about the situation. This won't save your image, but since it works on non-windows VMs, that's not a problem. > > Thanks for the reply. Unfortunately, I do not know how to do that. > > Furthermore, it's not about one image. These images are produced automatically several times per day, and people want to be able to download them and play with the data inside. > > And again, having a 200M image cannot be so unusual. I tried in multiple situations to simply generate a large enough image and it won't open. > >>> And if it is an image problem, why does it only appear on Windows? >> >> Are you using the same VMs (interpreter/cog, version number matches, etc)? If you didn't try so far, then open the image with the latest interpreter VM on windows, it has some extra checks for allocations which is not implemented in Cog yet. > > I tried with several versions of Cog including the latest ones (on both platforms) and I got the same result. I did not try with an interpreter VM because I only have Cog images around (based on Pharo 1.2) and they are not compatible. > @Eliot, can you comment or recommend something concerning this issue? > Cheers, > Doru > -- Best regards, Igor Stasenko AKA sig.

May 18, 2011

Re: [Pharo-project] A lil simplification of MorphTreeNodeMorph

by Igor Stasenko

On 18 May 2011 17:15, Tudor Girba <tudor.girba(a)gmail.com> wrote: > I just tried to load Glamorous Toolkit and run "GTCoder open" in a Pharo 1.3 and the tree does not fill the space horizontally. This prompted my mail. > We just checked it with Marcus, and yes, this stuff are already integrated into 1.3. About bugs you mentioning, it is hard to say. I remember there was a little piece of code which i forced to remove because it worked well in 1.2 images but caused complete layout mess in 1.3. Maybe it is because of it. Can you send a screenshot? > Cheers, > Doru > > -- Best regards, Igor Stasenko AKA sig.

May 18, 2011

Re: [Pharo-project] A lil simplification of MorphTreeNodeMorph

by Tudor Girba

I just tried to load Glamorous Toolkit and run "GTCoder open" in a Pharo 1.3 and the tree does not fill the space horizontally. This prompted my mail. Cheers, Doru On 18 May 2011, at 17:10, Igor Stasenko wrote: > On 18 May 2011 14:14, Tudor Girba <tudor.girba(a)gmail.com> wrote: >> Hi, >> >> In this thread, there were several cs proposed. I thought they were integrated in 1.3, but they do not seem to be there. >> >> I was so looking forward to using them :). Igor, could you take a look? >> > > hmm.. strange.. i thought we are integrated it. > >> Cheers, >> Doru >> >> > > -- > Best regards, > Igor Stasenko AKA sig. > -- www.tudorgirba.com "To lead is not to demand things, it is to make them happen."

May 18, 2011