Re: [Pharo-dev] Availability of Smallapack in Pharo6.0

[Tudor Girba]

Hi Nicolas,

Very nice! It’s great to have a fast library for linear algebra.

Cheers,
Doru


> On Jan 12, 2019, at 12:33 AM, Nicolas Cellier 
>  wrote:
> 
> Hi,
> I announce the availability of Smallapack in Pharo6.
> 
> The ConfigurationOfSmallapack is in 
> http://www.squeaksource.com/MetacelloRepository and there is a copy in meta 
> repo for Pharo 3/4/5/6.
> 
> Currently, the ported version uses a derivative of OpalCompiler patched to 
> handle method with 16+ arguments.
> External function calls have not been converted yet to UnifiedFFI, but the 
> patched compiler rather has hook to compile legacy FFI.
> Though I did not install the hook to call FFI with more than 15 arguments, so 
> there is at least 1 unit test failing (but not crashing).
> 
> I have auto-re-generated all the source code for using UnifiedFFI formats, so 
> the dependency on legacy FFI is not a necessity (apart for simplifying cross 
> dialect maintenance).
> 
> But I want to review the generated code method by method rather than filing 
> it in blindly (the wrapper functions are also generated, and I might loose 
> comments or improvments if I'm careless). Unfortunately, the state of diff 
> tools in Pharo6, be it thru MC or worse than all, thru legacy change lists, 
> does not enable such a large scale review, so I think that I will edit in 
> Squeak and run in Pharo...
> 
> Now that Smallapack supports Opal, there should be no major problem for 
> porting to Pharo7, but I did not have time to try yet. A few more MC 
> regressions, and the fact to forbid protocol beginning with a * was too 
> serious a cross compatibility hurdle for me. But I'll come back to it, tools 
> are generally better in ph7 than ph6. Stay tuned.
> 

--
www.feenk.com

“Programming is executable philosophy."

Re: [Pharo-dev] Is metacello aware of MC branches???

[Cyril Ferlicot]

On Fri 11 Jan 2019 at 22:51, Nicolas Cellier <
nicolas.cellier.aka.n...@gmail.com> wrote:

> Thanks,
> that did not work, but I think my mistake was to write this;
>
> spec for: #'pharo6.0.x'
>
> instead of:
>
> spec for: #'pharo6.x'.
>
> Smalltalk version -> 'Pharo6.0', so probably the second dot does not match
> anything...
> I'll have to review more ConfigurationOf...
>
>>
Hello,

I do not have an image to check but you can find compatible  by executing
something like `Smalltalk metacelloPlatformAttributes` in a Pharo 6 image.

>From what I wrote here:

https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/Baselines.md#loads-different-packages-depending-on-the-pharo-version


I guess your problem is that you tried to load the code in Pharo 6.1 and
not 6.0.


>>> --
Cyril Ferlicot
https://ferlicot.fr

[Pharo-dev] Availability of Smallapack in Pharo6.0

[Nicolas Cellier]

Hi,
I announce the availability of Smallapack in Pharo6.

The ConfigurationOfSmallapack is in
http://www.squeaksource.com/MetacelloRepository and there is a copy in meta
repo for Pharo 3/4/5/6.

Currently, the ported version uses a derivative of OpalCompiler patched to
handle method with 16+ arguments.
External function calls have not been converted yet to UnifiedFFI, but the
patched compiler rather has hook to compile legacy FFI.
Though I did not install the hook to call FFI with more than 15 arguments,
so there is at least 1 unit test failing (but not crashing).

I have auto-re-generated all the source code for using UnifiedFFI formats,
so the dependency on legacy FFI is not a necessity (apart for simplifying
cross dialect maintenance).

But I want to review the generated code method by method rather than filing
it in blindly (the wrapper functions are also generated, and I might loose
comments or improvments if I'm careless). Unfortunately, the state of diff
tools in Pharo6, be it thru MC or worse than all, thru legacy change lists,
does not enable such a large scale review, so I think that I will edit in
Squeak and run in Pharo...

Now that Smallapack supports Opal, there should be no major problem for
porting to Pharo7, but I did not have time to try yet. A few more MC
regressions, and the fact to forbid protocol beginning with a * was too
serious a cross compatibility hurdle for me. But I'll come back to it,
tools are generally better in ph7 than ph6. Stay tuned.

Re: [Pharo-dev] Is metacello aware of MC branches???

[Nicolas Cellier]

Thanks,
that did not work, but I think my mistake was to write this;

spec for: #'pharo6.0.x'

instead of:

spec for: #'pharo6.x'.

Smalltalk version -> 'Pharo6.0', so probably the second dot does not match
anything...
I'll have to review more ConfigurationOf...

Le ven. 11 janv. 2019 à 21:51, Andrei Chis  a
écrit :

> Hi,
>
> Would something like this work:
>
>  spec for: #'pharo6.0.x' do: [
> spec package: 'Smallapack-StdLib' with: [
>   spec
>  file:  'Smallapack-StdLib.UFFI-nice.1']
> ]
>
> Or maybe in the baseline you can have:
>
>  spec package: 'Smallapack-StdLib' with: [
>   spec
>  file:  'Smallapack-StdLib.UFFI-nice']
> ]
>
>
> Cheers,
> Andrei
>
>
> On Fri, Jan 11, 2019 at 12:19 PM Nicolas Cellier <
> nicolas.cellier.aka.n...@gmail.com> wrote:
>
>> Hi all,
>> I'm trying to resolve a dialect compatibility problem like this:
>>
>> I want to load the Squeak and Pharo3 to 5 version depending on FFI
>> Smallapack-StdLib-nice.1
>>
>> For Pharo6, I made a different branch depending on UFFI
>> Smallapack-StdLib.UFFI-nice.1
>>
>> In the base line, i tell
>> spec for: #'common' do: [
>> spec blessing: #'baseline'.
>> spec repository: 'http://www.squeaksource.com/Smallapack'.
>> spec package: 'Smallapack-StdLib']
>> and in the version I tell
>>
>> spec for: #squeak do: [
>> spec package: 'Smallapack-StdLib' with:
>> 'Smallapack-StdLib-nice.1'].
>> spec for: #'pharo5.0.x' do: [
>> spec package: 'Smallapack-StdLib' with:
>> 'Smallapack-StdLib-nice.1'].
>> spec for: #'pharo6.0.x' do: [
>> spec package: 'Smallapack-StdLib' with:
>> 'Smallapack-StdLib.UFFI-nice.1'].
>>
>> but the configuration loads Smallapack-StdLib-nice.1 instead of
>> Smallapack-StdLib.UFFI-nice.1
>>
>> I would like to avoid using two different package names because it
>> complexifies the baseline for nothing.
>> It the same package, just a different branch.
>> Isn't it possible?
>> Why?
>> Can we fix it?
>>
>

Re: [Pharo-dev] DebugSession>>activePC:

[Thomas Dupriez via Pharo-dev]

--- Begin Message ---
Yeah, it's a bit unfortunate you assumed I wanted to remove the method. 
It brought up a not so pleasant discussion.

Everyone makes mistakes. :-)

So if I understand, this method gives the pc that maps to the ast node 
the debugger should highlight when a context is selected in the stack 
widget? If I'm right, how comes that this method has no senders in the 
debugger code? That would mean this feature is also implemented 
somewhere else.


Thomas

Le 11/01/2019 à 20:28, Eliot Miranda a écrit :

Hi Thomas,

   forgive me, my first response was too terse.  Having thought about it in the 
shower it becomes clear :-)


On Jan 11, 2019, at 6:49 AM, Thomas Dupriez  
wrote:

Hi,

Yes, my question was just of the form: "Hey there's this method in DebugSession. 
What is it doing? What's the intention behind it? Does someone know?". There was no 
hidden agenda behind it.

@Eliot

After taking another look at this method, there's something I don't understand:

activePC: aContext
^ (self isLatestContext: aContext)
 ifTrue: [ interruptedContext pc ]
 ifFalse: [ self previousPC: aContext ]

isLatestContext: checks whether its argument is the suspended context (the 
context at the top of the stack of the interrupted process). And if that's 
true, activePC: returns the pc of **interruptedContext**, not of the suspended 
context. These two contexts are different when the debugger opens on an 
exception, so this method is potentially returning a pc for another context 
than its argument...

Another question I have to improve the comment for this method is: what's the high-level 
meaning of this concept of "activePC". You gave the formal definition, but 
what's the point of defining this so to speak? What makes this concept interesting enough 
to warrant defining it and giving it a name?

There are two “modes” where a pc us mapped to a source range.  One is when 
stepping a context in the debugger (the context is on top and is actively 
executing bytecodes).  Here the debugger stops immediately before a send or 
assignment or return, so that for sends we can do into or over, or for 
assignments or returns check stack top to see what will be assigned or 
returned.  In this mode we want the pc of the send, assign or return to map to 
the source range for the send, or the expression being assigned or returned.  
Since this is the “common case”, and since this is the only choice that makes 
sense for assignments ta and returns, the bytecode compiler constructs it’s pc 
to source range map in terms of the pc of the first byte if the send, assign or 
return bytecode.

The second “mode” is when selecting a context below the top context.  The pc 
for any context below the top context will be the return pc for a send, because 
the send has already happened.  The compiler could choose to map this pc to the 
send, but it would not match what works for the common case. Another choice 
would appear be to have two map entries, one for the send and one for the 
return pc, both mapping to the source range.  But this wouldn’t work because 
the result of a send might be assigned or returned and so there is a potential 
conflict.  I stead the reasonable solution is to select the previous pc for 
contexts below the top of context, which will be the pc for the start of the 
send bytecode.

HTH


Cheers,
Thomas


On 11/01/2019 13:53, Tudor Girba wrote:
Hi,

@Eliot: Thanks for the clarifying answer.

I believe you might have jumped to conclusion about the intention of the 
question. Thomas asked a legitimate question. Without users of a method it is 
hard to understand its use. It does not necessarily imply that the intention is 
to remove it, but it does show that someone wants to understand.

As far as I know, Thomas actually wants to write a test to cover that usage. I 
am sure that you appreciate and encourage that :).

@Thomas: Thanks for this effort!

Cheers,
Doru



On Jan 10, 2019, at 3:11 PM, Eliot Miranda  wrote:

Hi Thomas,


On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev 
 wrote:



in a stack of contexts the active pc is different for the top context.  For 
other than the top context, a context’s pc will be pointing after the send that 
created the context above it, so to find the pc of the send one finds the 
previous pc.  For the top context its pc is the active pc.

Typically the debugger is invoked in two different modes, interruption or 
exception. When interrupted, a process is stopped at the next suspension point 
(method entry or backward branch) and the top context in the process is the 
context to be displayed in the debugger.  When an exception occurs the 
exception search machinery will find the signaling context, the context that 
raised the exception, which will be below the search machinery and the debugger 
invocation above that. The active pc of the signaling context will be the of 
for the send of digbsl et al.

So the distinction is important and the utility method 

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] Is metacello aware of MC branches???

[Andrei Chis]

Hi,

Would something like this work:

 spec for: #'pharo6.0.x' do: [
spec package: 'Smallapack-StdLib' with: [
  spec
 file:  'Smallapack-StdLib.UFFI-nice.1']
]

Or maybe in the baseline you can have:

 spec package: 'Smallapack-StdLib' with: [
  spec
 file:  'Smallapack-StdLib.UFFI-nice']
]


Cheers,
Andrei


On Fri, Jan 11, 2019 at 12:19 PM Nicolas Cellier <
nicolas.cellier.aka.n...@gmail.com> wrote:

> Hi all,
> I'm trying to resolve a dialect compatibility problem like this:
>
> I want to load the Squeak and Pharo3 to 5 version depending on FFI
> Smallapack-StdLib-nice.1
>
> For Pharo6, I made a different branch depending on UFFI
> Smallapack-StdLib.UFFI-nice.1
>
> In the base line, i tell
> spec for: #'common' do: [
> spec blessing: #'baseline'.
> spec repository: 'http://www.squeaksource.com/Smallapack'.
> spec package: 'Smallapack-StdLib']
> and in the version I tell
>
> spec for: #squeak do: [
> spec package: 'Smallapack-StdLib' with:
> 'Smallapack-StdLib-nice.1'].
> spec for: #'pharo5.0.x' do: [
> spec package: 'Smallapack-StdLib' with:
> 'Smallapack-StdLib-nice.1'].
> spec for: #'pharo6.0.x' do: [
> spec package: 'Smallapack-StdLib' with:
> 'Smallapack-StdLib.UFFI-nice.1'].
>
> but the configuration loads Smallapack-StdLib-nice.1 instead of
> Smallapack-StdLib.UFFI-nice.1
>
> I would like to avoid using two different package names because it
> complexifies the baseline for nothing.
> It the same package, just a different branch.
> Isn't it possible?
> Why?
> Can we fix it?
>

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] DebugSession>>activePC:

[Eliot Miranda]

Hi Thomas,

  forgive me, my first response was too terse.  Having thought about it in the 
shower it becomes clear :-)

> On Jan 11, 2019, at 6:49 AM, Thomas Dupriez  
> wrote:
> 
> Hi,
> 
> Yes, my question was just of the form: "Hey there's this method in 
> DebugSession. What is it doing? What's the intention behind it? Does someone 
> know?". There was no hidden agenda behind it.
> 
> @Eliot
> 
> After taking another look at this method, there's something I don't 
> understand:
> 
> activePC: aContext
> ^ (self isLatestContext: aContext)
> ifTrue: [ interruptedContext pc ]
> ifFalse: [ self previousPC: aContext ]
> 
> isLatestContext: checks whether its argument is the suspended context (the 
> context at the top of the stack of the interrupted process). And if that's 
> true, activePC: returns the pc of **interruptedContext**, not of the 
> suspended context. These two contexts are different when the debugger opens 
> on an exception, so this method is potentially returning a pc for another 
> context than its argument...
> 
> Another question I have to improve the comment for this method is: what's the 
> high-level meaning of this concept of "activePC". You gave the formal 
> definition, but what's the point of defining this so to speak? What makes 
> this concept interesting enough to warrant defining it and giving it a name?

There are two “modes” where a pc us mapped to a source range.  One is when 
stepping a context in the debugger (the context is on top and is actively 
executing bytecodes).  Here the debugger stops immediately before a send or 
assignment or return, so that for sends we can do into or over, or for 
assignments or returns check stack top to see what will be assigned or 
returned.  In this mode we want the pc of the send, assign or return to map to 
the source range for the send, or the expression being assigned or returned.  
Since this is the “common case”, and since this is the only choice that makes 
sense for assignments ta and returns, the bytecode compiler constructs it’s pc 
to source range map in terms of the pc of the first byte if the send, assign or 
return bytecode.

The second “mode” is when selecting a context below the top context.  The pc 
for any context below the top context will be the return pc for a send, because 
the send has already happened.  The compiler could choose to map this pc to the 
send, but it would not match what works for the common case. Another choice 
would appear be to have two map entries, one for the send and one for the 
return pc, both mapping to the source range.  But this wouldn’t work because 
the result of a send might be assigned or returned and so there is a potential 
conflict.  I stead the reasonable solution is to select the previous pc for 
contexts below the top of context, which will be the pc for the start of the 
send bytecode.

HTH

> 
> Cheers,
> Thomas
> 
>> On 11/01/2019 13:53, Tudor Girba wrote:
>> Hi,
>> 
>> @Eliot: Thanks for the clarifying answer.
>> 
>> I believe you might have jumped to conclusion about the intention of the 
>> question. Thomas asked a legitimate question. Without users of a method it 
>> is hard to understand its use. It does not necessarily imply that the 
>> intention is to remove it, but it does show that someone wants to understand.
>> 
>> As far as I know, Thomas actually wants to write a test to cover that usage. 
>> I am sure that you appreciate and encourage that :).
>> 
>> @Thomas: Thanks for this effort!
>> 
>> Cheers,
>> Doru
>> 
>> 
>>> On Jan 10, 2019, at 3:11 PM, Eliot Miranda  wrote:
>>> 
>>> Hi Thomas,
>>> 
 On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev 
  wrote:
 
 
>>> in a stack of contexts the active pc is different for the top context.  For 
>>> other than the top context, a context’s pc will be pointing after the send 
>>> that created the context above it, so to find the pc of the send one finds 
>>> the previous pc.  For the top context its pc is the active pc.
>>> 
>>> Typically the debugger is invoked in two different modes, interruption or 
>>> exception. When interrupted, a process is stopped at the next suspension 
>>> point (method entry or backward branch) and the top context in the process 
>>> is the context to be displayed in the debugger.  When an exception occurs 
>>> the exception search machinery will find the signaling context, the context 
>>> that raised the exception, which will be below the search machinery and the 
>>> debugger invocation above that. The active pc of the signaling context will 
>>> be the of for the send of digbsl et al.
>>> 
>>> So the distinction is important and the utility method is probably useful.
>>> 
>>> 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 

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] DebugSession>>activePC:

[Eliot Miranda]

Hi Thomas,


> On Jan 11, 2019, at 6:49 AM, Thomas Dupriez  
> wrote:
> 
> Hi,
> 
> Yes, my question was just of the form: "Hey there's this method in 
> DebugSession. What is it doing? What's the intention behind it? Does someone 
> know?". There was no hidden agenda behind it.
> 
> @Eliot
> 
> After taking another look at this method, there's something I don't 
> understand:
> 
> activePC: aContext
> ^ (self isLatestContext: aContext)
> ifTrue: [ interruptedContext pc ]
> ifFalse: [ self previousPC: aContext ]
> 
> isLatestContext: checks whether its argument is the suspended context (the 
> context at the top of the stack of the interrupted process). And if that's 
> true, activePC: returns the pc of **interruptedContext**, not of the 
> suspended context. These two contexts are different when the debugger opens 
> on an exception, so this method is potentially returning a pc for another 
> context than its argument...

Ugh, I had missed that.  Thanks for pointing that out.  It does look like a 
bug.  The Squeak code is very different (much less elegant code written by me 
in DebuggerMethodMap) but that code does use only one context.

So I expect the code should read
activePC: aContext
^ (self isLatestContext: aContext)
ifTrue: [ aContext pc ]
ifFalse: [ self previousPC: aContext ]

> 
> Another question I have to improve the comment for this method is: what's the 
> high-level meaning of this concept of "activePC". You gave the formal 
> definition, but what's the point of defining this so to speak? What makes 
> this concept interesting enough to warrant defining it and giving it a name?

Because the active pc is used to derive display feedback in the debugger.  In 
particular it is used to derive source ranges for contexts.

> 
> Cheers,
> Thomas
> 
>> On 11/01/2019 13:53, Tudor Girba wrote:
>> Hi,
>> 
>> @Eliot: Thanks for the clarifying answer.
>> 
>> I believe you might have jumped to conclusion about the intention of the 
>> question. Thomas asked a legitimate question. Without users of a method it 
>> is hard to understand its use. It does not necessarily imply that the 
>> intention is to remove it, but it does show that someone wants to understand.
>> 
>> As far as I know, Thomas actually wants to write a test to cover that usage. 
>> I am sure that you appreciate and encourage that :).
>> 
>> @Thomas: Thanks for this effort!
>> 
>> Cheers,
>> Doru
>> 
>> 
>>> On Jan 10, 2019, at 3:11 PM, Eliot Miranda  wrote:
>>> 
>>> Hi Thomas,
>>> 
 On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev 
  wrote:
 
 
>>> in a stack of contexts the active pc is different for the top context.  For 
>>> other than the top context, a context’s pc will be pointing after the send 
>>> that created the context above it, so to find the pc of the send one finds 
>>> the previous pc.  For the top context its pc is the active pc.
>>> 
>>> Typically the debugger is invoked in two different modes, interruption or 
>>> exception. When interrupted, a process is stopped at the next suspension 
>>> point (method entry or backward branch) and the top context in the process 
>>> is the context to be displayed in the debugger.  When an exception occurs 
>>> the exception search machinery will find the signaling context, the context 
>>> that raised the exception, which will be below the search machinery and the 
>>> debugger invocation above that. The active pc of the signaling context will 
>>> be the of for the send of digbsl et al.
>>> 
>>> So the distinction is important and the utility method is probably useful.
>>> 
>>> 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.
>> --
>> www.feenk.com
>> 
>> “The smaller and more pervasive the hardware becomes, the more physical the 
>> software gets."
>> 
>> 
> 

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] DebugSession>>activePC:

[Eliot Miranda]

Hi Doru,


> On Jan 11, 2019, at 4:53 AM, Tudor Girba  wrote:
> 
> Hi,
> 
> @Eliot: Thanks for the clarifying answer.
> 
> I believe you might have jumped to conclusion about the intention of the 
> question. Thomas asked a legitimate question. Without users of a method it is 
> hard to understand its use. It does not necessarily imply that the intention 
> is to remove it, but it does show that someone wants to understand.

Indeed.  I am responding because of the recent experience we had, that you are 
intimately aware of, of moving the somewhat functional Pharo 6 VMMaker port 
forward to Pharo 7, which is frustrating because enough things changes that it 
was broken.  And that is far from an isolated experience.

I want very, very much for Pharo to succeed.  It is the most important user of 
the opensmalltalk-vm by far.  If Pharo fails, opensmalltalk-vm will very likely 
become entirely irrelevant and uninteresting.  So my career and financial 
security are wedded to Pharo’s success.  At the same time I do not feel 
positive about Pharo, as I have said, in its stability and in the community’s 
difficulty in discussing problems (primarily the stability and development 
model issues).  I am therefore very much interested in solving these problems.  
So if I jump to conclusions it is because I am concerned and want to change how 
I feel about Pharo as a viable platform for my work, and that means being able 
to talk about difficult issues and not be shushed.  I want there to be 
constructive discussion, not defensiveness or blithe positivity.  Progress 
depends on truth and ingenuity, not positive thinking.

> 
> As far as I know, Thomas actually wants to write a test to cover that usage. 
> I am sure that you appreciate and encourage that :).

Indeed I do!

> 
> @Thomas: Thanks for this effort!
> 
> Cheers,
> Doru
> 
> 
>> On Jan 10, 2019, at 3:11 PM, Eliot Miranda  wrote:
>> 
>> Hi Thomas,
>> 
>>> On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev 
>>>  wrote:
>>> 
>>> 
>> 
>> in a stack of contexts the active pc is different for the top context.  For 
>> other than the top context, a context’s pc will be pointing after the send 
>> that created the context above it, so to find the pc of the send one finds 
>> the previous pc.  For the top context its pc is the active pc.
>> 
>> Typically the debugger is invoked in two different modes, interruption or 
>> exception. When interrupted, a process is stopped at the next suspension 
>> point (method entry or backward branch) and the top context in the process 
>> is the context to be displayed in the debugger.  When an exception occurs 
>> the exception search machinery will find the signaling context, the context 
>> that raised the exception, which will be below the search machinery and the 
>> debugger invocation above that. The active pc of the signaling context will 
>> be the of for the send of digbsl et al.
>> 
>> So the distinction is important and the utility method is probably useful.
>> 
>> 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.
> 
> --
> www.feenk.com
> 
> “The smaller and more pervasive the hardware becomes, the more physical the 
> software gets."
> 
> 

Re: [Pharo-dev] DebugSession>>activePC:

[Eliot Miranda]

Craig,

thank you. +1000

> On Jan 11, 2019, at 12:58 AM, Craig Latta  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
> cr...@blackpagedigital.com
> +31   6 2757 7177 (SMS ok)
> + 1 415  287 3547 (no SMS)
> 

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 

[Pharo-dev] [Pharo 7.0] Build #120: 21867-cannot-loadsave-to-ftp-repository

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!
  
The status of the build #120 was: FAILURE.

The Pull Request #2208 was integrated: "21867-cannot-loadsave-to-ftp-repository"
Pull request url: https://github.com/pharo-project/pharo/pull/2208

Issue Url: https://pharo.fogbugz.com/f/cases/21867
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo7.0/120/

[Pharo-dev] [Pharo 7.0] Build #119: 22892 update to iceberg v154 support for win64

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!
  
The status of the build #119 was: SUCCESS.

The Pull Request #2221 was integrated: "22892 update to iceberg v154   support 
for win64"
Pull request url: https://github.com/pharo-project/pharo/pull/2221

Issue Url: https://pharo.fogbugz.com/f/cases/22892
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo7.0/119/

Re: [Pharo-dev] DebugSession>>activePC:

[Thomas Dupriez]

Hi,

Yes, my question was just of the form: "Hey there's this method in 
DebugSession. What is it doing? What's the intention behind it? Does 
someone know?". There was no hidden agenda behind it.


@Eliot

After taking another look at this method, there's something I don't 
understand:


activePC: aContext
^ (self isLatestContext: aContext)
        ifTrue: [ interruptedContext pc ]
        ifFalse: [ self previousPC: aContext ]

isLatestContext: checks whether its argument is the suspended context 
(the context at the top of the stack of the interrupted process). And if 
that's true, activePC: returns the pc of **interruptedContext**, not of 
the suspended context. These two contexts are different when the 
debugger opens on an exception, so this method is potentially returning 
a pc for another context than its argument...


Another question I have to improve the comment for this method is: 
what's the high-level meaning of this concept of "activePC". You gave 
the formal definition, but what's the point of defining this so to 
speak? What makes this concept interesting enough to warrant defining it 
and giving it a name?


Cheers,
Thomas

On 11/01/2019 13:53, Tudor Girba wrote:

Hi,

@Eliot: Thanks for the clarifying answer.

I believe you might have jumped to conclusion about the intention of the 
question. Thomas asked a legitimate question. Without users of a method it is 
hard to understand its use. It does not necessarily imply that the intention is 
to remove it, but it does show that someone wants to understand.

As far as I know, Thomas actually wants to write a test to cover that usage. I 
am sure that you appreciate and encourage that :).

@Thomas: Thanks for this effort!

Cheers,
Doru



On Jan 10, 2019, at 3:11 PM, Eliot Miranda  wrote:

Hi Thomas,


On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev 
 wrote:



in a stack of contexts the active pc is different for the top context.  For 
other than the top context, a context’s pc will be pointing after the send that 
created the context above it, so to find the pc of the send one finds the 
previous pc.  For the top context its pc is the active pc.

Typically the debugger is invoked in two different modes, interruption or 
exception. When interrupted, a process is stopped at the next suspension point 
(method entry or backward branch) and the top context in the process is the 
context to be displayed in the debugger.  When an exception occurs the 
exception search machinery will find the signaling context, the context that 
raised the exception, which will be below the search machinery and the debugger 
invocation above that. The active pc of the signaling context will be the of 
for the send of digbsl et al.

So the distinction is important and the utility method is probably useful.

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.

--
www.feenk.com

“The smaller and more pervasive the hardware becomes, the more physical the software 
gets."

[Pharo-dev] [Pharo 7.0] Build #118: Correct a typo in ZnDefaultServerDelegate class

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!
  
The status of the build #118 was: SUCCESS.

The Pull Request #2216 was integrated: "Correct a typo in 
ZnDefaultServerDelegate class"
Pull request url: https://github.com/pharo-project/pharo/pull/2216

Issue Url: https://pharo.fogbugz.com/f/cases/patch
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo7.0/118/

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] DebugSession>>activePC:

[Tudor Girba]

Hi,

@Eliot: Thanks for the clarifying answer.

I believe you might have jumped to conclusion about the intention of the 
question. Thomas asked a legitimate question. Without users of a method it is 
hard to understand its use. It does not necessarily imply that the intention is 
to remove it, but it does show that someone wants to understand.

As far as I know, Thomas actually wants to write a test to cover that usage. I 
am sure that you appreciate and encourage that :).

@Thomas: Thanks for this effort!

Cheers,
Doru


> On Jan 10, 2019, at 3:11 PM, Eliot Miranda  wrote:
> 
> Hi Thomas,
> 
>> On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev 
>>  wrote:
>> 
>> 
> 
> in a stack of contexts the active pc is different for the top context.  For 
> other than the top context, a context’s pc will be pointing after the send 
> that created the context above it, so to find the pc of the send one finds 
> the previous pc.  For the top context its pc is the active pc.
> 
> Typically the debugger is invoked in two different modes, interruption or 
> exception. When interrupted, a process is stopped at the next suspension 
> point (method entry or backward branch) and the top context in the process is 
> the context to be displayed in the debugger.  When an exception occurs the 
> exception search machinery will find the signaling context, the context that 
> raised the exception, which will be below the search machinery and the 
> debugger invocation above that. The active pc of the signaling context will 
> be the of for the send of digbsl et al.
> 
> So the distinction is important and the utility method is probably useful.
> 
> 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.

--
www.feenk.com

“The smaller and more pervasive the hardware becomes, the more physical the 
software gets."

[Pharo-dev] Is metacello aware of MC branches???

[Nicolas Cellier]

Hi all,
I'm trying to resolve a dialect compatibility problem like this:

I want to load the Squeak and Pharo3 to 5 version depending on FFI
Smallapack-StdLib-nice.1

For Pharo6, I made a different branch depending on UFFI
Smallapack-StdLib.UFFI-nice.1

In the base line, i tell
spec for: #'common' do: [
spec blessing: #'baseline'.
spec repository: 'http://www.squeaksource.com/Smallapack'.
spec package: 'Smallapack-StdLib']
and in the version I tell

spec for: #squeak do: [
spec package: 'Smallapack-StdLib' with: 'Smallapack-StdLib-nice.1'].
spec for: #'pharo5.0.x' do: [
spec package: 'Smallapack-StdLib' with: 'Smallapack-StdLib-nice.1'].
spec for: #'pharo6.0.x' do: [
spec package: 'Smallapack-StdLib' with:
'Smallapack-StdLib.UFFI-nice.1'].

but the configuration loads Smallapack-StdLib-nice.1 instead of
Smallapack-StdLib.UFFI-nice.1

I would like to avoid using two different package names because it
complexifies the baseline for nothing.
It the same package, just a different branch.
Isn't it possible?
Why?
Can we fix it?

[Pharo-dev] FFILibrary uniqueInstance

[Nicolas Cellier]

Hi all,
I wanted to know if the moduleName was cached somewhere or recomputed at
each function call...
It seems to be recomputed.

We could have a different scheme:
moduleName is cached in a class inst var of FFILibrary.
FFILibrary is then added to startup list and moduleName is reset when
resuming on a different platform.
instance side moduleName calls class side moduleName.

Or moduleName becomes an inst var, set during uniqueInstance construction,
and uniqueInstance is nilled out when resuming.

What do you think?

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] DebugSession>>activePC:

[ducasse]

Then perfect!


> On 11 Jan 2019, at 09:58, Craig Latta  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
> cr...@blackpagedigital.com 
> +31   6 2757 7177 (SMS ok)
> + 1 415  287 3547 (no SMS)

Re: [Pharo-dev] DebugSession>>activePC:

[Craig Latta]

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
cr...@blackpagedigital.com
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)

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