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

Re: [Pharo-project] [NB] Speaking about callbacks

by Henrik Sperre Johansen

On 17.09.2012 11:48, Igor Stasenko wrote: > On 17 September 2012 11:19, Henrik Sperre Johansen > <henrik.s.johansen(a)veloxit.no> wrote: >> On 16.09.2012 20:42, StÃ©phane Ducasse wrote: >>> On Sep 16, 2012, at 7:17 PM, Igor Stasenko wrote: >>> >>>> So, i'd like to hear your input, which one you like, and which ones >>>> you prefer to have >>>> >>>> 1. requires creating a subclass of NBFFICallback, overriding it's >>>> fnSpec method. Takes a block closure as a callback. >>>> 2. first you must create a factory object by specifying a callback >>>> signature, then you can instantiate new callbacks by passing a block >>>> closure to that factory >>>> 3. to create a callback you must specify it's signature in one of the >>>> compiled methods, and specify an object which will receive a message >>>> when callback will be called. >>> for what it is worth I like the 3rd form. Now I'm not sure on: is the >>> right selector. >>> >> +1, out of those listed #3 seems the most convenient to use. >> >> Being able to do something like: >> Integer >> #+ >> <types: #( int (int aNumber) )> >> >> Then specify the callback parameter as >> self callback: 3 with: #+ >> >> would be really neat. >> >> As an added bonus, it also highlights the problems this approach would have >> with simply annotating normal methods which utilize multiple >> return/parameter types :) >> > not sure i understood your sentence about problems. > Integer + can return LargePositiveIntegers as well as SmallIntegers. Argument type can be anything from float, to Fraction, to.. well, any kind of number. So annotating such methods with a single <types> annotation (which is to serve all uses of it as a callback), rather than defining signature on a per-use basis can be somewhat limiting and end up working against the inherent polymorphism you (at least when it comes to numerics) see in usual smalltalk code. When it comes to return values that's mostly fine, you simply raise an error if unable to convert to the specified type from what the smalltalk method actually returns. But for parameters, you'd have to define separate methods per signature, say addFloat: <types: #( int (float aNumber) )> addUnsignedInt: <types: #( int (uint aNumber) )> when #+ actually handles those cases correctly. Maybe a way to "override" the default parameter signatures when specifying the callback would be nice? self callback: 3 with: #+ parameterTypes: {aNumber -> float} Leaves the usefulness of a default signature for a method, but enables you to change it on a per-use basis, rather than pollute the base-image with extra methods covering parametric variances. Cheers, Henry

Sept. 17, 2012

Re: [Pharo-project] Changing permanently the mouse cursor

by Igor Stasenko

On 17 September 2012 11:40, Hilaire Fernandes <hilaire.fernandes(a)edu.ge.ch> wrote: > Hello, > > One can change temporary the mouse cursor with something like: > > World currentHand showTemporaryCursor: ThemeIcons eyedropperIcon > > But depending on the widgets the mouse is over, its cursor may change again. > > Beside hacking the HandMorph class is there a way to change permanently > the mouse cursor? > Good question. AFAIK, last time i seen it in code, the point where cursor is controlled is in Cursor class. Hand resets cursor by sending #normal message to it. It would be really nice to have changeable default cursor. The Cursor global used everywhere in system. We should find the way how to avoid that. > Thanks > > Hilaire -- Best regards, Igor Stasenko.

Sept. 17, 2012

Re: [Pharo-project] [NB] Speaking about callbacks

by Igor Stasenko

On 17 September 2012 11:19, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 16.09.2012 20:42, StÃ©phane Ducasse wrote: >> >> On Sep 16, 2012, at 7:17 PM, Igor Stasenko wrote: >> >>> So, i'd like to hear your input, which one you like, and which ones >>> you prefer to have >>> >>> 1. requires creating a subclass of NBFFICallback, overriding it's >>> fnSpec method. Takes a block closure as a callback. >>> 2. first you must create a factory object by specifying a callback >>> signature, then you can instantiate new callbacks by passing a block >>> closure to that factory >>> 3. to create a callback you must specify it's signature in one of the >>> compiled methods, and specify an object which will receive a message >>> when callback will be called. >> >> for what it is worth I like the 3rd form. Now I'm not sure on: is the >> right selector. >> > +1, out of those listed #3 seems the most convenient to use. > > Being able to do something like: > Integer >> #+ > <types: #( int (int aNumber) )> > > Then specify the callback parameter as > self callback: 3 with: #+ > > would be really neat. > > As an added bonus, it also highlights the problems this approach would have > with simply annotating normal methods which utilize multiple > return/parameter types :) > not sure i understood your sentence about problems. > Cheers, > Henry > -- Best regards, Igor Stasenko.

Sept. 17, 2012

[Pharo-project] Changing permanently the mouse cursor

by Hilaire Fernandes

Hello, One can change temporary the mouse cursor with something like: World currentHand showTemporaryCursor: ThemeIcons eyedropperIcon But depending on the widgets the mouse is over, its cursor may change again. Beside hacking the HandMorph class is there a way to change permanently the mouse cursor? Thanks Hilaire

Sept. 17, 2012

Re: [Pharo-project] [NB] Speaking about callbacks

by Henrik Sperre Johansen

On 16.09.2012 20:42, StÃ©phane Ducasse wrote: > On Sep 16, 2012, at 7:17 PM, Igor Stasenko wrote: > >> So, i'd like to hear your input, which one you like, and which ones >> you prefer to have >> >> 1. requires creating a subclass of NBFFICallback, overriding it's >> fnSpec method. Takes a block closure as a callback. >> 2. first you must create a factory object by specifying a callback >> signature, then you can instantiate new callbacks by passing a block >> closure to that factory >> 3. to create a callback you must specify it's signature in one of the >> compiled methods, and specify an object which will receive a message >> when callback will be called. > for what it is worth I like the 3rd form. Now I'm not sure on: is the right selector. > +1, out of those listed #3 seems the most convenient to use. Being able to do something like: Integer >> #+ <types: #( int (int aNumber) )> Then specify the callback parameter as self callback: 3 with: #+ would be really neat. As an added bonus, it also highlights the problems this approach would have with simply annotating normal methods which utilize multiple return/parameter types :) Cheers, Henry

Sept. 17, 2012

Re: [Pharo-project] Smalltalkhub news

by Sven Van Caekenberghe

On 17 Sep 2012, at 11:05, Igor Stasenko <siguctua(a)gmail.com> wrote: > yeah, i think it is pointless to retry if you get 404 "not found" > response. Usually (of course if web server conforms to HTTP RFC), this > means that requested resource is really not there and will not be > there anytime soon :) I decided to only do retries on NetworkError, ZnParseError for now, we'll see how it goes. The ifFail block will be triggered on any Error. > On 16 September 2012 23:10, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >> On 2012-09-16, at 22:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> >>> On 16 Sep 2012, at 21:56, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> >>>>> I am especially interested in the last point. Has it something to do with (using) Zn ? >>>> >>>> yes, we basically did a HEAD request and returned false on 404, however >>>> Zn does 3 or so retries, and thus makes everything slow :). I don't know what >>>> the side-effects are, but we reduce the retryCount to 0, to get low response times. >>>> >>>> I thought that upon a valid 404 response there is no retry needed? (but I guess >>>> I miss something here :P) >>> >>> The reason ZnClient keeps on retrying on 404 is because you probably had #enforceHttpSuccess true as part of #systemPolicy and only 2xx response are considered a success. >> >> ah right, that will do it! >> >>> But this is an interesting use case: basically 404 is a valid response here. I'll have to think about that so more. >> >> well now I know, so I'm fine by manually changing it :P -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Sept. 17, 2012

Re: [Pharo-project] Smalltalkhub news

by Igor Stasenko

yeah, i think it is pointless to retry if you get 404 "not found" response. Usually (of course if web server conforms to HTTP RFC), this means that requested resource is really not there and will not be there anytime soon :) On 16 September 2012 23:10, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2012-09-16, at 22:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 16 Sep 2012, at 21:56, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >>>> I am especially interested in the last point. Has it something to do with (using) Zn ? >>> >>> yes, we basically did a HEAD request and returned false on 404, however >>> Zn does 3 or so retries, and thus makes everything slow :). I don't know what >>> the side-effects are, but we reduce the retryCount to 0, to get low response times. >>> >>> I thought that upon a valid 404 response there is no retry needed? (but I guess >>> I miss something here :P) >> >> The reason ZnClient keeps on retrying on 404 is because you probably had #enforceHttpSuccess true as part of #systemPolicy and only 2xx response are considered a success. > > ah right, that will do it! > >> But this is an interesting use case: basically 404 is a valid response here. I'll have to think about that so more. > > well now I know, so I'm fine by manually changing it :P -- Best regards, Igor Stasenko.

Sept. 17, 2012

Re: [Pharo-project] Zinc Progress

by Sven Van Caekenberghe

On 17 Sep 2012, at 10:18, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Thanks again for the help, you made Pharo faster by removing my explicit Delays ;-) After fixing this in my working image, all MC operations just fly. I am happy and sad at the same time. Sorry guys. Sven

Sept. 17, 2012

Re: [Pharo-project] pharo on ipad3 -- tiny image shown only

by Hilaire Fernandes

Esteban should be able to tell. Hilaire

Sept. 17, 2012

Re: [Pharo-project] [ANN] iPad Dr. Geo 12.10

by Sven Van Caekenberghe

Hi Hilaire, I bought a copy for iOS as well. What are the differences between the free and paying versions ? And yes, you need a Help button with things like an overlay showing the main functions, a short tutorial (anything is better than none), a couple of demo projects and links to your website for support. Sven On 16 Sep 2012, at 12:01, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Great achievement, congratulations ! -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Sept. 17, 2012