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

[Pharo-project] Hook into the new progress bar notification?

by Mariano Martinez Peck

Hi guys. For some tests I was doing something like this: | log result | log := FLLoggingSystemProgressItemMorph new. result := [ super serialize: anObject ] on: ProgressInitiationException do: [ :ex | ex sendNotificationsTo: log ]. self deny: log history isEmpty. ^ result FLLoggingSystemProgressItemMorph was just a simple logger so that then I could be sure something was logged. Of course, this does not work anymore with new progress bar. Is there a way to achieve more or less the same? Thanks, -- Mariano http://marianopeck.wordpress.com

Nov. 17, 2012

Re: [Pharo-project] [^ 1] and ifCurtailed:

by ClÃ©ment Bera

Yeah here in your BlockClosure [^1] the homeContext and the outerContext is the context created for UndefinedObject>>DoIt. 2012/11/17 Frank Shearar <frank.shearar(a)gmail.com> > On 16 November 2012 16:53, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > Hi guys > > > > I'm updating the exception chapter to show the interplay between > exception and ensure/ifcurtailed: > > > > [[ ^ 1 ] > > ifCurtailed: [ Transcript show: 'show only curtailed'; cr. ]] > > on: Error do: [ :e | > > Transcript show: 'error'; cr. "do not show it" > > e return: 4 ]. > > > > normally shows that only the ifCurtailed: argument is executed. > > > > Now I do not get why when I select > > [^ 1] value and execute it I do not get an error telling me that > there is no context to return to. > > > > May be because the evaluation itself creates a context. > > That's certainly true if you run it from a Workspace. > > frank > > > Stef > > > > > >

Nov. 17, 2012

Re: [Pharo-project] about sharing class binding and others

by Fernando Olivero

I love Marcus idea, classes aren't globals any more, and to access them is simply another message send to a receiver: the environment. ( like the lobby in Self ) . Fernando On Sat, Nov 17, 2012 at 8:56 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > The alternative to the current scheme would be to not hard-code the > class at all in the method at compile time. > > > > Instead of looking up the class and compiling the shared literal > association, we could compile a message send > > to the current environment. > > > > self class environment at: #NameOfClass > > > > And it should be noted that this could be evaluated at Jit-compile > time... the same is true for ivar offsets. There > > is no reason why these should be visible at the image level. The image > could talk about names and let the runtime > > translator infrastucture do the lookups needed for making a static > version that is fast. > > Yes I would like to measure that too. > My benchmarks were to measure the worse case where we have to manually > update the methods each time the class is modified. > > >

Nov. 17, 2012

Re: [Pharo-project] [^ 1] and ifCurtailed:

by Frank Shearar

On 16 November 2012 16:53, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > I'm updating the exception chapter to show the interplay between exception and ensure/ifcurtailed: > > [[ ^ 1 ] > ifCurtailed: [ Transcript show: 'show only curtailed'; cr. ]] > on: Error do: [ :e | > Transcript show: 'error'; cr. "do not show it" > e return: 4 ]. > > normally shows that only the ifCurtailed: argument is executed. > > Now I do not get why when I select > [^ 1] value and execute it I do not get an error telling me that there is no context to return to. > > May be because the evaluation itself creates a context. That's certainly true if you run it from a Workspace. frank > Stef > >

Nov. 17, 2012

Re: [Pharo-project] Please review DrGeo

by Hilaire Fernandes

Le 17/11/2012 09:23, Hilaire Fernandes a Ã©crit : > Ok, I can upload the free version along the complete .app version for > workstations. You can download the APK version from http://drgeo.eu/download-install Direct access the to the 12.10 binary repository: https://gforge.inria.fr/frs/?group_id=1308&release_id=7576 Thanks Hilaire

Nov. 17, 2012

Re: [Pharo-project] Please review DrGeo

by Hilaire Fernandes

Le 16/11/2012 18:59, Phil (list) a Ã©crit : > I agree that it may not be worth the effort since you could also put an apk download link on a website that would let the majority of the users who for whatever reason can't or don't want to use the Play Store use DrGeo (assuming you're not concerned about collecting revenue). I'll let others speak to the pros and cons of alternate markets and mainly wanted to pass along that you're not limited should one or more of them make sense for you or your users. Ok, I can upload the free version along the complete .app version for workstations. Hilaire

Nov. 17, 2012

Re: [Pharo-project] Breaking PDF into smaller PDFs

by StÃ©phane Ducasse

Thanks this is good to know that Christian library is able to parse PDF. This is a really nice addition to our biotope. On Nov 17, 2012, at 3:34 AM, askoh wrote: > Thanks everyone for helping. I found VisualWorks PDF4Smalltalk to be perfect > for me. The author Christian Haider was most helpful too. He has a > successful business using it. Pharo will benefit greatly having a port. > https://gitorious.org/pdf4smalltalk > http://www.freelists.org/list/pdf4st > > See my post on VisualWorks forum > http://forum.world.st/Breaking-PDF-into-smaller-PDFs-td4655116.html#a4655655 > > Aik-Siong Koh > > > > -- > View this message in context: http://forum.world.st/Breaking-PDF-into-smaller-PDFs-tp4655015p4655656.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Nov. 17, 2012

Re: [Pharo-project] about sharing class binding and others

by StÃ©phane Ducasse

> The alternative to the current scheme would be to not hard-code the class at all in the method at compile time. > > Instead of looking up the class and compiling the shared literal association, we could compile a message send > to the current environment. > > self class environment at: #NameOfClass > > And it should be noted that this could be evaluated at Jit-compile time... the same is true for ivar offsets. There > is no reason why these should be visible at the image level. The image could talk about names and let the runtime > translator infrastucture do the lookups needed for making a static version that is fast. Yes I would like to measure that too. My benchmarks were to measure the worse case where we have to manually update the methods each time the class is modified.

Nov. 17, 2012

Re: [Pharo-project] [update 2.0] #20403

by StÃ©phane Ducasse

On Nov 16, 2012, at 11:44 PM, Marcus Denker wrote: > > On Nov 16, 2012, at 7:30 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> I really like the idea of the errorNode. >> > > This is needed to replace the ad-hoc parser that is in the syntax highlighting. > With the error nodes, we can just use the same parser and implement syntax > highlighting as a normal visitor on the standard AST. Excellent we could try to work on autocompletion of code :) by trying to smartly substituting the errorCodeNode by the smallest closing element :) Stef

Nov. 17, 2012

Re: [Pharo-project] Case study/ aside test for tanker

by StÃ©phane Ducasse

then load again but this other package. In fact the names of the package and categories are totally insane :) On Nov 16, 2012, at 11:37 PM, Martin Dias wrote: > how can I try? > > Gofer it > squeaksource: 'MethodWrappers'; > package: 'MethodWrappers4'; > load. > > ? > > > > On Fri, Nov 16, 2012 at 6:55 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > with the default system, trying to reload methodWrapper in a image with methodWrapper leads to an error: > MethodStubWrpper cannot be recompiled. > > So I hope that the new classBuilder will be able to do it. > > Stef >

Nov. 17, 2012