- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] KeyDown and KeyUp without automatic key repeating.

by Ronie Salgado

Thank you, Its not exactly what I need, but using it I can hack the result that I want using some dictionary holding the key down state. Greetings, Ronie Salgado 2013/8/5 Erwan Douaille <douailleerwan(a)gmail.com> > I made an example, i guess it's what you need. > Cheat with the keyUp > > ExempleKey new > > Mouse over the morph and try key left / right > > > 2013/8/5 Ronie Salgado <roniesalg(a)gmail.com> > >> Hello, >> I need to know how I can handle a KeyDown and a KeyUp morph event without >> automatic key repeating, to be able to setup an object that performs per >> frame animation. >> For the ones who have worked with SDL, what I need is something like >> SDL_EnableKeyRepeat(0, 0) >> >> Greetings, >> Ronie Salgado >> > > > > -- > Best regards, > > Douaille Erwan <douaille.erwan(a)gmail.com> >

Aug. 5, 2013

Re: [Pharo-dev] renaming method propagation

by StÃ©phane Ducasse

> Now, why does ring answer true to isActive if the method does not exist any more? Because a RGMethod is active when it simply represents a compiledMethod (by opposition to an old version of a method in the versionBrowser). So when we populate the MessageBrowser this is normal that the RG is active (it is done exactly for this purpose). Stef > > > On Mon, Aug 5, 2013 at 10:03 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > I found a problem with method renaming. The scenario is the following one: > > - you have a message browser open with a list a methods (resulting from a sender/implementor). > - you rename a method and you get an error > > why because the message browser does not replace the currently changed method. > and the RGMethodDefinition that represented the renamed method defines the code like that > > MessageBrowser>>wrapItem: anItem > | s | > > s :=String streamContents: [ :aStream | > 3 to: (cachedHierarchy at: anItem) size do: [:i | aStream << ' ']. > aStream > << anItem methodClass name << ' ('. > anItem isFromTrait > ifTrue: [ aStream << anItem compiledMethod origin name; space ]. > aStream << (anItem category ifNil: ['']) <<')']. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > ^ {s. anItem selector}. > > RGMethodDefinition>>compiledMethod > "Retrieves the compiled method of this definition if exists" > > | rClass | > (rClass := self realClass) notNil > ifTrue: [ (rClass includesSelector: self selector) > ifTrue: [ ^rClass >> self selector ] ]. > ^nil > > category > > ^ self protocol > > protocol > > self isActive > ifTrue: [ ^ self compiledMethod category ]]. > self isHistorical > ifTrue: [ ^ self protocolAtPointer ifNil:[ self compiledMethod ifNil:[ protocol ] ifNotNil:[ :cm| cm category ] ] ]. > ^ protocol > > So I patched the protocol method as follows > > protocol > > self isActive > ifTrue: [ ^ self compiledMethod ifNil: [ ' '] ifNotNilDo: [ :cm | cm category ]]. > "I hate this ifNil test, the problem is that when we rename a method, a method definition in a list may still refers to > the old selector and the definition of compiled method is that case is not finding the associated method because it holds the > old selector and not the one corresponding to the one defined in the class." > self isHistorical > ifTrue: [ ^ self protocolAtPointer ifNil:[ self compiledMethod ifNil:[ protocol ] ifNotNil:[ :cm| cm category ] ] ]. > ^ protocol > > I imagine that the best solution would be that the tools update their contents but I wanted to know your point of view. > > Stef > > > >

Aug. 5, 2013

Re: [Pharo-dev] renaming method propagation

by Guillermo Polito

Now, why does ring answer true to isActive if the method does not exist any more? On Mon, Aug 5, 2013 at 10:03 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Hi guys > > I found a problem with method renaming. The scenario is the following one: > > - you have a message browser open with a list a methods (resulting > from a sender/implementor). > - you rename a method and you get an error > > why because the message browser does not replace the currently changed > method. > and the RGMethodDefinition that represented the renamed method defines > the code like that > > MessageBrowser>>wrapItem: anItem > | s | > > s :=String streamContents: [ :aStream | > 3 to: (cachedHierarchy at: anItem) size do: [:i | aStream > << ' ']. > aStream > << anItem methodClass name << ' ('. > anItem isFromTrait > ifTrue: [ aStream << anItem compiledMethod origin > name; space ]. > aStream << (anItem category ifNil: ['']) <<')']. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > ^ {s. anItem selector}. > > RGMethodDefinition>>compiledMethod > "Retrieves the compiled method of this definition if exists" > > | rClass | > (rClass := self realClass) notNil > ifTrue: [ (rClass includesSelector: self selector) > ifTrue: [ ^rClass >> self selector ] ]. > ^nil > > category > > ^ self protocol > > protocol > > self isActive > ifTrue: [ ^ self compiledMethod category ]]. > self isHistorical > ifTrue: [ ^ self protocolAtPointer ifNil:[ self > compiledMethod ifNil:[ protocol ] ifNotNil:[ :cm| cm category ] ] ]. > ^ protocol > > So I patched the protocol method as follows > > protocol > > self isActive > ifTrue: [ ^ self compiledMethod ifNil: [ ' '] ifNotNilDo: > [ :cm | cm category ]]. > "I hate this ifNil test, the problem is that when we > rename a method, a method definition in a list may still refers to > the old selector and the definition of compiled method is > that case is not finding the associated method because it holds the > old selector and not the one corresponding to the one > defined in the class." > self isHistorical > ifTrue: [ ^ self protocolAtPointer ifNil:[ self > compiledMethod ifNil:[ protocol ] ifNotNil:[ :cm| cm category ] ] ]. > ^ protocol > > I imagine that the best solution would be that the tools update their > contents but I wanted to know your point of view. > > Stef > > > >

Aug. 5, 2013

renaming method propagation

by StÃ©phane Ducasse

Hi guys I found a problem with method renaming. The scenario is the following one: - you have a message browser open with a list a methods (resulting from a sender/implementor). - you rename a method and you get an error why because the message browser does not replace the currently changed method. and the RGMethodDefinition that represented the renamed method defines the code like that MessageBrowser>>wrapItem: anItem | s | s :=String streamContents: [ :aStream | 3 to: (cachedHierarchy at: anItem) size do: [:i | aStream << ' ']. aStream << anItem methodClass name << ' ('. anItem isFromTrait ifTrue: [ aStream << anItem compiledMethod origin name; space ]. aStream << (anItem category ifNil: ['']) <<')']. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^ {s. anItem selector}. RGMethodDefinition>>compiledMethod "Retrieves the compiled method of this definition if exists" | rClass | (rClass := self realClass) notNil ifTrue: [ (rClass includesSelector: self selector) ifTrue: [ ^rClass >> self selector ] ]. ^nil category ^ self protocol protocol self isActive ifTrue: [ ^ self compiledMethod category ]]. self isHistorical ifTrue: [ ^ self protocolAtPointer ifNil:[ self compiledMethod ifNil:[ protocol ] ifNotNil:[ :cm| cm category ] ] ]. ^ protocol So I patched the protocol method as follows protocol self isActive ifTrue: [ ^ self compiledMethod ifNil: [ ' '] ifNotNilDo: [ :cm | cm category ]]. "I hate this ifNil test, the problem is that when we rename a method, a method definition in a list may still refers to the old selector and the definition of compiled method is that case is not finding the associated method because it holds the old selector and not the one corresponding to the one defined in the class." self isHistorical ifTrue: [ ^ self protocolAtPointer ifNil:[ self compiledMethod ifNil:[ protocol ] ifNotNil:[ :cm| cm category ] ] ]. ^ protocol I imagine that the best solution would be that the tools update their contents but I wanted to know your point of view. Stef

Aug. 5, 2013

KeyDown and KeyUp without automatic key repeating.

by Ronie Salgado

Hello, I need to know how I can handle a KeyDown and a KeyUp morph event without automatic key repeating, to be able to setup an object that performs per frame animation. For the ones who have worked with SDL, what I need is something like SDL_EnableKeyRepeat(0, 0) Greetings, Ronie Salgado

Aug. 5, 2013

Re: [Pharo-dev] WhatsUp from: 2013-08-05 until: 2013-08-18

by Damien Cassou

### Here's what I've been up to since the last WhatsUp: writing for Deep into Pharo website for Deep into Pharo http://rmod.lille.inria.fr/deepIntoPharo/ -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Aug. 5, 2013

Re: [Pharo-dev] [Pharo-fuel] Fuel API bug

by StÃ©phane Ducasse

Hi francisco thanks for the suggestion. Indeed me too :) Now I will check. Stef On Aug 5, 2013, at 8:17 PM, Francisco Garau <francisco.garau(a)gmail.com> wrote: > I'd prefer #when:do: rather than #onAnnouncement:do: > > - Francisco > > On 5 Aug 2013, at 18:01, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> >> On Aug 5, 2013, at 4:18 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >>> false polymorphism with exception handling? >> >> indeed. >> >> When I read code and I see on:do: there is a big sign that shows up in my mind: exception. >> >> In addition when I look inside the senders I get false sense of use. >> >> This is the case for example with on:do: for announcement which I really do not like. >> I think that we will rename on:do: into onAnnouncement:do: >> because I did not see one case where suddenly I would like to mix exception with announcement. >> >> Stef >> >> >> >> >>> 2013/8/5 Mariano Martinez Peck <marianopeck(a)gmail.com> >>> Indeed, I thought the same. >>> Stef, could you tell us why implementing on:do: is wrong? >>> >>> >>> On Mon, Aug 5, 2013 at 10:30 AM, Martin Dias <tinchodias(a)gmail.com> wrote: >>> Hi >>> >>> Thanks Stef for fighting with the leak and thanks Max for the fast response. >>> >>> >>> I think was me who added the method #on:do:, and my reasoning was: >>> >>> - FileStream has #fileNamed: and #fileNamed:do: >>> - PositionableStream has #on: >>> - I needed the analog to FileStream>>fileNamed:do: in PositionableStream >>> >>> So, I created #on:do:. It looked consistent. >>> >>> MartÃn >>> >>> >>> On Sun, Aug 4, 2013 at 5:02 PM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>> > impressive :) >>> > Tx guys. >>> > We are fighting with memory leaks like mad :) >>> > >>> > Stef >>> > >>> > On Aug 4, 2013, at 4:49 PM, Max Leske <maxleske(a)gmail.com> wrote: >>> > >>> >> Done. >>> >> >>> >> Name: ConfigurationOfFuel-MaxLeske.207 >>> >> Author: MaxLeske >>> >> Time: 4 August 2013, 4:49:17.037 pm >>> >> UUID: 5cc59075-e365-4a58-a20b-22e40b2b70c9 >>> >> Ancestors: ConfigurationOfFuel-MartinDias.206 >>> >> >>> >> * created new version 1.9.2 for development >>> >> * pointed development to 1.9.2 >>> >> * includes changes Camillo wanted to introduce into 1.9.1 (DateAndTime fix) >>> >> >>> >> >>> >> On 04.08.2013, at 16:35, Max Leske <maxleske(a)gmail.com> wrote: >>> >> >>> >>> Yeah, no problem. I'll get on it right away. >>> >>> >>> >>> Max >>> >>> >>> >>> On 04.08.2013, at 16:10, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >>> >>> >>>> Hi guys >>> >>>> >>> >>>> can you rename this method? >>> >>>> >>> >>>> on: aCollectionOrStream do: aBlock >>> >>>> "Evaluates a block with a new stream based on the collection or stream. Answers the result of the block evaluation. Follows the style of FileStream>>fileNamed:do:." >>> >>>> | aStream | >>> >>>> aStream := self on: aCollectionOrStream. >>> >>>> [ ^ aBlock value: aStream ] ensure: [ aStream close ] >>> >>>> >>> >>>> >>> >>>> Please do not use on:do: for something that is not about exception (and announcements). >>> >>>> >>> >>>> It is too confusing and refactor after. >>> >>>> >>> >>>> Stef >>> >>> >>> >> >>> >> >>> >> _______________________________________________ >>> >> Pharo-fuel mailing list >>> >> Pharo-fuel(a)lists.gforge.inria.fr >>> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >>> > >>> > >>> > _______________________________________________ >>> > Pharo-fuel mailing list >>> > Pharo-fuel(a)lists.gforge.inria.fr >>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >>> >>> _______________________________________________ >>> Pharo-fuel mailing list >>> Pharo-fuel(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>

Aug. 5, 2013

Re: [Pharo-dev] [Pharo-fuel] Fuel API bug

by Esteban A. Maringolo

2013/8/5 Francisco Garau <francisco.garau(a)gmail.com>: > I'd prefer #when:do: rather than #onAnnouncement:do: +1 Me too. -- Esteban.

Aug. 5, 2013

Re: [Pharo-dev] [Pharo-fuel] Fuel API bug

by Francisco Garau

I'd prefer #when:do: rather than #onAnnouncement:do: - Francisco On 5 Aug 2013, at 18:01, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Aug 5, 2013, at 4:18 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> false polymorphism with exception handling? > > indeed. > > When I read code and I see on:do: there is a big sign that shows up in my mind: exception. > > In addition when I look inside the senders I get false sense of use. > > This is the case for example with on:do: for announcement which I really do not like. > I think that we will rename on:do: into onAnnouncement:do: > because I did not see one case where suddenly I would like to mix exception with announcement. > > Stef > > > > >> 2013/8/5 Mariano Martinez Peck <marianopeck(a)gmail.com> >> Indeed, I thought the same. >> Stef, could you tell us why implementing on:do: is wrong? >> >> >> On Mon, Aug 5, 2013 at 10:30 AM, Martin Dias <tinchodias(a)gmail.com> wrote: >> Hi >> >> Thanks Stef for fighting with the leak and thanks Max for the fast response. >> >> >> I think was me who added the method #on:do:, and my reasoning was: >> >> - FileStream has #fileNamed: and #fileNamed:do: >> - PositionableStream has #on: >> - I needed the analog to FileStream>>fileNamed:do: in PositionableStream >> >> So, I created #on:do:. It looked consistent. >> >> MartÃn >> >> >> On Sun, Aug 4, 2013 at 5:02 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >> > impressive :) >> > Tx guys. >> > We are fighting with memory leaks like mad :) >> > >> > Stef >> > >> > On Aug 4, 2013, at 4:49 PM, Max Leske <maxleske(a)gmail.com> wrote: >> > >> >> Done. >> >> >> >> Name: ConfigurationOfFuel-MaxLeske.207 >> >> Author: MaxLeske >> >> Time: 4 August 2013, 4:49:17.037 pm >> >> UUID: 5cc59075-e365-4a58-a20b-22e40b2b70c9 >> >> Ancestors: ConfigurationOfFuel-MartinDias.206 >> >> >> >> * created new version 1.9.2 for development >> >> * pointed development to 1.9.2 >> >> * includes changes Camillo wanted to introduce into 1.9.1 (DateAndTime fix) >> >> >> >> >> >> On 04.08.2013, at 16:35, Max Leske <maxleske(a)gmail.com> wrote: >> >> >> >>> Yeah, no problem. I'll get on it right away. >> >>> >> >>> Max >> >>> >> >>> On 04.08.2013, at 16:10, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>> >> >>>> Hi guys >> >>>> >> >>>> can you rename this method? >> >>>> >> >>>> on: aCollectionOrStream do: aBlock >> >>>> "Evaluates a block with a new stream based on the collection or stream. Answers the result of the block evaluation. Follows the style of FileStream>>fileNamed:do:." >> >>>> | aStream | >> >>>> aStream := self on: aCollectionOrStream. >> >>>> [ ^ aBlock value: aStream ] ensure: [ aStream close ] >> >>>> >> >>>> >> >>>> Please do not use on:do: for something that is not about exception (and announcements). >> >>>> >> >>>> It is too confusing and refactor after. >> >>>> >> >>>> Stef >> >>> >> >> >> >> >> >> _______________________________________________ >> >> Pharo-fuel mailing list >> >> Pharo-fuel(a)lists.gforge.inria.fr >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >> > >> > >> > _______________________________________________ >> > Pharo-fuel mailing list >> > Pharo-fuel(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >> >> _______________________________________________ >> Pharo-fuel mailing list >> Pharo-fuel(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >

Aug. 5, 2013

Re: [Pharo-dev] [Pharo-fuel] Fuel API bug

by StÃ©phane Ducasse

On Aug 5, 2013, at 4:18 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > false polymorphism with exception handling? indeed. When I read code and I see on:do: there is a big sign that shows up in my mind: exception. In addition when I look inside the senders I get false sense of use. This is the case for example with on:do: for announcement which I really do not like. I think that we will rename on:do: into onAnnouncement:do: because I did not see one case where suddenly I would like to mix exception with announcement. Stef > 2013/8/5 Mariano Martinez Peck <marianopeck(a)gmail.com> > Indeed, I thought the same. > Stef, could you tell us why implementing on:do: is wrong? > > > On Mon, Aug 5, 2013 at 10:30 AM, Martin Dias <tinchodias(a)gmail.com> wrote: > Hi > > Thanks Stef for fighting with the leak and thanks Max for the fast response. > > > I think was me who added the method #on:do:, and my reasoning was: > > - FileStream has #fileNamed: and #fileNamed:do: > - PositionableStream has #on: > - I needed the analog to FileStream>>fileNamed:do: in PositionableStream > > So, I created #on:do:. It looked consistent. > > MartÃn > > > On Sun, Aug 4, 2013 at 5:02 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: > > impressive :) > > Tx guys. > > We are fighting with memory leaks like mad :) > > > > Stef > > > > On Aug 4, 2013, at 4:49 PM, Max Leske <maxleske(a)gmail.com> wrote: > > > >> Done. > >> > >> Name: ConfigurationOfFuel-MaxLeske.207 > >> Author: MaxLeske > >> Time: 4 August 2013, 4:49:17.037 pm > >> UUID: 5cc59075-e365-4a58-a20b-22e40b2b70c9 > >> Ancestors: ConfigurationOfFuel-MartinDias.206 > >> > >> * created new version 1.9.2 for development > >> * pointed development to 1.9.2 > >> * includes changes Camillo wanted to introduce into 1.9.1 (DateAndTime fix) > >> > >> > >> On 04.08.2013, at 16:35, Max Leske <maxleske(a)gmail.com> wrote: > >> > >>> Yeah, no problem. I'll get on it right away. > >>> > >>> Max > >>> > >>> On 04.08.2013, at 16:10, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >>> > >>>> Hi guys > >>>> > >>>> can you rename this method? > >>>> > >>>> on: aCollectionOrStream do: aBlock > >>>> "Evaluates a block with a new stream based on the collection or stream. Answers the result of the block evaluation. Follows the style of FileStream>>fileNamed:do:." > >>>> | aStream | > >>>> aStream := self on: aCollectionOrStream. > >>>> [ ^ aBlock value: aStream ] ensure: [ aStream close ] > >>>> > >>>> > >>>> Please do not use on:do: for something that is not about exception (and announcements). > >>>> > >>>> It is too confusing and refactor after. > >>>> > >>>> Stef > >>> > >> > >> > >> _______________________________________________ > >> Pharo-fuel mailing list > >> Pharo-fuel(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel > > > > > > _______________________________________________ > > Pharo-fuel mailing list > > Pharo-fuel(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel > > _______________________________________________ > Pharo-fuel mailing list > Pharo-fuel(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel > > > > -- > Mariano > http://marianopeck.wordpress.com >

Aug. 5, 2013