- Pharo-dev - lists.pharo.org

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