poolDictionaries removal breaks my projects
So⦠that. Is super cool to remove poolDictionaries from the default class template. What is not cool *at all* is the fact that now my low level projects, who uses them intensively, does not work anymore. The reason? the classes are created without poolDictionaries. So, please⦠whoever pushed this change. Please fix it. thanks, Esteban
Woha that sounds kind of wild Easy on radical changes guys, change have costs On Jan 30, 2014, at 3:14 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
So⦠that.
Is super cool to remove poolDictionaries from the default class template. What is not cool *at all* is the fact that now my low level projects, who uses them intensively, does not work anymore. The reason? the classes are created without poolDictionaries.
So, please⦠whoever pushed this change. Please fix it.
thanks, Esteban
and is even worst: classes from system that uses pools do not show them. take a look at AJx86Assembler it should be like that: AJAssembler subclass: #AJx86Assembler instanceVariableNames: 'instructions last labels stackManager level is64' classVariableNames: '' poolDictionaries: 'AJConstants AJx86Registers' category: 'AsmJit-x86â and now you cannot see it (pools are there, the problem of not being there is with injected classes). And EVEN WORST: I cannot re-add my pools. It just does not works. please, fix it. AND GUYS STOP CHANGING THE API IN A FROZEN VERSION!!!!!! thanks, Esteban On 30 Jan 2014, at 18:14, Esteban Lorenzano <estebanlm@gmail.com> wrote:
So⦠that.
Is super cool to remove poolDictionaries from the default class template. What is not cool *at all* is the fact that now my low level projects, who uses them intensively, does not work anymore. The reason? the classes are created without poolDictionaries.
So, please⦠whoever pushed this change. Please fix it.
thanks, Esteban
I checked: it was introduced in update no. 30711 with #issue 12163
including the following statements:
>"Who uses poolDictionaries? I suspect extremely few of us."
>...
>"It would be a bit cleaner. I know us old timers don't even see the poolDictionaries: line anymore, but >I dislike having to explain it to students."
<humor>
I would also vote for not displaying Traits anymore. It confuses me when I see them.
Instance variables are also overvalued - we should remove them from the default
template too. It's just too confusing to have them there.
And categories now make no sense either - we now have real packages. Let's remove them
since nobody understands them.
Object subclass: #Foo
would be much easier to understand! Maybe we should remove superclass as well - lets
inherit from Object. Would also avoid deep hierarchies like Morphic ;)
</humor>
But for real:
If it is too complicated for students one could build a custom "teaching" image.
>From the info I see on the issue tracker it sounds to me like an "academic" change
- still do not understand the real reason...
Bye
T.
On 30 Jan 2014, at 19:43, Torsten Bergmann <astares@gmx.de> wrote:
I checked: it was introduced in update no. 30711 with #issue 12163 including the following statements:
"Who uses poolDictionaries? I suspect extremely few of us." ... "It would be a bit cleaner. I know us old timers don't even see the poolDictionaries: line anymore, but >I dislike having to explain it to students."
<humor> I would also vote for not displaying Traits anymore. It confuses me when I see them. Instance variables are also overvalued - we should remove them from the default template too. It's just too confusing to have them there.
And categories now make no sense either - we now have real packages. Let's remove them since nobody understands them.
he, humor or not, is our objective to replace them for real packages. Is just that we still do not have the time :)
Object subclass: #Foo
would be much easier to understand! Maybe we should remove superclass as well - lets inherit from Object. Would also avoid deep hierarchies like Morphic ;) </humor>
But for real: If it is too complicated for students one could build a custom "teaching" image.
From the info I see on the issue tracker it sounds to me like an "academic" change - still do not understand the real reason...
Bye T.
On Thu, Jan 30, 2014 at 10:58 AM, Esteban Lorenzano <estebanlm@gmail.com>wrote:
On 30 Jan 2014, at 19:43, Torsten Bergmann <astares@gmx.de> wrote:
I checked: it was introduced in update no. 30711 with #issue 12163 including the following statements:
"Who uses poolDictionaries? I suspect extremely few of us." ... "It would be a bit cleaner. I know us old timers don't even see the poolDictionaries: line anymore, but >I dislike having to explain it to students."
<humor> I would also vote for not displaying Traits anymore. It confuses me when I see them. Instance variables are also overvalued - we should remove them from the default template too. It's just too confusing to have them there.
And categories now make no sense either - we now have real packages. Let's remove them since nobody understands them.
he, humor or not, is our objective to replace them for real packages. Is just that we still do not have the time :)
So VMMaker will get completely broken :-(. Has everyone forgotten IIABDFI?
Object subclass: #Foo
would be much easier to understand! Maybe we should remove superclass as well - lets inherit from Object. Would also avoid deep hierarchies like Morphic ;) </humor>
But for real: If it is too complicated for students one could build a custom "teaching" image.
From the info I see on the issue tracker it sounds to me like an "academic" change - still do not understand the real reason...
Bye T.
-- best, Eliot
On 30 Jan 2014, at 20:03, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Thu, Jan 30, 2014 at 10:58 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 30 Jan 2014, at 19:43, Torsten Bergmann <astares@gmx.de> wrote:
I checked: it was introduced in update no. 30711 with #issue 12163 including the following statements:
"Who uses poolDictionaries? I suspect extremely few of us." ... "It would be a bit cleaner. I know us old timers don't even see the poolDictionaries: line anymore, but >I dislike having to explain it to students."
<humor> I would also vote for not displaying Traits anymore. It confuses me when I see them. Instance variables are also overvalued - we should remove them from the default template too. It's just too confusing to have them there.
And categories now make no sense either - we now have real packages. Let's remove them since nobody understands them.
he, humor or not, is our objective to replace them for real packages. Is just that we still do not have the time :)
So VMMaker will get completely broken :-(. Has everyone forgotten IIABDFI?
it will be compatible, when we do it⦠and will be compatible for a long time. but donât worry, in any case it will not happen in a really *long* time :) and the problem of brokenness, is that it depends a lot on points of view and purposes. Esteban
Object subclass: #Foo
would be much easier to understand! Maybe we should remove superclass as well - lets inherit from Object. Would also avoid deep hierarchies like Morphic ;) </humor>
But for real: If it is too complicated for students one could build a custom "teaching" image.
From the info I see on the issue tracker it sounds to me like an "academic" change - still do not understand the real reason...
Bye T.
-- best, Eliot
In fact I do not understand why the solution can just display Pool when there are and none when not. I think that this is what johan wanted to do. Iâm curious to see why this is not the case. Because it looks obvious that current users should not get impacted. I like the idea to remove pool entry when we do not need it. Sebastien can you give an example of what does not work. Stef
On 30 Jan 2014, at 6:14 , Esteban Lorenzano <estebanlm@gmail.com> wrote:
So⦠that.
Is super cool to remove poolDictionaries from the default class template. What is not cool *at all* is the fact that now my low level projects, who uses them intensively, does not work anymore. The reason? the classes are created without poolDictionaries.
So, please⦠whoever pushed this change. Please fix it.
thanks, Esteban
Sooo, since Iâm curios, anyone care to explain how a change intended to affect whether Nautilus displays pool Dicts end up breaking how theyâre loaded from Monticello? Did Nautilus pick up on the class load announcement from RPackage and end up recompiling the class with itâs own (lacking) default definition or something similarly crazy? Cheers, Henry
I donât know what happened. All that I know is that it was not working and now with the last fix it is, so Iâm happy for now. worried? yes. But not too much :) On 31 Jan 2014, at 14:59, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
On 30 Jan 2014, at 6:14 , Esteban Lorenzano <estebanlm@gmail.com> wrote:
So⦠that.
Is super cool to remove poolDictionaries from the default class template. What is not cool *at all* is the fact that now my low level projects, who uses them intensively, does not work anymore. The reason? the classes are created without poolDictionaries.
So, please⦠whoever pushed this change. Please fix it.
thanks, Esteban
Sooo, since Iâm curios, anyone care to explain how a change intended to affect whether Nautilus displays pool Dicts end up breaking how theyâre loaded from Monticello?
Did Nautilus pick up on the class load announcement from RPackage and end up recompiling the class with itâs own (lacking) default definition or something similarly crazy?
Cheers, Henry
What probably happened is that Monticello loading with pooldictionaries was still working, but Nautilus was not showing them. This is the only thing that changed, and the fix addresses the showing part. So you should not worry. On Jan 31, 2014, at 1:26 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
I donât know what happened. All that I know is that it was not working and now with the last fix it is, so Iâm happy for now. worried? yes. But not too much :)
On 31 Jan 2014, at 14:59, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
On 30 Jan 2014, at 6:14 , Esteban Lorenzano <estebanlm@gmail.com> wrote:
So⦠that.
Is super cool to remove poolDictionaries from the default class template. What is not cool *at all* is the fact that now my low level projects, who uses them intensively, does not work anymore. The reason? the classes are created without poolDictionaries.
So, please⦠whoever pushed this change. Please fix it.
thanks, Esteban
Sooo, since Iâm curios, anyone care to explain how a change intended to affect whether Nautilus displays pool Dicts end up breaking how theyâre loaded from Monticello?
Did Nautilus pick up on the class load announcement from RPackage and end up recompiling the class with itâs own (lacking) default definition or something similarly crazy?
Cheers, Henry
---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
No, because my pools were not there and my tests were failing. But no matters, it works now :)
On 31 Jan 2014, at 17:45, Johan Fabry <jfabry@dcc.uchile.cl> wrote:
What probably happened is that Monticello loading with pooldictionaries was still working, but Nautilus was not showing them. This is the only thing that changed, and the fix addresses the showing part. So you should not worry.
On Jan 31, 2014, at 1:26 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
I donât know what happened. All that I know is that it was not working and now with the last fix it is, so Iâm happy for now. worried? yes. But not too much :)
On 31 Jan 2014, at 14:59, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
On 30 Jan 2014, at 6:14 , Esteban Lorenzano <estebanlm@gmail.com> wrote:
So⦠that.
Is super cool to remove poolDictionaries from the default class template. What is not cool *at all* is the fact that now my low level projects, who uses them intensively, does not work anymore. The reason? the classes are created without poolDictionaries.
So, please⦠whoever pushed this change. Please fix it.
thanks, Esteban
Sooo, since Iâm curios, anyone care to explain how a change intended to affect whether Nautilus displays pool Dicts end up breaking how theyâre loaded from Monticello?
Did Nautilus pick up on the class load announcement from RPackage and end up recompiling the class with itâs own (lacking) default definition or something similarly crazy?
Cheers, Henry
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
I would like to get to the bottom of this, to be doubly sure there is no remaining problem. Can you send me privately the steps to reproduce so I can have a go at it using the unfixed version? On Jan 31, 2014, at 2:04 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
No, because my pools were not there and my tests were failing. But no matters, it works now :)
On 31 Jan 2014, at 17:45, Johan Fabry <jfabry@dcc.uchile.cl> wrote:
What probably happened is that Monticello loading with pooldictionaries was still working, but Nautilus was not showing them. This is the only thing that changed, and the fix addresses the showing part. So you should not worry.
---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
participants (7)
-
Eliot Miranda -
Esteban Lorenzano -
Henrik Johansen -
Johan Fabry -
Pharo4Stef -
Sebastian Sastre -
Torsten Bergmann