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

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

by Stefan Marr

Hi Mariano: On 17 Jan 2012, at 18:20, Mariano Martinez Peck wrote: > Yes, that was pretty much the same idea I got when I tried it. After walking home, the reason for the hang became clear. Recompile is obviously using getSource. 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. Is there somewhere an encoding for plain text, or do I have to add that? The image size goes currently up by ca. 50%, from 22MB to 31MB. 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

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

by Mariano Martinez Peck

On Tue, Jan 17, 2012 at 6:31 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > If you don't bother about being slow, you can also make it much easier: >> >> >> |trailer source m | >> m := (Gofer>>#load). >> trailer := m trailer. >> source := m getSource. >> trailer sourceCode: source. >> m becomeForward: (m copyWithTrailerBytes: trailer) >> >> and if you want to do it for the whole image you can use one bulk become >> and it will be fast. >> >> I will experiment and see if it is working. >> >> > 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. Cheers -- Mariano http://marianopeck.wordpress.com

Jan. 17, 2012

Re: [Pharo-project] CogVM on Fedora

by Bernardo Ezequiel Contreras

im using the cogVM on 64bits debian but i had to install 32 bit libraries. On Tue, Jan 17, 2012 at 3:06 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Tue, Jan 17, 2012 at 7:04 PM, Garret Raziel <boloomka(a)gmail.com> wrote: > >> Hi, does anybody have experience with CogVM on 64bit Fedora? I'm >> currently using Fedora 16 and prebuild vm doesn't work (says that there is >> some problem with x11 plugin). Is there any simple method how to run it? Or >> any simple method how to build it from sourcecode? >> >> > You have to install the 32 bits libraries. > > Cheers > > -- > Mariano > http://marianopeck.wordpress.com > >

Jan. 17, 2012

Re: [Pharo-project] CogVM on Fedora

by Mariano Martinez Peck

On Tue, Jan 17, 2012 at 7:04 PM, Garret Raziel <boloomka(a)gmail.com> wrote: > Hi, does anybody have experience with CogVM on 64bit Fedora? I'm currently > using Fedora 16 and prebuild vm doesn't work (says that there is some > problem with x11 plugin). Is there any simple method how to run it? Or any > simple method how to build it from sourcecode? > > You have to install the 32 bits libraries. Cheers -- Mariano http://marianopeck.wordpress.com

Jan. 17, 2012

[Pharo-project] CogVM on Fedora

by Garret Raziel

Hi, does anybody have experience with CogVM on 64bit Fedora? I'm currently using Fedora 16 and prebuild vm doesn't work (says that there is some problem with x11 plugin). Is there any simple method how to run it? Or any simple method how to build it from sourcecode? Jan

Jan. 17, 2012

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

by Guillermo Polito

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 :). Thanks!!

Jan. 17, 2012

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

by Lukas Renggli

Please note that this configuration loads completely outdated code from last summer. Lukas On 17 January 2012 17:26, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > great guille! > > El 17/01/2012, a las 1:19p.m., Guillermo Polito escribiÃ³: > > Hi! > > I've been working the last days in making OB work in pharo 1.4.Â I updated > several deprecations like method reference and stuff and discovered some > bugs that I've already published in: > > http://code.google.com/p/pharo/issues/detail?id=5189&q=milestone%3D1.4&cols… > http://code.google.com/p/pharo/issues/detail?id=5183&q=milestone%3D1.4&cols… > > I've already proposed some fixes for them, but if anyone can have a look too > I'll feel better :). > Those fixes are needed in order to load OB.Â Meanwhile, you can also have > some patches from the cs and fileout I attach. > > What's working now?Â OB + OCompletion + Shout + Sunit integration. > > So, It's everything but Refactoring browser, which is a little more > difficult since there is another RB version loaded in the image :P. > > To load it (after integrating the patches): > > Gofer it > Â Â Â squeaksource: 'MetacelloRepository'; > Â Â Â package: 'ConfigurationOfOmniBrowser'; > Â Â Â load. > > (ConfigurationOfOmniBrowser project version: #stable) load: #( 'Core Tests' > 'OCompletion Tests' ) ,Â #( 'Core' 'OB-SUnitIntegration' 'OB-Shout' > 'OCForOB'). > > Cheers, > Guille > <pluggable list morph fix.1.cs><Slider-setValue.st> > > -- Lukas Renggli www.lukas-renggli.ch

Jan. 17, 2012

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

by Mariano Martinez Peck

> If you don't bother about being slow, you can also make it much easier: > > > |trailer source m | > m := (Gofer>>#load). > trailer := m trailer. > source := m getSource. > trailer sourceCode: source. > m becomeForward: (m copyWithTrailerBytes: trailer) > > and if you want to do it for the whole image you can use one bulk become > and it will be fast. > > I will experiment and see if it is working. > > Well...do not try to execute this: | trailer source key dict | dict := IdentityDictionary new. CompiledMethod allInstances do: [:each | trailer := each trailer. source := each getSource. trailer sourceCode: source. each becomeForward: (each copyWithTrailerBytes: trailer). "dict at: each put: (each copyWithTrailerBytes: trailer)." ]. dict keys asArray elementsExchangeIdentityWith: dict values asArray. since it hangs my VM... time to go now... cheers > >> > >> > PS: I will interested if you do it :) >> In return, I would really appreciate if you could learn a bit about >> etiquette and quoting >> http://www.gweep.ca/~edmonds/usenet/ml-etiquette.html#SECTION00090000000000… >> >> > 99% of the cases I answer where I have to answer (like I am doing now). > But sometimes if my answer is obvious, I think it is much easier a top > posting than having to quote your email. > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

Jan. 17, 2012

Re: [Pharo-project] Saga of trying to integrate IDE with OpenGL continuesRe: [squeak-dev] Re:NativeBoost and NBOpenGL on Mac?

by Alexandre Bergel

Keep going. I would love to have opengl well integrated. Alexandre On 16 Jan 2012, at 23:44, Lawson English wrote: > The latest video in the saga: http://www.youtube.com/watch?v=TsJmBwi9lDY > > BTW, the video I mentioned a day or so ago now has 90 views, in only 3 days. > > People who want to promote squeak/pharo/seaside/etc to the world at large should take note. > > L. > > > > > On 1/14/12 12:20 PM, Igor Stasenko wrote: >> [...] >>>> well, one of the ideas is to use fallback display in case of openGL >>>> error(s). >>>> And render not to GL context but to bitmap. Then you can actually use >>>> debugger to debug GL calls step by step >>>> without interfering with GL stack/state. >>>> Another approach would be to create a separate GL context and use it >>>> for debugger. But then you need to keep an eye >>>> for switching active contexts at right moment. >>>> >>>>> L. >>>>> >>> >> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 17, 2012

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

by Mariano Martinez Peck

On Tue, Jan 17, 2012 at 5:58 PM, Stefan Marr <smalltalk(a)stefan-marr.de>wrote: > Hi: > > On 17 Jan 2012, at 09:47, Mariano Martinez Peck wrote: > > > Stefan, another approach would be to store the source code in the > compiled method trailer. > Looks like everything is there already, but it does not seem to work > stable enough. > > Yes, that was pretty much the same idea I got when I tried it. > > With the code below, this should work: (do not apply the change to > getSourceFromFile!!) > ------------- > |trailer source m | > m := (Gofer>>#load). > trailer := m trailer. > source := m getSource. > trailer sourceCode: source. > m recompileWithTrailer: trailer. > ------------- > > If you don't bother about being slow, you can also make it much easier: |trailer source m | m := (Gofer>>#load). trailer := m trailer. source := m getSource. trailer sourceCode: source. m becomeForward: (m copyWithTrailerBytes: trailer) and if you want to do it for the whole image you can use one bulk become and it will be fast. I will experiment and see if it is working. > > > > PS: I will interested if you do it :) > In return, I would really appreciate if you could learn a bit about > etiquette and quoting > http://www.gweep.ca/~edmonds/usenet/ml-etiquette.html#SECTION00090000000000… > > 99% of the cases I answer where I have to answer (like I am doing now). But sometimes if my answer is obvious, I think it is much easier a top posting than having to quote your email. -- Mariano http://marianopeck.wordpress.com

Jan. 17, 2012