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

Re: [Pharo-dev] Athens BitBlt bug?

by Nicolai Hess

2015-01-27 21:46 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: > Anyone knows what this BitBlt bug is or was? > 12818 <https://pharo.fogbugz.com/default.asp?12818> Last row missing > 13236 <https://pharo.fogbugz.com/default.asp?13236> Fix 1 extra height > for Cairo surface > > Because with the fix in 13236, it is not (easily) possible to make > a repeating (vertical) pattern paint with 1 pixel height: > 14813 <https://pharo.fogbugz.com/default.asp?14813> Wrong size for Athens > surface pattern paint from a Form > > > nicolai > > > BUMP

March 13, 2015

Re: [Pharo-dev] [BUG?]: Strange Fuel Result

by Max Leske

> On 13 Mar 2015, at 08:39, Max Leske <maxleske(a)gmail.com> wrote: > >> >> On 13 Mar 2015, at 07:37, Max Leske <maxleske(a)gmail.com> wrote: >> >> >>> On 13 Mar 2015, at 02:24, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>> >>> Sean P. DeNigris wrote >>>> the file-in target had the slots in the same order as the inst var >>>> indexes. >>> >>> One more observation: if I serialize in the second image (the one that >>> originally materialized), and materialize in a fresh image, the object is >>> faithfully created i.e. the same as the serialized object. >>> >>> >> >> Hi Sean >> >> This definitely sounds like a problem related to slots. Fuel materializes instance variables by name and not by index, so what you describe shouldnât be possible. Iâll see what I can find. > > Well, that was actually wrong. Fuel does use indeces, not names during materialization. And again I have to correct myself: I was right the first time around, Fuel *does* use indices but *after* determining those indices from the variable names (so the serialized object only holds the variable names, not their indices). In addition, all operations concerning instance variables are done through #instanceVariables. We never use #instVarNames or others, so I really canât see how this could have happened. > >> >> Cheers, >> Max > > I wasnât able to reproduce your problem. I see the problem when I materialize your file but when I try to recreate the situation everything works. Have you tried the same with two fresh images (of the same version respectively)? > > I even tried switching around instance variables to see if I could see a difference in ordering when using #instanceVariables et al but no luck. It really looks like you serialized an instance of a class with switched instance variables. > > What I donât understand, is how you got to the situation where âself slotsâ didnât have the same ordering as âself instanceVariablesâ. > > > >> >>> ----- >>> Cheers, >>> Sean >>> -- >>> View this message in context: http://forum.world.st/BUG-Strange-Fuel-Result-tp4811628p4811631.html <http://forum.world.st/BUG-Strange-Fuel-Result-tp4811628p4811631.html> >>> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com <http://nabble.com/>.

March 13, 2015

Re: [Pharo-dev] [BUG?]: Strange Fuel Result

by stepharo

Le 13/3/15 09:01, Marcus Denker a Ã©crit : >> >> ClassDescription>>superclass: aSuperclass layout: aLayout >> layout := aLayout. >> >> self >> superclass: aSuperclass >> methodDictionary: MethodDictionary new >> format: aLayout format. >> self halt. >> instanceVariables := layout instanceVariables asArray >> >> is (in practice) the only place where âinstanceVariablesâ is set. >> > We need to remove the instanceVariables from ClassDescription and rely on the layout object. > This is on my list for Pharo5â¦ > > #instanceVariables does not even return variables, but stringsâ¦ > > And it is fun that #instanceVariables and #instVarNames are similarly named yet different... Marcus I remember that I added some protocols and I paid attention that it was clear that we would either manipulate a string or the instance variable because I was thinking that one day we would get first class variable. Now it was probably not done everywhere. Stef > > Marcus > > > >

March 13, 2015

Re: [Pharo-dev] Ring class/metaclass

by stepharo

Ok I will propose something. And test it in the context of the FilePackage contents browser I'm writing. Stef Le 9/3/15 07:50, Marcus Denker a Ã©crit : >> On 08 Mar 2015, at 20:16, stepharo <stepharo(a)free.fr> wrote: >> >> Hi >> >> RGClassDefinition named: className. >> >> does not create the associated metaclass. It means that all the clients will have to create the metaclass explicitly >> and I wonder if it would not be better that the default RingClass definition creates it. >> >> What do you think? >> > Yes. In general the API needs to be updated to follow the one for classesâ¦ > > Marcus > > >

March 13, 2015

Re: [Pharo-dev] [BUG?]: Strange Fuel Result

by Max Leske

> On 13 Mar 2015, at 09:01, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> >> ClassDescription>>superclass: aSuperclass layout: aLayout >> layout := aLayout. >> >> self >> superclass: aSuperclass >> methodDictionary: MethodDictionary new >> format: aLayout format. >> self halt. >> instanceVariables := layout instanceVariables asArray >> >> is (in practice) the only place where âinstanceVariablesâ is set. >> > > We need to remove the instanceVariables from ClassDescription and rely on the layout object. > This is on my list for Pharo5â¦ Cool! > > #instanceVariables does not even return variables, but stringsâ¦ > > And it is fun that #instanceVariables and #instVarNames are similarly named yet differentâ¦ Yes, itâs very confusing at the moment... > > Marcus > >

March 13, 2015

Re: [Pharo-dev] [BUG?]: Strange Fuel Result

by Marcus Denker

> > > ClassDescription>>superclass: aSuperclass layout: aLayout > layout := aLayout. > > self > superclass: aSuperclass > methodDictionary: MethodDictionary new > format: aLayout format. > self halt. > instanceVariables := layout instanceVariables asArray > > is (in practice) the only place where âinstanceVariablesâ is set. > We need to remove the instanceVariables from ClassDescription and rely on the layout object. This is on my list for Pharo5â¦ #instanceVariables does not even return variables, but stringsâ¦ And it is fun that #instanceVariables and #instVarNames are similarly named yet different... Marcus

March 13, 2015

Re: [Pharo-dev] [BUG?]: Strange Fuel Result

by Max Leske

> On 13 Mar 2015, at 08:39, Max Leske <maxleske(a)gmail.com> wrote: > >> >> On 13 Mar 2015, at 07:37, Max Leske <maxleske(a)gmail.com> wrote: >> >> >>> On 13 Mar 2015, at 02:24, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>> >>> Sean P. DeNigris wrote >>>> the file-in target had the slots in the same order as the inst var >>>> indexes. >>> >>> One more observation: if I serialize in the second image (the one that >>> originally materialized), and materialize in a fresh image, the object is >>> faithfully created i.e. the same as the serialized object. >>> >>> >> >> Hi Sean >> >> This definitely sounds like a problem related to slots. Fuel materializes instance variables by name and not by index, so what you describe shouldnât be possible. Iâll see what I can find. > > Well, that was actually wrong. Fuel does use indeces, not names during materialization. > >> >> Cheers, >> Max > > I wasnât able to reproduce your problem. I see the problem when I materialize your file but when I try to recreate the situation everything works. Have you tried the same with two fresh images (of the same version respectively)? > > I even tried switching around instance variables to see if I could see a difference in ordering when using #instanceVariables et al but no luck. It really looks like you serialized an instance of a class with switched instance variables. > > What I donât understand, is how you got to the situation where âself slotsâ didnât have the same ordering as âself instanceVariablesâ. AFAICT that can only happen if thereâs an error during class modification, since this ClassDescription>>superclass: aSuperclass layout: aLayout layout := aLayout. self superclass: aSuperclass methodDictionary: MethodDictionary new format: aLayout format. self halt. instanceVariables := layout instanceVariables asArray is (in practice) the only place where âinstanceVariablesâ is set. > > > >> >>> ----- >>> Cheers, >>> Sean >>> -- >>> View this message in context: http://forum.world.st/BUG-Strange-Fuel-Result-tp4811628p4811631.html <http://forum.world.st/BUG-Strange-Fuel-Result-tp4811628p4811631.html> >>> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com <http://nabble.com/>.

March 13, 2015

Re: [Pharo-dev] [BUG?]: Strange Fuel Result

by Max Leske

> On 13 Mar 2015, at 07:37, Max Leske <maxleske(a)gmail.com> wrote: > > >> On 13 Mar 2015, at 02:24, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> Sean P. DeNigris wrote >>> the file-in target had the slots in the same order as the inst var >>> indexes. >> >> One more observation: if I serialize in the second image (the one that >> originally materialized), and materialize in a fresh image, the object is >> faithfully created i.e. the same as the serialized object. >> >> > > Hi Sean > > This definitely sounds like a problem related to slots. Fuel materializes instance variables by name and not by index, so what you describe shouldnât be possible. Iâll see what I can find. Well, that was actually wrong. Fuel does use indeces, not names during materialization. > > Cheers, > Max I wasnât able to reproduce your problem. I see the problem when I materialize your file but when I try to recreate the situation everything works. Have you tried the same with two fresh images (of the same version respectively)? I even tried switching around instance variables to see if I could see a difference in ordering when using #instanceVariables et al but no luck. It really looks like you serialized an instance of a class with switched instance variables. What I donât understand, is how you got to the situation where âself slotsâ didnât have the same ordering as âself instanceVariablesâ. > >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/BUG-Strange-Fuel-Result-tp4811628p4811631.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> >

March 13, 2015

Re: [Pharo-dev] [BUG?]: Strange Fuel Result

by Max Leske

> On 13 Mar 2015, at 02:24, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Sean P. DeNigris wrote >> the file-in target had the slots in the same order as the inst var >> indexes. > > One more observation: if I serialize in the second image (the one that > originally materialized), and materialize in a fresh image, the object is > faithfully created i.e. the same as the serialized object. > > Hi Sean This definitely sounds like a problem related to slots. Fuel materializes instance variables by name and not by index, so what you describe shouldnât be possible. Iâll see what I can find. Cheers, Max > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/BUG-Strange-Fuel-Result-tp4811628p4811631.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

March 13, 2015

Re: [Pharo-dev] [BUG?]: Strange Fuel Result

by Sean P. DeNigris

Sean P. DeNigris wrote > the file-in target had the slots in the same order as the inst var > indexes. One more observation: if I serialize in the second image (the one that originally materialized), and materialize in a fresh image, the object is faithfully created i.e. the same as the serialized object. ----- Cheers, Sean -- View this message in context: http://forum.world.st/BUG-Strange-Fuel-Result-tp4811628p4811631.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 13, 2015