Hi, We faced a problem with committing and loading packages with Slots. It seams like when loading a package, compiler first compiles a class that uses custom Slot and only then Slot itself. It leads to an error like MessageNotUnderstood: CustomSlot>>index:, but index: is implemented for sure! I'm using the latest image and vm. How to reproduce: 1) Create CustomSlot: Slot subclass: #CustomSlot instanceVariableNames: '' classVariableNames: '' category: 'CustomSlot-Test' Implement the following methods: index ^ index index: anIndex index := anIndex read: anObject ^ anObject instVarAt: index write: aValue to: anObject ^ anObject instVarAt: index put: aValue. 2) Add our custom class: Object subclass: #CutomClass slots: { #var => CustomSlot } classVariables: { } category: 'CustomSlot-Test' 3) Commit 4) Try to load in fresh image 5) Face error Any suggestions? Thanks, Alex
On 22 Jan 2015, at 17:20, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Hi,
We faced a problem with committing and loading packages with Slots. It seams like when loading a package, compiler first compiles a class that uses custom Slot and only then Slot itself. It leads to an error like MessageNotUnderstood: CustomSlot>>index:, but index: is implemented for sure! I'm using the latest image and vm.
I think the reason why this fails is that it loads the first all classes and then the methods. But this just makes another issue prominent: I want to add a class in-between Slot and InstanceVariableSlot for people to subclass in this cas (AbstractInstanceVariableSlot). Because InstanceVariableSlot already needs the byte code level stuff, while Slot is the superclass of all Slots, even those that have no index. I will do that as the next step.
How to reproduce:
1) Create CustomSlot:
Slot subclass: #CustomSlot instanceVariableNames: '' classVariableNames: '' category: 'CustomSlot-Test'
Implement the following methods:
index ^ index
index: anIndex index := anIndex
read: anObject ^ anObject instVarAt: index
write: aValue to: anObject ^ anObject instVarAt: index put: aValue.
2) Add our custom class:
Object subclass: #CutomClass slots: { #var => CustomSlot } classVariables: { } category: 'CustomSlot-Test'
3) Commit 4) Try to load in fresh image 5) Face error
Any suggestions?
Thanks, Alex
Hi Marcus, I think I just found a workaround: if you make Slot>>isVirtual to return *true* by default and override it in InstanceVariableSlot to return *false* the problem will be gone I don't want to subclass InstanceVariableSlot because it becomes impossible to see definition of class with slots in Browser and as soon as I add new instvars all old ones become default InstanceVariableSlot and not my custom. Cheers, Alex On Thu, Jan 22, 2015 at 5:32 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 22 Jan 2015, at 17:20, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Hi,
We faced a problem with committing and loading packages with Slots. It seams like when loading a package, compiler first compiles a class that uses custom Slot and only then Slot itself. It leads to an error like MessageNotUnderstood: CustomSlot>>index:, but index: is implemented for sure! I'm using the latest image and vm.
I think the reason why this fails is that it loads the first all classes and then the methods. But this just makes another issue prominent:
I want to add a class in-between Slot and InstanceVariableSlot for people to subclass in this cas (AbstractInstanceVariableSlot). Because InstanceVariableSlot already needs the byte code level stuff, while Slot is the superclass of all Slots, even those that have no index.
I will do that as the next step.
How to reproduce:
1) Create CustomSlot:
Slot subclass: #CustomSlot instanceVariableNames: '' classVariableNames: '' category: 'CustomSlot-Test'
Implement the following methods:
index ^ index
index: anIndex index := anIndex
read: anObject ^ anObject instVarAt: index
write: aValue to: anObject ^ anObject instVarAt: index put: aValue.
2) Add our custom class:
Object subclass: #CutomClass slots: { #var => CustomSlot } classVariables: { } category: 'CustomSlot-Test'
3) Commit 4) Try to load in fresh image 5) Face error
Any suggestions?
Thanks, Alex
On 22 Jan 2015, at 17:44, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Hi Marcus,
I think I just found a workaround: if you make Slot>>isVirtual to return true by default and override it in InstanceVariableSlot to return false the problem will be gone
Yes, that should be done.
I don't want to subclass InstanceVariableSlot because it becomes impossible to see definition of class with slots in Browser and as soon as I add new instvars all old ones become default InstanceVariableSlot and not my custom.
Yes, I will fix that one, too. Because it can be nice to just subclass that one⦠but people need to then know about byte code and change the emit* methods, too. Therefore the first step: https://pharo.fogbugz.com/f/cases/14772/add-AbstractInstanceVariableSlot Marcus
On 22 Jan 2015, at 17:52, Marcus Denker <marcus.denker@inria.fr> wrote:
On 22 Jan 2015, at 17:44, Aliaksei Syrel <alex.syrel@gmail.com <mailto:alex.syrel@gmail.com>> wrote:
Hi Marcus,
I think I just found a workaround: if you make Slot>>isVirtual to return true by default and override it in InstanceVariableSlot to return false the problem will be gone
Yes, that should be done.
I don't want to subclass InstanceVariableSlot because it becomes impossible to see definition of class with slots in Browser and as soon as I add new instvars all old ones become default InstanceVariableSlot and not my custom.
Yes, I will fix that one, too. Because it can be nice to just subclass that one⦠but people need to then know about byte code and change the emit* methods, too.
Therefore the first step:
https://pharo.fogbugz.com/f/cases/14772/add-AbstractInstanceVariableSlot <https://pharo.fogbugz.com/f/cases/14772/add-AbstractInstanceVariableSlot>
This is now in 40457 #isSpecial is fixed, too. This means that you can subclass AbstractInstanceVariableSlot and just override #read and #write:to: and it should work. To get more performance, later you should look into #emitStore: and #emitValue: Marcus
Thank you, Marcus, for very fast response Cheers, Alex On Thu, Jan 22, 2015 at 9:11 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 22 Jan 2015, at 17:52, Marcus Denker <marcus.denker@inria.fr> wrote:
On 22 Jan 2015, at 17:44, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Hi Marcus,
I think I just found a workaround: if you make Slot>>isVirtual to return *true* by default and override it in InstanceVariableSlot to return *false* the problem will be gone
Yes, that should be done.
I don't want to subclass InstanceVariableSlot because it becomes impossible to see definition of class with slots in Browser and as soon as I add new instvars all old ones become default InstanceVariableSlot and not my custom.
Yes, I will fix that one, too. Because it can be nice to just subclass that one⦠but people need to then know about byte code and change the emit* methods, too.
Therefore the first step:
https://pharo.fogbugz.com/f/cases/14772/add-AbstractInstanceVariableSlot
This is now in 40457
#isSpecial is fixed, too.
This means that you can subclass AbstractInstanceVariableSlot and just override #read and #write:to: and it should work.
To get more performance, later you should look into #emitStore: and #emitValue:
Marcus
On 22 Jan 2015, at 21:11, Marcus Denker <marcus.denker@inria.fr> wrote:
On 22 Jan 2015, at 17:52, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
On 22 Jan 2015, at 17:44, Aliaksei Syrel <alex.syrel@gmail.com <mailto:alex.syrel@gmail.com>> wrote:
Hi Marcus,
I think I just found a workaround: if you make Slot>>isVirtual to return true by default and override it in InstanceVariableSlot to return false the problem will be gone
Yes, that should be done.
I don't want to subclass InstanceVariableSlot because it becomes impossible to see definition of class with slots in Browser and as soon as I add new instvars all old ones become default InstanceVariableSlot and not my custom.
Yes, I will fix that one, too. Because it can be nice to just subclass that one⦠but people need to then know about byte code and change the emit* methods, too.
Therefore the first step:
https://pharo.fogbugz.com/f/cases/14772/add-AbstractInstanceVariableSlot <https://pharo.fogbugz.com/f/cases/14772/add-AbstractInstanceVariableSlot>
This is now in 40457
#isSpecial is fixed, too.
This means that you can subclass AbstractInstanceVariableSlot and just override #read and #write:to: and it should work.
Hmm⦠maybe IndexedSlot would be a better name� I do not like AbstractSomethings. And it actually is not abstract, it should work (just slower than InstanceVariableSlot) Marcus
This is now in 40457
#isSpecial is fixed, too.
This means that you can subclass AbstractInstanceVariableSlot and just override #read and #write:to: and it should work.
Hmm⦠maybe IndexedSlot would be a better name� I do not like AbstractSomethings. And it actually is not abstract, it should work (just slower than InstanceVariableSlot)
I rename it but keep the AbstractInstanceVariableSlot subclass so it does not brake any code loading. Any users should change AbstractInstanceVariableSlot to IndexedSlot, I will remove the class next week. https://pharo.fogbugz.com/f/cases/14786/Slots-add-HiddenInstanceVariableSlot... <https://pharo.fogbugz.com/f/cases/14786/Slots-add-HiddenInstanceVariableSlot...> Marcus
On 22 Jan 2015, at 17:44, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Hi Marcus,
I think I just found a workaround: if you make Slot>>isVirtual to return true by default and override it in InstanceVariableSlot to return false the problem will be gone
I don't want to subclass InstanceVariableSlot because it becomes impossible to see definition of class with slots in Browser and as soon as I add new instvars all old ones become default InstanceVariableSlot and not my custom.
I will implement the method that checks if a slot should be print the full definition (I guess will rename it, too) to be this: isSpecial "I am just a backward compatible ivar slot. Note: my subclasses are special" ^(self class = InstanceVariableSlot) not this way the subclass of InstanceVariableSlot will print the full definition. Marcus
I will implement the method that checks if a slot should be print the full definition (I guess will rename it, too) to be this: isSpecial "I am just a backward compatible ivar slot. Note: my subclasses are special" ^(self class = InstanceVariableSlot) not this way the subclass of InstanceVariableSlot will print the full definition.
Yes, it would be great! Thanks Cheers, Alex On Thu, Jan 22, 2015 at 5:58 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 22 Jan 2015, at 17:44, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Hi Marcus,
I think I just found a workaround: if you make Slot>>isVirtual to return *true* by default and override it in InstanceVariableSlot to return *false* the problem will be gone
I don't want to subclass InstanceVariableSlot because it becomes impossible to see definition of class with slots in Browser and as soon as I add new instvars all old ones become default InstanceVariableSlot and not my custom.
I will implement the method that checks if a slot should be print the full definition (I guess will rename it, too) to be this:
isSpecial "I am just a backward compatible ivar slot. Note: my subclasses are special" ^(self class = InstanceVariableSlot) not
this way the subclass of InstanceVariableSlot will print the full definition.
Marcus
And I also think that InstanceVariableSlot >>definitionString in subclasses should return self printString and not only its name Cheers, Alex On Thu, Jan 22, 2015 at 6:02 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
I will implement the method that checks if a slot should be print the full
definition (I guess will rename it, too) to be this: isSpecial "I am just a backward compatible ivar slot. Note: my subclasses are special" ^(self class = InstanceVariableSlot) not this way the subclass of InstanceVariableSlot will print the full definition.
Yes, it would be great! Thanks
Cheers, Alex
On Thu, Jan 22, 2015 at 5:58 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 22 Jan 2015, at 17:44, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Hi Marcus,
I think I just found a workaround: if you make Slot>>isVirtual to return *true* by default and override it in InstanceVariableSlot to return *false* the problem will be gone
I don't want to subclass InstanceVariableSlot because it becomes impossible to see definition of class with slots in Browser and as soon as I add new instvars all old ones become default InstanceVariableSlot and not my custom.
I will implement the method that checks if a slot should be print the full definition (I guess will rename it, too) to be this:
isSpecial "I am just a backward compatible ivar slot. Note: my subclasses are special" ^(self class = InstanceVariableSlot) not
this way the subclass of InstanceVariableSlot will print the full definition.
Marcus
On 22 Jan 2015, at 18:06, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
And I also think that InstanceVariableSlot >>definitionString in subclasses should return self printString and not only its name
The thing is that we have two cases: 1) Full definition {#slot => PropertySlot} 2) shortened definition { #ivar } the later one is for ânormalâ instance variables (and globals), for all the cases where slots just model what we have now. the #isSpecial check returns false for those and true for all other slots. I think we should implement definitionString in InstanceVariableSlot to check isSpecial and call the super class method for the case when it is. This way it will work even for subclasses as expected. (the irregularity of the #simple notation adds a bit complexity, but I think it is worth it) Marcus
On 22 Jan 2015, at 18:15, Marcus Denker <marcus.denker@inria.fr> wrote:
On 22 Jan 2015, at 18:06, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
And I also think that InstanceVariableSlot >>definitionString in subclasses should return self printString and not only its name
The thing is that we have two cases:
1) Full definition {#slot => PropertySlot} 2) shortened definition { #ivar }
the later one is for ânormalâ instance variables (and globals), for all the cases where slots just model what we have now.
the #isSpecial check returns false for those and true for all other slots.
I think we should implement definitionString in InstanceVariableSlot to check isSpecial and call the super class method for the case when it is. This way it will work even for subclasses as expected.
This is fixed with https://pharo.fogbugz.com/f/cases/14779/fix-definitionString-for-subclasses-... <https://pharo.fogbugz.com/f/cases/14779/fix-definitionString-for-subclasses-...> Marcus
Perfect, thanks! Until now all faced bugs are gone and it works flawlessly :) Cheers, Alex On Fri, Jan 23, 2015 at 2:42 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 22 Jan 2015, at 18:15, Marcus Denker <marcus.denker@inria.fr> wrote:
On 22 Jan 2015, at 18:06, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
And I also think that InstanceVariableSlot >>definitionString in subclasses should return self printString and not only its name
The thing is that we have two cases:
1) Full definition {#slot => PropertySlot} 2) shortened definition { #ivar }
the later one is for ânormalâ instance variables (and globals), for all the cases where slots just model what we have now.
the #isSpecial check returns false for those and true for all other slots.
I think we should implement definitionString in InstanceVariableSlot to check isSpecial and call the super class method for the case when it is. This way it will work even for subclasses as expected.
This is fixed with
https://pharo.fogbugz.com/f/cases/14779/fix-definitionString-for-subclasses-...
Marcus
participants (2)
-
Aliaksei Syrel -
Marcus Denker