--- Begin Message ---
On Thu, 10 Jan 2019 at 23:51, ducasse via Pharo-dev <
pharo-dev@lists.pharo.org> wrote:
> Thomas can you integrate such comments in the debugger class comment
>
> @Eliot thanks for the explanation.
> About the method removed, could you please react less negatively? It would
> be nice.
> I cannot believe that you the guy that know the VM would get stopped to
> open a bug entry telling us that isOptimizedBlock
> has been removed and it should not. How much time opening a bug entry can
> take? Under 1 min I guess.
>
I'd guess it takes more than 1 minute overall - a few minutes to shift
context to open an old Pharo image
and a few more open the original method to copy it to Pharo and repeat that
for the next ten missing methods,
and then having fixed it for yourself, rather than just log a job for
someone else, having fixed your own
you now repair your pharo repo with Iceberg and submit a commit, and your
now off-task by half an hour.
Not a great deal of time if that was what you schedule to work on, you but
frustrating when dragged off task.
The thing is, when is someone is frustrated, without sharing there is no
chance to resolve anything,
so the frustration doubles and builds up, and unconsciously creeps in
relationships and/or leads to a breakdown.
Putting it out in the world relieves that pressure and provides the
possibility that someone might
find a middle path. As always, it is not what is said but how it is said,
and personally that seemed okay to me.
>> 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.
On the flip side, if the rule was "don't touch unused methods", that would
block a lot of action
around cleaning, minimisation and modulation that are important. Even
though those things
aren't directly the shiney new tools that make Pharo great, its their
philosophy that underpins
a lot of the visible Pharo improvements which has facilitated Pharo's
growth.
That "vision" is why I'm here.
The pivot point here the concept of "unused" and perhaps where we can do
better.
Currently developers have no information available to base their decision
on.
Requiring developers to query the mail list about every cleaning,
minimisation and modulation action
would have a freezing effect.
For stuff that is image its much easier for developers since:
* its "visible" right in front of them
* they can make decisions and take action around it
* tests can be run
So the question is how we can get those things for important modules
outside the image?
For me, VM is not like any third party app but is very much a *part* of
Pharo
since its something which helps Pharo itself advance. So lets treat it as
such, similar
to how we treat other modules like Calypso or Iceberg which happen
distributed in-Image.
Can we consider the last step of the CI (after packing the CI product)
could load a static version of VMMaker? Not that any issues would fail the
commit, but just report
to bring "visibility" to the table ?
Or, once VMMaker is in git, perhaps a separate opensmalltalk-vm CI job
could run against each latest Pharo image to report problems?
Or to broaden the perspective of "unused" further, we could put broader
#senders-info in front
of developers so then can make informed decisions at design time rather
cleaning up after-the-fact?
Projects could register on a central site their list of #senders (generated
from some tool)
so the Pharo IDE could reference that when asked for #senders - so the
information is available
to make informed decisions.
Clicking on an external#sender could pop up the actual code hosted on
github,
so developers have even better knowledge for decisions and communication.
Of course, creating such a system requires effort in our world of limited
resources.
But the external#senders register could be a premium service available just
to Pharo Association/Consortium members which sets up a bit of a win/win
scenario.
It helps developers and is an incentive to join up. This is not to
guarantee changes won't
affect your project's #senders, but just to improve communication around
them.
So why if marcus removed it inadvertently would you want to make him feel
> bad? I don’t want people to feel bad.
> We can do mistake.
That is an important philosophy, but here is a key thing to be clear on...
[ "If you are not open to hearing about mistakes, then you are not open
to making mistakes." ] repeat.
There is no reason for an individual to feel bad about removing an "unused"
method if that is the process.
But can the process be improved?
cheers -ben
--- End Message ---
