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

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

by Tudor Girba

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? Cheers, Doru On 6 Apr 2011, at 13:43, Igor Stasenko wrote: > Okay, here the updated version. > > > GTCoder open > looks fine > > Settings look fine. > and > > SimpleGridExample new open > looking fine as well > > -- > Best regards, > Igor Stasenko AKA sig. > <theTreee.8.cs> -- www.tudorgirba.com "Be rather willing to give than demanding to get."

May 18, 2011

[Pharo-project] [Hudson] Filesystem testrunner

by Marcus Denker

https://pharo-ic.lille.inria.fr/hudson/job/Filesystem/ 1.3, rebuild after every core update. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 18, 2011

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

by Johan Brichau

thanks guys! I didn't test in 1.3 indeed. btw, since moving to 1.2, after doing pullup or pushdown refactorings, I often get methods that badly reference instance variables. Their instvar index seems to be off in the sense that the name references another variable. I can fix the problem by recompiling the method but it's quite a pain. Unfortunately, I have been unsuccessful in creating a scenario that always works... I hope to do that asap.

May 18, 2011

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

by Marcus Denker

On May 18, 2011, at 1:32 PM, Toon Verwaest wrote: > 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 ... :-) -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 18, 2011

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

by Norbert Hartl

Am 18.05.2011 um 13:15 schrieb Sean Allen: > > 11) We currently require infrastructure support for https eg stunnel or reverse proxy through a webserver eg http://www.monkeysnatchbanana.com/posts/2010/06/23/reverse-proxying-to-seas… > > actually that link is... http://www.monkeysnatchbanana.com/posts/2010/06/22/faking-a-https-client-fo… > just for posterity. > Just for the record. I used stunnel for a short while. But then the need for the use of client certificates arose (I'm implementing an apple push notification server). A very easy way to add SSL handling is to write a little server in node.js [1]. It supports SSL and client certificates out of the box. It could act as an intelligent proxy for SSL handling. If the use cases are known I could even provide a small node proxy. It is written in javascript and might be interesting for some to learn javascript on the server side. Node.js btw. is a cool server to know :) Norbert [1] http://nodejs.org/

May 18, 2011

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

by Toon Verwaest

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 ... >> 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] Decompiler problem (leading to infinite loop of opening debuggers)

by Marcus Denker

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... > 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] Basic tricks for improving a serializer?

by Mariano Martinez Peck

On Wed, May 18, 2011 at 1:03 PM, Henrik Sperre Johansen < henrik.s.johansen(a)veloxit.no> wrote: > On 18.05.2011 09:21, Martin Dias 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? > > You don't ever need the asByteArray call to store ByteStrings if you use > nextPutAll: on a default stream in binary mode, the primitive handles that > just fine for variableByte subclasses. > > If you are doing the same as DataStream, only ByteStrings are written using > nextStringPut: , WideStrings are stored with the default writeWordLike: > facilities. > > Is there a document describing the binary format of Fuel somewhere? > Hi Henry. When I sent this email, I was thinking in you :) Depends what you mean by binary format ;) How the whole subgraph is encoded (the order, the references, indexes, etc) is quite hard to follow. This is because of the pickle format. But I guess that if you check this slides: http://rmod.lille.inria.fr/web/pier/software/Fuel you will get it. That being said, to see how Fuel serialize or deserialize a particular class is really easy. Every class has a Fuel extension method called #fuelSerializer that answers the class to serialize/des it. So the easiest way is to check for #fuelSerializer implementors and then map to its serializer class. The relation is not 1 to 1. To load it: Gofer it squeaksource: 'Fuel'; package: 'ConfigurationOfFuel'; load. ((Smalltalk at: #ConfigurationOfFuel) project version: '1.2-baseline') load. If you play with something and you want to run benchmarks, just open a Transcript and evaluate: FLBenchmarks newFullFuelOnly run Thanks Henry for any review you can do. -- Mariano http://marianopeck.wordpress.com

May 18, 2011

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

by Toon Verwaest

I haven't figured out the exact decompiler bug yet, but just so you can easily fix your problem: 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

May 18, 2011

[Pharo-project] The Cult of Done Manifesto

by Marcus Denker

The Cult of Done Manifesto - There are three states of being. Not knowing, action and completion. - Accept that everything is a draft. It helps to get it done. - There is no editing stage. - Pretending you know what you're doing is almost the same as knowing what you are doing, so just accept that you know what you're doing even if you don't and do it. - Banish procrastination. If you wait more than a week to get an idea done, abandon it. - The point of being done is not to finish but to get other things done. - Once you're done you can throw it away. - Laugh at perfection. It's boring and keeps you from being done. - People without dirty hands are wrong. Doing something makes you right. - Failure counts as done. So do mistakes. - Destruction is a variant of done. - If you have an idea and publish it on the internet, that counts as a ghost of done. - Done is the engine of more. http://www.brepettis.com/blog/2009/3/3/the-cult-of-done-manifesto.html?v=1 -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 18, 2011