April 2015 - Pharo-users - lists.pharo.org

SoundSystem subclassing

by Mark Rizun

Hi, I was investigating how to play sounds in Pharo, and found SoundSystem class. It is stated that you should subclass it, like DummySoundSystem does. Is there any cool subclass (besides DummySoundSystem =D ) already implemented so I can use it? Thanks, Mark -- View this message in context: http://forum.world.st/SoundSystem-subclassing-tp4821475.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 23, 2015

Re: [Pharo-users] ViDI error: variable named "aModuleName" in NativeBoost>>#loadModule:

by Rafael Luque

I'd like to use it in a Linux box, but as you told me Linux is not yet supported, I'm using a Mac OS X Yosemite (version 10.10.2). Thanks 2015-04-23 17:37 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > Hi Rafael, > > I will take a look. Which operating system are you using? > > Uko > > On 23 Apr 2015, at 17:30, Rafael Luque <rafael.luque.leiva(a)gmail.com> > wrote: > > Hi, > > I installed ViDI on Pharo 4 following the project instructions detailed > in its GitHub page: > > Gofer new > smalltalkhubUser: 'YuriyTymchuk' > project: 'Configuration'; > configurationOf: 'Vidi'; > load. > #ConfigurationOfVidi asClass loadStable > > When I launch a review session over any package I always get the following > error: > > "Could not find accesor for variable named "aModuleName" in > NativeBoost>>#loadModule:" > > I'm very interested in this kind of quality assurance tools, so any help > will be very welcomed. > > Thank you. > > >

April 23, 2015

Re: [Pharo-users] ViDI error: variable named "aModuleName" in NativeBoost>>#loadModule:

by Yuriy Tymchuk

Hi Rafael, I will take a look. Which operating system are you using? Uko > On 23 Apr 2015, at 17:30, Rafael Luque <rafael.luque.leiva(a)gmail.com> wrote: > > Hi, > > I installed ViDI on Pharo 4 following the project instructions detailed in its GitHub page: > > Gofer new > smalltalkhubUser: 'YuriyTymchuk' > project: 'Configuration'; > configurationOf: 'Vidi'; > load. > #ConfigurationOfVidi asClass loadStable > > When I launch a review session over any package I always get the following error: > > "Could not find accesor for variable named "aModuleName" in NativeBoost>>#loadModule:" > > I'm very interested in this kind of quality assurance tools, so any help will be very welcomed. > > Thank you.

April 23, 2015

ViDI error: variable named "aModuleName" in NativeBoost>>#loadModule:

by Rafael Luque

Hi, I installed ViDI on Pharo 4 following the project instructions detailed in its GitHub page: Gofer new smalltalkhubUser: 'YuriyTymchuk' project: 'Configuration'; configurationOf: 'Vidi'; load. #ConfigurationOfVidi asClass loadStable When I launch a review session over any package I always get the following error: "Could not find accesor for variable named "aModuleName" in NativeBoost>>#loadModule:" I'm very interested in this kind of quality assurance tools, so any help will be very welcomed. Thank you.

April 23, 2015

Re: [Pharo-users] [Pharo-dev] QualityAssistant v0.4

by Yuriy Tymchuk

Hi Cyril, Iâve checked the problem. It could be indeed easier if the rule pointed to it :). So you have PRFileInclusion>>replace: and it is identical (not taking empty lines into account) to PRTransformer>>replace:. So the rule is correct. You override a method with an identical method. Uko > On 23 Apr 2015, at 12:48, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > I changed that but i still have the warning from quality assistant. > > On 23 April 2015 at 12:44, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: >> Oh, ok ! Thank you Guillermo ! >> >> On 23 April 2015 at 11:58, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >>> Hi Cyril, >>> >>> Your problem is caused because abstract methods should be marked with >>> "subclassResponsibility" and not "shouldBeImplemented". >>> >>> - shouldBeImplemented means "this is a method I did not implement yet, I >>> should replace *this* method with another implementation" >>> - subclassResponsibility means "my subclasses should implement a method with >>> this same selector" >>> >>> The tools recognize the first as a normal "concrete" method and the second >>> as an abstract method. >>> >>> El jue., 23 de abr. de 2015 a la(s) 10:15 a. m., Norbert Hartl >>> <norbert(a)hartl.name> escribiÃ³: >>>> >>>> Stef, >>>> >>>> where is "the tool"? >>>> >>>> Norbert >>>> >>>>> Am 23.04.2015 um 08:01 schrieb stepharo <stepharo(a)free.fr>: >>>>> >>>>> Two things: >>>>> >>>>> One: >>>>> We paid a guy to work on a tool to help us identifying dependencies, The >>>>> tool works well is fast. >>>>> if this tool would be in the image, everybody could check that there are >>>>> bad dependencies in his >>>>> code (and there are many around in nearly anybody's code). >>>>> No we prefer that me, pavel, and guille run it and fight with this >>>>> instead of making sure that >>>>> when you commit we get some feedback like: "oh strange that this package >>>>> is bound with this one". >>>>> This tool breaks when we do change in the image and I nicely (stupidly I >>>>> would say) maintain it. >>>>> >>>>> Two: >>>>> Our process is not great to manage external packages and we will add >>>>> more. >>>>> Sure it sounds like the right things to do, especially now. >>>>> >>>>> So to me it simply means that we are not serious and convinced about >>>>> modularity. >>>>> >>>>> But this is great, I'm reconsidering what I will do in Pharo so you give >>>>> me good indication >>>>> that I should not continue the way I was thinking. And no need to think >>>>> that I'm emotional >>>>> I'm not. I'm thinking about why hell I'm doing all this. >>>>> >>>>> Stef >>>>> >>>>> Le 22/4/15 21:27, Marcus Denker a Ã©crit : >>>>>>> On 22 Apr 2015, at 20:22, stepharo <stepharo(a)free.fr> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Le 22/4/15 13:23, Esteban Lorenzano a Ã©crit : >>>>>>>> this is so good. >>>>>>>> what about integrate it to Pharo? >>>>>>> No. People should start to think modular. >>>>>>> No more external tools loaded by default. >>>>>>> Better invest in "add a startup preference" functionality in the >>>>>>> configurationBrowser. >>>>>>> >>>>>>> Why we do not integrate the excellent tool of baptiste that would show >>>>>>> to people >>>>>>> when they are creating package mess? Because of the same reason. >>>>>>> >>>>>> But the Pharo that we download should be the Pharo we use. >>>>>> >>>>>> We tried the other back in Pharo1.0: Do you remember how we fixed with >>>>>> lots >>>>>> care all details, but then, everyone was using a different image, and >>>>>> all the >>>>>> details there where not fixed and all work was done double? >>>>>> >>>>>> If we do not make the Pharo that is downloaded to be that was is used, >>>>>> we will have >>>>>> that again. >>>>>> >>>>>> I donât want everything in the image, but what everyone is supposed to >>>>>> be using should >>>>>> be there without needing an additional step. >>>>>> >>>>>> Marcus >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >> >> >> >> -- >> Cheers >> Cyril Ferlicot > > > > -- > Cheers > Cyril Ferlicot >

April 23, 2015

Versionner repository moved to PharoExtras

by Christophe Demarey

Hi, I just moved the Versionner repository from http://smalltalkhub.com/#!/~demarey/Versionner/ to http://smalltalkhub.com/#!/~PharoExtras/Versionner/. It will ease contributions and it will be easier to find with other tools / library of Pharo. Regards, Christophe.

April 23, 2015

Re: [Pharo-users] [Pharo-dev] QualityAssistant v0.4

by Cyril Ferlicot

I changed that but i still have the warning from quality assistant. On 23 April 2015 at 12:44, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > Oh, ok ! Thank you Guillermo ! > > On 23 April 2015 at 11:58, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> Hi Cyril, >> >> Your problem is caused because abstract methods should be marked with >> "subclassResponsibility" and not "shouldBeImplemented". >> >> - shouldBeImplemented means "this is a method I did not implement yet, I >> should replace *this* method with another implementation" >> - subclassResponsibility means "my subclasses should implement a method with >> this same selector" >> >> The tools recognize the first as a normal "concrete" method and the second >> as an abstract method. >> >> El jue., 23 de abr. de 2015 a la(s) 10:15 a. m., Norbert Hartl >> <norbert(a)hartl.name> escribiÃ³: >>> >>> Stef, >>> >>> where is "the tool"? >>> >>> Norbert >>> >>> > Am 23.04.2015 um 08:01 schrieb stepharo <stepharo(a)free.fr>: >>> > >>> > Two things: >>> > >>> > One: >>> > We paid a guy to work on a tool to help us identifying dependencies, The >>> > tool works well is fast. >>> > if this tool would be in the image, everybody could check that there are >>> > bad dependencies in his >>> > code (and there are many around in nearly anybody's code). >>> > No we prefer that me, pavel, and guille run it and fight with this >>> > instead of making sure that >>> > when you commit we get some feedback like: "oh strange that this package >>> > is bound with this one". >>> > This tool breaks when we do change in the image and I nicely (stupidly I >>> > would say) maintain it. >>> > >>> > Two: >>> > Our process is not great to manage external packages and we will add >>> > more. >>> > Sure it sounds like the right things to do, especially now. >>> > >>> > So to me it simply means that we are not serious and convinced about >>> > modularity. >>> > >>> > But this is great, I'm reconsidering what I will do in Pharo so you give >>> > me good indication >>> > that I should not continue the way I was thinking. And no need to think >>> > that I'm emotional >>> > I'm not. I'm thinking about why hell I'm doing all this. >>> > >>> > Stef >>> > >>> > Le 22/4/15 21:27, Marcus Denker a Ã©crit : >>> >>> On 22 Apr 2015, at 20:22, stepharo <stepharo(a)free.fr> wrote: >>> >>> >>> >>> >>> >>> >>> >>> Le 22/4/15 13:23, Esteban Lorenzano a Ã©crit : >>> >>>> this is so good. >>> >>>> what about integrate it to Pharo? >>> >>> No. People should start to think modular. >>> >>> No more external tools loaded by default. >>> >>> Better invest in "add a startup preference" functionality in the >>> >>> configurationBrowser. >>> >>> >>> >>> Why we do not integrate the excellent tool of baptiste that would show >>> >>> to people >>> >>> when they are creating package mess? Because of the same reason. >>> >>> >>> >> But the Pharo that we download should be the Pharo we use. >>> >> >>> >> We tried the other back in Pharo1.0: Do you remember how we fixed with >>> >> lots >>> >> care all details, but then, everyone was using a different image, and >>> >> all the >>> >> details there where not fixed and all work was done double? >>> >> >>> >> If we do not make the Pharo that is downloaded to be that was is used, >>> >> we will have >>> >> that again. >>> >> >>> >> I donât want everything in the image, but what everyone is supposed to >>> >> be using should >>> >> be there without needing an additional step. >>> >> >>> >> Marcus >>> >> >>> >> >>> >> >>> >> >>> > >>> > >>> >>> >> > > > > -- > Cheers > Cyril Ferlicot -- Cheers Cyril Ferlicot

April 23, 2015

Re: [Pharo-users] [Pharo-dev] QualityAssistant v0.4

by Cyril Ferlicot

Oh, ok ! Thank you Guillermo ! On 23 April 2015 at 11:58, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi Cyril, > > Your problem is caused because abstract methods should be marked with > "subclassResponsibility" and not "shouldBeImplemented". > > - shouldBeImplemented means "this is a method I did not implement yet, I > should replace *this* method with another implementation" > - subclassResponsibility means "my subclasses should implement a method with > this same selector" > > The tools recognize the first as a normal "concrete" method and the second > as an abstract method. > > El jue., 23 de abr. de 2015 a la(s) 10:15 a. m., Norbert Hartl > <norbert(a)hartl.name> escribiÃ³: >> >> Stef, >> >> where is "the tool"? >> >> Norbert >> >> > Am 23.04.2015 um 08:01 schrieb stepharo <stepharo(a)free.fr>: >> > >> > Two things: >> > >> > One: >> > We paid a guy to work on a tool to help us identifying dependencies, The >> > tool works well is fast. >> > if this tool would be in the image, everybody could check that there are >> > bad dependencies in his >> > code (and there are many around in nearly anybody's code). >> > No we prefer that me, pavel, and guille run it and fight with this >> > instead of making sure that >> > when you commit we get some feedback like: "oh strange that this package >> > is bound with this one". >> > This tool breaks when we do change in the image and I nicely (stupidly I >> > would say) maintain it. >> > >> > Two: >> > Our process is not great to manage external packages and we will add >> > more. >> > Sure it sounds like the right things to do, especially now. >> > >> > So to me it simply means that we are not serious and convinced about >> > modularity. >> > >> > But this is great, I'm reconsidering what I will do in Pharo so you give >> > me good indication >> > that I should not continue the way I was thinking. And no need to think >> > that I'm emotional >> > I'm not. I'm thinking about why hell I'm doing all this. >> > >> > Stef >> > >> > Le 22/4/15 21:27, Marcus Denker a Ã©crit : >> >>> On 22 Apr 2015, at 20:22, stepharo <stepharo(a)free.fr> wrote: >> >>> >> >>> >> >>> >> >>> Le 22/4/15 13:23, Esteban Lorenzano a Ã©crit : >> >>>> this is so good. >> >>>> what about integrate it to Pharo? >> >>> No. People should start to think modular. >> >>> No more external tools loaded by default. >> >>> Better invest in "add a startup preference" functionality in the >> >>> configurationBrowser. >> >>> >> >>> Why we do not integrate the excellent tool of baptiste that would show >> >>> to people >> >>> when they are creating package mess? Because of the same reason. >> >>> >> >> But the Pharo that we download should be the Pharo we use. >> >> >> >> We tried the other back in Pharo1.0: Do you remember how we fixed with >> >> lots >> >> care all details, but then, everyone was using a different image, and >> >> all the >> >> details there where not fixed and all work was done double? >> >> >> >> If we do not make the Pharo that is downloaded to be that was is used, >> >> we will have >> >> that again. >> >> >> >> I donât want everything in the image, but what everyone is supposed to >> >> be using should >> >> be there without needing an additional step. >> >> >> >> Marcus >> >> >> >> >> >> >> >> >> > >> > >> >> > -- Cheers Cyril Ferlicot

April 23, 2015

Re: [Pharo-users] [Pharo-dev] QualityAssistant v0.4

by Guillermo Polito

Hi Cyril, Your problem is caused because abstract methods should be marked with "subclassResponsibility" and not "shouldBeImplemented". - shouldBeImplemented means "this is a method I did not implement yet, I should replace *this* method with another implementation" - subclassResponsibility means "my subclasses should implement a method with this same selector" The tools recognize the first as a normal "concrete" method and the second as an abstract method. El jue., 23 de abr. de 2015 a la(s) 10:15 a. m., Norbert Hartl < norbert(a)hartl.name> escribiÃ³: > Stef, > > where is "the tool"? > > Norbert > > > Am 23.04.2015 um 08:01 schrieb stepharo <stepharo(a)free.fr>: > > > > Two things: > > > > One: > > We paid a guy to work on a tool to help us identifying dependencies, The > tool works well is fast. > > if this tool would be in the image, everybody could check that there are > bad dependencies in his > > code (and there are many around in nearly anybody's code). > > No we prefer that me, pavel, and guille run it and fight with this > instead of making sure that > > when you commit we get some feedback like: "oh strange that this package > is bound with this one". > > This tool breaks when we do change in the image and I nicely (stupidly I > would say) maintain it. > > > > Two: > > Our process is not great to manage external packages and we will add > more. > > Sure it sounds like the right things to do, especially now. > > > > So to me it simply means that we are not serious and convinced about > modularity. > > > > But this is great, I'm reconsidering what I will do in Pharo so you give > me good indication > > that I should not continue the way I was thinking. And no need to think > that I'm emotional > > I'm not. I'm thinking about why hell I'm doing all this. > > > > Stef > > > > Le 22/4/15 21:27, Marcus Denker a Ã©crit : > >>> On 22 Apr 2015, at 20:22, stepharo <stepharo(a)free.fr> wrote: > >>> > >>> > >>> > >>> Le 22/4/15 13:23, Esteban Lorenzano a Ã©crit : > >>>> this is so good. > >>>> what about integrate it to Pharo? > >>> No. People should start to think modular. > >>> No more external tools loaded by default. > >>> Better invest in "add a startup preference" functionality in the > configurationBrowser. > >>> > >>> Why we do not integrate the excellent tool of baptiste that would show > to people > >>> when they are creating package mess? Because of the same reason. > >>> > >> But the Pharo that we download should be the Pharo we use. > >> > >> We tried the other back in Pharo1.0: Do you remember how we fixed with > lots > >> care all details, but then, everyone was using a different image, and > all the > >> details there where not fixed and all work was done double? > >> > >> If we do not make the Pharo that is downloaded to be that was is used, > we will have > >> that again. > >> > >> I donât want everything in the image, but what everyone is supposed to > be using should > >> be there without needing an additional step. > >> > >> Marcus > >> > >> > >> > >> > > > > > > >

April 23, 2015

Re: [Pharo-users] Time traveling Pharo

by Marcus Denker

fixed > On 21 Apr 2015, at 19:11, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > This is not correctâ¦ can you enter an issue? > >> On 21 Apr 2015, at 19:07, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: >> >> Hi all, >> >> finally having some time to develop again, I downloaded the 4.0 image sources and vm (http://files.pharo.org/get-files/40/pharo.zip et cetera) through the links on the downloads page. >> >> Itâs a bit strange that the image version is 5000, but OK I can understand it. More funny is the time traveling behavior that occurs when doing World->System->About. It says: >> >> Pharo5.0 >> Latest update: #50000 >> >> [â¦] >> >> Time-traveling from next year back to today! Wow! :-P >> >> ---> Save our in-boxes! http://emailcharter.org <--- >> >> Johan Fabry - http://pleiad.cl/~jfabry >> PLEIAD lab - Computer Science Department (DCC) - University of Chile >> >> >

April 23, 2015