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

Re: [Pharo-dev] Consequence of NBExternalStructure refactorings

by StÃ©phane Ducasse

well if the bug entry is not tag as ready to include the chance to get it loaded is really low. If people do not pay attention to basics like thatâ¦.We will not make progress. Stef On Aug 9, 2013, at 5:18 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Hello, > > lately we changed the object format of subject class from variableByte > to normal one. > > All projects which using NBExternalStructure can meet certain problems with it, > and first which comes is that it may load code cleanly but in fact > result in bogus > variable subclasses of NBExternalStructure , while it can't because > superclass has instance variable. > (i suspecting classbuilder bug, but need to verify first). > > To address that, you need to manually go over all subclasses and double-check. > > Another thing: since now instances NBExternalStructure can also point > to external memory, > special care should be taken for #copying. > Sending #copy to instance which uses external memory, will create a > copy on object memory > (and copy all data from external memory into it). This is same > behavior as in NBExternalArray. > > - there is a bugs in #initialize and #postCopy (fixed but not intergated yet) > https://pharo.fogbugz.com/default.asp?11395#83020 > will do that in nearest time. > > also note, that in callouts, you cannot pass an instance of > NBExternalStructure anymore > to function, which uses raw pointer (like void*) anymore. > > For passing a pointer to structure data for callouts, use > myStructure address > idiom (or use right struct type, which is preferable). > > -- > Best regards, > Igor Stasenko. >

Aug. 9, 2013

Re: [Pharo-dev] Fwd: Consequence of NBExternalStructure refactorings

by Martin Dias

On Fri, Aug 9, 2013 at 5:18 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Hello, > > lately we changed the object format of subject class from variableByte > to normal one. > > All projects which using NBExternalStructure can meet certain problems > with it, > and first which comes is that it may load code cleanly but in fact > result in bogus > variable subclasses of NBExternalStructure , while it can't because > superclass has instance variable. > > (i suspecting classbuilder bug, but need to verify first). > I can help with classbuilder if you confirm the bug cheers, MartÃn

Aug. 9, 2013

Fwd: Consequence of NBExternalStructure refactorings

by Igor Stasenko

Hello, lately we changed the object format of subject class from variableByte to normal one. All projects which using NBExternalStructure can meet certain problems with it, and first which comes is that it may load code cleanly but in fact result in bogus variable subclasses of NBExternalStructure , while it can't because superclass has instance variable. (i suspecting classbuilder bug, but need to verify first). To address that, you need to manually go over all subclasses and double-check. Another thing: since now instances NBExternalStructure can also point to external memory, special care should be taken for #copying. Sending #copy to instance which uses external memory, will create a copy on object memory (and copy all data from external memory into it). This is same behavior as in NBExternalArray. - there is a bugs in #initialize and #postCopy (fixed but not intergated yet) https://pharo.fogbugz.com/default.asp?11395#83020 will do that in nearest time. also note, that in callouts, you cannot pass an instance of NBExternalStructure anymore to function, which uses raw pointer (like void*) anymore. For passing a pointer to structure data for callouts, use myStructure address idiom (or use right struct type, which is preferable). -- Best regards, Igor Stasenko.

Aug. 9, 2013

[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