August 2013 - Pharo-dev - lists.pharo.org

[update 3.0] #30324

by Esteban Lorenzano

Aug. 6, 2013

[update30] #30323

by Esteban Lorenzano

30323 ----- 11200 Repeated methods in superclasses, explicit requirement no implemented, repeated methods in traits https://pharo.fogbugz.com/f/cases/11200 (pass 1)

Aug. 6, 2013

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

by Henrik Johansen

On Aug 5, 2013, at 9:15 , StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi francisco > > thanks for the suggestion. Indeed me too :) > Now I will check. > > Stef #when:do: is there already ;) #when:send:to: and #when:do:for: should be added though. Cheers, Henry

Aug. 6, 2013

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

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

by Igor Stasenko

On 5 August 2013 16:18, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > false polymorphism with exception handling? > innndeeeed :) > > 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 > > -- Best regards, Igor Stasenko.

Aug. 5, 2013

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

by Nicolas Cellier

false polymorphism with exception handling? 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 Mariano Martinez Peck

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 Martin Dias

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

Aug. 5, 2013

Re: [Pharo-dev] Did canUnderstand: changed?

by Sebastian Tleye

It's a bug i introduced in one of my changes, i am fixing it. 2013/8/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Hi > > why canUnderstand: now handles shouldNotImplement? > > Stef > >

Aug. 5, 2013

Re: [Pharo-dev] about on:do: -> onKey:do:

by Igor Stasenko

On 5 August 2013 10:32, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Ok, I commited a slice with a different selector name we discussed with Ben > a while ago. #bindKeyCombination:toAction: > > On Mon, Aug 5, 2013 at 9:42 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 4 August 2013 15:50, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> > I would use #onKeyCombination:do: to keep coherency with the framework. >> > >> >> why not naming it >> onKeyCombinationInKeyBindingsFramework:do: >> :) > > > Really? > >> >> >> >> >> OnKey: is good because it short. > > > Short is not always better, come on igor! > >> >> And not ambiguous (you can use single >> key(s) > > > yes but also... > >> as well as key combinations, > > > And then why Key is ok? The role the object is playing there is the one of a > key combination. If a key can be used as a key combination it is only > circumstantial. > >> >> but that details). > > > You know better than a lot of people that details matter :). And now you can > solve the detail instantaneously by just making the selector more intention > revealing. I do not see the problem. > Well, it is always a tradeoff between being explicit and too elaborate. Now, of course, you, as designer of key bindings know better, so i won't argue about that. Just thought that onKey:do: is explicit enough to indicate the intent (and in any case, much better than on:do: ). -- Best regards, Igor Stasenko.

Aug. 5, 2013

[update 3.0] #30322

by Esteban Lorenzano

Aug. 5, 2013

Re: [Pharo-dev] about on:do: -> onKey:do:

by Guillermo Polito

Ok, I commited a slice with a different selector name we discussed with Ben a while ago. #bindKeyCombination:toAction: On Mon, Aug 5, 2013 at 9:42 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 4 August 2013 15:50, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > I would use #onKeyCombination:do: to keep coherency with the framework. > > > > why not naming it > onKeyCombinationInKeyBindingsFramework:do: > :) Really? > > OnKey: is good because it short. Short is not always better, come on igor! > And not ambiguous (you can use single > key(s) yes but also... *as well as key combinations*, And then why Key is ok? The role the object is playing there is the one of a key combination. If a key can be used as a key combination it is only circumstantial. > but that details). > You know better than a lot of people that details matter :). And now you can solve the detail instantaneously by just making the selector more intention revealing. I do not see the problem. > > > On Aug 4, 2013, at 3:04 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > > >> Hi ben and others > >> > >> we are introducing onKey:do: for bindings so that we can control the > complexity and the registration > >> of announcements. So if you can I have a look it would be good. > >> > >> https://pharo.fogbugz.com/default.asp?11299 > >> > >> Stef > > > > > > > > -- > Best regards, > Igor Stasenko. > >

Aug. 5, 2013

Re: [Pharo-dev] is there anyone who can use SimpleMIDIPort on Mac OSX 10.6.8?

by Igor Stasenko

On 4 August 2013 18:35, laurent laffont <laurent.laffont(a)gmail.com> wrote: > Hi, > > I was looking about MIDI on Linux today, and may be that's related. On > Linux, for the MIDI plugin, there's 2 files: > - sqUnixMIDIALSA.inc > - sqUnixMIDINone.inc > > it seems sqUnixMIDINone is build, and not ALSA one. In > /platforms/unix/plugins/MIDIPlugin/sqUnixMIDI.c: > #if defined(USE_MIDI_ALSA) > # include "sqUnixMIDIALSA.inc" > #else > # include "sqUnixMIDINone.inc" > #endif > > USE_MIDI_ALSA is set in a configure script, and if I understand correctly, > it is not used with the cmake process ? Anyway, I've changed to: > #include "sqUnixMIDIALSA.inc" > > and the file compile, but fail to link. It seems gcc doesn't have the needed > -l flag to link to alsa lib, but I don't know where to specify this (I > suppose somewhere in VMMaker ?) > Look for CPlatformConfig and its descendants. > Cheers, > > Laurent > > > > > > On Sun, Aug 4, 2013 at 5:09 PM, NISHIHARA Satoshi <goonsh(a)gmail.com> wrote: >> >> is there anyone who can use SimpleMIDIPort on Mac OSX 10.6.8? >> >> StÃ©phane Ducasse san told me that it can use MIDIPlugin in Pharo 2.0 >> on Mac 10.8.3. >> but I can't use MIDIPlugin on Mac OSX 10.6.8. >> >> SimpleMIDIPort>>#midiIsSupported >> -> false >> SimpleMIDIPort>>#primPortCount >> -> 0 >> >> vm: >> Pharo.app(13/03/13) >> Pharo-126.app(13/05/04) >> Pharo-145.app(13/05/31) >> Pharo-169.app(13/07/10) >> Pharo-186.app(13/07/15) >> Pharo-187.app(13/07/19) >> Pharo-188.app(13/07/31) >> >> I would like to know whether it is a problem of all those that are >> using 10.6.8 or personal trouble. >> >> -p.s.- >> >> On Eliot Miranda san's CogMT.r2761.app and Cog.r2761.app, >> SimpleMIDIPort>>#midiIsSupported >> -> true >> SimpleMIDIPort>>#primPortCount >> -> 1 >> >> regards. >> > -- Best regards, Igor Stasenko.

Aug. 5, 2013

Re: [Pharo-dev] about on:do: -> onKey:do:

by Igor Stasenko

On 4 August 2013 15:50, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > I would use #onKeyCombination:do: to keep coherency with the framework. > why not naming it onKeyCombinationInKeyBindingsFramework:do: :) OnKey: is good because it short. And not ambiguous (you can use single key(s) as well as key combinations, but that details). > On Aug 4, 2013, at 3:04 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Hi ben and others >> >> we are introducing onKey:do: for bindings so that we can control the complexity and the registration >> of announcements. So if you can I have a look it would be good. >> >> https://pharo.fogbugz.com/default.asp?11299 >> >> Stef > > -- Best regards, Igor Stasenko.

Aug. 5, 2013

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

by Erwan Douaille

2013/8/5 <seaside(a)rmod.lille.inria.fr> > Hi! We're sending this automatic email twice a month, to give the > community an opportunity to easily know what's happening and to coordinate > efforts. Just answer informally, and feel free to spawn discussions > thereafter! > > ### Here's what I've been up to since the last WhatsUp: > > GSOC try to fix bugs (Thanks Esteban :) GSOC evaluation GSOC spec code generation, i made a video. You can watch it there : http://uipainter-gsoc.over-blog.com/ > > ### What's next, until 2013-08-18 (*): > - GSOC spec code generation, the past one is really "stupid". I have to parse the morph and know exactly where my submorphs are and which layout i have to use to setup the final render. -- Best regards, Douaille Erwan <douaille.erwan(a)gmail.com>

Aug. 5, 2013

Re: [Pharo-dev] Smalltalk = strongly typed

by Igor Stasenko

On 3 August 2013 20:53, kilon <thekilon(a)yahoo.co.uk> wrote: > btc wrote >> btc@ > >> wrote: >> >> Kilon, I agree with most of you writeup, except that I think Smalltalk >> has types - except the types are not associated with variables, rather >> they are associated with objects. This aligns with Igor's comment "in >> smalltalk, assignment is not copying value, but changing the reference". > > Actually I also mostly agree with Igor point. If I am not mistake we agree > on the fact that smalltalk has no types. > > The only thing I would not agree, if my assumption is correct here, is that > Igor appears here implying that smalltalk somehow is special to assign > values by reference. If this assumption of mine is correct then I do > disagree strongly , its actually a very common practice. Python also > implement this, Lisp does, ruby and an array of dynamic type languages. I am > not so sure about C and C++ but since they use pointers its a moot point > anyway. > > I explain this concept in my book about python that I have published in > blenderwiki , section "Reference" which can be found here -> > http://wiki.blender.org/index.php/User:Kilon/Python_book_of_magic/05.Dictio… > Sure, i didn't meant that this is unique to smalltalk. > However this concept is implementation specific and not language specific. > Its obviously a massive diffirence because a coder rarely worries about the > implementation itself the same way a user of an OS does not worry how and > why an OS does the things it does, he only care about what it does. > Well, a language should define how assignment works, so it can be implemented. And apparently assignment by copying value won't fit for smalltalk. > Also I am not sure how that prove the existence of types, for me it does > not, it only describes how values are assigned. What prevents you from > assigning by reference typeless data ? > > Unless once again we talk about how pharo itself implement this and somehow > uses its own internal type system. The question that remain why I the coder > should care about this , if at language level Smalltalk is typeless. > > Maybe Igor can clarify this more to make a more clear picture what happens > at implementation level. But at language level yes I have seen nothing that > proves the existence of types inside Smalltalk unless we treat types in a > very vague kind way which for me it just defeats their purpose. > I think that too.. To me it looks like an attempt to describe the world with favorite tool - thermometer. > I also agree on the remark of Duck Typing , it definitely smells like > smalltalk , but once again the terminology is failed because it implies a > type system. > > Once more I have to stress the importance of dichotomy between language > specification and language implementation. Types obviously touch both areas > but not necessarily for same reasons. > > > > > > -- > View this message in context: http://forum.world.st/Smalltalk-strongly-typed-tp4701894p4702028.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

Aug. 5, 2013

WhatsUp from: 2013-08-05 until: 2013-08-18

by seaside＠rmod.lille.inria.fr

Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS ### What's next, until 2013-08-18 (*): - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION (*) we'll be expecting results by then ;)

Aug. 5, 2013

Did canUnderstand: changed?

by StÃ©phane Ducasse

Hi why canUnderstand: now handles shouldNotImplement? Stef

Aug. 4, 2013

Re: [Pharo-dev] is there anyone who can use SimpleMIDIPort on Mac OSX 10.6.8?

by laurent laffont

Hi, I was looking about MIDI on Linux today, and may be that's related. On Linux, for the MIDI plugin, there's 2 files: - sqUnixMIDIALSA.inc - sqUnixMIDINone.inc it seems sqUnixMIDINone is build, and not ALSA one. In /platforms/unix/plugins/MIDIPlugin/sqUnixMIDI.c: #if defined(USE_MIDI_ALSA) # include "sqUnixMIDIALSA.inc" #else # include "sqUnixMIDINone.inc" #endif USE_MIDI_ALSA is set in a configure script, and if I understand correctly, it is not used with the cmake process ? Anyway, I've changed to: #include "sqUnixMIDIALSA.inc" and the file compile, but fail to link. It seems gcc doesn't have the needed -l flag to link to alsa lib, but I don't know where to specify this (I suppose somewhere in VMMaker ?) Cheers, Laurent On Sun, Aug 4, 2013 at 5:09 PM, NISHIHARA Satoshi <goonsh(a)gmail.com> wrote: > is there anyone who can use SimpleMIDIPort on Mac OSX 10.6.8? > > StÃ©phane Ducasse san told me that it can use MIDIPlugin in Pharo 2.0 > on Mac 10.8.3. > but I can't use MIDIPlugin on Mac OSX 10.6.8. > > SimpleMIDIPort>>#midiIsSupported > -> false > SimpleMIDIPort>>#primPortCount > -> 0 > > vm: > Pharo.app(13/03/13) > Pharo-126.app(13/05/04) > Pharo-145.app(13/05/31) > Pharo-169.app(13/07/10) > Pharo-186.app(13/07/15) > Pharo-187.app(13/07/19) > Pharo-188.app(13/07/31) > > I would like to know whether it is a problem of all those that are > using 10.6.8 or personal trouble. > > -p.s.- > > On Eliot Miranda san's CogMT.r2761.app and Cog.r2761.app, > SimpleMIDIPort>>#midiIsSupported > -> true > SimpleMIDIPort>>#primPortCount > -> 1 > > regards. > >

Aug. 4, 2013

Re: [Pharo-dev] Announcer problem :)

by StÃ©phane Ducasse

The real problem is that the error that was raised on on:do: was removed and now... NewValueHolder>>whenChangedDo: aBlock | block | block := [:announcement :ann | aBlock cull: announcement newContents cull: announcement oldContents cull: announcement cull: ann ]. announcer weak on: ValueChanged do: block Now may be it is not a problem and a strong reference is ok too. We will have to analyse that. Stef > So igor is thinking about ephemerons and object formats. > Because we are going over all the weak on:do: and rewriting the ones we can. > > > whenListChanged: aBlock > "Specify a block to value after the contents of the list has changed" > > "Basically when you set a new list of items" > > <api: #event> > | block | > block := [ :announcement :ann | > aBlock > cull: announcement newContents > cull: announcement oldContents > cull: announcement > cull: ann ]. > listAnnouncer weak > on: ValueChanged > do: block > > > On Aug 4, 2013, at 4:16 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > >> addDependent: anObject >> >> self announcer >> on: MorphChanged >> do: [ :ann | anObject update: ann selector ]. >> >> self announcer >> on: MorphChangedWithArguments >> do: [ :ann | anObject update: ann selector with: ann arguments ]. >> >> ^ anObject >> >> is an example of the problem because addDependent: was holding also weakly its dependent and now >> we cannot use weak with blocks. >> >> Stef > >

Aug. 4, 2013

Re: [Pharo-dev] is there anyone who can use SimpleMIDIPort on Mac OSX 10.6.8?

by StÃ©phane Ducasse

to test please load Gofer new smalltalkhubUser: 'PharoExtras' project: 'Sound'; package: 'ConfigurationOfPharoSound'; load. ((Smalltalk globals at: #ConfigurationOfPharoSound) project version: '5.3') load

Aug. 4, 2013

Re: [Pharo-dev] Announcer problem :)

by StÃ©phane Ducasse

So igor is thinking about ephemerons and object formats. Because we are going over all the weak on:do: and rewriting the ones we can. whenListChanged: aBlock "Specify a block to value after the contents of the list has changed" "Basically when you set a new list of items" <api: #event> | block | block := [ :announcement :ann | aBlock cull: announcement newContents cull: announcement oldContents cull: announcement cull: ann ]. listAnnouncer weak on: ValueChanged do: block On Aug 4, 2013, at 4:16 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > addDependent: anObject > > self announcer > on: MorphChanged > do: [ :ann | anObject update: ann selector ]. > > self announcer > on: MorphChangedWithArguments > do: [ :ann | anObject update: ann selector with: ann arguments ]. > > ^ anObject > > is an example of the problem because addDependent: was holding also weakly its dependent and now > we cannot use weak with blocks. > > Stef

Aug. 4, 2013

is there anyone who can use SimpleMIDIPort on Mac OSX 10.6.8?

by NISHIHARA Satoshi

is there anyone who can use SimpleMIDIPort on Mac OSX 10.6.8? StÃ©phane Ducasse san told me that it can use MIDIPlugin in Pharo 2.0 on Mac 10.8.3. but I can't use MIDIPlugin on Mac OSX 10.6.8. SimpleMIDIPort>>#midiIsSupported -> false SimpleMIDIPort>>#primPortCount -> 0 vm: Pharo.app(13/03/13) Pharo-126.app(13/05/04) Pharo-145.app(13/05/31) Pharo-169.app(13/07/10) Pharo-186.app(13/07/15) Pharo-187.app(13/07/19) Pharo-188.app(13/07/31) I would like to know whether it is a problem of all those that are using 10.6.8 or personal trouble. -p.s.- On Eliot Miranda san's CogMT.r2761.app and Cog.r2761.app, SimpleMIDIPort>>#midiIsSupported -> true SimpleMIDIPort>>#primPortCount -> 1 regards.

Aug. 4, 2013

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

by StÃ©phane Ducasse

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

Aug. 4, 2013

Re: [Pharo-dev] Fuel API bug

by Max Leske

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 >

Aug. 4, 2013

Re: [Pharo-dev] Fuel API bug

by Max Leske

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

Aug. 4, 2013

Re: [Pharo-dev] about on:do: -> onKey:do:

by Esteban Lorenzano

On Aug 4, 2013, at 4:11 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > No because the asKeyCombination is sent to the argument by the onKey:do: method. I don't really see the relation :) > We will be able to rename it anyway once we sort the problems. yep! most important is to move on and fix that annoying bug. > > >> I would use #onKeyCombination:do: to keep coherency with the framework. >> >> On Aug 4, 2013, at 3:04 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>> Hi ben and others >>> >>> we are introducing onKey:do: for bindings so that we can control the complexity and the registration >>> of announcements. So if you can I have a look it would be good. >>> >>> https://pharo.fogbugz.com/default.asp?11299 >>> >>> Stef >> >> > >

Aug. 4, 2013

Announcer problem :)

by StÃ©phane Ducasse

addDependent: anObject self announcer on: MorphChanged do: [ :ann | anObject update: ann selector ]. self announcer on: MorphChangedWithArguments do: [ :ann | anObject update: ann selector with: ann arguments ]. ^ anObject is an example of the problem because addDependent: was holding also weakly its dependent and now we cannot use weak with blocks. Stef

Aug. 4, 2013

Re: [Pharo-dev] about on:do: -> onKey:do:

by StÃ©phane Ducasse

No because the asKeyCombination is sent to the argument by the onKey:do: method. We will be able to rename it anyway once we sort the problems. > I would use #onKeyCombination:do: to keep coherency with the framework. > > On Aug 4, 2013, at 3:04 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Hi ben and others >> >> we are introducing onKey:do: for bindings so that we can control the complexity and the registration >> of announcements. So if you can I have a look it would be good. >> >> https://pharo.fogbugz.com/default.asp?11299 >> >> Stef > >

Aug. 4, 2013

Fuel API bug

by StÃ©phane Ducasse

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

Aug. 4, 2013

Re: [Pharo-dev] about on:do: -> onKey:do:

by Esteban Lorenzano

I would use #onKeyCombination:do: to keep coherency with the framework. On Aug 4, 2013, at 3:04 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi ben and others > > we are introducing onKey:do: for bindings so that we can control the complexity and the registration > of announcements. So if you can I have a look it would be good. > > https://pharo.fogbugz.com/default.asp?11299 > > Stef

Aug. 4, 2013

about on:do: and weak

by StÃ©phane Ducasse

Hi guys we are looking at the memory leak problems with igor and here are the conclusions: we are renaming on:do: for shortcut into onKey:do: so that we can see a bit more (normally easy) Now the complex part. on:do: should not be used in weak announcement. because the block holds a context that prevents the garbage collection to reclaim the object. For blocks implicitly the receiver of the message containing the block is held strongly. Now the block cannot We are adding a message in the on:do: implementation and we will have a look at the complete image. on:do: should only be used for strong references. The problem is that for UI we need weak. So we are looking at users for now. Stef

Aug. 4, 2013

Re: [Pharo-dev] about on:do: -> onKey:do:

by Tudor Girba

Great. Doru On Sun, Aug 4, 2013 at 3:04 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > Hi ben and others > > we are introducing onKey:do: for bindings so that we can control the > complexity and the registration > of announcements. So if you can I have a look it would be good. > > https://pharo.fogbugz.com/default.asp?11299 > > Stef > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 4, 2013

about on:do: -> onKey:do:

by StÃ©phane Ducasse

Hi ben and others we are introducing onKey:do: for bindings so that we can control the complexity and the registration of announcements. So if you can I have a look it would be good. https://pharo.fogbugz.com/default.asp?11299 Stef

Aug. 4, 2013

Re: [Pharo-dev] New version of PharoSound

by kilon

Its still all your fault :D I did not imply that you have to do anything. I only asked that a link to the library is offered and maybe some general information to trigger more interest. Thank you for the link will take a look. :) StÃ©phane Ducasse wrote > good idea I will do that in the future > > http://smalltalkhub.com/#!/~PharoExtras > > then the configurationOfPharoSound is published in > ss3.gemtalk.com/MetaRepoForPharo20 > > I looked around and that are some text in > > http://stephane.ducasse.free.fr/FreeBooks/GuzdialBookDrafts/Multimedia-ch7.… > > If somebody would start to extract and work on a simple doc it would be > great. > > > About the doc, did you realise that we are writing docs while often there > were not a single documentation > even though people got payed when developing squeak. > So we are doing our best. > > Did you realise that we write even document on things we do not know? :) > > > Stef > > > >> May I ask for a small favor ? >> >> That you guys each time you refer to a pharo library you also link its >> project page that hopefully contains also its docs. So we can all follow >> you >> easily. I know google is my friend but I do think its more convenient >> and a better motivation for people to try new libraries. >> >> Thanks :) >> >> PS: Thats what google found for me >> http://www.squeaksource.com/@_2hZJ-jfU7KYRTE3/wk_ym4n7. Does not seem to >> have any docs :( >> >> >> >> -- >> View this message in context: >> http://forum.world.st/New-version-of-PharoSound-tp4702031p4702033.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> -- View this message in context: http://forum.world.st/New-version-of-PharoSound-tp4702031p4702050.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 4, 2013

Re: [Pharo-dev] New version of PharoSound

by StÃ©phane Ducasse

>> good idea I will do that in the future >> >> http://smalltalkhub.com/#!/~PharoExtras >> >> then the configurationOfPharoSound is published in ss3.gemtalk.com/MetaRepoForPharo20 >> >> I looked around and that are some text in >> http://stephane.ducasse.free.fr/FreeBooks/GuzdialBookDrafts/Multimedia-ch7.… >> >> If somebody would start to extract and work on a simple doc it would be great. >> >> >> About the doc, did you realise that we are writing docs while often there were not a single documentation >> even though people got payed when developing squeak. >> So we are doing our best. >> >> Did you realise that we write even document on things we do not know? :) > > Yes, StÃ©phane, most people completely underestimate how much effort documentation is, both in code as in separate nice documents. I for one, appreciate your work on that front, a lot. The book style documentation is extremely important. > > But I think what he means is something like this: > > http://www.smalltalkhub.com/#!/~SvenVanCaekenberghe/STON > > one page as a reference, where you can get the code and read some introduction and basic documentation. > > Your work on the meta package documentation will certainly help, but it are still the developers who have to write it. 100% in sync with you :) Stef

Aug. 4, 2013

Re: [Pharo-dev] New version of PharoSound

by Sven Van Caekenberghe

On 04 Aug 2013, at 09:47, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > good idea I will do that in the future > > http://smalltalkhub.com/#!/~PharoExtras > > then the configurationOfPharoSound is published in ss3.gemtalk.com/MetaRepoForPharo20 > > I looked around and that are some text in > http://stephane.ducasse.free.fr/FreeBooks/GuzdialBookDrafts/Multimedia-ch7.… > > If somebody would start to extract and work on a simple doc it would be great. > > > About the doc, did you realise that we are writing docs while often there were not a single documentation > even though people got payed when developing squeak. > So we are doing our best. > > Did you realise that we write even document on things we do not know? :) Yes, StÃ©phane, most people completely underestimate how much effort documentation is, both in code as in separate nice documents. I for one, appreciate your work on that front, a lot. The book style documentation is extremely important. But I think what he means is something like this: http://www.smalltalkhub.com/#!/~SvenVanCaekenberghe/STON one page as a reference, where you can get the code and read some introduction and basic documentation. Your work on the meta package documentation will certainly help, but it are still the developers who have to write it. Sven > Stef > > > >> May I ask for a small favor ? >> >> That you guys each time you refer to a pharo library you also link its >> project page that hopefully contains also its docs. So we can all follow you >> easily. I know google is my friend but I do think its more convenient >> and a better motivation for people to try new libraries. >> >> Thanks :) >> >> PS: Thats what google found for me >> http://www.squeaksource.com/@_2hZJ-jfU7KYRTE3/wk_ym4n7. Does not seem to >> have any docs :( >> >> >> >> -- >> View this message in context: http://forum.world.st/New-version-of-PharoSound-tp4702031p4702033.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> > >

Aug. 4, 2013

Re: [Pharo-dev] New version of PharoSound

by StÃ©phane Ducasse

good idea I will do that in the future http://smalltalkhub.com/#!/~PharoExtras then the configurationOfPharoSound is published in ss3.gemtalk.com/MetaRepoForPharo20 I looked around and that are some text in http://stephane.ducasse.free.fr/FreeBooks/GuzdialBookDrafts/Multimedia-ch7.… If somebody would start to extract and work on a simple doc it would be great. About the doc, did you realise that we are writing docs while often there were not a single documentation even though people got payed when developing squeak. So we are doing our best. Did you realise that we write even document on things we do not know? :) Stef > May I ask for a small favor ? > > That you guys each time you refer to a pharo library you also link its > project page that hopefully contains also its docs. So we can all follow you > easily. I know google is my friend but I do think its more convenient > and a better motivation for people to try new libraries. > > Thanks :) > > PS: Thats what google found for me > http://www.squeaksource.com/@_2hZJ-jfU7KYRTE3/wk_ym4n7. Does not seem to > have any docs :( > > > > -- > View this message in context: http://forum.world.st/New-version-of-PharoSound-tp4702031p4702033.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Aug. 4, 2013

DigitalSignatureAlgorithm depends on Sound

by StÃ©phane Ducasse

Hi I discovered that UUIDGenerator and DigitalSignatureAlgorithm used in some encrypting algo are dependent of Sound. BaseSoundSystem>>:randomBitsFromSoundInput: bitCount "Answer a positive integer with the given number of random bits of 'noise' from a sound input source. Typically, one would use a microphone or line input as the sound source, although many sound cards have enough thermal noise that you get random low-order sample bits even with no microphone connected. Only the least signficant bit of the samples is used. Since not all sound cards support 16-bits of sample resolution, we use the lowest bit that changes." "(1 to: 10) collect: [:i | BaseSoundSystem new randomBitsFromSoundInput: 512]" | recorder buf mid samples bitMask randomBits bit | "collect some sound data" recorder := SoundRecorder new clearRecordedSound. recorder resumeRecording. (Delay forSeconds: 1) wait. recorder stopRecording. buf := recorder condensedSamples. "grab bitCount samples from the middle" mid := buf monoSampleCount // 2. samples := buf copyFrom: mid to: mid + bitCount - 1. "find the least significant bit that varies" bitMask := 1. [bitMask < 16r10000 and: [(samples collect: [:s | s bitAnd: bitMask]) asSet size < 2]] whileTrue: [bitMask := bitMask bitShift: 1]. bitMask = 16r10000 ifTrue: [^ self error: 'sound samples do not vary']. "pack the random bits into a positive integer" randomBits := 0. 1 to: samples size do: [:i | bit := ((samples at: i) bitAnd: bitMask) = 0 ifTrue: [0] ifFalse: [1]. randomBits := (randomBits bitShift: 1) + bit]. ^ randomBits Now I was thinking that when the sound package is not loaded we could have a random number generator. Stef

Aug. 3, 2013

Re: [Pharo-dev] Discard option while editing code seems to be broken or strange

by Camille Teruel

Yes I have this bug times to times but no mean to reproduce it. On 3 aoÃ»t 2013, at 21:27, StÃ©phane Ducasse wrote: > When I modify a method and click on somewhere else I get a pop up and pressing discard does not work but pops up another. > Now I'm trying to reproduce the problem to describe it clearly and I cannot anymore but I'm sure I did get this strange behavior. > > Stef

Aug. 3, 2013

Re: [Pharo-dev] New version of PharoSound

by kilon

May I ask for a small favor ? That you guys each time you refer to a pharo library you also link its project page that hopefully contains also its docs. So we can all follow you easily. I know google is my friend but I do think its more convenient and a better motivation for people to try new libraries. Thanks :) PS: Thats what google found for me http://www.squeaksource.com/@_2hZJ-jfU7KYRTE3/wk_ym4n7. Does not seem to have any docs :( -- View this message in context: http://forum.world.st/New-version-of-PharoSound-tp4702031p4702033.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 3, 2013