Re: [Pharo-dev] external#senders (was Re: DebugSession>>activePC:)

[Eliot Miranda]

Sven,

> On Jan 11, 2019, at 11:40 AM, Sven Van Caekenberghe  wrote:
> 
> 
> 
>> On 11 Jan 2019, at 19:32, Eliot Miranda  wrote:
>> 
>> Sven,
>> 
>>> On Jan 11, 2019, at 10:03 AM, Sven Van Caekenberghe  wrote:
>>> 
>>> Eliot, 
>>> 
>>> I can assure you that multiple core Pharo people had the same reaction, 
>>> don't turn this (again) in a play on one person's emotions (apart from the 
>>> fact that those are present in all living creatures).
>> 
>> First you assume a motive I don’t have.  I am not trying to provoke anyone.  
> 
> Clearly you are, given the reactions. 
> 
> Like Doru said, you did not just answer the question, your last two 
> paragraphs contained lots of provocation.

You’re entitled to your opinion.  But since the intent to provoke or not would 
be in my head you’re is a projection, not fact.

> 
>> Second, I think emotions are the results of mammalian brains, perhaps bird 
>> and fish brains, and certainly not present in amoeba.
> 
> First an IS reference, now this: yes, you are a man ratio and reason only, 
> devout of human emotions like the rest of us. Good for you.
> 
> Hundreds of libraries and frameworks were moved between Pharo 6.x and 7, with 
> minimal changes.
> 
> We are an active, living community where many, many people contribute, are 
> allowed to make mistakes, to question old code and old rules, to learn, to 
> make things better.
> 
>>> Sven
>>> 
 On 11 Jan 2019, at 18:57, Eliot Miranda  wrote:
 
 Stef,
 
> On Jan 10, 2019, at 11:24 PM, ducasse  wrote:
> 
> Ben
> 
> Since you asked I reply. 
> For calypso we try and sometimes fail and retry. But we do not rant. 
> 
> Now the solution is also to have tests and this is what we are doing. 
> We want more tests and we are working on having more tests.
> 
> The solution is also to have ***positive* communication. 
> 
> There is no point to piss on our process because
>   - we were the first to push package usage back in squeal 3.9
>   - increase enormously the number of tests
>   - have CI to run the tests and use PR. 
>   and it is working!
> 
> So before bashing us I would expect a bit of respect that it is due to 
> our track record. 
 
 Again you fail to respond to an attempt to discuss real issues and instead 
 take it as a personal map attack and respond emotionally.  Ben is /not/ 
 bashing your process in an attempt to damage Pharo.  As an academic 
 researcher you should be able to respond objectively to criticism.  This 
 frequent emotionality doesn’t help you or the community.
 
> 
> Finally it takes 1 min to enter a bug entry and now you cannot even 
> complain that you have to log 
> because it is on github. (BTW nobdoy is asking the amount of time it 
> takes US to migrate and go over the bug entry -
> again I ask for respect for the people doing this tedious, boring but 
> important job). 
> 
> When VMMaker will be available in Pharo we will be able to automate 
> things not before. 
> Please remember also that Igor paid by us spent a lot of time making sure 
> that 
> everybody and in particular our jenkins server could automatically build 
> vm.
> 
> So we believe in agility, communication and automation. 
> 
> Stef
> 
> 
> 
> 
>> On 11 Jan 2019, at 05:54, Ben Coman  wrote:
>> 
>> On Thu, 10 Jan 2019 at 23:51, ducasse via Pharo-dev 
>>  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 

Re: [Pharo-dev] external#senders (was Re: DebugSession>>activePC:)

[Sven Van Caekenberghe]

> On 11 Jan 2019, at 19:32, Eliot Miranda  wrote:
> 
> Sven,
> 
> On Jan 11, 2019, at 10:03 AM, Sven Van Caekenberghe  wrote:
> 
>> Eliot, 
>> 
>> I can assure you that multiple core Pharo people had the same reaction, 
>> don't turn this (again) in a play on one person's emotions (apart from the 
>> fact that those are present in all living creatures).
> 
> First you assume a motive I don’t have.  I am not trying to provoke anyone.  

Clearly you are, given the reactions. 

Like Doru said, you did not just answer the question, your last two paragraphs 
contained lots of provocation.

> Second, I think emotions are the results of mammalian brains, perhaps bird 
> and fish brains, and certainly not present in amoeba.

First an IS reference, now this: yes, you are a man ratio and reason only, 
devout of human emotions like the rest of us. Good for you.

Hundreds of libraries and frameworks were moved between Pharo 6.x and 7, with 
minimal changes.

We are an active, living community where many, many people contribute, are 
allowed to make mistakes, to question old code and old rules, to learn, to make 
things better.

>> Sven
>> 
>>> On 11 Jan 2019, at 18:57, Eliot Miranda  wrote:
>>> 
>>> Stef,
>>> 
>>> On Jan 10, 2019, at 11:24 PM, ducasse  wrote:
>>> 
 Ben
 
 Since you asked I reply. 
 For calypso we try and sometimes fail and retry. But we do not rant. 
 
 Now the solution is also to have tests and this is what we are doing. 
 We want more tests and we are working on having more tests.
 
 The solution is also to have ***positive* communication. 
 
 There is no point to piss on our process because
- we were the first to push package usage back in squeal 3.9
- increase enormously the number of tests
- have CI to run the tests and use PR. 
and it is working!
 
 So before bashing us I would expect a bit of respect that it is due to our 
 track record. 
>>> 
>>> Again you fail to respond to an attempt to discuss real issues and instead 
>>> take it as a personal map attack and respond emotionally.  Ben is /not/ 
>>> bashing your process in an attempt to damage Pharo.  As an academic 
>>> researcher you should be able to respond objectively to criticism.  This 
>>> frequent emotionality doesn’t help you or the community.
>>> 
 
 Finally it takes 1 min to enter a bug entry and now you cannot even 
 complain that you have to log 
 because it is on github. (BTW nobdoy is asking the amount of time it takes 
 US to migrate and go over the bug entry -
 again I ask for respect for the people doing this tedious, boring but 
 important job). 
 
 When VMMaker will be available in Pharo we will be able to automate things 
 not before. 
 Please remember also that Igor paid by us spent a lot of time making sure 
 that 
 everybody and in particular our jenkins server could automatically build 
 vm.
 
 So we believe in agility, communication and automation. 
 
 Stef
 
 
 
 
> On 11 Jan 2019, at 05:54, Ben Coman  wrote:
> 
> On Thu, 10 Jan 2019 at 23:51, ducasse via Pharo-dev 
>  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 

Re: [Pharo-dev] external#senders (was Re: DebugSession>>activePC:)

[Eliot Miranda]

Sven,

> On Jan 11, 2019, at 10:03 AM, Sven Van Caekenberghe  wrote:
> 
> Eliot, 
> 
> I can assure you that multiple core Pharo people had the same reaction, don't 
> turn this (again) in a play on one person's emotions (apart from the fact 
> that those are present in all living creatures).

First you assume a motive I don’t have.  I am not trying to provoke anyone.  
Second, I think emotions are the results of mammalian brains, perhaps bird and 
fish brains, and certainly not present in amoeba.

> 
> Sven
> 
>> On 11 Jan 2019, at 18:57, Eliot Miranda  wrote:
>> 
>> Stef,
>> 
>>> On Jan 10, 2019, at 11:24 PM, ducasse  wrote:
>>> 
>>> Ben
>>> 
>>> Since you asked I reply. 
>>> For calypso we try and sometimes fail and retry. But we do not rant. 
>>> 
>>> Now the solution is also to have tests and this is what we are doing. 
>>> We want more tests and we are working on having more tests.
>>> 
>>> The solution is also to have ***positive* communication. 
>>> 
>>> There is no point to piss on our process because
>>>- we were the first to push package usage back in squeal 3.9
>>>- increase enormously the number of tests
>>>- have CI to run the tests and use PR. 
>>>and it is working!
>>> 
>>> So before bashing us I would expect a bit of respect that it is due to our 
>>> track record. 
>> 
>> Again you fail to respond to an attempt to discuss real issues and instead 
>> take it as a personal map attack and respond emotionally.  Ben is /not/ 
>> bashing your process in an attempt to damage Pharo.  As an academic 
>> researcher you should be able to respond objectively to criticism.  This 
>> frequent emotionality doesn’t help you or the community.
>> 
>>> 
>>> Finally it takes 1 min to enter a bug entry and now you cannot even 
>>> complain that you have to log 
>>> because it is on github. (BTW nobdoy is asking the amount of time it takes 
>>> US to migrate and go over the bug entry -
>>> again I ask for respect for the people doing this tedious, boring but 
>>> important job). 
>>> 
>>> When VMMaker will be available in Pharo we will be able to automate things 
>>> not before. 
>>> Please remember also that Igor paid by us spent a lot of time making sure 
>>> that 
>>> everybody and in particular our jenkins server could automatically build vm.
>>> 
>>> So we believe in agility, communication and automation. 
>>> 
>>> Stef
>>> 
>>> 
>>> 
>>> 
 On 11 Jan 2019, at 05:54, Ben Coman  wrote:
 
 On Thu, 10 Jan 2019 at 23:51, ducasse via Pharo-dev 
  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 

Re: [Pharo-dev] external#senders (was Re: DebugSession>>activePC:)

[Eliot Miranda]

Esteban,


> On Jan 10, 2019, at 11:45 PM, Esteban Lorenzano  wrote:
> 
>> On 11 Jan 2019, at 08:24, ducasse  wrote:
>> 
>> Ben
>> 
>> Since you asked I reply. 
>> For calypso we try and sometimes fail and retry. But we do not rant. 
>> 
>> Now the solution is also to have tests and this is what we are doing. 
>> We want more tests and we are working on having more tests.
>> 
>> The solution is also to have ***positive* communication. 
>> 
>> There is no point to piss on our process because
>>  - we were the first to push package usage back in squeal 3.9
>>  - increase enormously the number of tests
>>  - have CI to run the tests and use PR. 
>>  and it is working!
>> 
>> So before bashing us I would expect a bit of respect that it is due to our 
>> track record. 
>> 
>> Finally it takes 1 min to enter a bug entry and now you cannot even complain 
>> that you have to log 
>> because it is on github. (BTW nobdoy is asking the amount of time it takes 
>> US to migrate and go over the bug entry -
>> again I ask for respect for the people doing this tedious, boring but 
>> important job). 
>> 
>> When VMMaker will be available in Pharo we will be able to automate things 
>> not before. 
>> Please remember also that Igor paid by us spent a lot of time making sure 
>> that 
>> everybody and in particular our jenkins server could automatically build vm.
>> 
>> So we believe in agility, communication and automation. 
>> 
>> Stef
>> 
>> 
>> 
>> 
>>> On 11 Jan 2019, at 05:54, Ben Coman  wrote:
>>> 
 On Thu, 10 Jan 2019 at 23:51, ducasse via Pharo-dev 
  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 ?
> 
> You know? since we are sharing frustrations, 

Re: [Pharo-dev] external#senders (was Re: DebugSession>>activePC:)

[Sven Van Caekenberghe]

Eliot, 

I can assure you that multiple core Pharo people had the same reaction, don't 
turn this (again) in a play on one person's emotions (apart from the fact that 
those are present in all living creatures).

Sven

> On 11 Jan 2019, at 18:57, Eliot Miranda  wrote:
> 
> Stef,
> 
> On Jan 10, 2019, at 11:24 PM, ducasse  wrote:
> 
>> Ben
>> 
>> Since you asked I reply. 
>> For calypso we try and sometimes fail and retry. But we do not rant. 
>> 
>> Now the solution is also to have tests and this is what we are doing. 
>> We want more tests and we are working on having more tests.
>> 
>> The solution is also to have ***positive* communication. 
>> 
>> There is no point to piss on our process because
>>  - we were the first to push package usage back in squeal 3.9
>>  - increase enormously the number of tests
>>  - have CI to run the tests and use PR. 
>>  and it is working!
>> 
>> So before bashing us I would expect a bit of respect that it is due to our 
>> track record. 
> 
> Again you fail to respond to an attempt to discuss real issues and instead 
> take it as a personal map attack and respond emotionally.  Ben is /not/ 
> bashing your process in an attempt to damage Pharo.  As an academic 
> researcher you should be able to respond objectively to criticism.  This 
> frequent emotionality doesn’t help you or the community.
> 
>> 
>> Finally it takes 1 min to enter a bug entry and now you cannot even complain 
>> that you have to log 
>> because it is on github. (BTW nobdoy is asking the amount of time it takes 
>> US to migrate and go over the bug entry -
>> again I ask for respect for the people doing this tedious, boring but 
>> important job). 
>> 
>> When VMMaker will be available in Pharo we will be able to automate things 
>> not before. 
>> Please remember also that Igor paid by us spent a lot of time making sure 
>> that 
>> everybody and in particular our jenkins server could automatically build vm.
>> 
>> So we believe in agility, communication and automation. 
>> 
>> Stef
>> 
>> 
>> 
>> 
>>> On 11 Jan 2019, at 05:54, Ben Coman  wrote:
>>> 
>>> On Thu, 10 Jan 2019 at 23:51, ducasse via Pharo-dev 
>>>  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 

Re: [Pharo-dev] external#senders (was Re: DebugSession>>activePC:)

[Eliot Miranda]

> On Jan 10, 2019, at 11:24 PM, ducasse  wrote:
> 
> Ben
> 
> Since you asked I reply. 
> For calypso we try and sometimes fail and retry. But we do not rant. 
> 
> Now the solution is also to have tests and this is what we are doing. 
> We want more tests and we are working on having more tests.
> 
> The solution is also to have ***positive* communication. 

What do we understand by positive communication?  Is it IS-style patting on the 
back for average performance some we don’t hurt people’s feelings or is it 
communication that advances a community’s work product?  For me it is the 
latter.

I would never dream of responding to technical criticism of the CM with a 
response that says “please refrain from criticizing us”.  I try and respond 
honestly with an objective assessment of the technical, logistical and human 
issues.  In fact I welcome criticism; how on earth will the VM improve in 
directions other than the narrow ones those working on it set without criticism 
from other stake holders?

> 
> There is no point to piss on our process because
>   - we were the first to push package usage back in squeal 3.9
>   - increase enormously the number of tests
>   - have CI to run the tests and use PR. 
>   and it is working!
> 
> So before bashing us I would expect a bit of respect that it is due to our 
> track record. 
> 
> Finally it takes 1 min to enter a bug entry and now you cannot even complain 
> that you have to log 
> because it is on github. (BTW nobdoy is asking the amount of time it takes US 
> to migrate and go over the bug entry -
> again I ask for respect for the people doing this tedious, boring but 
> important job). 
> 
> When VMMaker will be available in Pharo we will be able to automate things 
> not before. 
> Please remember also that Igor paid by us spent a lot of time making sure 
> that 
> everybody and in particular our jenkins server could automatically build vm.
> 
> So we believe in agility, communication and automation. 
> 
> Stef
> 
> 
> 
> 
>> On 11 Jan 2019, at 05:54, Ben Coman  wrote:
>> 
>>> On Thu, 10 Jan 2019 at 23:51, ducasse via Pharo-dev 
>>>  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 

Re: [Pharo-dev] external#senders (was Re: DebugSession>>activePC:)

[Eliot Miranda]

Stef,

> On Jan 10, 2019, at 11:24 PM, ducasse  wrote:
> 
> Ben
> 
> Since you asked I reply. 
> For calypso we try and sometimes fail and retry. But we do not rant. 
> 
> Now the solution is also to have tests and this is what we are doing. 
> We want more tests and we are working on having more tests.
> 
> The solution is also to have ***positive* communication. 
> 
> There is no point to piss on our process because
>   - we were the first to push package usage back in squeal 3.9
>   - increase enormously the number of tests
>   - have CI to run the tests and use PR. 
>   and it is working!
> 
> So before bashing us I would expect a bit of respect that it is due to our 
> track record. 

Again you fail to respond to an attempt to discuss real issues and instead take 
it as a personal map attack and respond emotionally.  Ben is /not/ bashing your 
process in an attempt to damage Pharo.  As an academic researcher you should be 
able to respond objectively to criticism.  This frequent emotionality doesn’t 
help you or the community.

> 
> Finally it takes 1 min to enter a bug entry and now you cannot even complain 
> that you have to log 
> because it is on github. (BTW nobdoy is asking the amount of time it takes US 
> to migrate and go over the bug entry -
> again I ask for respect for the people doing this tedious, boring but 
> important job). 
> 
> When VMMaker will be available in Pharo we will be able to automate things 
> not before. 
> Please remember also that Igor paid by us spent a lot of time making sure 
> that 
> everybody and in particular our jenkins server could automatically build vm.
> 
> So we believe in agility, communication and automation. 
> 
> Stef
> 
> 
> 
> 
>> On 11 Jan 2019, at 05:54, Ben Coman  wrote:
>> 
>>> On Thu, 10 Jan 2019 at 23:51, ducasse via Pharo-dev 
>>>  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 

Re: [Pharo-dev] external#senders (was Re: DebugSession>>activePC:)

[Norbert Hartl]

> Am 11.01.2019 um 11:33 schrieb Sven Van Caekenberghe :
> 
> 
> 
>> On 11 Jan 2019, at 08:45, Esteban Lorenzano  wrote:
>> 
>> You know? since we are sharing frustrations, I have to say: we already had 
>> that process (which was the old pharo-vm project). In that project, for each 
>> version of vmmaker we were loading it, generating a vm and running pharo 
>> tests there (since there are no vm-specific tests, this was working at least 
>> to test things were not broken). 
>> And… we were told this was not good and that we needed to submit to the 
>> canonical way of building the vm, which we did to not split more the 
>> community. 
>> 
>> In the process we lost all our validation process. 
>> 
>> Now we are told that we remove things without caring. 
>> But we care, and we spent a lot of time and effort putting in place 
>> mechanisms to allow things to continue moving.
>> And then we needed to throw it away.
>> 
>> Maybe now we have a new attempt and possibility of improving, but honestly I 
>> already spent one year of the work this community pays me to do to improve 
>> things and then it was wasted work. 
>> I do not thing I want to spend another “sabatical” year like that.
>> 
>> Esteban
>> 
>> Ps: I’m sorry for the frustration rant, but when I see this things emerge I 
>> become very-very sad.
> 
> One can only image, dream, of a world where VM development decided years ago 
> to step into the future with a better process, better code management, modern 
> tools, actual CI, tests, open process for real, welcoming more contributors, 
> catering for its largest user base.
> We live in an ever changing world, resisting change is not the solution.
> 
> Open source is about embracing and nurturing community, and yes that is 
> sometimes messy, but totally worth it.
> 
Amen  
> 

Re: [Pharo-dev] external#senders (was Re: DebugSession>>activePC:)

[Sven Van Caekenberghe]

> On 11 Jan 2019, at 08:45, Esteban Lorenzano  wrote:
> 
> You know? since we are sharing frustrations, I have to say: we already had 
> that process (which was the old pharo-vm project). In that project, for each 
> version of vmmaker we were loading it, generating a vm and running pharo 
> tests there (since there are no vm-specific tests, this was working at least 
> to test things were not broken). 
> And… we were told this was not good and that we needed to submit to the 
> canonical way of building the vm, which we did to not split more the 
> community. 
> 
> In the process we lost all our validation process. 
> 
> Now we are told that we remove things without caring. 
> But we care, and we spent a lot of time and effort putting in place 
> mechanisms to allow things to continue moving.
> And then we needed to throw it away.
> 
> Maybe now we have a new attempt and possibility of improving, but honestly I 
> already spent one year of the work this community pays me to do to improve 
> things and then it was wasted work. 
> I do not thing I want to spend another “sabatical” year like that.
> 
> Esteban
> 
> Ps: I’m sorry for the frustration rant, but when I see this things emerge I 
> become very-very sad.

One can only image, dream, of a world where VM development decided years ago to 
step into the future with a better process, better code management, modern 
tools, actual CI, tests, open process for real, welcoming more contributors, 
catering for its largest user base.

We live in an ever changing world, resisting change is not the solution.

Open source is about embracing and nurturing community, and yes that is 
sometimes messy, but totally worth it.

Re: [Pharo-dev] external#senders (was Re: DebugSession>>activePC:)

[Ben Coman]

On Fri, 11 Jan 2019 at 15:24, ducasse  wrote:

> Ben
>
> Since you asked I reply.
> For calypso we try and sometimes fail and retry. But we do not rant.
>
> Now the solution is also to have tests and this is what we are doing.
> We want more tests and we are working on having more tests.
>
> The solution is also to have ***positive* communication.
>

Agreed.


> There is no point to piss on our process because
> - we were the first to push package usage back in squeal 3.9
> - increase enormously the number of tests
> - have CI to run the tests and use PR.
> and it is working!
>
> So before bashing us I would expect a bit of respect that it is due to our
> track record.
>

A massive amount of work on the process has been done behind the scenes,
and we are reaping the benefit of it daily.  Thanks everyone involved in
that.

By offering some ideas to take things to the next level I didn't mean to
imply something
was wrong, more acknowledging the constraint under which those decisions
are made.


Finally it takes 1 min to enter a bug entry and now you cannot even
> complain that you have to log
> because it is on github. (BTW nobdoy is asking the amount of time it takes
> US to migrate and go over the bug entry -
> again I ask for respect for the people doing this tedious, boring but
> important job).
>
> When VMMaker will be available in Pharo we will be able to automate things
> not before.
>

Cool. As priority and constraints dictate, it will be a good day when it
gets here.


Please remember also that Igor paid by us spent a lot of time making sure
> that
> everybody and in particular our jenkins server could automatically build
> vm.
>

So we believe in agility, communication and automation.
>

I like that.

Thanks for your response.
cheers -ben

Re: [Pharo-dev] external#senders (was Re: DebugSession>>activePC:)

[Esteban Lorenzano]

> On 11 Jan 2019, at 08:24, ducasse  wrote:
> 
> Ben
> 
> Since you asked I reply. 
> For calypso we try and sometimes fail and retry. But we do not rant. 
> 
> Now the solution is also to have tests and this is what we are doing. 
> We want more tests and we are working on having more tests.
> 
> The solution is also to have ***positive* communication. 
> 
> There is no point to piss on our process because
>   - we were the first to push package usage back in squeal 3.9
>   - increase enormously the number of tests
>   - have CI to run the tests and use PR. 
>   and it is working!
> 
> So before bashing us I would expect a bit of respect that it is due to our 
> track record. 
> 
> Finally it takes 1 min to enter a bug entry and now you cannot even complain 
> that you have to log 
> because it is on github. (BTW nobdoy is asking the amount of time it takes US 
> to migrate and go over the bug entry -
> again I ask for respect for the people doing this tedious, boring but 
> important job). 
> 
> When VMMaker will be available in Pharo we will be able to automate things 
> not before. 
> Please remember also that Igor paid by us spent a lot of time making sure 
> that 
> everybody and in particular our jenkins server could automatically build vm.
> 
> So we believe in agility, communication and automation. 
> 
> Stef
> 
> 
> 
> 
>> On 11 Jan 2019, at 05:54, Ben Coman > > wrote:
>> 
>> On Thu, 10 Jan 2019 at 23:51, ducasse via Pharo-dev 
>> mailto: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 ?

You know? since we are sharing frustrations, I have to say: we already had that 
process (which was the old pharo-vm project). In that project, for each version 
of vmmaker we were 

Re: [Pharo-dev] external#senders (was Re: DebugSession>>activePC:)

[ducasse]

Ben

Since you asked I reply. 
For calypso we try and sometimes fail and retry. But we do not rant. 

Now the solution is also to have tests and this is what we are doing. 
We want more tests and we are working on having more tests.

The solution is also to have ***positive* communication. 

There is no point to piss on our process because
- we were the first to push package usage back in squeal 3.9
- increase enormously the number of tests
- have CI to run the tests and use PR. 
and it is working!

So before bashing us I would expect a bit of respect that it is due to our 
track record. 

Finally it takes 1 min to enter a bug entry and now you cannot even complain 
that you have to log 
because it is on github. (BTW nobdoy is asking the amount of time it takes US 
to migrate and go over the bug entry -
again I ask for respect for the people doing this tedious, boring but important 
job). 

When VMMaker will be available in Pharo we will be able to automate things not 
before. 
Please remember also that Igor paid by us spent a lot of time making sure that 
everybody and in particular our jenkins server could automatically build vm.

So we believe in agility, communication and automation. 

Stef




> On 11 Jan 2019, at 05:54, Ben Coman  wrote:
> 
> On Thu, 10 Jan 2019 at 23:51, ducasse via Pharo-dev 
> mailto: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 

[Pharo-dev] external#senders (was Re: DebugSession>>activePC:)

[Ben Coman via Pharo-dev]

--- 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 ---