- Pharo-dev - lists.pharo.org

[update 3.0] #30329

by Esteban Lorenzano

Aug. 9, 2013

Re: [Pharo-dev] Mariano & Behavior>>methodDict

by Nicolas Cellier

+my own 2 cents on this one 2013/8/9 Igor Stasenko <siguctua(a)gmail.com> > my 2 cents. > the method should be like that: > > Behavior>>methodDict > ^ methodDict > > the tools should be aware that it is low-level accessor and result can be > nil. > Or use higher-level accessors provided by Class api (like #selectors > etc) to avoid hacky coding. > > On 9 August 2013 14:33, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Hello Mariano and others, > > > > In Pharo there is a method: > > > > Behavior>>methodDict > > methodDict == nil ifTrue: [^ MethodDictionary new ]. > > ^ methodDict > > > > It seems (according to the latest author) that it is Mariano who changed > it > > from: > > > > Behavior>>methodDict > > methodDict == nil ifTrue: [self error: 'MethodDict is nil']. > > ^ methodDict > > > > A comment is present: > > > > "The method dictionary of a class can be nil when we want to use > the > > #cannotInterpret: hook. Indeed when a class dictionary is nil, the VM > sends > > the message cannotInterpret: to the receiver but starting the look up in > the > > superclass of the class whose method dictionary was nil. > > Now the system relies that when the message methodDict is sent to a > class a > > method dictionary is returned. In order to prevent the complaints of > tools > > and IDE unaware of this feature, we fool them by providing an empty > > MethodDictionary. This will hopefully work in most cases, but the tools > will > > loose the ability to modify the behavior of this behavior. The user of > > #cannotInterpret: should be aware of this." > > > > Now my problem is when I do: > > > > MyClass methodDict: nil. > > MyClass new name. > > > > It crashes the image in latest Pharo 3. > > > > Mariano, do you have an idea on how to fix it ? I ask you because you are > > the latest author and it seems tat the bug comes from this method. > > > > Thanks for any answer. > > > > -- > Best regards, > Igor Stasenko. > >

Aug. 9, 2013

Re: [Pharo-dev] Mariano & Behavior>>methodDict

by Igor Stasenko

my 2 cents. the method should be like that: Behavior>>methodDict ^ methodDict the tools should be aware that it is low-level accessor and result can be nil. Or use higher-level accessors provided by Class api (like #selectors etc) to avoid hacky coding. On 9 August 2013 14:33, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hello Mariano and others, > > In Pharo there is a method: > > Behavior>>methodDict > methodDict == nil ifTrue: [^ MethodDictionary new ]. > ^ methodDict > > It seems (according to the latest author) that it is Mariano who changed it > from: > > Behavior>>methodDict > methodDict == nil ifTrue: [self error: 'MethodDict is nil']. > ^ methodDict > > A comment is present: > > "The method dictionary of a class can be nil when we want to use the > #cannotInterpret: hook. Indeed when a class dictionary is nil, the VM sends > the message cannotInterpret: to the receiver but starting the look up in the > superclass of the class whose method dictionary was nil. > Now the system relies that when the message methodDict is sent to a class a > method dictionary is returned. In order to prevent the complaints of tools > and IDE unaware of this feature, we fool them by providing an empty > MethodDictionary. This will hopefully work in most cases, but the tools will > loose the ability to modify the behavior of this behavior. The user of > #cannotInterpret: should be aware of this." > > Now my problem is when I do: > > MyClass methodDict: nil. > MyClass new name. > > It crashes the image in latest Pharo 3. > > Mariano, do you have an idea on how to fix it ? I ask you because you are > the latest author and it seems tat the bug comes from this method. > > Thanks for any answer. -- Best regards, Igor Stasenko.

Aug. 9, 2013

Mariano & Behavior>>methodDict

by ClÃ©ment Bera

Hello Mariano and others, In Pharo there is a method: Behavior>>methodDict methodDict == nil ifTrue: [^ MethodDictionary new ]. ^ methodDict It seems (according to the latest author) that it is Mariano who changed it from: Behavior>>methodDict methodDict == nil ifTrue: [self error: 'MethodDict is nil']. ^ methodDict A comment is present: "The method dictionary of a class can be nil when we want to use the #cannotInterpret: hook. Indeed when a class dictionary is nil, the VM sends the message cannotInterpret: to the receiver but starting the look up in the superclass of the class whose method dictionary was nil. Now the system relies that when the message methodDict is sent to a class a method dictionary is returned. In order to prevent the complaints of tools and IDE unaware of this feature, we fool them by providing an empty MethodDictionary. This will hopefully work in most cases, but the tools will loose the ability to modify the behavior of this behavior. The user of #cannotInterpret: should be aware of this." Now my problem is when I do: MyClass methodDict: nil. MyClass new name. It crashes the image in latest Pharo 3. Mariano, do you have an idea on how to fix it ? I ask you because you are the latest author and it seems tat the bug comes from this method. Thanks for any answer.

Aug. 9, 2013

Re: [Pharo-dev] Put issues from cog issue tracker into pharo issue tracker

by Igor Stasenko

On 9 August 2013 13:28, Camillo Bruni <camillobruni(a)gmail.com> wrote: > thanks, perfect! > > that's very nice, now we have everything in one place. > Nobody besides Pharo guys touched this issue tracker anyway :) > if that would be true, i wouldn't say anything.. The truth is that pharo team is most active on it.. yes. But does that give us right to decide what to do with it? -- Best regards, Igor Stasenko.

Aug. 9, 2013

Re: [Pharo-dev] Put issues from cog issue tracker into pharo issue tracker

by Camillo Bruni

thanks, perfect! that's very nice, now we have everything in one place. Nobody besides Pharo guys touched this issue tracker anyway :) On 2013-08-07, at 12:56, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > https://pharo.fogbugz.com/default.asp?pre=preSaveFilterProject&ixProject=6 > > They are under the Pharo-VM project. > > That way we can handle them easily. > > Guille

Aug. 9, 2013

Re: [Pharo-dev] Put issues from cog issue tracker into pharo issue tracker

by Igor Stasenko

I must admit, that even despite that most of us grinding teeth when using it, it is quite good and people using it a lot. And service quality is also impressive: i don't remember we had any downtime, system errors or any other outages since started using it. -- Best regards, Igor Stasenko.

Aug. 9, 2013

auto updates from issue tracker now blocked (was: Put issues from cog issue tracker into pharo issue tracker)

by David T. Lewis

We have gotten well over 100 updates to the vm-dev list for issues being moved around between various issue trackers. This is excessive and seems to be of little relevance to the vm-dev list. As list admin for the vm-dev list, I am responsible for keeping things like this under control. Unless I hear a convincing argument to the contrary, I will disable the cog(a)googlecode.com updates 24 hours from now. Dave On Thu, Aug 08, 2013 at 04:04:44PM +0200, Henrik Johansen wrote: > > On Aug 8, 2013, at 3:03 , Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 8 August 2013 14:14, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > >> > >> I guess that solves the question around the fate of the cog issue tracker: I > >> didn't mean a deprecation or similar, people can continue using it as they > >> want. I put for that links so people can go back and forth between the issue > >> trackers. My unique and good intention was to make those issues more > >> visible. > > > > Thanks, Guillermo. > > I think everyone understands that your intention was for good, but > > when you don't inform > > people properly they tend to think worst (including me) > > > > :) > > > > -- > > Best regards, > > Igor Stasenko. > > > > Especially when you end up spamming VM-dev with Cog issue tracker updates saying "Moved to fogbugz". > Even with the modified updates, why you'd need to mirror an existing tracker for a related but distinct project into the Pharo tracker, with the synchronization issues that might cause, js still a bit beyond me. > > Cheers, > Henry >

Aug. 8, 2013

[update 3.0] #30328

by StÃ©phane Ducasse

Aug. 8, 2013

Re: [Pharo-dev] Put issues from cog issue tracker into pharo issue tracker

by StÃ©phane Ducasse

On Aug 8, 2013, at 7:37 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Thu, 8 Aug 2013, Esteban Lorenzano wrote: > >> that's a restriction made by the service we choose. > > So it is you, who have chosen the restriction. > >> issues are publicly visible here: >> >> http://bugs.pharo.org >> >> and there you also can register your self so you can also edit issues in fogbugz. >> so yes... is public in the "non-restricted access" meaning of the word. > > The barrier is way to high for anyone without an account to access the tracker. All links to issues on this mailing list point to fogbugz.com. Finding the matching issue on bugs.pharo.org seems to be kinda impossible. > For example can you point me to the publicly visible link for this case https://pharo.fogbugz.com/f/cases/11144 (without checking pharo.fogbugz.com ofc)? > > Also bugs.pharo.org doesn't seem to be up-to-date. For example I can't find the recently moved issues from the Cog tracker. Levente we did not take fogbuz because it forces people to log to edit bugs. We took it because google removed the script API of google code. We had really something else to do than to change a bug tracker when it was not the moment nor our wishes. Now fogbugz people nicely offered us to host and be able to use software that costs 25$ per site per month. So we decided to give a try and it has the cost that we cannot edit bugs without being log and a complex interface but we are happy that we do not have to run mantis or another bug tracker by ourselves. Now guillermo saw that squeakers use the squeak bug tracker to track Cog VM bugs so there is no point for us to have two bugtrackers to deal with. So this is simple I guess and this bug tracker stays a public one. Anybody on earth willing to have an access can get one. S. > > > Levente > >> >> Esteban >> >> On Aug 8, 2013, at 4:57 PM, Mark Bestley <news{(a)bestley.co.uk> wrote: >> >>> Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>>> On 8 August 2013 13:35, Levente Uzonyi >>> <leves(a)elte.hu> wrote: > > On Thu, 8 Aug 2013, >>> StÃ©phane Ducasse wrote: > > g the issue on a public tracker means >>> private? > > > > > > How is that a "public tracker"? > > > > can you >>> elaborate? > https://pharo.fogbugz.com/ > is publicly accessible, no? or >>> what makes you think it is not public? > >>> >>> Take the first bug fix from the Pharo Summer release details at >>> <https://pharo.fogbugz.com/f/cases/10014/World-menu-System-Switch-User-s >>> erves-no-purpose> >>> >>> This gives a the fogbugz log in page so to get info you need to login so >>> not public (also are the bugs indexed by google?) >>> >>> >>> -- >>> Mark >>> >>> >> >>

Aug. 8, 2013