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

Re: [Pharo-project] Decompiler problem (leading to infinite loop of opening debuggers)

by Nicolas Cellier

2011/5/18 Toon Verwaest <toon.verwaest(a)gmail.com>: > On 05/18/2011 01:30 PM, Marcus Denker wrote: >> >> On May 18, 2011, at 1:26 PM, Toon Verwaest wrote: >> >>> I haven't figured out the exact decompiler bug yet, but just so you can >>> easily fix your problem: >>> >> I tested on 1.3, and it's fixed there... we synced in 1.3 with some fixes >> from the old compiler. >> >> We could backport the compiler fixes to 1.2... > > Oh ok, then I don't even look further. But that decompiler is a mess ... > moving to OPAL would be a great improvement I'd say ... Yes this code is very hard to track by just reading code... So hard to maintain too. Too many states in a single class. And you often discover that the processing you were looking for in fact was coded somewhere else (like in MessageNode). The best way to understand the old Decompiler is to debugIt. Nicolas >>> >>> just move the temp in the whileFalse: [ |newReqd| to the toplevel of the >>> method (if this is semantically equivalent; but it looks like). >>> Then it can actually decompile it ;) >>> >>> cheers, >>> Toon >>> >>> On 05/18/2011 12:16 PM, Johan Brichau wrote: >>>> >>>> Â (MetacelloMCVersionSpec compiledMethodAt: #resolveToLoadableSpecs:map:) >>>> decompileWithTemps >>> >> -- >> Marcus Denker Â -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> > > >

May 18, 2011

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

by Igor Stasenko

On 18 May 2011 17:57, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Hi, > > > 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) > Now i'd like to ask you , if this is a general requirement for all morphs placed in treemorph node? Or it should be controlled by morph which you placing? This should be controlled by #hResizing: , but not all morphs actually honor this. I can mistake, but string morph which is used for labels just paints the string and any extra width is ignored.. It is also, a good question what to do if you have multiple morphs which has #spaceFill placed in a row? Consider following: <column1> | <column2> <m1> <m2 spacefill .......> <m3 spacfill ... > | <mx ... > <my ... > < mz> > Cheers, > Doru > -- Best regards, Igor Stasenko AKA sig.

May 18, 2011

Re: [Pharo-project] Wishes for new ClassBuilder (toon?)

by Toon Verwaest

The PlayOut classbuilder indeed separates this nicely. We have the distinction between the "installer" and the "builder". The builder uses an "installer" as a client and notifies it about stuff that happens. For example we have an "anonymous subclass builder" that's implemented like that. It basically just ignores most of the notifications of the builder since it doesn't really do anything. ... but of course this means that you need PlayOut ;) You can get an image at http://pinocchio.unibe.ch/~tverwaes/PlayOut.tar.gz caveats: - At the moment that system doesn't validate everything yet like the old classbuilder (since I wanted to freely change classes with any name) - it doesn't handle obsolete subclasses yet. Oh well ;) - it's still intertwined with our slots implementation, so it relies on Helvetia. But that can/should/will be fixed without changing the API. cheers, Toon On 05/18/2011 03:18 PM, Mariano Martinez Peck wrote: > Hi guys. As part of the Fuel project, one of the things we want to do > (in fact, it is done) is to serialize classes. There want to have 3 > possibilities: > 1) Do something like DiskProxy where you only save its global name and > some selector to run when deserialing it > 2) Really searialize the whole class (following method dictionary, > compiled methods, class pools and friend, etc) so that you can > deserialize it in another image where such class is not present. > 3) Do the same as 2 but validating and installing the class in the system. > > For 2) what we want to do is just to serialize the class as any other > object. As a result, we get a Class instance. Nothing is validated, > nothing is added in Smalltalk globals, nothing is compiled. We do not > use ClassBuilder at all. > > For 3) we want to do 2) plus validating and installing the class in > the system. For validating I mean ALL the validations that the class > builder does when creating or modifying a class. And for "installing > in the system" I mean notify, put in Smalltalk globals, re compile > what is needed, etc... > > ClassBuilder seems to do 2) and 3) together. So, what I would love to > have in a new class builder is to have those two things separated. So > that I can say to an object ClassManager validate: aClass or > ClassManager installClassOnSystem: aClass. > > Do you think such thing is possible? Right now going through > ClassBuilder and understand all the validations it does is really > complicated :( > > Thanks in advance, > > -- > Mariano > http://marianopeck.wordpress.com >

May 18, 2011

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

by Levente Uzonyi

On Wed, 18 May 2011, Tudor Girba wrote: snip > > 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. You can use this interpreter vm to open cog images: http://leves.web.elte.hu/squeak/SqueakVM-Win32-4.4.9-2358-non-official-bin.… Levente snip

May 18, 2011

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