January 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Putting source code in method trailer [WAS] Re: Speeding up Finder string search

by Stefan Marr

On 17 Jan 2012, at 22:40, Mariano Martinez Peck wrote: > 1) From a design point of view, I think that CompiledMethodTrailer is the correct place where source code should be stored. Why? >From my point of view, the source fits into the image, but does not belong into the CompiledMethod. CompiledMethod is the representation for execution purpose. Encoding it into the bytearray along the the bytecode just asks for trouble. CompiledMethod should have a counter part, which can also carry all kind of other meta data. I bet there is something in the ring framework to represent methods that is not based on CompiledMethod. That is where I would put the code. > 3) I think (I should measure it) that having source code in the image is faster, even thought that's the least I care about. The finder is obviously faster... Other tools wont benefit as much, because the cost of reading a single method is insignificant. Refactorings which might need to read code, or recompile everything might benefit. > 4) Ease the logic of pointers in the trailer... > 5) Easy of versioning for a binary serializer ;) so for example in Fuel we can now be able to serialize compiled methods with trailer that have the source code. Hence, versioning it (Monticello) is easier. I still do not see why you would want the extra complexity (with encoding and all) to put it into the ByteArray of compiled method. That makes everything harder, and one argument you might want to use, no, it does not guarantee consistency between the two parts. Putting the code into the image, yes, but not into the compiled method. At least I do not see any clear benefits. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Jan. 17, 2012

Re: [Pharo-project] First steps making OB work in 1.4

by Mariano Martinez Peck

On Tue, Jan 17, 2012 at 6:46 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > On Tue, Jan 17, 2012 at 2:31 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > >> Please note that this configuration loads completely outdated code > > from last summer. >> > > Haha, well... So far, that configuration is stable, so I'll freeze that > (maybe old but working) version and begin merging the stuff in your repo :). > > +1 Thank you so much for your pushing Guille :) -- Mariano http://marianopeck.wordpress.com

Jan. 17, 2012

Re: [Pharo-project] [Vm-dev] Primitive to set an identityHash

by Mariano Martinez Peck

On Tue, Jan 17, 2012 at 8:04 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > > On Tue, Jan 17, 2012 at 8:43 AM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> >> Hi guys. Becuase of some work I am doing with proxies, I would like to be >> able to set a specific identityHash to a proxy instance. I can add this >> primitive in my VM, but I was thinking if this could be of a general >> interest also? >> > > It already exists. See primitiveSetIdentityHash in InterpreterPrimitives. > Primitive # 161. > Thank you so much Eliot. You even save my time of coding it ;) I should have checked before...I always forget about InterpreterPrimitives hahaha So...Pharaoers... do you want the image side of the primitive and some tests? I can provide that if desired (in my opinion I would include it) Cheers > > >> Cheers >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >> > > > -- > best, > Eliot > > > -- Mariano http://marianopeck.wordpress.com

Jan. 17, 2012

Re: [Pharo-project] Squeaksource Mirror Q&A

by GastÃ³n Dall' Oglio

mmm, in 1.3 its work, I try with the incorrect 1.3 image.... Sorry for the noise. 2012/1/17 GastÃ³n Dall' Oglio <gaston.dalloglio(a)gmail.com> > Hello Johan. > > >> - Pharo 1.4 / ObjectAsMethodWrapper issues: The redirect package was >> written for 1.3, it uses ObjectAsMethodWrapper (i.e. method wrappers). I >> don't know why ObjectAsMethodWrapper (apparently) is no longer in 1.4 but I >> would highly recommend including it as it is a very useful package. I >> thought even the profiler used it. In any case, I welcome any contributions >> on how to make it work for 1.4 >> > > In Pharo-1.3-13315 (stable) haven't ObjectAsMethodWarapper. Then in 1.3 > and 1.4 evaluate this and get mirror working: > > Gofer new > url: 'http://dsal.cl/squeaksource/ObjectsAsMethodsWrap'; > package: 'ObjectAsMethodWrapper'; > url: 'http://dsal.cl/squeaksource/MonticelloRedirect'; > package: 'MontiRedirect'; > load. > > > Maybe you can add this to HOW TO USE in http://dsal.cl/squeaksource > > Regards. >

Jan. 17, 2012

Re: [Pharo-project] latest build yields stack trace running #cleanUpForProduction

by Mariano Martinez Peck

I have already opened an issue several months ago: http://code.google.com/p/pharo/issues/detail?id=5005 I have also made it as much reproducable as I could and I have also asked for help: http://forum.world.st/Help-with-cleanUpForRelease-is-broken-MessageNotUnder… No answers :( Cheers On Tue, Jan 17, 2012 at 10:18 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > Hi Yanni > > open a bug entry. We got some strange behavior with becomeForward: and set > rehash and I wonder if this is not related. > > stef > > On Jan 17, 2012, at 10:03 PM, Yanni Chiu wrote: > > > Using Pharo 1.4 (#220), I end up in: > > ByteSymbol(Object)>>doesNotUnderstand: #run:with:in: > > > > which was called from: > > (MCPackage named: self theScriptLoaderPackageName) unload. > > > > First I thought it was because I had OSProcess loaded when I ran > cleanUpForProduction, and it stopped in an OSProcess class. > > > > Without OSProcess, the I got a slightly different problem: the > doesNotUnderstand of #run:with:in: is due to something in > #cleanUpForRelease. Trying to debug it, new debuggers pop up, and then the > emergency evaluator. > > > > I have Seaside30/Magritte/Pier loaded, so I can try without those too. > But, it used to work with all these things loaded. > > > > -- > > Yanni > > > > > > > -- Mariano http://marianopeck.wordpress.com

Jan. 17, 2012

Re: [Pharo-project] Squeaksource Mirror Q&A

by GastÃ³n Dall' Oglio

Hello Johan. > - Pharo 1.4 / ObjectAsMethodWrapper issues: The redirect package was > written for 1.3, it uses ObjectAsMethodWrapper (i.e. method wrappers). I > don't know why ObjectAsMethodWrapper (apparently) is no longer in 1.4 but I > would highly recommend including it as it is a very useful package. I > thought even the profiler used it. In any case, I welcome any contributions > on how to make it work for 1.4 > In Pharo-1.3-13315 (stable) haven't ObjectAsMethodWarapper. Then in 1.3 and 1.4 evaluate this and get mirror working: Gofer new url: 'http://dsal.cl/squeaksource/ObjectsAsMethodsWrap'; package: 'ObjectAsMethodWrapper'; url: 'http://dsal.cl/squeaksource/MonticelloRedirect'; package: 'MontiRedirect'; load. Maybe you can add this to HOW TO USE in http://dsal.cl/squeaksource Regards.

Jan. 17, 2012

Re: [Pharo-project] Putting source code in method trailer [WAS] Re: Speeding up Finder string search

by Mariano Martinez Peck

> Well, with the following script it seems I am able to embed all source > code in trailers: > > | trailer source key dict classes | > dict := IdentityDictionary new. > CompiledMethod allInstances do: [:aMethod | > trailer := aMethod trailer. > source := aMethod getSource. > trailer sourceCode: source. > dict at: aMethod put: (aMethod copyWithTrailerBytes: trailer). > ]. > dict keys asArray elementsExchangeIdentityWith: dict values asArray. > > > Problem is that after executing the script, when a method is recompiled > from the system browser, it puts back a trailer with a .changes pointer :( > I will see if I find where I can change that. > > In another thread, Stefan Marr asked "Is there any general use for such an embedding, beside making the finder usable?" I would just give my answer: 1) From a design point of view, I think that CompiledMethodTrailer is the correct place where source code should be stored. 2) I can understand to put source code in files would make sense 20 years ago. But I don't think so anymore... a normal notebook has 8gb of RAM these days. 3) I think (I should measure it) that having source code in the image is faster, even thought that's the least I care about. 4) Ease the logic of pointers in the trailer... 5) Easy of versioning for a binary serializer ;) so for example in Fuel we can now be able to serialize compiled methods with trailer that have the source code. Hence, versioning it (Monticello) is easier. So...what I would do (that's just my opinion) is: 1) always store source code in trailer 2) do not use .sources anymore 3) Use .changes ONLY for recovery but not for getting source code (#getSource) 4) Provide a way to shrink an image for production cases where people is interested in image size. Can can very easily replace compiled methods trailers with empty trailers (zap) and then if it just happens that you need the sources..you decompile it. Maybe there are obvious drawbacks I am not seeing... Cheers -- Mariano http://marianopeck.wordpress.com

Jan. 17, 2012

Re: [Pharo-project] Speeding up Finder string search

by Mariano Martinez Peck

On Tue, Jan 17, 2012 at 10:10 PM, Stefan Marr <smalltalk(a)stefan-marr.de>wrote: > And here we go: > > On 17 Jan 2012, at 19:37, Stefan Marr wrote: > > After fixing that, I get these numbers: > > #(102851 10781 10798 9511 10335 9883) > > Not really impressive. > > > > I did not immediately see how to avoid the compression. > > The image size goes currently up by ca. 50%, from 22MB to 31MB. > > #(76700 1787 1793 1768 1741 1748) > > That is space for performance: image size is at 39MB. > > > > > > Not that my version with an extra dictionary is still faster by about 20% > (1.4s vs. 1.7s) since it avoids the decoding from the compiled method. > > Is there any general use for such an embedding, > beside making the finder usable? > I have created a separate thread because under this subject nobody will read it. I will answer there. > > > Best regards > Stefan > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > > -- Mariano http://marianopeck.wordpress.com

Jan. 17, 2012

Re: [Pharo-project] Speeding up Finder string search

by StÃ©phane Ducasse

marcus would love to have all the code in the image. Now we should think about it as a community. Stef On Jan 17, 2012, at 10:10 PM, Stefan Marr wrote: > And here we go: > > On 17 Jan 2012, at 19:37, Stefan Marr wrote: >> After fixing that, I get these numbers: >> #(102851 10781 10798 9511 10335 9883) >> Not really impressive. >> >> I did not immediately see how to avoid the compression. >> The image size goes currently up by ca. 50%, from 22MB to 31MB. > > #(76700 1787 1793 1768 1741 1748) > > That is space for performance: image size is at 39MB. > > > <SourceInMethods.1.cs> > > Not that my version with an extra dictionary is still faster by about 20% (1.4s vs. 1.7s) since it avoids the decoding from the compiled method. > > Is there any general use for such an embedding, > beside making the finder usable? > > > Best regards > Stefan > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 >

Jan. 17, 2012

Re: [Pharo-project] Exception logging

by StÃ©phane Ducasse

On Jan 17, 2012, at 10:07 PM, Nicolas Cellier wrote: > Silly question, but what happens to your newProcess if you don't resume it? > > [Beeper primitiveBeep] newProcess. > > won't beep... But: > > [Beeper primitiveBeep] newProcess resume. > > willâ¦ The problem is that this new process is the only one (yes only one) of a strange image I generated with hazelnuts (I need to get the compiler working so that we even evaluate an expression in this image :). > If you did resume then > - What is OCClosureCompiler? I tried with OPAL because it did not work with the Compiler but since I cannot debug it this is why I open a file and put information inside :) > - Does it generate an exception? no > - Did you try with a regular Compiler? yes but it does not work. in fact I do not understand why yesterday [Compiler evaluate: '1 foooo' ] on: Error do: [:ex | ex inspect] did not work and today it does :) so I guess that I should sleep more. Thanks nicolas I should sleep more and breath deeper :). Stef > With a regular Compiler I clearly here the buzzer. > > Nicolas > > 2012/1/17 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> Thanks guys >> now what is really strange to me is that whe the code does not contain error to make it compile I have to wrap it with on:do: >> Any idea? >> >> >>> and if I wrap the execution with a on: error do: >>> I get >>> Start33 in the file >>> >>> >>> OCClosureCompiler >>> >>> >>> if I remove the on:do: >>> I do not get anything no beep. >> >> >

Jan. 17, 2012