Re: [Pharo-dev] DebugSession>>activePC:
Hi all-- Eliot writes:
Do you want to remove the method simply because there are no senders in the image?
If so, this is indicative of a serious problem with the Pharo development process. In the summer I ported VMMaker.oscog to Pharo 6. Now as feenk try and build a VMMaker.oscog image on Pharo 7, the system is broken, in part because of depreciations and in part because useful methods (isOptimisedBlock (isOptimizedBlock?) in the Opal compiler) have been removed.
Just because a method is not in the image does not imply it is not in use. It simply means that it is not in use in the base image. As the system gets modularised this issue will only increase. There are lots of collection methods that exist as a library that are not used in the base image and removing them would clearly damage the library for users. This is the case for lots of so-called system code. There are users out there, like those of us in the vm team, who rely on such system code, and it is extremely unsettling and frustrating to have that system code change all the time. If Pharo is to be a useful platform to the vm team it has to be more stable.
Esteban responds:
...we are told that we remove things without caring.
I don't see where Eliot said anyone didn't care. Stef responds:
About the method removed, could you please react less negatively? It would be nice.
...
How much time opening a bug entry can take? Under 1 min I guess. So why if marcus removed it inadvertly would you want to make him feel bad?
Eliot said the system has to be more stable. It doesn't seem like a negative reaction, or an attempt to make anyone feel bad. As Ben pointed out, the major cost of reporting regressions isn't the time spent interacting with the bug-tracking system, it's being switched away from what you were doing. Using the automated regression-testing system seems like a good way of catching this particular issue (even though it's a step away from having full live traceability all the time, before committing changes).
For calypso we try and sometimes fail and retry. But we do not rant... The solution is also to have ***********positive********* communication... There is no point to piss on our process... So before bashing us I would expect a bit of respect that it is due to our track record... it would be nice if you could refrain to be systematically negative about what we are doing.
I don't think Eliot is being systematically negative, or that he was ranting, pissing, or bashing. I think introducing those accusatory words into the conversation detracts from positive communication.
I think that we are doing a great job make Smalltalk cool.
I do, too! (And thanks for using that word. ;) thanks, -C -- Craig Latta Black Page Digital Amsterdam :: San Francisco craig@blackpagedigital.com +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)
Then perfect!
On 11 Jan 2019, at 09:58, Craig Latta <craig@blackpagedigital.com> wrote:
Hi all--
Eliot writes:
Do you want to remove the method simply because there are no senders in the image?
If so, this is indicative of a serious problem with the Pharo development process. In the summer I ported VMMaker.oscog to Pharo 6. Now as feenk try and build a VMMaker.oscog image on Pharo 7, the system is broken, in part because of depreciations and in part because useful methods (isOptimisedBlock (isOptimizedBlock?) in the Opal compiler) have been removed.
Just because a method is not in the image does not imply it is not in use. It simply means that it is not in use in the base image. As the system gets modularised this issue will only increase. There are lots of collection methods that exist as a library that are not used in the base image and removing them would clearly damage the library for users. This is the case for lots of so-called system code. There are users out there, like those of us in the vm team, who rely on such system code, and it is extremely unsettling and frustrating to have that system code change all the time. If Pharo is to be a useful platform to the vm team it has to be more stable.
Esteban responds:
...we are told that we remove things without caring.
I don't see where Eliot said anyone didn't care.
Stef responds:
About the method removed, could you please react less negatively? It would be nice.
...
How much time opening a bug entry can take? Under 1 min I guess. So why if marcus removed it inadvertly would you want to make him feel bad?
Eliot said the system has to be more stable. It doesn't seem like a negative reaction, or an attempt to make anyone feel bad. As Ben pointed out, the major cost of reporting regressions isn't the time spent interacting with the bug-tracking system, it's being switched away from what you were doing. Using the automated regression-testing system seems like a good way of catching this particular issue (even though it's a step away from having full live traceability all the time, before committing changes).
For calypso we try and sometimes fail and retry. But we do not rant... The solution is also to have ***********positive********* communication... There is no point to piss on our process... So before bashing us I would expect a bit of respect that it is due to our track record... it would be nice if you could refrain to be systematically negative about what we are doing.
I don't think Eliot is being systematically negative, or that he was ranting, pissing, or bashing. I think introducing those accusatory words into the conversation detracts from positive communication.
I think that we are doing a great job make Smalltalk cool.
I do, too! (And thanks for using that word. ;)
thanks,
-C
-- Craig Latta Black Page Digital Amsterdam :: San Francisco craig@blackpagedigital.com <mailto:craig@blackpagedigital.com> +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)
Craig, thank you. +1000
On Jan 11, 2019, at 12:58 AM, Craig Latta <craig@blackpagedigital.com> wrote:
Hi all--
Eliot writes:
Do you want to remove the method simply because there are no senders in the image?
If so, this is indicative of a serious problem with the Pharo development process. In the summer I ported VMMaker.oscog to Pharo 6. Now as feenk try and build a VMMaker.oscog image on Pharo 7, the system is broken, in part because of depreciations and in part because useful methods (isOptimisedBlock (isOptimizedBlock?) in the Opal compiler) have been removed.
Just because a method is not in the image does not imply it is not in use. It simply means that it is not in use in the base image. As the system gets modularised this issue will only increase. There are lots of collection methods that exist as a library that are not used in the base image and removing them would clearly damage the library for users. This is the case for lots of so-called system code. There are users out there, like those of us in the vm team, who rely on such system code, and it is extremely unsettling and frustrating to have that system code change all the time. If Pharo is to be a useful platform to the vm team it has to be more stable.
Esteban responds:
...we are told that we remove things without caring.
I don't see where Eliot said anyone didn't care.
Stef responds:
About the method removed, could you please react less negatively? It would be nice.
...
How much time opening a bug entry can take? Under 1 min I guess. So why if marcus removed it inadvertly would you want to make him feel bad?
Eliot said the system has to be more stable. It doesn't seem like a negative reaction, or an attempt to make anyone feel bad. As Ben pointed out, the major cost of reporting regressions isn't the time spent interacting with the bug-tracking system, it's being switched away from what you were doing. Using the automated regression-testing system seems like a good way of catching this particular issue (even though it's a step away from having full live traceability all the time, before committing changes).
For calypso we try and sometimes fail and retry. But we do not rant... The solution is also to have ***********positive********* communication... There is no point to piss on our process... So before bashing us I would expect a bit of respect that it is due to our track record... it would be nice if you could refrain to be systematically negative about what we are doing.
I don't think Eliot is being systematically negative, or that he was ranting, pissing, or bashing. I think introducing those accusatory words into the conversation detracts from positive communication.
I think that we are doing a great job make Smalltalk cool.
I do, too! (And thanks for using that word. ;)
thanks,
-C
-- Craig Latta Black Page Digital Amsterdam :: San Francisco craig@blackpagedigital.com +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)
participants (3)
-
Craig Latta -
ducasse -
Eliot Miranda