February 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] A challenge for all who cares

by Igor Stasenko

On 20 February 2012 23:55, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Le 20 fÃ©vrier 2012 23:06, Guido Stepken <gstepken(a)googlemail.com> a Ã©crit : >> Am 20.02.2012 21:30, schrieb Nicolas Cellier: >> >>> What, what, the right development process wouldn't solve such a >>> trivial problem ? >>> Guido, try to inspect yourself with all your introspection tools and >>> development process know how, because I have the feeling that despite >>> the many answers you got, you still face a message not understood >>> problem ;) >>> >>> Nicolas >> >> >> Nicolas, i *know*, there must be a solution! Cannot be, that i klick into a >> menu and *directly* run into error messages. >> >> Think! >> >> Develop the development process! Don't argue! >> >> tnx, Guido Stepken >> > > Guido, you take a bug in a hacked Cuis image to demonstrate that Pharo > development process is wrong... > So how could I possibly argue if you don't use logic. Because it is much easier to keep saying "you're wrong/you doing it wrong" than do anything towards fixing it by yourself. > > That's a pity, because for once we had something pretty close to a > true bug report... > but the bug doesn't even show in a Cuis image, I just took my not so > precious time to check. > > That doesn't matter because I have no doubt that you are not > interested at all in bug reporting/fixing. > When I unwind your long stack of message sends, I see the same good > political slogan, develop the development process. > Well very nice, you found yourself initiated with higher level > functions, but beware, in Haskell like in Guido, there is no way to > detect an infinite recursion, even if we seriously suspect one. > Can't wait till Guido will start learning quantum mechanics. I can hear his "you doing it wrong" echoing from future :) > Nicolas > -- Best regards, Igor Stasenko.

Feb. 21, 2012

Re: [Pharo-project] A challenge for all who cares

by Guido Stepken

Nicolas, i *only* complain *systematic* bugs, that *can* be avoided! See the difference to *occationally occurring* bugs!!!! tnx 4 understanding, Guido Stepken

Feb. 20, 2012

Re: [Pharo-project] A challenge for all who cares

by Nicolas Cellier

Le 20 fÃ©vrier 2012 23:06, Guido Stepken <gstepken(a)googlemail.com> a Ã©crit : > Am 20.02.2012 21:30, schrieb Nicolas Cellier: > >> What, what, the right development process wouldn't solve such a >> trivial problem ? >> Guido, try to inspect yourself with all your introspection tools and >> development process know how, because I have the feeling that despite >> the many answers you got, you still face a message not understood >> problem ;) >> >> Nicolas > > > Nicolas, i *know*, there must be a solution! Cannot be, that i klick into a > menu and *directly* run into error messages. > > Think! > > Develop the development process! Don't argue! > > tnx, Guido Stepken > Guido, you take a bug in a hacked Cuis image to demonstrate that Pharo development process is wrong... So how could I possibly argue if you don't use logic. That's a pity, because for once we had something pretty close to a true bug report... but the bug doesn't even show in a Cuis image, I just took my not so precious time to check. That doesn't matter because I have no doubt that you are not interested at all in bug reporting/fixing. When I unwind your long stack of message sends, I see the same good political slogan, develop the development process. Well very nice, you found yourself initiated with higher level functions, but beware, in Haskell like in Guido, there is no way to detect an infinite recursion, even if we seriously suspect one. Nicolas

Feb. 20, 2012

Re: [Pharo-project] A challenge for all who cares

by Guido Stepken

Am 20.02.2012 23:21 schrieb "Frank Shearar" <frank.shearar(a)gmail.com>: > > Thank you, indirectly admitting, that there must be such a tool. ;-) > > > > Think! > > Sure. Given a decent statically typed language you can completely > avoid the null problem, at least if you leave out input, which is what > Igor's hinting at in his reply to me. > > And as soon as you allow arbitrary input, you're hosed. That is, you > run smack into the entscheidungsproblem. Any Entscheidungsproblem *is* a permutation problem, of course! Again, ensure quality! I don't want no more errors! Especially when i simply click menus, and also when a image is simply stripped and obviously a package missing! Don't argue, develop the development process!!! Again! Don't type in nothing, that *is* not tested. If you remove code, write a tool, that ensures, that it can be removed without running into troubles!!! Tnx 4 understanding, Guido Stepken

Feb. 20, 2012

Re: [Pharo-project] Nautilus Refactorings

by Benjamin

I will add a setting for that :) Ben On Feb 20, 2012, at 11:33 PM, Mariano Martinez Peck wrote: > One last thing: when you type the name of a class somewhere and you do a cmd+b I think it would be much better if Nautilus open the "normal" browser and not "hierarchy" one. > > > On Mon, Feb 20, 2012 at 8:38 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > To be honest, if it works, I do not want to lose my time on Configuration > > > It shouldn't be done by hand, but generated by a tool :) > > > Ben > > On Feb 20, 2012, at 8:06 PM, Mariano Martinez Peck wrote: > >> >> >> On Tue, Feb 14, 2012 at 6:39 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >> Hello guys, >> >> I know a some of you are waiting for the integration of the RB engine into Nautilus. >> >> Some of them are already implemented, so if you wanna test them, here is the gofer script >> >> Gofer new >> url: 'http://ss3.gemstone.com/ss/Nautilus'; >> package: 'ConfigurationOfNautilus'; >> load. >> >> (Smalltalk at: #ConfigurationOfNautilusRefactoring) perform: #loadDefault >> >> >> >> >> So...that's the way of loading Nautilus with refactorings? Wouldn't it be better to include RB dependencis in ConfigurationOfNautilus and have a specific group there. So you can do for example >> >> ConfigurationOfNautilus project stableVersion load: 'WithRefactorings'. >> >> ? >> >> BTW, I checked the ConfigurationOfNautilusRefactoring and it looks you miss a critical feature of Metacello: project references :) From ConfigurationOfNautilusRefactoring you can directly depend on ConfigurationOfRB or ConfigurationOfNautilus rather than duplicating everything in there. Don't tell Stef you didn't read the chapter hahahaha >> >> >> >> It loads everything. >> >> For now I have only done some refactorings for classes, so if you popup the menu on a class, a new item named Refactoring should appear :) >> >> Moreover, the 'rename class' method is replaced by the RB one :) >> >> >> Thanks in advance for your feedback, and if you want to participate, you are more than welcome :) >> >> >> Ben >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > > -- > Mariano > http://marianopeck.wordpress.com >

Feb. 20, 2012

Re: [Pharo-project] Nautilus throws PluggableIconListMorph(Object)>>doesNotUnderstand: #detachAllKeymapCategories

by Mariano Martinez Peck

thanks :) On Mon, Feb 20, 2012 at 11:01 PM, Benjamin < benjamin.vanryseghem.pharo(a)gmail.com> wrote: > Yep, I just update it, if you load the latest stable version, it should > work fine :) > > > Thanks for the report ;) > > > Ben > > On Feb 20, 2012, at 10:44 PM, Mariano Martinez Peck wrote: > > In > > showPackages: aBoolean > > self okToChange > ifTrue: [ > listElements := nil. > list2Elements := nil. > list detachAllKeymapCategories. > list2 detachAllKeymapCategories. > aBoolean > ifTrue: [ > self setPackageShorcutsTo: list. > self setClassShorcutsTo: list2.] > ifFalse: [| class | > class := self selectedClass. > classesSelection at: class put: true. > self hierarchyClass: class . > listElements := nil. > list2Elements := nil. > self showGroups > ifTrue: [self showGroupsSilently: false]. > self setPackageShorcutsTo: list2. > self setClassShorcutsTo: list ]. > listElements := nil. > list2Elements := nil. > self model showPackages: aBoolean. > self changed: #groupsButtonLabel. > self updateBothView. > self changed: #toogleButtonState. > self changedLabels ] > > > ideas? > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

Feb. 20, 2012

Re: [Pharo-project] Nautilus Refactorings

by Mariano Martinez Peck

One last thing: when you type the name of a class somewhere and you do a cmd+b I think it would be much better if Nautilus open the "normal" browser and not "hierarchy" one. On Mon, Feb 20, 2012 at 8:38 PM, Benjamin < benjamin.vanryseghem.pharo(a)gmail.com> wrote: > To be honest, if it works, I do not want to lose my time on Configuration > > > It shouldn't be done by hand, but generated by a tool :) > > > Ben > > On Feb 20, 2012, at 8:06 PM, Mariano Martinez Peck wrote: > > > > On Tue, Feb 14, 2012 at 6:39 PM, Benjamin < > benjamin.vanryseghem.pharo(a)gmail.com> wrote: > >> Hello guys, >> >> I know a some of you are waiting for the integration of the RB engine >> into Nautilus. >> >> Some of them are already implemented, so if you wanna test them, here is >> the gofer script >> >> Gofer new >> url: 'http://ss3.gemstone.com/ss/Nautilus'; >> package: 'ConfigurationOfNautilus'; >> load. >> >> (Smalltalk at: #ConfigurationOfNautilusRefactoring) perform: #loadDefault >> >> >> > > So...that's the way of loading Nautilus with refactorings? Wouldn't it > be better to include RB dependencis in ConfigurationOfNautilus and have a > specific group there. So you can do for example > > ConfigurationOfNautilus project stableVersion load: 'WithRefactorings'. > > ? > > BTW, I checked the ConfigurationOfNautilusRefactoring and it looks you > miss a critical feature of Metacello: project references :) From > ConfigurationOfNautilusRefactoring you can directly depend on > ConfigurationOfRB or ConfigurationOfNautilus rather than duplicating > everything in there. Don't tell Stef you didn't read the chapter hahahaha > > > > >> It loads everything. >> >> For now I have only done some refactorings for classes, so if you popup >> the menu on a class, a new item named Refactoring should appear :) >> >> Moreover, the 'rename class' method is replaced by the RB one :) >> >> >> Thanks in advance for your feedback, and if you want to participate, you >> are more than welcome :) >> >> >> Ben >> > > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

Feb. 20, 2012

Re: [Pharo-project] A challenge for all who cares

by Frank Shearar

On 20 February 2012 21:58, Guido Stepken <gstepken(a)googlemail.com> wrote: > Am 20.02.2012 21:18, schrieb Frank Shearar: > >> On 20 February 2012 19:41, Guido Stepken<gstepken(a)googlemail.com> Â wrote: >>> >>> Am 20.02.2012 10:22, schrieb Edgar J. De Cleene: >>> >>> Yesterday in a response to Craig I said have a Cuis with a wiki on top >>> and >>> this .image is 5 mb and run on a âmodernâ G4 400 mhz PowerMac. >>> >>> Thatâs is a beauty and the power of Cuis, thanks Juan for your reduced >>> image >>> of 2 mb >>> >>> >>> Looks nice. >>> >>> World menu -> Â appearance -> Â set desktop color -> Â Error >>> >>> What i - never ever - understand is, why - when Smalltalk is a reflective >>> language and there are so mighty tools - like Moose - out there, able to >>> search the whole codebase for possible occurrences of "message not >>> understood"????? >> >> This is just a trivial application of the solution to the Halting >> Problem (left as an exercise for the reader). >> >> Or: if you want to avoid MNU, don't use a dynamically typed language. > > > Thank you, indirectly admitting, that there must be such a tool. ;-) > > Think! Sure. Given a decent statically typed language you can completely avoid the null problem, at least if you leave out input, which is what Igor's hinting at in his reply to me. And as soon as you allow arbitrary input, you're hosed. That is, you run smack into the entscheidungsproblem. So, no, I was quite explicitly saying that there is provably no such tool. If you're finding a bug, then _report it_. Ideally, _produce a replicable series of steps to expose the bug_. You can program, so _write a test for it_. frank

Feb. 20, 2012

Re: [Pharo-project] A challenge for all who cares

by Carlo

Guido what are you on? arghh soooo annoying Think! Don't argue! You're annoying! On 21 Feb 2012, at 12:06 AM, Guido Stepken wrote: Am 20.02.2012 21:30, schrieb Nicolas Cellier: > What, what, the right development process wouldn't solve such a > trivial problem ? > Guido, try to inspect yourself with all your introspection tools and > development process know how, because I have the feeling that despite > the many answers you got, you still face a message not understood > problem ;) > > Nicolas Nicolas, i *know*, there must be a solution! Cannot be, that i klick into a menu and *directly* run into error messages. Think! Develop the development process! Don't argue! tnx, Guido Stepken

Feb. 20, 2012

Re: [Pharo-project] A challenge for all who cares

by Camillo Bruni

A true don quixote of modern times fighting the endless mills of the halting problem again you made my day :D On 2012-02-20, at 23:01, Guido Stepken wrote: > Am 20.02.2012 21:30, schrieb Nicolas Cellier: >> Le 20 fÃ©vrier 2012 21:18, Frank Shearar<frank.shearar(a)gmail.com> a Ã©crit : >>> On 20 February 2012 19:41, Guido Stepken<gstepken(a)googlemail.com> wrote: >>>> Am 20.02.2012 10:22, schrieb Edgar J. De Cleene: >>>> >>>> Yesterday in a response to Craig I said have a Cuis with a wiki on top and >>>> this .image is 5 mb and run on a âmodernâ G4 400 mhz PowerMac. >>>> >>>> Thatâs is a beauty and the power of Cuis, thanks Juan for your reduced image >>>> of 2 mb >>>> >>>> >>>> Looks nice. >>>> >>>> World menu -> appearance -> set desktop color -> Error >>>> >>>> What i - never ever - understand is, why - when Smalltalk is a reflective >>>> language and there are so mighty tools - like Moose - out there, able to >>>> search the whole codebase for possible occurrences of "message not >>>> understood"????? >>> This is just a trivial application of the solution to the Halting >>> Problem (left as an exercise for the reader). >>> >>> Or: if you want to avoid MNU, don't use a dynamically typed language. >>> >> What, what, the right development process wouldn't solve such a >> trivial problem ? >> Guido, try to inspect yourself with all your introspection tools and >> development process know how, because I have the feeling that despite >> the many answers you got, you still face a message not understood >> problem ;) >> >> Nicolas > > There *is* a possibility to check, if there is some sender sending something, that a receiver cannot understand. > > NONSENSE! > > Do it, develop the development process, insure quality in the code!!! > > Have fun! > > Guido Stepken >

Feb. 20, 2012