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

why can we interrupt the UI thread?

by StÃ©phane Ducasse

Aug. 15, 2013

Re: [Pharo-dev] XML writer in the default image

by Esteban Lorenzano

+1 On Aug 15, 2013, at 9:41 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Aug 15, 2013, at 2:15 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> As reported a while ago (https://pharo.fogbugz.com/default.asp?7412#80347) the TestRunner >> is crashing when test failures accidentally spit out XML sensitive characters: >> >> https://ci.inria.fr/pharo/view/all/job/Pharo-3.0-Regression-Tests/304/VM=vm… >> >> I don't really see a reason to generate XML by concatenating strings, so I wonder >> whether we could include the XMLWriter in the default image? > > Why don't we load HDTestRunner when needed? And HDTestRunner could then use XMLWriter > >> This way I could finally fix the HDTestRunner with very little effort. > > I will finish to pop up my list and start to work on managing the image with Metacello > because we should build it based on subproject > RB > Nautilus > Athens > NativeBoost > AsmJit > Zinc > OPAL > were/are managed with metacello so we could be there :) > > Stef > >

Aug. 15, 2013

Re: [Pharo-dev] XML writer in the default image

by StÃ©phane Ducasse

On Aug 15, 2013, at 2:15 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > As reported a while ago (https://pharo.fogbugz.com/default.asp?7412#80347) the TestRunner > is crashing when test failures accidentally spit out XML sensitive characters: > > https://ci.inria.fr/pharo/view/all/job/Pharo-3.0-Regression-Tests/304/VM=vm… > > I don't really see a reason to generate XML by concatenating strings, so I wonder > whether we could include the XMLWriter in the default image? Why don't we load HDTestRunner when needed? And HDTestRunner could then use XMLWriter > This way I could finally fix the HDTestRunner with very little effort. I will finish to pop up my list and start to work on managing the image with Metacello because we should build it based on subproject RB Nautilus Athens NativeBoost AsmJit Zinc OPAL were/are managed with metacello so we could be there :) Stef

Aug. 15, 2013

Re: [Pharo-dev] --no-quit option of eval command handler broken ?

by StÃ©phane Ducasse

Camillo is it what was blocking you with the CI and erwan because yesterday we started to update Ubuntu and other nice libs to be able to check but we did not get an idea about that was the problem. So do you have an expression that does not work? Stef On Aug 15, 2013, at 1:32 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > I can confirm. > However, if you save the image in interactive mode it works again. > > On 2013-08-14, at 17:09, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> Hi, >> >> I have the impression that the --no-quit option of the eval command line handler is broken in 3.0 latest. >> >> This used to work >> >> ./pharo Pharo.image --no-quit eval 'ZnServer startDefaultOn: 8080.' >> >> while now, only this works >> >> ./pharo Pharo.image eval 'ZnServer startDefaultOn: 8080. [1 hour asDelay wait] repeat.' >> >> Can anyone confirm this ? Maybe with another example ? >> >> It is a bit hard to debug: nothing happens with --no-quit, no error, no log fileâ¦ >> >> Sven >> >> >> > >

Aug. 15, 2013

Re: [Pharo-dev] Uniformizing Pharo

by StÃ©phane Ducasse

On Aug 14, 2013, at 9:26 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > ah looks very nice, indeed much more powerful than my hack. > If you have time, switch to real regular expressions, because things like >> add: (MethodCategorizationRule whenSelectorMatches: 'as*' categorizeIn: #converting); > will easily produce false positives. For instance #assert: will end up in converting, which is not what you want ;) > => /as[A-Z][a-zA-Z]*/ for instance does a much better job Ok thanks for the idea. I will.

Aug. 15, 2013

XML writer in the default image

by Camillo Bruni

As reported a while ago (https://pharo.fogbugz.com/default.asp?7412#80347) the TestRunner is crashing when test failures accidentally spit out XML sensitive characters: https://ci.inria.fr/pharo/view/all/job/Pharo-3.0-Regression-Tests/304/VM=vm… I don't really see a reason to generate XML by concatenating strings, so I wonder whether we could include the XMLWriter in the default image? This way I could finally fix the HDTestRunner with very little effort.

Aug. 15, 2013

Re: [Pharo-dev] --no-quit option of eval command handler broken ?

by Camillo Bruni

I can confirm. However, if you save the image in interactive mode it works again. On 2013-08-14, at 17:09, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > I have the impression that the --no-quit option of the eval command line handler is broken in 3.0 latest. > > This used to work > > ./pharo Pharo.image --no-quit eval 'ZnServer startDefaultOn: 8080.' > > while now, only this works > > ./pharo Pharo.image eval 'ZnServer startDefaultOn: 8080. [1 hour asDelay wait] repeat.' > > Can anyone confirm this ? Maybe with another example ? > > It is a bit hard to debug: nothing happens with --no-quit, no error, no log fileâ¦ > > Sven > > >

Aug. 14, 2013

--no-quit option of eval command handler broken ?

by Sven Van Caekenberghe

Hi, I have the impression that the --no-quit option of the eval command line handler is broken in 3.0 latest. This used to work ./pharo Pharo.image --no-quit eval 'ZnServer startDefaultOn: 8080.' while now, only this works ./pharo Pharo.image eval 'ZnServer startDefaultOn: 8080. [1 hour asDelay wait] repeat.' Can anyone confirm this ? Maybe with another example ? It is a bit hard to debug: nothing happens with --no-quit, no error, no log fileâ¦ Sven

Aug. 14, 2013

Re: [Pharo-dev] Uniformizing Pharo

by Camillo Bruni

ah looks very nice, indeed much more powerful than my hack. If you have time, switch to real regular expressions, because things like > add: (MethodCategorizationRule whenSelectorMatches: 'as*' categorizeIn: #converting); will easily produce false positives. For instance #assert: will end up in converting, which is not what you want ;) => /as[A-Z][a-zA-Z]*/ for instance does a much better job On 2013-08-14, at 15:24, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Ok I checked and I prefer the one I used because you can express nice rules :) > My next step will be to check the tests again, hack/replace the methodClassifier and code with the hacked version for a while > and push everything in the system. Now I will look to see how to make them polymorphic because the classifier is simpler > > Here is the default rules list (I added bench from the other list). > > What is nice is that > - we can express that the superclass should be used in last resort > - I filtered the extensions for now. > > > > defaultCategorizationRules > > "The order is relevant, the categorizer uses the first rule matching - DF" > > ^OrderedCollection new > add: MethodCategorizationRule forAccessors; > > "initialize" > add: (MethodCategorizationRule whenSelectorMatches: 'initialize*' categorizeIn: #initialization); > add: (MethodCategorizationRule whenSelectorMatches: 'init*' categorizeIn: #initialization); > add: (MethodCategorizationRule whenSelectorMatches: 'default*' categorizeIn: #defaults); > > add: (MethodCategorizationRule whenSelectorMatches: 'as*' categorizeIn: #converting); > add: (MethodCategorizationRule whenSelectorMatches: 'hash' categorizeIn: #comparing); > "order is important" > > "testing" > add: (MethodCategorizationRule whenSelectorMatches: 'is*' categorizeIn: #testing); > add: (MethodCategorizationRule whenSelectorMatches: 'has*' categorizeIn: #testing); > > add: (MethodCategorizationRule whenSelectorMatches: '=' categorizeIn: #comparing); > > > add: (MethodCategorizationRule whenSelectorMatches: 'new' categorizeIn: #'instance creation'); > add: (MethodCategorizationRule whenSelectorMatches: 'setting' categorizeIn: #'settings'); > > add: (MethodCategorizationRule whenSelectorMatches: 'printOn:' categorizeIn: #printing); > add: (MethodCategorizationRule whenSelectorMatches: 'storeOn:' categorizeIn: #printing); > > add: (MethodCategorizationRule whenSelectorMatches: '*copy*' categorizeIn: #copying); > > add: (MethodCategorizationRule whenSelectorMatches: 'draw*' categorizeIn: #drawing); > add: (MethodCategorizationRule whenSelectorMatches: 'bench*' categorizeIn: #benchmarking); > add: (MethodCategorizationRule whenSelectorMatches: 'signal*' categorizeIn: #signalling); > add: (MethodCategorizationRule whenSelectorMatches: 'add*' categorizeIn: #adding); > add: (MethodCategorizationRule whenSelectorMatches: 'remove*' categorizeIn: #adding); > > add: (MethodCategorizationRule whenSelectorMatches: 'open*' categorizeIn: #opening); > add: (MethodCategorizationRule whenSelectorMatches: 'update*' categorizeIn: #updating); > add: (MethodCategorizationRule whenSelectorMatches: 'change*' categorizeIn: #updating); > > add: (MethodCategorizationRule whenSelectorMatches: 'accept*' categorizeIn: #'visitor accepting'); > add: (MethodCategorizationRule whenSelectorMatches: 'visit*' categorizeIn: #visiting); > > add: (MethodCategorizationRule whenSelectorMatches: 'menu*' categorizeIn: #menus); > > add: (MethodCategorizationRule whenSelectorMatches: 'value' categorizeIn: #value); > > "test cases" > add: (MethodCategorizationRule > whenSelectorMatches: 'test*' > andClassInheritsFrom: TestCase > categorizeIn: #tests); > > add: (MethodCategorizationRule > whenSelectorMatches: 'setUp' > andClassInheritsFrom: TestCase > categorizeIn: #'setup'); > add: (MethodCategorizationRule > whenSelectorMatches: 'tearDown' > andClassInheritsFrom: TestCase > categorizeIn: #'setup'); > > "baselines, versions..." > add: (MethodCategorizationRule > whenSelectorMatches: 'version*' > andClassMatches: 'ConfigurationOf*' > categorizeIn: #'versions'); > add: (MethodCategorizationRule > whenSelectorMatches: 'baseline*' > andClassMatches: 'ConfigurationOf*' > categorizeIn: #'baselines'); > add: (MethodCategorizationRule > whenSelectorMatches: 'development*' > andClassMatches: 'ConfigurationOf*' > categorizeIn: #'symbolic'); > add: (MethodCategorizationRule > whenSelectorMatches: 'stable*' > andClassMatches: 'ConfigurationOf*' > categorizeIn: #'symbolic'); > > > > add: MethodCategorizationRule usingMostUsedCategoryInSuperClasses; > add: MethodCategorizationRule usingMostUsedCategoryInImage; > yourself > >>> Did you use the method categorizer that is already in the image? >>> >>> => MethodClassifier >>> >>> it implements already a lot of rules, so you should plug in your tool there or remove MethodClassifier and make it work with nautilus. otherwise we have a lot of duplicated functionality. >> >> I was not aware of it I will look at it. >> In fact there was a method categorizer in a nice package with tests and I took this one and adapted it. >> I will check the rules. >> >> Stef >> >> > >

Aug. 14, 2013

Re: [Pharo-dev] Uniformizing Pharo

by StÃ©phane Ducasse

Ok I checked and I prefer the one I used because you can express nice rules :) My next step will be to check the tests again, hack/replace the methodClassifier and code with the hacked version for a while and push everything in the system. Now I will look to see how to make them polymorphic because the classifier is simpler Here is the default rules list (I added bench from the other list). What is nice is that - we can express that the superclass should be used in last resort - I filtered the extensions for now. defaultCategorizationRules "The order is relevant, the categorizer uses the first rule matching - DF" ^OrderedCollection new add: MethodCategorizationRule forAccessors; "initialize" add: (MethodCategorizationRule whenSelectorMatches: 'initialize*' categorizeIn: #initialization); add: (MethodCategorizationRule whenSelectorMatches: 'init*' categorizeIn: #initialization); add: (MethodCategorizationRule whenSelectorMatches: 'default*' categorizeIn: #defaults); add: (MethodCategorizationRule whenSelectorMatches: 'as*' categorizeIn: #converting); add: (MethodCategorizationRule whenSelectorMatches: 'hash' categorizeIn: #comparing); "order is important" "testing" add: (MethodCategorizationRule whenSelectorMatches: 'is*' categorizeIn: #testing); add: (MethodCategorizationRule whenSelectorMatches: 'has*' categorizeIn: #testing); add: (MethodCategorizationRule whenSelectorMatches: '=' categorizeIn: #comparing); add: (MethodCategorizationRule whenSelectorMatches: 'new' categorizeIn: #'instance creation'); add: (MethodCategorizationRule whenSelectorMatches: 'setting' categorizeIn: #'settings'); add: (MethodCategorizationRule whenSelectorMatches: 'printOn:' categorizeIn: #printing); add: (MethodCategorizationRule whenSelectorMatches: 'storeOn:' categorizeIn: #printing); add: (MethodCategorizationRule whenSelectorMatches: '*copy*' categorizeIn: #copying); add: (MethodCategorizationRule whenSelectorMatches: 'draw*' categorizeIn: #drawing); add: (MethodCategorizationRule whenSelectorMatches: 'bench*' categorizeIn: #benchmarking); add: (MethodCategorizationRule whenSelectorMatches: 'signal*' categorizeIn: #signalling); add: (MethodCategorizationRule whenSelectorMatches: 'add*' categorizeIn: #adding); add: (MethodCategorizationRule whenSelectorMatches: 'remove*' categorizeIn: #adding); add: (MethodCategorizationRule whenSelectorMatches: 'open*' categorizeIn: #opening); add: (MethodCategorizationRule whenSelectorMatches: 'update*' categorizeIn: #updating); add: (MethodCategorizationRule whenSelectorMatches: 'change*' categorizeIn: #updating); add: (MethodCategorizationRule whenSelectorMatches: 'accept*' categorizeIn: #'visitor accepting'); add: (MethodCategorizationRule whenSelectorMatches: 'visit*' categorizeIn: #visiting); add: (MethodCategorizationRule whenSelectorMatches: 'menu*' categorizeIn: #menus); add: (MethodCategorizationRule whenSelectorMatches: 'value' categorizeIn: #value); "test cases" add: (MethodCategorizationRule whenSelectorMatches: 'test*' andClassInheritsFrom: TestCase categorizeIn: #tests); add: (MethodCategorizationRule whenSelectorMatches: 'setUp' andClassInheritsFrom: TestCase categorizeIn: #'setup'); add: (MethodCategorizationRule whenSelectorMatches: 'tearDown' andClassInheritsFrom: TestCase categorizeIn: #'setup'); "baselines, versions..." add: (MethodCategorizationRule whenSelectorMatches: 'version*' andClassMatches: 'ConfigurationOf*' categorizeIn: #'versions'); add: (MethodCategorizationRule whenSelectorMatches: 'baseline*' andClassMatches: 'ConfigurationOf*' categorizeIn: #'baselines'); add: (MethodCategorizationRule whenSelectorMatches: 'development*' andClassMatches: 'ConfigurationOf*' categorizeIn: #'symbolic'); add: (MethodCategorizationRule whenSelectorMatches: 'stable*' andClassMatches: 'ConfigurationOf*' categorizeIn: #'symbolic'); add: MethodCategorizationRule usingMostUsedCategoryInSuperClasses; add: MethodCategorizationRule usingMostUsedCategoryInImage; yourself >> Did you use the method categorizer that is already in the image? >> >> => MethodClassifier >> >> it implements already a lot of rules, so you should plug in your tool there or remove MethodClassifier and make it work with nautilus. otherwise we have a lot of duplicated functionality. > > I was not aware of it I will look at it. > In fact there was a method categorizer in a nice package with tests and I took this one and adapted it. > I will check the rules. > > Stef > >

Aug. 14, 2013

Re: [Pharo-dev] Uniformizing Pharo

by StÃ©phane Ducasse

> Did you use the method categorizer that is already in the image? > > => MethodClassifier > > it implements already a lot of rules, so you should plug in your tool there or remove MethodClassifier and make it work with nautilus. otherwise we have a lot of duplicated functionality. I was not aware of it I will look at it. In fact there was a method categorizer in a nice package with tests and I took this one and adapted it. I will check the rules. Stef

Aug. 14, 2013

Re: [Pharo-dev] Uniformizing Pharo

by Camillo Bruni

Did you use the method categorizer that is already in the image? => MethodClassifier it implements already a lot of rules, so you should plug in your tool there or remove MethodClassifier and make it work with nautilus. otherwise we have a lot of duplicated functionality. On 2013-08-14, at 02:44, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > On Aug 14, 2013, at 4:38 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> i wonder, if we can modify the compiler, so that when it sees that >> method's selector has well known name, it categorizing method >> automatically under right category :) >> (dunno however, what to do about existing code, when you recompiling it) > > we will integrate the categorizer close to the code browser and may be later the compiler > > >> >> On 14 August 2013 04:32, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>> StÃ©phane Ducasse wrote >>>> I started to be fed up about protocol inconsistencies >>> >>> Amen >>> >>> >>> StÃ©phane Ducasse wrote >>>> So I will propose a set of rules (and a tool - I'm working on it) to >>>> automatically categorize methods. >>>> ... >>>> Now we discussed today with esteban for initialize* we will use >>>> 'initialization' >>> >>> Yay! >>> >>> >>> >>> ----- >>> Cheers, >>> Sean >>> -- >>> View this message in context: http://forum.world.st/Uniformizing-Pharo-tp4703357p4703577.html >>> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > >

Aug. 14, 2013

[update 3.0] #30336

by StÃ©phane Ducasse

Aug. 14, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=win/… 1 regressions found. Zinc.Zodiac.ZnHTTPSTests.testGetPharoVersion

Aug. 14, 2013

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

by StÃ©phane Ducasse

Thanks for the feedback. Please let us know if you find problemsâ¦. because we could not find the original code which was probably never in the source management. So we really enjoy seeing your code running on Pharo :) Stef On Aug 14, 2013, at 1:06 PM, NISHIHARA Satoshi <goonsh(a)gmail.com> wrote: > I've just noticed github message > - added missing methods for SerialPlugin > https://github.com/pharo-project/pharovm/commit/f7c0b24ffde391c93fc479ab7ba… > > and tested MIDIPlugin with 214 VM and Pharo-20618.image. > IT WORKS! > > thank you!! > > > > 2013/8/5 Igor Stasenko <siguctua(a)gmail.com>: >> 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. >> > > > > -- > -- > "NISHIHARA Satoshi" > [:goonsh :nsh | ^ nishis perform: goonsh with: nsh] > <System Reporter2.png>

Aug. 14, 2013

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

by Esteban Lorenzano

Ah yes... I forget to send a mail to the list, but I spent monday fixing the MIDI plugin :P cool to know that it worked! Esteban On Aug 14, 2013, at 1:06 PM, NISHIHARA Satoshi <goonsh(a)gmail.com> wrote: > I've just noticed github message > - added missing methods for SerialPlugin > https://github.com/pharo-project/pharovm/commit/f7c0b24ffde391c93fc479ab7ba… > > and tested MIDIPlugin with 214 VM and Pharo-20618.image. > IT WORKS! > > thank you!! > > > > 2013/8/5 Igor Stasenko <siguctua(a)gmail.com>: >> 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. >> > > > > -- > -- > "NISHIHARA Satoshi" > [:goonsh :nsh | ^ nishis perform: goonsh with: nsh] > <System Reporter2.png>

Aug. 14, 2013

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

by NISHIHARA Satoshi

I've just noticed github message - added missing methods for SerialPlugin https://github.com/pharo-project/pharovm/commit/f7c0b24ffde391c93fc479ab7ba… and tested MIDIPlugin with 214 VM and Pharo-20618.image. IT WORKS! thank you!! 2013/8/5 Igor Stasenko <siguctua(a)gmail.com>: > 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. > -- -- "NISHIHARA Satoshi" [:goonsh :nsh | ^ nishis perform: goonsh with: nsh]

Aug. 14, 2013

Re: [Pharo-dev] inria jenkins got much faster

by Tudor Girba

Yes, we are always using the latest :). I just saw now the report about #20619. http://permalink.gmane.org/gmane.comp.lang.smalltalk.pharo.devel/81515 Wow, this is a phenomenal boost! Thank you very much. Doru On Wed, Aug 14, 2013 at 11:46 AM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > if you are using latest 2.0, that's probably because the integration of > the RPackageSet cache. > the previous slowdown was exponential, so big projects like moose took > *really* much time to load. > > Esteban > > > On Aug 14, 2013, at 11:43 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > I just noticed that the Jenkins jobs got much faster. For example, the > Moose job went from 36 minutes to 6 minutes. Or the Glamour job went from > 11 minutes to 3 minutes. This is fantastic, but I do not know why the > difference occurs. > > It seems that the difference started yesterday before 15:00: > https://ci.inria.fr/moose/job/moose-latest-dev-4.8/871/ (15:49 -- 6 min) > https://ci.inria.fr/moose/job/moose-latest-dev-4.8/870/ (02:49 -- 36 min) > > As it affected multiple jobs, I suspect it has to do with the > infrastructure. > > Anyone has any idea as to why this happens? > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 14, 2013

Re: [Pharo-dev] Updating the Pharo Contributors listing

by Sven Van Caekenberghe

Many people already submitted their details and I edited a couple of entries manually to add at least an email address, so the list is already looking better: http://contributors.pharo.org Please spread the word and convince everyone to step in and update their info. On 12 Aug 2013, at 17:12, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Dear Fellow Pharoers, > > As some of you may know, we have a page listing Pharo Contributors > > http://www.pharo-project.org/community/contributors > > This page was manually constructed and urgently needs an update. > Based on the code behind the Pharo Consultants page > > http://consultants.pharo.org > > we want a similar data driven, statically generated page for Pharo Contributors > > http://contributors.pharo.org > > the new page is based on some of the old data, but needs updating. Many people are missing as well. So please, please, edit the template and send me your new or up to date information. > > PharoContributor new > name: 'StÃ©phane Ducasse'; > id: 'stephaneducasse'; > email: 'stephane.ducasse(a)inria.fr'; > website: 'http://stephane.ducasse.free.fr/'; > description: 'Research director at INRIA Lille leading the RMoD Team. Pharo board member and president of ESUG.'; > image: 'http://stephane.ducasse.free.fr/StefFingerOnNose128.jpg'; > yourself > > PharoContributor new > name: 'Camillo Bruni'; > email: 'camillobruni(a)gmail.com'; > description: 'Cosmopolitan Swiss Hacker, currently at INRIA'; > yourself > > Some notes: > > - id is only needed when your name contains non-ascii characters > - email will default to pharo-dev(a)lists.pharo.org if missing > - website will default to a Google search for your name if a URL is missing > - image can be omitted if you have a Gravatar, else it becomes a smiley > - images will be rescaled to fit in 128x128, the URL needs to remain accessible > - description is a pure text String, no markup is allowed > - the description does not have to be too formal > - the page is statically generated, only then do changes take effect > > Regards, > > Sven, on behalf of the Pharo Board. > > PS: If you are curious, the code for generating this page can be found at > > http://www.smalltalkhub.com/#!/~Pharo/PharoPeople >

Aug. 14, 2013

Re: [Pharo-dev] inria jenkins got much faster

by Esteban Lorenzano

if you are using latest 2.0, that's probably because the integration of the RPackageSet cache. the previous slowdown was exponential, so big projects like moose took *really* much time to load. Esteban On Aug 14, 2013, at 11:43 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I just noticed that the Jenkins jobs got much faster. For example, the Moose job went from 36 minutes to 6 minutes. Or the Glamour job went from 11 minutes to 3 minutes. This is fantastic, but I do not know why the difference occurs. > > It seems that the difference started yesterday before 15:00: > https://ci.inria.fr/moose/job/moose-latest-dev-4.8/871/ (15:49 -- 6 min) > https://ci.inria.fr/moose/job/moose-latest-dev-4.8/870/ (02:49 -- 36 min) > > As it affected multiple jobs, I suspect it has to do with the infrastructure. > > Anyone has any idea as to why this happens? > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Aug. 14, 2013

Re: [Pharo-dev] inria jenkins got much faster

by Sven Van Caekenberghe

On 14 Aug 2013, at 11:43, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I just noticed that the Jenkins jobs got much faster. For example, the Moose job went from 36 minutes to 6 minutes. Or the Glamour job went from 11 minutes to 3 minutes. This is fantastic, but I do not know why the difference occurs. > > It seems that the difference started yesterday before 15:00: > https://ci.inria.fr/moose/job/moose-latest-dev-4.8/871/ (15:49 -- 6 min) > https://ci.inria.fr/moose/job/moose-latest-dev-4.8/870/ (02:49 -- 36 min) > > As it affected multiple jobs, I suspect it has to do with the infrastructure. > > Anyone has any idea as to why this happens? Is it not related to the RPackage caching that significantly improves code loading ? > Cheers, > Doru > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Aug. 14, 2013

inria jenkins got much faster

by Tudor Girba

Hi, I just noticed that the Jenkins jobs got much faster. For example, the Moose job went from 36 minutes to 6 minutes. Or the Glamour job went from 11 minutes to 3 minutes. This is fantastic, but I do not know why the difference occurs. It seems that the difference started yesterday before 15:00: https://ci.inria.fr/moose/job/moose-latest-dev-4.8/871/ (15:49 -- 6 min) https://ci.inria.fr/moose/job/moose-latest-dev-4.8/870/ (02:49 -- 36 min) As it affected multiple jobs, I suspect it has to do with the infrastructure. Anyone has any idea as to why this happens? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

Aug. 14, 2013

Re: [Pharo-dev] [update 3.0] #30334

by StÃ©phane Ducasse

yes I saw it too On Aug 14, 2013, at 10:23 AM, Sebastian Tleye <stleye(a)gmail.com> wrote: > I think 11417 was not well integrated, the changes are not in the latest image. > > > 2013/8/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > [update 3.0] #30334 > 30334 > ----- > > - issue 11418 RBBrowserEnvironment definesClass: is unfinished > https://pharo.fogbugz.com/default.asp?11418 > > - issue 11417 Test for checking repeated code in superclasses must not watch in nativeBoost classes > https://pharo.fogbugz.com/default.asp?11417 > > - issue 11415 More green tests for BehaviorTest and MetaclassTest > https://pharo.fogbugz.com/default.asp?11415 > Diff information: > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tests-StephaneDucasse.609.diff > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Environment-Steph… > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Critics-StephaneD… > http://smalltalkhub.com/mc/Pharo/Pharo30/main/NativeBoost-Tests-StephaneDuc… > http://smalltalkhub.com/mc/Pharo/Pharo30/main/KernelTests-StephaneDucasse.5… > http://smalltalkhub.com/mc/Pharo/Pharo30/main/HudsonBuildTools20-StephaneDu… > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Generated-code-non-existing-p… > > >

Aug. 14, 2013

[update 3.0] #30335

by StÃ©phane Ducasse

30335 ----- - issue 11415 More green tests for BehaviorTest and MetaclassTest https://pharo.fogbugz.com/default.asp?11415 - issue 11406 Cleaning categories: Object https://pharo.fogbugz.com/default.asp?11406 - issue 11251 Add coherent icons set for up/down/top/bottom actions https://pharo.fogbugz.com/default.asp?11251 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-StephaneDuc… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Nautilus-StephaneDucasse.512.… http://smalltalkhub.com/mc/Pharo/Pharo30/main/KernelTests-StephaneDucasse.5… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-StephaneDucasse.1560.d…

Aug. 14, 2013

Re: [Pharo-dev] [update 3.0] #30334

by Sebastian Tleye

I think 11417 was not well integrated, the changes are not in the latest image. 2013/8/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > [update 3.0] #30334 > 30334 > ----- > > - issue 11418 RBBrowserEnvironment definesClass: is unfinished > https://pharo.fogbugz.com/default.asp?11418 > > - issue 11417 Test for checking repeated code in superclasses must not > watch in nativeBoost classes > https://pharo.fogbugz.com/default.asp?11417 > > - issue 11415 More green tests for BehaviorTest and MetaclassTest > https://pharo.fogbugz.com/default.asp?11415 > Diff information: > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tests-StephaneDucasse.609.diff > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Environment-Steph… > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Critics-StephaneD… > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/NativeBoost-Tests-StephaneDuc… > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/KernelTests-StephaneDucasse.5… > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/HudsonBuildTools20-StephaneDu… > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Generated-code-non-existing-p… > > >

Aug. 14, 2013

Re: [Pharo-dev] The point of extending NativeBoost-Win32 more than neccessary?

by StÃ©phane Ducasse

On Aug 14, 2013, at 4:05 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 14 August 2013 00:57, Torsten Bergmann <astares(a)gmx.de> wrote: >> Hi Igor, >> >> I dont see this neither as "destructive" nor as "critics", especially since: >> >> - you initially started to add things to NB that were more or less API wrappers instead of real Core NB functionality ;) >> >> - I see the same risk for overloading NB and wanted to start the same discussion next time we meet on Skype. >> In the long term the distinction just by having different categories (core vs OS specific) will also in my opinion >> only be a workaround in need for better modularization or one/many separate platform specific projects >> >> As you know I already suggested to refactor tests to separate OS dependent stuff from core tests and I have >> more ideas for better modularization with the same idea of moving this to independent projects. >> >> I would suggest: >> >> 1. NB really just includes the core functionality of an external interface (FFI), including the support for calls >> and callbacks. Other projects can then build on top of it and it helps to keep it small for the Pharo image. >> >> 2. We pull out the OS specific stuff (for instance Win32) into real own project to provide more native API >> functionality. Such an API wrapper project is then not part of NB and therefore also not part of the standard Pharo >> image. We can make it accessible via a Configurations that are easily loadable from the config browser. >> I will do that as soon as time permits. >> >> 3. If others jump onto the bandwagon and put their API bindings for their favorite OS/platform (GTK, Linux, Mac, ...) >> we may later be able to implement/abstract a common layer API that depending on the loaded OS code provides >> native functionality but still allows platform independence of calling code. >> I mean something similar to SWT in Eclipse if you know what I'm talking about. In pseudocode this would >> mean to have: >> >> OSWindow new open >> >> while this is just a facade and dependent on the OS and loaded native support the underlying Win32, Mac or Linux >> API's for opening a Window are used. >> >> Regarding last changes/commits: >> As you will see in the repo I merged Stefs and your version of core and added #= to compare external handles. >> Will also write a test for it when theres the next minute. >> >> I also "bloated" or "enhanced" (depending on POV) it with more wrappers for Win32 (POINT, window functions, >> Process, Threads) which I will soon move to an own project on STHub so we can safely remove it from NB. >> Just be a little bit patient for the next possible time slot. >> > > Good to know that we are aligned in our vision. > >> Two wishes from my side if there is a timeslot/minute on your side: I would really appreciate a working >> example for opening a native Window as you started with NBWin32Window. Since a callback for the window procedure >> is required it would serve as a good example for callbacks too. It would also help if the proper marshalling >> for the WideStrings could be provided since this would allow to use more API's and even implement a COM binding. > > Window callbacks is ones that very tricky (and ones which usually most > important ones). > Because they called not at the moment when you call some external > function, but at the moment > when VM handling events (during interrupt). > >> You wanted to check if the methods necessary for the marshalling were removed or have to be implemented... > > Yes, i will check, but i suspect it don't exists :) > >> >> Thx >> T. > > > > -- > Best regards, > Igor Stasenko. >

Aug. 14, 2013

Re: [Pharo-dev] Uniformizing Pharo

by StÃ©phane Ducasse

On Aug 14, 2013, at 4:38 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > i wonder, if we can modify the compiler, so that when it sees that > method's selector has well known name, it categorizing method > automatically under right category :) > (dunno however, what to do about existing code, when you recompiling it) we will integrate the categorizer close to the code browser and may be later the compiler > > On 14 August 2013 04:32, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> StÃ©phane Ducasse wrote >>> I started to be fed up about protocol inconsistencies >> >> Amen >> >> >> StÃ©phane Ducasse wrote >>> So I will propose a set of rules (and a tool - I'm working on it) to >>> automatically categorize methods. >>> ... >>> Now we discussed today with esteban for initialize* we will use >>> 'initialization' >> >> Yay! >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/Uniformizing-Pharo-tp4703357p4703577.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> > > > > -- > Best regards, > Igor Stasenko. >

Aug. 14, 2013

Re: [Pharo-dev] Uniformizing Pharo

by ClÃ©ment Bera

2013/8/14 Igor Stasenko <siguctua(a)gmail.com> > i wonder, if we can modify the compiler, so that when it sees that > method's selector has well known name, it categorizing method > automatically under right category :) > (dunno however, what to do about existing code, when you recompiling it) > This is possible but I don't think it belongs to the compiler to do that. I would rather modify Behavior so when it adds a method with no protocol it categorize it efficiently according to its superclasses / subclasses selectors and protocols.. > > On 14 August 2013 04:32, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > StÃ©phane Ducasse wrote > >> I started to be fed up about protocol inconsistencies > > > > Amen > > > > > > StÃ©phane Ducasse wrote > >> So I will propose a set of rules (and a tool - I'm working on it) to > >> automatically categorize methods. > >> ... > >> Now we discussed today with esteban for initialize* we will use > >> 'initialization' > > > > Yay! > > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: > http://forum.world.st/Uniformizing-Pharo-tp4703357p4703577.html > > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > > > -- > Best regards, > Igor Stasenko. > >

Aug. 14, 2013

Re: [Pharo-dev] Access to issue tracker?

by Javier PimÃ¡s

Cool, it worked. Went to "forgot password", put the registered email and received a link to change my pass. Thanks! Just to note, the http link doesn't work for me, but using https instead works ok. On Tue, Aug 13, 2013 at 11:38 AM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > I never tried the monkey/registration page. > But you should be able to login here: http://pharo.fogbugz.org > > - reset your password (since you don't have one yet) > - login at http://pharo.fogbugz.org > > I hope that helps. > > On 2013-08-13, at 01:01, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> > wrote: > > Same here > > > > El 13/08/2013 0:34, Javier PimÃ¡s escribiÃ³: > >> Hi, I don't know if it's just me or if I'm doing something wrong but I > >> was never able to get a user for the issue tracker. I enter here > >> <http://bugs.pharo.org/issues/register>, put a username, an email and > >> tick the not a monkey box in order to create an account. It redirects me > >> here <https://pharo.fogbugz.com/> but I never get a mail or anything I > >> could use to login, what I am doing wrong? > >> > >> Cheers, > >> Javier > >> > >> -- > >> Lic. Javier PimÃ¡s > >> Ciudad de Buenos Aires > > > > > > > -- Lic. Javier PimÃ¡s Ciudad de Buenos Aires

Aug. 14, 2013

Re: [Pharo-dev] Uniformizing Pharo

by Igor Stasenko

i wonder, if we can modify the compiler, so that when it sees that method's selector has well known name, it categorizing method automatically under right category :) (dunno however, what to do about existing code, when you recompiling it) On 14 August 2013 04:32, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > StÃ©phane Ducasse wrote >> I started to be fed up about protocol inconsistencies > > Amen > > > StÃ©phane Ducasse wrote >> So I will propose a set of rules (and a tool - I'm working on it) to >> automatically categorize methods. >> ... >> Now we discussed today with esteban for initialize* we will use >> 'initialization' > > Yay! > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Uniformizing-Pharo-tp4703357p4703577.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

Aug. 14, 2013

Re: [Pharo-dev] Uniformizing Pharo

by Sean P. DeNigris

StÃ©phane Ducasse wrote > I started to be fed up about protocol inconsistencies Amen StÃ©phane Ducasse wrote > So I will propose a set of rules (and a tool - I'm working on it) to > automatically categorize methods. > ... > Now we discussed today with esteban for initialize* we will use > 'initialization' Yay! ----- Cheers, Sean -- View this message in context: http://forum.world.st/Uniformizing-Pharo-tp4703357p4703577.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 14, 2013

Re: [Pharo-dev] The point of extending NativeBoost-Win32 more than neccessary?

by Igor Stasenko

On 14 August 2013 00:57, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi Igor, > > I dont see this neither as "destructive" nor as "critics", especially since: > > - you initially started to add things to NB that were more or less API wrappers instead of real Core NB functionality ;) > > - I see the same risk for overloading NB and wanted to start the same discussion next time we meet on Skype. > In the long term the distinction just by having different categories (core vs OS specific) will also in my opinion > only be a workaround in need for better modularization or one/many separate platform specific projects > > As you know I already suggested to refactor tests to separate OS dependent stuff from core tests and I have > more ideas for better modularization with the same idea of moving this to independent projects. > > I would suggest: > > 1. NB really just includes the core functionality of an external interface (FFI), including the support for calls > and callbacks. Other projects can then build on top of it and it helps to keep it small for the Pharo image. > > 2. We pull out the OS specific stuff (for instance Win32) into real own project to provide more native API > functionality. Such an API wrapper project is then not part of NB and therefore also not part of the standard Pharo > image. We can make it accessible via a Configurations that are easily loadable from the config browser. > I will do that as soon as time permits. > > 3. If others jump onto the bandwagon and put their API bindings for their favorite OS/platform (GTK, Linux, Mac, ...) > we may later be able to implement/abstract a common layer API that depending on the loaded OS code provides > native functionality but still allows platform independence of calling code. > I mean something similar to SWT in Eclipse if you know what I'm talking about. In pseudocode this would > mean to have: > > OSWindow new open > > while this is just a facade and dependent on the OS and loaded native support the underlying Win32, Mac or Linux > API's for opening a Window are used. > > Regarding last changes/commits: > As you will see in the repo I merged Stefs and your version of core and added #= to compare external handles. > Will also write a test for it when theres the next minute. > > I also "bloated" or "enhanced" (depending on POV) it with more wrappers for Win32 (POINT, window functions, > Process, Threads) which I will soon move to an own project on STHub so we can safely remove it from NB. > Just be a little bit patient for the next possible time slot. > Good to know that we are aligned in our vision. > Two wishes from my side if there is a timeslot/minute on your side: I would really appreciate a working > example for opening a native Window as you started with NBWin32Window. Since a callback for the window procedure > is required it would serve as a good example for callbacks too. It would also help if the proper marshalling > for the WideStrings could be provided since this would allow to use more API's and even implement a COM binding. Window callbacks is ones that very tricky (and ones which usually most important ones). Because they called not at the moment when you call some external function, but at the moment when VM handling events (during interrupt). > You wanted to check if the methods necessary for the marshalling were removed or have to be implemented... Yes, i will check, but i suspect it don't exists :) > > Thx > T. -- Best regards, Igor Stasenko.

Aug. 14, 2013

Re: [Pharo-dev] The point of extending NativeBoost-Win32 more than neccessary?

by Torsten Bergmann

Hi Igor, I dont see this neither as "destructive" nor as "critics", especially since: - you initially started to add things to NB that were more or less API wrappers instead of real Core NB functionality ;) - I see the same risk for overloading NB and wanted to start the same discussion next time we meet on Skype. In the long term the distinction just by having different categories (core vs OS specific) will also in my opinion only be a workaround in need for better modularization or one/many separate platform specific projects As you know I already suggested to refactor tests to separate OS dependent stuff from core tests and I have more ideas for better modularization with the same idea of moving this to independent projects. I would suggest: 1. NB really just includes the core functionality of an external interface (FFI), including the support for calls and callbacks. Other projects can then build on top of it and it helps to keep it small for the Pharo image. 2. We pull out the OS specific stuff (for instance Win32) into real own project to provide more native API functionality. Such an API wrapper project is then not part of NB and therefore also not part of the standard Pharo image. We can make it accessible via a Configurations that are easily loadable from the config browser. I will do that as soon as time permits. 3. If others jump onto the bandwagon and put their API bindings for their favorite OS/platform (GTK, Linux, Mac, ...) we may later be able to implement/abstract a common layer API that depending on the loaded OS code provides native functionality but still allows platform independence of calling code. I mean something similar to SWT in Eclipse if you know what I'm talking about. In pseudocode this would mean to have: OSWindow new open while this is just a facade and dependent on the OS and loaded native support the underlying Win32, Mac or Linux API's for opening a Window are used. Regarding last changes/commits: As you will see in the repo I merged Stefs and your version of core and added #= to compare external handles. Will also write a test for it when theres the next minute. I also "bloated" or "enhanced" (depending on POV) it with more wrappers for Win32 (POINT, window functions, Process, Threads) which I will soon move to an own project on STHub so we can safely remove it from NB. Just be a little bit patient for the next possible time slot. Two wishes from my side if there is a timeslot/minute on your side: I would really appreciate a working example for opening a native Window as you started with NBWin32Window. Since a callback for the window procedure is required it would serve as a good example for callbacks too. It would also help if the proper marshalling for the WideStrings could be provided since this would allow to use more API's and even implement a COM binding. You wanted to check if the methods necessary for the marshalling were removed or have to be implemented... Thx T.

Aug. 13, 2013

do we need MCSnapshotBrowserTest

by StÃ©phane Ducasse

Frankly I do not see the added value of this test, except that we should maintain it. Stef

Aug. 13, 2013

Re: [Pharo-dev] Checking your Gravatar

by Sven Van Caekenberghe

On 13 Aug 2013, at 22:53, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I could not resist: here is a little blog post about removing your troublesome morph :) > > http://www.humane-assessment.com/blog/spotting-a-troublesome-image-morph Nice! > Cheers, > Doru > > > > > On Tue, Aug 13, 2013 at 2:21 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > This one is more fun > > (ImageMorph fromStream:( > ZnClient new > beOneShot; > url: 'http://www.gravatar.com/avatar'; > addPathSegment: (ZnDigestAuthenticator md5Hash: 'marianopeck(a)gmail.com'); > queryAt: #s put: '128'; > queryAt: #d put: '404'; > get) readStream) openInWorld > > > uhhh but I cannot remove the morph from the world....damn it! > > > On Mon, Aug 12, 2013 at 7:46 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > Related to the usage of Gravatars (http://en.wikipedia.org/wiki/Gravatar) for http://contributors.pharo.org here is some code you can use to check whether your Gravatar image really works: > > ZnClient new > beOneShot; > url: 'http://www.gravatar.com/avatar'; > addPathSegment: (ZnDigestAuthenticator md5Hash: 'sven(a)stfx.eu'); > queryAt: #s put: '128'; > queryAt: #d put: '404'; > get; > isSuccess. > > ZnClient new > beOneShot; > url: 'http://www.gravatar.com/avatar'; > addPathSegment: (ZnDigestAuthenticator md5Hash: 'nobody.at.all(a)gmail.com'); > queryAt: #s put: '128'; > queryAt: #d put: '404'; > get; > isSuccess. > > (ZnClient new > enforceHttpSuccess: true; > beOneShot; > url: 'http://www.gravatar.com/avatar'; > addPathSegment: (ZnDigestAuthenticator md5Hash: 'tudor(a)tudorgirba.com'); > queryAt: #s put: '128'; > queryAt: #d put: '404'; > contentReader: [ :entity | ImageMorph fromStream: entity readStream ]; > get) openInWindow. > > And now you know how simple Gravatars really are, provided you use a proper programming language to access them. > > Enjoy! > > Sven > > > > > > -- > Mariano > http://marianopeck.wordpress.com > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Aug. 13, 2013

Re: [Pharo-dev] Checking your Gravatar

by Tudor Girba

Ha. Funny. I actually did not know about Alt+Shift+Click :). I only know the Ctrl+Shift+Click combination to spawn the menu and choose halos from there. Doru On Tue, Aug 13, 2013 at 11:04 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > ok....it's alt (option) + command + shift in my keyword... > you were lucky Doru :) > > > On Tue, Aug 13, 2013 at 6:01 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> I forgot to say..cmd+shift+click doesn't open the halos for me, it just >> "picks" the picture and draws a small shadow and allows me to move the >> picture around... >> bug? >> >> >> On Tue, Aug 13, 2013 at 6:00 PM, Mariano Martinez Peck < >> marianopeck(a)gmail.com> wrote: >> >>> That's so cool Doru :) >>> I arrived at the point of "ImageMorph allInstances size". >>> The "World submorphs select: [:each | each class = ImageMorph]" was a >>> great idea!!! >>> >>> While I appreciate the post and you know I love your inspector, I >>> wonder, isn't there a bug? >>> If I try to open the halos on the picture, it actually takes the World. >>> Is this the expected behavior? >>> >>> Thanks! >>> >>> >>> >>> On Tue, Aug 13, 2013 at 5:53 PM, Tudor Girba <tudor(a)tudorgirba.com>wrote: >>> >>>> Hi, >>>> >>>> I could not resist: here is a little blog post about removing your >>>> troublesome morph :) >>>> >>>> http://www.humane-assessment.com/blog/spotting-a-troublesome-image-morph >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> >>>> >>>> On Tue, Aug 13, 2013 at 2:21 PM, Mariano Martinez Peck < >>>> marianopeck(a)gmail.com> wrote: >>>> >>>>> This one is more fun >>>>> >>>>> (ImageMorph fromStream:( >>>>> ZnClient new >>>>> beOneShot; >>>>> url: 'http://www.gravatar.com/avatar'; >>>>> addPathSegment: (ZnDigestAuthenticator md5Hash: ' >>>>> marianopeck(a)gmail.com'); >>>>> queryAt: #s put: '128'; >>>>> queryAt: #d put: '404'; >>>>> get) readStream) openInWorld >>>>> >>>>> >>>>> uhhh but I cannot remove the morph from the world....damn it! >>>>> >>>>> >>>>> On Mon, Aug 12, 2013 at 7:46 PM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Related to the usage of Gravatars ( >>>>>> http://en.wikipedia.org/wiki/Gravatar) for >>>>>> http://contributors.pharo.org here is some code you can use to check >>>>>> whether your Gravatar image really works: >>>>>> >>>>>> ZnClient new >>>>>> beOneShot; >>>>>> url: 'http://www.gravatar.com/avatar'; >>>>>> addPathSegment: (ZnDigestAuthenticator md5Hash: 'sven(a)stfx.eu'); >>>>>> queryAt: #s put: '128'; >>>>>> queryAt: #d put: '404'; >>>>>> get; >>>>>> isSuccess. >>>>>> >>>>>> ZnClient new >>>>>> beOneShot; >>>>>> url: 'http://www.gravatar.com/avatar'; >>>>>> addPathSegment: (ZnDigestAuthenticator md5Hash: ' >>>>>> nobody.at.all(a)gmail.com'); >>>>>> queryAt: #s put: '128'; >>>>>> queryAt: #d put: '404'; >>>>>> get; >>>>>> isSuccess. >>>>>> >>>>>> (ZnClient new >>>>>> enforceHttpSuccess: true; >>>>>> beOneShot; >>>>>> url: 'http://www.gravatar.com/avatar'; >>>>>> addPathSegment: (ZnDigestAuthenticator md5Hash: ' >>>>>> tudor(a)tudorgirba.com'); >>>>>> queryAt: #s put: '128'; >>>>>> queryAt: #d put: '404'; >>>>>> contentReader: [ :entity | ImageMorph fromStream: entity readStream >>>>>> ]; >>>>>> get) openInWindow. >>>>>> >>>>>> And now you know how simple Gravatars really are, provided you use a >>>>>> proper programming language to access them. >>>>>> >>>>>> Enjoy! >>>>>> >>>>>> Sven >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Mariano >>>>> http://marianopeck.wordpress.com >>>>> >>>> >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Every thing has its own flow" >>>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > -- > Mariano > http://marianopeck.wordpress.com > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 13, 2013

Re: [Pharo-dev] Checking your Gravatar

by Mariano Martinez Peck

ok....it's alt (option) + command + shift in my keyword... you were lucky Doru :) On Tue, Aug 13, 2013 at 6:01 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > I forgot to say..cmd+shift+click doesn't open the halos for me, it just > "picks" the picture and draws a small shadow and allows me to move the > picture around... > bug? > > > On Tue, Aug 13, 2013 at 6:00 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> That's so cool Doru :) >> I arrived at the point of "ImageMorph allInstances size". >> The "World submorphs select: [:each | each class = ImageMorph]" was a >> great idea!!! >> >> While I appreciate the post and you know I love your inspector, I wonder, >> isn't there a bug? >> If I try to open the halos on the picture, it actually takes the World. >> Is this the expected behavior? >> >> Thanks! >> >> >> >> On Tue, Aug 13, 2013 at 5:53 PM, Tudor Girba <tudor(a)tudorgirba.com>wrote: >> >>> Hi, >>> >>> I could not resist: here is a little blog post about removing your >>> troublesome morph :) >>> >>> http://www.humane-assessment.com/blog/spotting-a-troublesome-image-morph >>> >>> Cheers, >>> Doru >>> >>> >>> >>> >>> On Tue, Aug 13, 2013 at 2:21 PM, Mariano Martinez Peck < >>> marianopeck(a)gmail.com> wrote: >>> >>>> This one is more fun >>>> >>>> (ImageMorph fromStream:( >>>> ZnClient new >>>> beOneShot; >>>> url: 'http://www.gravatar.com/avatar'; >>>> addPathSegment: (ZnDigestAuthenticator md5Hash: ' >>>> marianopeck(a)gmail.com'); >>>> queryAt: #s put: '128'; >>>> queryAt: #d put: '404'; >>>> get) readStream) openInWorld >>>> >>>> >>>> uhhh but I cannot remove the morph from the world....damn it! >>>> >>>> >>>> On Mon, Aug 12, 2013 at 7:46 PM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: >>>> >>>>> Hi, >>>>> >>>>> Related to the usage of Gravatars ( >>>>> http://en.wikipedia.org/wiki/Gravatar) for >>>>> http://contributors.pharo.org here is some code you can use to check >>>>> whether your Gravatar image really works: >>>>> >>>>> ZnClient new >>>>> beOneShot; >>>>> url: 'http://www.gravatar.com/avatar'; >>>>> addPathSegment: (ZnDigestAuthenticator md5Hash: 'sven(a)stfx.eu'); >>>>> queryAt: #s put: '128'; >>>>> queryAt: #d put: '404'; >>>>> get; >>>>> isSuccess. >>>>> >>>>> ZnClient new >>>>> beOneShot; >>>>> url: 'http://www.gravatar.com/avatar'; >>>>> addPathSegment: (ZnDigestAuthenticator md5Hash: ' >>>>> nobody.at.all(a)gmail.com'); >>>>> queryAt: #s put: '128'; >>>>> queryAt: #d put: '404'; >>>>> get; >>>>> isSuccess. >>>>> >>>>> (ZnClient new >>>>> enforceHttpSuccess: true; >>>>> beOneShot; >>>>> url: 'http://www.gravatar.com/avatar'; >>>>> addPathSegment: (ZnDigestAuthenticator md5Hash: ' >>>>> tudor(a)tudorgirba.com'); >>>>> queryAt: #s put: '128'; >>>>> queryAt: #d put: '404'; >>>>> contentReader: [ :entity | ImageMorph fromStream: entity readStream >>>>> ]; >>>>> get) openInWindow. >>>>> >>>>> And now you know how simple Gravatars really are, provided you use a >>>>> proper programming language to access them. >>>>> >>>>> Enjoy! >>>>> >>>>> Sven >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > -- > Mariano > http://marianopeck.wordpress.com > -- Mariano http://marianopeck.wordpress.com

Aug. 13, 2013

Re: [Pharo-dev] Checking your Gravatar

by Mariano Martinez Peck

I forgot to say..cmd+shift+click doesn't open the halos for me, it just "picks" the picture and draws a small shadow and allows me to move the picture around... bug? On Tue, Aug 13, 2013 at 6:00 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > That's so cool Doru :) > I arrived at the point of "ImageMorph allInstances size". > The "World submorphs select: [:each | each class = ImageMorph]" was a > great idea!!! > > While I appreciate the post and you know I love your inspector, I wonder, > isn't there a bug? > If I try to open the halos on the picture, it actually takes the World. Is > this the expected behavior? > > Thanks! > > > > On Tue, Aug 13, 2013 at 5:53 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi, >> >> I could not resist: here is a little blog post about removing your >> troublesome morph :) >> >> http://www.humane-assessment.com/blog/spotting-a-troublesome-image-morph >> >> Cheers, >> Doru >> >> >> >> >> On Tue, Aug 13, 2013 at 2:21 PM, Mariano Martinez Peck < >> marianopeck(a)gmail.com> wrote: >> >>> This one is more fun >>> >>> (ImageMorph fromStream:( >>> ZnClient new >>> beOneShot; >>> url: 'http://www.gravatar.com/avatar'; >>> addPathSegment: (ZnDigestAuthenticator md5Hash: ' >>> marianopeck(a)gmail.com'); >>> queryAt: #s put: '128'; >>> queryAt: #d put: '404'; >>> get) readStream) openInWorld >>> >>> >>> uhhh but I cannot remove the morph from the world....damn it! >>> >>> >>> On Mon, Aug 12, 2013 at 7:46 PM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: >>> >>>> Hi, >>>> >>>> Related to the usage of Gravatars ( >>>> http://en.wikipedia.org/wiki/Gravatar) for >>>> http://contributors.pharo.org here is some code you can use to check >>>> whether your Gravatar image really works: >>>> >>>> ZnClient new >>>> beOneShot; >>>> url: 'http://www.gravatar.com/avatar'; >>>> addPathSegment: (ZnDigestAuthenticator md5Hash: 'sven(a)stfx.eu'); >>>> queryAt: #s put: '128'; >>>> queryAt: #d put: '404'; >>>> get; >>>> isSuccess. >>>> >>>> ZnClient new >>>> beOneShot; >>>> url: 'http://www.gravatar.com/avatar'; >>>> addPathSegment: (ZnDigestAuthenticator md5Hash: ' >>>> nobody.at.all(a)gmail.com'); >>>> queryAt: #s put: '128'; >>>> queryAt: #d put: '404'; >>>> get; >>>> isSuccess. >>>> >>>> (ZnClient new >>>> enforceHttpSuccess: true; >>>> beOneShot; >>>> url: 'http://www.gravatar.com/avatar'; >>>> addPathSegment: (ZnDigestAuthenticator md5Hash: 'tudor(a)tudorgirba.com >>>> '); >>>> queryAt: #s put: '128'; >>>> queryAt: #d put: '404'; >>>> contentReader: [ :entity | ImageMorph fromStream: entity readStream ]; >>>> get) openInWindow. >>>> >>>> And now you know how simple Gravatars really are, provided you use a >>>> proper programming language to access them. >>>> >>>> Enjoy! >>>> >>>> Sven >>>> >>>> >>>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > > > -- > Mariano > http://marianopeck.wordpress.com > -- Mariano http://marianopeck.wordpress.com

Aug. 13, 2013

Re: [Pharo-dev] Checking your Gravatar

by Mariano Martinez Peck

That's so cool Doru :) I arrived at the point of "ImageMorph allInstances size". The "World submorphs select: [:each | each class = ImageMorph]" was a great idea!!! While I appreciate the post and you know I love your inspector, I wonder, isn't there a bug? If I try to open the halos on the picture, it actually takes the World. Is this the expected behavior? Thanks! On Tue, Aug 13, 2013 at 5:53 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I could not resist: here is a little blog post about removing your > troublesome morph :) > > http://www.humane-assessment.com/blog/spotting-a-troublesome-image-morph > > Cheers, > Doru > > > > > On Tue, Aug 13, 2013 at 2:21 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> This one is more fun >> >> (ImageMorph fromStream:( >> ZnClient new >> beOneShot; >> url: 'http://www.gravatar.com/avatar'; >> addPathSegment: (ZnDigestAuthenticator md5Hash: ' >> marianopeck(a)gmail.com'); >> queryAt: #s put: '128'; >> queryAt: #d put: '404'; >> get) readStream) openInWorld >> >> >> uhhh but I cannot remove the morph from the world....damn it! >> >> >> On Mon, Aug 12, 2013 at 7:46 PM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: >> >>> Hi, >>> >>> Related to the usage of Gravatars (http://en.wikipedia.org/wiki/Gravatar) >>> for http://contributors.pharo.org here is some code you can use to >>> check whether your Gravatar image really works: >>> >>> ZnClient new >>> beOneShot; >>> url: 'http://www.gravatar.com/avatar'; >>> addPathSegment: (ZnDigestAuthenticator md5Hash: 'sven(a)stfx.eu'); >>> queryAt: #s put: '128'; >>> queryAt: #d put: '404'; >>> get; >>> isSuccess. >>> >>> ZnClient new >>> beOneShot; >>> url: 'http://www.gravatar.com/avatar'; >>> addPathSegment: (ZnDigestAuthenticator md5Hash: ' >>> nobody.at.all(a)gmail.com'); >>> queryAt: #s put: '128'; >>> queryAt: #d put: '404'; >>> get; >>> isSuccess. >>> >>> (ZnClient new >>> enforceHttpSuccess: true; >>> beOneShot; >>> url: 'http://www.gravatar.com/avatar'; >>> addPathSegment: (ZnDigestAuthenticator md5Hash: 'tudor(a)tudorgirba.com >>> '); >>> queryAt: #s put: '128'; >>> queryAt: #d put: '404'; >>> contentReader: [ :entity | ImageMorph fromStream: entity readStream ]; >>> get) openInWindow. >>> >>> And now you know how simple Gravatars really are, provided you use a >>> proper programming language to access them. >>> >>> Enjoy! >>> >>> Sven >>> >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- Mariano http://marianopeck.wordpress.com

Aug. 13, 2013

[update 3.0] #30334

by StÃ©phane Ducasse

[update 3.0] #30334 30334 ----- - issue 11418 RBBrowserEnvironment definesClass: is unfinished https://pharo.fogbugz.com/default.asp?11418 - issue 11417 Test for checking repeated code in superclasses must not watch in nativeBoost classes https://pharo.fogbugz.com/default.asp?11417 - issue 11415 More green tests for BehaviorTest and MetaclassTest https://pharo.fogbugz.com/default.asp?11415 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tests-StephaneDucasse.609.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Environment-Steph… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Critics-StephaneD… http://smalltalkhub.com/mc/Pharo/Pharo30/main/NativeBoost-Tests-StephaneDuc… http://smalltalkhub.com/mc/Pharo/Pharo30/main/KernelTests-StephaneDucasse.5… http://smalltalkhub.com/mc/Pharo/Pharo30/main/HudsonBuildTools20-StephaneDu… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Generated-code-non-existing-p…

Aug. 13, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=win/… 1 regressions found. Zinc.Zodiac.ZnHTTPSTests.testGetPharoVersion

Aug. 13, 2013

Re: [Pharo-dev] Checking your Gravatar

by Tudor Girba

Hi, I could not resist: here is a little blog post about removing your troublesome morph :) http://www.humane-assessment.com/blog/spotting-a-troublesome-image-morph Cheers, Doru On Tue, Aug 13, 2013 at 2:21 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > This one is more fun > > (ImageMorph fromStream:( > ZnClient new > beOneShot; > url: 'http://www.gravatar.com/avatar'; > addPathSegment: (ZnDigestAuthenticator md5Hash: 'marianopeck(a)gmail.com > '); > queryAt: #s put: '128'; > queryAt: #d put: '404'; > get) readStream) openInWorld > > > uhhh but I cannot remove the morph from the world....damn it! > > > On Mon, Aug 12, 2013 at 7:46 PM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: > >> Hi, >> >> Related to the usage of Gravatars (http://en.wikipedia.org/wiki/Gravatar) >> for http://contributors.pharo.org here is some code you can use to check >> whether your Gravatar image really works: >> >> ZnClient new >> beOneShot; >> url: 'http://www.gravatar.com/avatar'; >> addPathSegment: (ZnDigestAuthenticator md5Hash: 'sven(a)stfx.eu'); >> queryAt: #s put: '128'; >> queryAt: #d put: '404'; >> get; >> isSuccess. >> >> ZnClient new >> beOneShot; >> url: 'http://www.gravatar.com/avatar'; >> addPathSegment: (ZnDigestAuthenticator md5Hash: ' >> nobody.at.all(a)gmail.com'); >> queryAt: #s put: '128'; >> queryAt: #d put: '404'; >> get; >> isSuccess. >> >> (ZnClient new >> enforceHttpSuccess: true; >> beOneShot; >> url: 'http://www.gravatar.com/avatar'; >> addPathSegment: (ZnDigestAuthenticator md5Hash: 'tudor(a)tudorgirba.com >> '); >> queryAt: #s put: '128'; >> queryAt: #d put: '404'; >> contentReader: [ :entity | ImageMorph fromStream: entity readStream ]; >> get) openInWindow. >> >> And now you know how simple Gravatars really are, provided you use a >> proper programming language to access them. >> >> Enjoy! >> >> Sven >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 13, 2013

Re: [Pharo-dev] loosing versions of method after deleting and creating new

by StÃ©phane Ducasse

On Aug 13, 2013, at 4:34 PM, Sabine KnÃ¶fel <sabine.knoefel(a)gmail.com> wrote: > Hi, > > sometimes I have got the following situation: > > 1) I delete a method > 2) I recognize uhhhh, I need it! it was wrong to delete it! > 3) I re-write it (or get it from changes file or old image) > 4) now, the versions of the method are lost Yes this is bug and nobody took the time to look at it. Martin is working on a new change management system. > I would have the following wishes for this situation: > a) it should be easier for me to get back the deleted method (easier as > searching the changes file or load old version of image) > b) after re-writing the method, I want the versions of this method back. us too. > Perhaps there is another way to handle this and I did not know it. > For a while I was renaming methods (e.g. from "methodname" to > "methodnameOLD") instead of deleting it but this is not the way it should be > imho. > > I was used to have this functionality in envy. Us too in Pharo but a bug was introduced. > What do you think about this? we want more time > > Regards > Sabine > > > > > > > > -- > View this message in context: http://forum.world.st/loosing-versions-of-method-after-deleting-and-creatin… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Aug. 13, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=win/… 2 regressions found. KernelTests.Classes.BehaviorTest.testBehaviorRespectsPolymorphismWithTraitBehavior KernelTests.Classes.MetaclassTest.testMetaclassAndTraitClassRespectsPolymorphismRules

Aug. 13, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=mac/… 2 regressions found. KernelTests.Classes.BehaviorTest.testBehaviorRespectsPolymorphismWithTraitBehavior KernelTests.Classes.MetaclassTest.testMetaclassAndTraitClassRespectsPolymorphismRules

Aug. 13, 2013

Re: [Pharo-dev] Access to issue tracker?

by Camillo Bruni

I never tried the monkey/registration page. But you should be able to login here: http://pharo.fogbugz.org - reset your password (since you don't have one yet) - login at http://pharo.fogbugz.org I hope that helps. On 2013-08-13, at 01:01, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > Same here > > El 13/08/2013 0:34, Javier PimÃ¡s escribiÃ³: >> Hi, I don't know if it's just me or if I'm doing something wrong but I >> was never able to get a user for the issue tracker. I enter here >> <http://bugs.pharo.org/issues/register>, put a username, an email and >> tick the not a monkey box in order to create an account. It redirects me >> here <https://pharo.fogbugz.com/> but I never get a mail or anything I >> could use to login, what I am doing wrong? >> >> Cheers, >> Javier >> >> -- >> Lic. Javier PimÃ¡s >> Ciudad de Buenos Aires > >

Aug. 13, 2013

loosing versions of method after deleting and creating new

by Sabine KnÃ¶fel

Hi, sometimes I have got the following situation: 1) I delete a method 2) I recognize uhhhh, I need it! it was wrong to delete it! 3) I re-write it (or get it from changes file or old image) 4) now, the versions of the method are lost I would have the following wishes for this situation: a) it should be easier for me to get back the deleted method (easier as searching the changes file or load old version of image) b) after re-writing the method, I want the versions of this method back. Perhaps there is another way to handle this and I did not know it. For a while I was renaming methods (e.g. from "methodname" to "methodnameOLD") instead of deleting it but this is not the way it should be imho. I was used to have this functionality in envy. What do you think about this? Regards Sabine -- View this message in context: http://forum.world.st/loosing-versions-of-method-after-deleting-and-creatin… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 13, 2013

Re: [Pharo-dev] [ANN] Stamp, another STOMP implementation

by StÃ©phane Ducasse

> > >> Excellent! >> And with a lovely documentation (even if too short to my eyes :)). > > Indeed, although it is better than nothing, it is too short and the code itself can use more comments as well, but it is a pretty complex subject, especially if you are unfamiliar with messaging-oriented middleware and architecture. > > It will improve over time. Users are an important driver for improvements. I'm sure about that :)

Aug. 13, 2013

Re: [Pharo-dev] [rmod] Link between Spec model and Morph ?

by Erwan Douaille

2013/8/13 ClÃ©ment Bera <bera.clement(a)gmail.com> > Ok I think get your question. Not an easy one :) > > So LabelModel knows its AbstractSpec with a class side method: > > LabelModel class>>defaultSpec > <spec> > ^ {#LabelSpec. > #model:. #model. > #getEnabledSelector:. #enabled. > #getTextSelector:. #getText. > #vResizing:. #shrinkWrap. > #hResizing:. #spaceFill. > #borderWidth:. #(model borderWidth). > #borderColor:. #(model borderColor). > #dragEnabled:. #(model dragEnabled). > #dropEnabled:. #(model dropEnabled). > #setBalloonText:. { #model . #help}} > > So you have LabelModel->#LabelSpec. > > This symbol, #LabelSpec, corresponds to a class. You can check: > > SpecBinder class>>initializeBindings > "self initializeBindings" > bindings := IdentityDictionary new. > bindings > at: #ListSpec put: ListSpec; > at: #MultiColumnListSpec put: MultiColumnListSpec; > at: #IconListSpec put: IconListSpec; > at:#model put: ModelSpec; > at: #RawSpec put: RawSpec; > at: #ComposableSpec put: ComposableSpec; > at: #TextSpec put: TextSpec; > at: #ButtonSpec put: ButtonSpec; > at: #CheckboxSpec put: CheckboxSpec; > at: #DropListSpec put: DropListSpec; > at: #LabelSpec put: LabelSpec; > at: #FrameLayoutSpec put: FrameLayoutSpec; > at: #TextFieldSpec put: TextFieldSpec; > at: #TreeSpec put: TreeSpec; > at: #WindowSpec put: WindowSpec; > at:#DialogWindowSpec put: DialogWindowSpec; > > So you have LabelModel->#LabelSpec->LabelSpec. > > LabelSpec is an AbstractSpec and subclasses of AbstractSpec has the method > classSymbol. Here we have > > LabelSpec>>classSymbol > ^ #Label > > So you have LabelModel->#LabelSpec->LabelSpec->#Label. > > Now this symbol corresponds to a class. You can check: > > MorphicBindings>>initializeClassesDictionary > > ^ IdentityDictionary new > at: #List put: #PluggableListMorph; > at: #IconList put: #PluggableIconListMorph; > at: #Text put: #PluggableTextMorph; > at: #Button put: #PluggableButtonMorph; > at: #Panel put: #PanelMorph; > at: #Checkbox put: #CheckboxMorph; > at: #DropList put: #DropListMorph; > at: #TextField put: #PluggableTextFieldMorph; > at: #Label put: #LabelMorph; > at: #MultiColumnList put: #PluggableMultiColumnListMorph; > at: #Tree put: #MorphTreeMorph; > at: #Slider put: #PluggableSliderMorph; > at: #FrameLayout put: #LayoutFrame; > at: #Window put: #SpecWindow; > at: #DialogWindow put: #SpecDialogWindow; > yourself > > So you have LabelModel->#LabelSpec->LabelSpec->#Label->LabelMorph. > > Does that answer your question this time ? > > > Perfect ! Thanks ! :) > > > > 2013/8/13 Erwan Douaille <douailleerwan(a)gmail.com> > >> Hi, >> >> Does anyone can explain me how/where the link is ? >> I guess its related to AbstractSpec subclasses, but i don't know how does >> it work. >> >> I will be at lab the whole week. >> >> >> 2013/8/12 ClÃ©ment Bera <clement.bera(a)minesdedouai.fr> >> A spec model (ComposableModel) has a window (WindowModel), this window >> has a window (SpecWindow), this window inherits from StandardWindow which >> inherits from SystemWindow which inherits from MorphicModel which inherits >> fromBorderedMorph which inherits from Morph >> >> Does that answer your question ? >> >> >> No :) >> >> I mean How the labelModel know than his morph is a LabelMorph ? >> >> >> -- >> Best regards, >> >> Douaille Erwan <douaille.erwan(a)gmail.com> >> > > -- Best regards, Douaille Erwan <douaille.erwan(a)gmail.com>

Aug. 13, 2013

Re: [Pharo-dev] [rmod] Link between Spec model and Morph ?

by ClÃ©ment Bera

Ok I think get your question. Not an easy one :) So LabelModel knows its AbstractSpec with a class side method: LabelModel class>>defaultSpec <spec> ^ {#LabelSpec. #model:. #model. #getEnabledSelector:. #enabled. #getTextSelector:. #getText. #vResizing:. #shrinkWrap. #hResizing:. #spaceFill. #borderWidth:. #(model borderWidth). #borderColor:. #(model borderColor). #dragEnabled:. #(model dragEnabled). #dropEnabled:. #(model dropEnabled). #setBalloonText:. { #model . #help}} So you have LabelModel->#LabelSpec. This symbol, #LabelSpec, corresponds to a class. You can check: SpecBinder class>>initializeBindings "self initializeBindings" bindings := IdentityDictionary new. bindings at: #ListSpec put: ListSpec; at: #MultiColumnListSpec put: MultiColumnListSpec; at: #IconListSpec put: IconListSpec; at:#model put: ModelSpec; at: #RawSpec put: RawSpec; at: #ComposableSpec put: ComposableSpec; at: #TextSpec put: TextSpec; at: #ButtonSpec put: ButtonSpec; at: #CheckboxSpec put: CheckboxSpec; at: #DropListSpec put: DropListSpec; at: #LabelSpec put: LabelSpec; at: #FrameLayoutSpec put: FrameLayoutSpec; at: #TextFieldSpec put: TextFieldSpec; at: #TreeSpec put: TreeSpec; at: #WindowSpec put: WindowSpec; at:#DialogWindowSpec put: DialogWindowSpec; So you have LabelModel->#LabelSpec->LabelSpec. LabelSpec is an AbstractSpec and subclasses of AbstractSpec has the method classSymbol. Here we have LabelSpec>>classSymbol ^ #Label So you have LabelModel->#LabelSpec->LabelSpec->#Label. Now this symbol corresponds to a class. You can check: MorphicBindings>>initializeClassesDictionary ^ IdentityDictionary new at: #List put: #PluggableListMorph; at: #IconList put: #PluggableIconListMorph; at: #Text put: #PluggableTextMorph; at: #Button put: #PluggableButtonMorph; at: #Panel put: #PanelMorph; at: #Checkbox put: #CheckboxMorph; at: #DropList put: #DropListMorph; at: #TextField put: #PluggableTextFieldMorph; at: #Label put: #LabelMorph; at: #MultiColumnList put: #PluggableMultiColumnListMorph; at: #Tree put: #MorphTreeMorph; at: #Slider put: #PluggableSliderMorph; at: #FrameLayout put: #LayoutFrame; at: #Window put: #SpecWindow; at: #DialogWindow put: #SpecDialogWindow; yourself So you have LabelModel->#LabelSpec->LabelSpec->#Label->LabelMorph. Does that answer your question this time ? 2013/8/13 Erwan Douaille <douailleerwan(a)gmail.com> > Hi, > > Does anyone can explain me how/where the link is ? > I guess its related to AbstractSpec subclasses, but i don't know how does > it work. > > I will be at lab the whole week. > > > 2013/8/12 ClÃ©ment Bera <clement.bera(a)minesdedouai.fr> > A spec model (ComposableModel) has a window (WindowModel), this window has > a window (SpecWindow), this window inherits from StandardWindow which > inherits from SystemWindow which inherits from MorphicModel which inherits > fromBorderedMorph which inherits from Morph > > Does that answer your question ? > > > No :) > > I mean How the labelModel know than his morph is a LabelMorph ? > > > -- > Best regards, > > Douaille Erwan <douaille.erwan(a)gmail.com> >

Aug. 13, 2013