March 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo4] RBEnvironment-based search is broken

by Nicolai Hess

2015-03-09 14:43 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > > > 2015-03-09 14:39 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: > >> 2015-03-09 14:18 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: >> >>> in short, implementorsOf:/referencesTo:/ is broken (does not search over >>> the class side of things). >>> >>> Moreover, depending on the kind of RBEnvironment one is looking at: >>> >>> allClasses >>> returns only the classes >>> or >>> returns classes and metaclasses >>> >>> >> I reported a couple of issues at fogbugz related to this (actually about >> smalllint validations rules, but they >> depend on this change on RBEnvironments) >> And I raised some topics about this on the mailing list. >> > > Ok, then we know what was the reason. > > >> >> I was not involved in the latest changes on RBEnvironment and don't have >> any project that >> depends on RBEnvironment. >> >> So I can *do* the fixes I proposed, but I will not make the decisions. >> Just waiting for feedback. >> > > Which issues are we talking about? I can have a look. > 14230 <https://pharo.fogbugz.com/default.asp?14230> Some rules aren't applied on the classside anymore 14621 <https://pharo.fogbugz.com/default.asp?14621> Some RBBrowserEnvironments don't work well with Metaclasses closed but related: 14228 <https://pharo.fogbugz.com/default.asp?14228> critic rules running on all methods of a class extended by a package (closed) 15077 <https://pharo.fogbugz.com/default.asp?15077> CriticBrowser MNU Trait>>methodClass (closed) closed, related and part of the problem: 14096 <https://pharo.fogbugz.com/default.asp?14096> Rewrite lint rules to check classes and methods 14098 <https://pharo.fogbugz.com/default.asp?14098> allClassesAndTraits significantly different from allClassesAndTraitsDo: And mailing list "discussions" http://forum.world.st/RBEnvironments-allClasses-Traits-Meta-tp4796370.html http://forum.world.st/What-is-a-Behavior-are-Traits-behavior-too-tp4804691.… > > >> >> >>> Of course, implementorsOf: is broken because allClasses does not returns >>> the metaclasses. >>> >>> I like it when people "normalize" things :( >>> >> >> He asked for feedback on this. And as far as I know no one complained. >> > > Fair enough. > > Really need to have more test cases to cover things like that :) > RBEnvironments are so nice, small but really powerfull (refactoring/searching/validation). I would like to get this right. > > Thierry >

March 9, 2015

Re: [Pharo-dev] I need to put smalltalkhub down (max 30m)

by Esteban Lorenzano

no, not yetâ¦ just wait a few minutes more please. > On 09 Mar 2015, at 14:43, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > okâ¦ looks like it is backâ¦ but no promises :P > > Esteban > >> On 09 Mar 2015, at 14:13, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> Hi, >> >> I need to apply an updateâ¦ nothing that you will actually see, but is needed :) >> I will put it down at 13:30 UTC (14:30 here in continental Europe, 10:30 in Argentina and I donât know the rest of the worldâ¦ but a hint: is in 15min :P ) >> >> Esteban >

March 9, 2015

Re: [Pharo-dev] [Pharo4] RBEnvironment-based search is broken

by Thierry Goubier

2015-03-09 14:39 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: > 2015-03-09 14:18 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> in short, implementorsOf:/referencesTo:/ is broken (does not search over >> the class side of things). >> >> Moreover, depending on the kind of RBEnvironment one is looking at: >> >> allClasses >> returns only the classes >> or >> returns classes and metaclasses >> >> > I reported a couple of issues at fogbugz related to this (actually about > smalllint validations rules, but they > depend on this change on RBEnvironments) > And I raised some topics about this on the mailing list. > Ok, then we know what was the reason. > > I was not involved in the latest changes on RBEnvironment and don't have > any project that > depends on RBEnvironment. > > So I can *do* the fixes I proposed, but I will not make the decisions. > Just waiting for feedback. > Which issues are we talking about? I can have a look. > > >> Of course, implementorsOf: is broken because allClasses does not returns >> the metaclasses. >> >> I like it when people "normalize" things :( >> > > He asked for feedback on this. And as far as I know no one complained. > Fair enough. Really need to have more test cases to cover things like that :) Thierry

March 9, 2015

Re: [Pharo-dev] I need to put smalltalkhub down (max 30m)

by Esteban Lorenzano

okâ¦ looks like it is backâ¦ but no promises :P Esteban > On 09 Mar 2015, at 14:13, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > I need to apply an updateâ¦ nothing that you will actually see, but is needed :) > I will put it down at 13:30 UTC (14:30 here in continental Europe, 10:30 in Argentina and I donât know the rest of the worldâ¦ but a hint: is in 15min :P ) > > Esteban

March 9, 2015

Re: [Pharo-dev] [Pharo4] RBEnvironment-based search is broken

by Nicolai Hess

2015-03-09 14:18 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > in short, implementorsOf:/referencesTo:/ is broken (does not search over > the class side of things). > > Moreover, depending on the kind of RBEnvironment one is looking at: > > allClasses > returns only the classes > or > returns classes and metaclasses > > I reported a couple of issues at fogbugz related to this (actually about smalllint validations rules, but they depend on this change on RBEnvironments) And I raised some topics about this on the mailing list. I was not involved in the latest changes on RBEnvironment and don't have any project that depends on RBEnvironment. So I can *do* the fixes I proposed, but I will not make the decisions. Just waiting for feedback. > Of course, implementorsOf: is broken because allClasses does not returns > the metaclasses. > > I like it when people "normalize" things :( > He asked for feedback on this. And as far as I know no one complained. nicolai > > Thierry >

March 9, 2015

[Pharo4] RBEnvironment-based search is broken

by Thierry Goubier

in short, implementorsOf:/referencesTo:/ is broken (does not search over the class side of things). Moreover, depending on the kind of RBEnvironment one is looking at: allClasses returns only the classes or returns classes and metaclasses Of course, implementorsOf: is broken because allClasses does not returns the metaclasses. I like it when people "normalize" things :( Thierry

March 9, 2015

I need to put smalltalkhub down (max 30m)

by Esteban Lorenzano

Hi, I need to apply an updateâ¦ nothing that you will actually see, but is needed :) I will put it down at 13:30 UTC (14:30 here in continental Europe, 10:30 in Argentina and I donât know the rest of the worldâ¦ but a hint: is in 15min :P ) Esteban

March 9, 2015

Re: [Pharo-dev] valid name for an instance variable?

by Marcus Denker

> On 09 Mar 2015, at 13:54, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > is x: (with colon) a valid inst var name ? no. > I can create the following object > > Object subclass: #InstVarNameTest > instanceVariableNames: 'x:' > classVariableNames: '' > category: 'TTT' > > But of course, I can not write an assignment statement. > Yes, but it is good that it allows to do these thingsâ¦ e.g. you can load a class definition with Slots in Pharo3, and it will put the slot definition as the name. If it would raise an error, loading would be impossible. > I am asking because if > Symbol>>#asMutator is called an a symbol with colon like x: > it returns > x:: > > It looks like that x:: is not even a valid message selector. > I would like to change the asMutator method to return > x: if it is called on x: Yes, that would make sense. Marcus

March 9, 2015

valid name for an instance variable?

by Nicolai Hess

is x: (with colon) a valid inst var name ? I can create the following object Object subclass: #InstVarNameTest instanceVariableNames: 'x:' classVariableNames: '' category: 'TTT' But of course, I can not write an assignment statement. I am asking because if Symbol>>#asMutator is called an a symbol with colon like x: it returns x:: It looks like that x:: is not even a valid message selector. I would like to change the asMutator method to return x: if it is called on x: (or throw an error ?) nicolai

March 9, 2015

Re: [Pharo-dev] Bloc: Why Fast Drag?

by Alain Plantec

checking this was in my to do list. Thanks a lot Nicolai, I will make a try. Alain > On 09 Mar 2015, at 11:54, Nicolai Hess <nicolaihess(a)web.de> wrote: > > 2015-03-09 8:59 GMT+01:00 Alain Plantec via Pharo-dev <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org>>: > > > ---------- Weitergeleitete Nachricht ---------- > From: Alain Plantec <alain.plantec(a)yahoo.com <mailto:alain.plantec@yahoo.com>> > To: Pharo Development List <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org>> > Cc: > Date: Mon, 9 Mar 2015 08:31:46 +0100 > Subject: Re: [Pharo-dev] Bloc: Why Fast Drag? > yes, this is because even in Bloc, morphic morphs are still drawn with the Form based framework, > whereas the hand is itself drawn with Athens. When a morph is dragged, it is added as a > hand child. As a hand child, it should also be drawn with Athens but not every Morphic morphs > can so, so far, a gray rectangle is drawn during the drag. > > When it will be possible to draw any Morphic morph with Athens, then all dragged morphs will be > rendered normally. > > This works quite well now, with the latest pharo 40. > You can test this yourself, replace Morph>>#drawWhenGrabbedByHandOnAthensCanvas: aCanvas > with > > Morph>>#drawWhenGrabbedByHandOnAthensCanvas: aCanvas > self fullDrawOnAthensCanvas: aCanvas > > Nicolai > > > > Cheers > Alain > > > > Le 9 mars 2015 Ã 04:28, Sean P. DeNigris <sean(a)clipperadams.com <mailto:sean@clipperadams.com>> a Ã©crit : > > > > From "Experiencing Self Objects": "Moving an object moves the actual object > > around the screen, not an outline, which contributes to maintaining the > > solidity of objects." > > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: http://forum.world.st/Bloc-Why-Fast-Drag-tp4810544.html <http://forum.world.st/Bloc-Why-Fast-Drag-tp4810544.html> > > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > > > > > >

March 9, 2015