Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

2016-07-08 Thread stepharo 



Do you think professional developers who use Pharo all day like crashes or 
hangs ? We are all the same here, we want a stable system.

It is not certain that the catalog download is the problem.

This specific feature that you think should only be enabled by those who want 
it (you call them pros) is exactly a beginner's feature: a way to discover 
every external library written. How ironic that you don't care.

Sven the students we have are not looking for published packages and if they 
need, they can use the catalog: entering XML and pressing ok
there is simple enough. It is not a complex ui. Spotter is a lot more confusing 
than the catalog UI. But dogma says the inverse so I will stop
arguing.

Well, you won, the feature is gone.

No it is not gone.
Update your preferences and help fixing the real problem and we will put 
it back.


You see I produce Spotter videos for the mooc. Do you think that I 
should have spent all this energy for something that I do not like.

Now we should be able to critic features.

Stef

Yes, newcomers hit all kinds of issues that more experienced users 
subconsciously avoid, being mindful for that is important. I think we all try 
to do that, by fixing things, not by turning things off.

We lack a proper process to decide these kinds of conflicts.


On 08 Jul 2016, at 11:21, stepharo  wrote:

Again again and again: How many times do you see students having Pharo frozen 
because the internet connection in the classroom is fleaky.

Apparently turning off these people is not an issue to you. Perfect but it is 
one for me.

For your productivity boost why can't you click on one setting and put it on?

Tell me I do not understand. In my dev image I have several settings set for my 
own usage.

So why you cannot have one extra one? Especially since preferences are loaded 
automatically.


Then when we will find a way to address the real problem we can just turn the 
setting on.

I will have spent half of my life showing software to newbies and may I ask you 
when is the last time

you show Pharo to a guy that is learning programming? I do that often (may be 
too often)

and in bad situation like in Afrika but not only.

Stef



Le 6/7/16 à 20:19, Sven Van Caekenberghe a écrit :

I'll try once more to explain.

You like the catalog, don't you ?  It was your idea in the first place. With 
this feature you can just type XML, CSV, JSON or whatever and it will suggest a 
couple of catalog projects that you can install with just one click, no need to 
open any tool you don't even know. This is especially good for new people. IT 
IS A FANTASTIC FEATURE, IT IS THE WAY THINGS SHOULD WORK. It leverages all the 
work put in the catalog.

Is Spotter or any other part of Pharo perfect ? No.

For many people, Spotter make a huge functional difference, we use it every 
minute. If it would hang or block the image even once a day, any of us would 
complain loudly.

Conclusion: it works for 99% of the people/cases.

Even in the 1% where there is a problem, it is not 100% sure it is related to 
the catalog searching. In the last concrete issue reported, the guy tried 
disabling the catalog searching AND IT MADE NO DIFFERENCE !

So again, why turn it off ? It is an overreaction, not engineering.

The underlying problem is that in some very rare, hard to reproduce cases we 
cannot reliably detect that there is no network. That's about it.

Note also that almost every application or app today will do some network 
calls, this is how the world work - we should be able to do the same with 
Pharo, not run away and kill every feature that does a network call.


On 06 Jul 2016, at 18:14, stepharo  wrote:

Who vote to put it in?

Seriously I think that my main concern is about getting Pharo stable in any 
occasion and not giving

a bad impression of the system. I takes enough time to build traction and such 
glitches can spoil

our effort in no time. "Yes Pharo froze."

So it would be nice to care take of such aspect.

I do not understand why super users do not manage to put a reference to on in 
the preferences.

Sorry esteban but I do not buy your argument that something off is remove. No 
it is off.

Stef

On 06 Jul 2016, at 09:52, GitHub  wrote:

18674 Turn spotter catalog off by default
https://pharo.fogbugz.com/f/cases/18674

We did not agree on this, at all, there was no public discussion, no vote.

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

2016-07-08 Thread Sven Van Caekenberghe 

> On 08 Jul 2016, at 12:21, stepharo  wrote:
> 
> 
> 
> Le 8/7/16 à 11:44, Sven Van Caekenberghe a écrit :
>> Do you think professional developers who use Pharo all day like crashes or 
>> hangs ? We are all the same here, we want a stable system.
>> 
>> It is not certain that the catalog download is the problem.
>> 
>> This specific feature that you think should only be enabled by those who 
>> want it (you call them pros) is exactly a beginner's feature: a way to 
>> discover every external library written. How ironic that you don't care.
> 
> Sven the students we have are not looking for published packages and if they 
> need, they can use the catalog: entering XML and pressing ok
> there is simple enough. It is not a complex ui. Spotter is a lot more 
> confusing than the catalog UI. But dogma says the inverse so I will stop
> arguing.

Well, you won, the feature is gone.

>> 
>> Yes, newcomers hit all kinds of issues that more experienced users 
>> subconsciously avoid, being mindful for that is important. I think we all 
>> try to do that, by fixing things, not by turning things off.
>> 
>> We lack a proper process to decide these kinds of conflicts.
>> 
>>> On 08 Jul 2016, at 11:21, stepharo  wrote:
>>> 
>>> Again again and again: How many times do you see students having Pharo 
>>> frozen because the internet connection in the classroom is fleaky.
>>> 
>>> Apparently turning off these people is not an issue to you. Perfect but it 
>>> is one for me.
>>> 
>>> For your productivity boost why can't you click on one setting and put it 
>>> on?
>>> 
>>> Tell me I do not understand. In my dev image I have several settings set 
>>> for my own usage.
>>> 
>>> So why you cannot have one extra one? Especially since preferences are 
>>> loaded automatically.
>>> 
>>> 
>>> Then when we will find a way to address the real problem we can just turn 
>>> the setting on.
>>> 
>>> I will have spent half of my life showing software to newbies and may I ask 
>>> you when is the last time
>>> 
>>> you show Pharo to a guy that is learning programming? I do that often (may 
>>> be too often)
>>> 
>>> and in bad situation like in Afrika but not only.
>>> 
>>> Stef
>>> 
>>> 
>>> 
>>> Le 6/7/16 à 20:19, Sven Van Caekenberghe a écrit :
 I'll try once more to explain.
 
 You like the catalog, don't you ?  It was your idea in the first place. 
 With this feature you can just type XML, CSV, JSON or whatever and it will 
 suggest a couple of catalog projects that you can install with just one 
 click, no need to open any tool you don't even know. This is especially 
 good for new people. IT IS A FANTASTIC FEATURE, IT IS THE WAY THINGS 
 SHOULD WORK. It leverages all the work put in the catalog.
 
 Is Spotter or any other part of Pharo perfect ? No.
 
 For many people, Spotter make a huge functional difference, we use it 
 every minute. If it would hang or block the image even once a day, any of 
 us would complain loudly.
 
 Conclusion: it works for 99% of the people/cases.
 
 Even in the 1% where there is a problem, it is not 100% sure it is related 
 to the catalog searching. In the last concrete issue reported, the guy 
 tried disabling the catalog searching AND IT MADE NO DIFFERENCE !
 
 So again, why turn it off ? It is an overreaction, not engineering.
 
 The underlying problem is that in some very rare, hard to reproduce cases 
 we cannot reliably detect that there is no network. That's about it.
 
 Note also that almost every application or app today will do some network 
 calls, this is how the world work - we should be able to do the same with 
 Pharo, not run away and kill every feature that does a network call.
 
> On 06 Jul 2016, at 18:14, stepharo  wrote:
> 
> Who vote to put it in?
> 
> Seriously I think that my main concern is about getting Pharo stable in 
> any occasion and not giving
> 
> a bad impression of the system. I takes enough time to build traction and 
> such glitches can spoil
> 
> our effort in no time. "Yes Pharo froze."
> 
> So it would be nice to care take of such aspect.
> 
> I do not understand why super users do not manage to put a reference to 
> on in the preferences.
> 
> Sorry esteban but I do not buy your argument that something off is 
> remove. No it is off.
> 
> Stef
>>> On 06 Jul 2016, at 09:52, GitHub  wrote:
>>> 
>>> 18674 Turn spotter catalog off by default
>>> https://pharo.fogbugz.com/f/cases/18674
>> We did not agree on this, at all, there was no public discussion, no 
>> vote.
>> 
>> 
 
>>> 
>> 
>> 
> 
>

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

2016-07-08 Thread stepharo 



Le 8/7/16 à 11:44, Sven Van Caekenberghe a écrit :

Do you think professional developers who use Pharo all day like crashes or 
hangs ? We are all the same here, we want a stable system.

It is not certain that the catalog download is the problem.

This specific feature that you think should only be enabled by those who want 
it (you call them pros) is exactly a beginner's feature: a way to discover 
every external library written. How ironic that you don't care.


Sven the students we have are not looking for published packages and if 
they need, they can use the catalog: entering XML and pressing ok
there is simple enough. It is not a complex ui. Spotter is a lot more 
confusing than the catalog UI. But dogma says the inverse so I will stop

arguing.



Yes, newcomers hit all kinds of issues that more experienced users 
subconsciously avoid, being mindful for that is important. I think we all try 
to do that, by fixing things, not by turning things off.

We lack a proper process to decide these kinds of conflicts.


On 08 Jul 2016, at 11:21, stepharo  wrote:

Again again and again: How many times do you see students having Pharo frozen 
because the internet connection in the classroom is fleaky.

Apparently turning off these people is not an issue to you. Perfect but it is 
one for me.

For your productivity boost why can't you click on one setting and put it on?

Tell me I do not understand. In my dev image I have several settings set for my 
own usage.

So why you cannot have one extra one? Especially since preferences are loaded 
automatically.


Then when we will find a way to address the real problem we can just turn the 
setting on.

I will have spent half of my life showing software to newbies and may I ask you 
when is the last time

you show Pharo to a guy that is learning programming? I do that often (may be 
too often)

and in bad situation like in Afrika but not only.

Stef



Le 6/7/16 à 20:19, Sven Van Caekenberghe a écrit :

I'll try once more to explain.

You like the catalog, don't you ?  It was your idea in the first place. With 
this feature you can just type XML, CSV, JSON or whatever and it will suggest a 
couple of catalog projects that you can install with just one click, no need to 
open any tool you don't even know. This is especially good for new people. IT 
IS A FANTASTIC FEATURE, IT IS THE WAY THINGS SHOULD WORK. It leverages all the 
work put in the catalog.

Is Spotter or any other part of Pharo perfect ? No.

For many people, Spotter make a huge functional difference, we use it every 
minute. If it would hang or block the image even once a day, any of us would 
complain loudly.

Conclusion: it works for 99% of the people/cases.

Even in the 1% where there is a problem, it is not 100% sure it is related to 
the catalog searching. In the last concrete issue reported, the guy tried 
disabling the catalog searching AND IT MADE NO DIFFERENCE !

So again, why turn it off ? It is an overreaction, not engineering.

The underlying problem is that in some very rare, hard to reproduce cases we 
cannot reliably detect that there is no network. That's about it.

Note also that almost every application or app today will do some network 
calls, this is how the world work - we should be able to do the same with 
Pharo, not run away and kill every feature that does a network call.


On 06 Jul 2016, at 18:14, stepharo  wrote:

Who vote to put it in?

Seriously I think that my main concern is about getting Pharo stable in any 
occasion and not giving

a bad impression of the system. I takes enough time to build traction and such 
glitches can spoil

our effort in no time. "Yes Pharo froze."

So it would be nice to care take of such aspect.

I do not understand why super users do not manage to put a reference to on in 
the preferences.

Sorry esteban but I do not buy your argument that something off is remove. No 
it is off.

Stef

On 06 Jul 2016, at 09:52, GitHub  wrote:

18674 Turn spotter catalog off by default
https://pharo.fogbugz.com/f/cases/18674

We did not agree on this, at all, there was no public discussion, no vote.

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

2016-07-08 Thread Sven Van Caekenberghe 
Do you think professional developers who use Pharo all day like crashes or 
hangs ? We are all the same here, we want a stable system.

It is not certain that the catalog download is the problem.

This specific feature that you think should only be enabled by those who want 
it (you call them pros) is exactly a beginner's feature: a way to discover 
every external library written. How ironic that you don't care.

Yes, newcomers hit all kinds of issues that more experienced users 
subconsciously avoid, being mindful for that is important. I think we all try 
to do that, by fixing things, not by turning things off.

We lack a proper process to decide these kinds of conflicts.

> On 08 Jul 2016, at 11:21, stepharo  wrote:
> 
> Again again and again: How many times do you see students having Pharo frozen 
> because the internet connection in the classroom is fleaky.
> 
> Apparently turning off these people is not an issue to you. Perfect but it is 
> one for me.
> 
> For your productivity boost why can't you click on one setting and put it on?
> 
> Tell me I do not understand. In my dev image I have several settings set for 
> my own usage.
> 
> So why you cannot have one extra one? Especially since preferences are loaded 
> automatically.
> 
> 
> Then when we will find a way to address the real problem we can just turn the 
> setting on.
> 
> I will have spent half of my life showing software to newbies and may I ask 
> you when is the last time
> 
> you show Pharo to a guy that is learning programming? I do that often (may be 
> too often)
> 
> and in bad situation like in Afrika but not only.
> 
> Stef
> 
> 
> 
> Le 6/7/16 à 20:19, Sven Van Caekenberghe a écrit :
>> I'll try once more to explain.
>> 
>> You like the catalog, don't you ?  It was your idea in the first place. With 
>> this feature you can just type XML, CSV, JSON or whatever and it will 
>> suggest a couple of catalog projects that you can install with just one 
>> click, no need to open any tool you don't even know. This is especially good 
>> for new people. IT IS A FANTASTIC FEATURE, IT IS THE WAY THINGS SHOULD WORK. 
>> It leverages all the work put in the catalog.
>> 
>> Is Spotter or any other part of Pharo perfect ? No.
>> 
>> For many people, Spotter make a huge functional difference, we use it every 
>> minute. If it would hang or block the image even once a day, any of us would 
>> complain loudly.
>> 
>> Conclusion: it works for 99% of the people/cases.
>> 
>> Even in the 1% where there is a problem, it is not 100% sure it is related 
>> to the catalog searching. In the last concrete issue reported, the guy tried 
>> disabling the catalog searching AND IT MADE NO DIFFERENCE !
>> 
>> So again, why turn it off ? It is an overreaction, not engineering.
>> 
>> The underlying problem is that in some very rare, hard to reproduce cases we 
>> cannot reliably detect that there is no network. That's about it.
>> 
>> Note also that almost every application or app today will do some network 
>> calls, this is how the world work - we should be able to do the same with 
>> Pharo, not run away and kill every feature that does a network call.
>> 
>>> On 06 Jul 2016, at 18:14, stepharo  wrote:
>>> 
>>> Who vote to put it in?
>>> 
>>> Seriously I think that my main concern is about getting Pharo stable in any 
>>> occasion and not giving
>>> 
>>> a bad impression of the system. I takes enough time to build traction and 
>>> such glitches can spoil
>>> 
>>> our effort in no time. "Yes Pharo froze."
>>> 
>>> So it would be nice to care take of such aspect.
>>> 
>>> I do not understand why super users do not manage to put a reference to on 
>>> in the preferences.
>>> 
>>> Sorry esteban but I do not buy your argument that something off is remove. 
>>> No it is off.
>>> 
>>> Stef
> On 06 Jul 2016, at 09:52, GitHub  wrote:
> 
> 18674 Turn spotter catalog off by default
>   https://pharo.fogbugz.com/f/cases/18674
 We did not agree on this, at all, there was no public discussion, no vote.
 
 
>>> 
>> 
>> 
> 
>

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

2016-07-08 Thread stepharo 
Again again and again: How many times do you see students having Pharo 
frozen because the internet connection in the classroom is fleaky.


Apparently turning off these people is not an issue to you. Perfect but 
it is one for me.


For your productivity boost why can't you click on one setting and put 
it on?


Tell me I do not understand. In my dev image I have several settings set 
for my own usage.


So why you cannot have one extra one? Especially since preferences are 
loaded automatically.



Then when we will find a way to address the real problem we can just 
turn the setting on.


I will have spent half of my life showing software to newbies and may I 
ask you when is the last time


you show Pharo to a guy that is learning programming? I do that often 
(may be too often)


and in bad situation like in Afrika but not only.

Stef



Le 6/7/16 à 20:19, Sven Van Caekenberghe a écrit :

I'll try once more to explain.

You like the catalog, don't you ?  It was your idea in the first place. With 
this feature you can just type XML, CSV, JSON or whatever and it will suggest a 
couple of catalog projects that you can install with just one click, no need to 
open any tool you don't even know. This is especially good for new people. IT 
IS A FANTASTIC FEATURE, IT IS THE WAY THINGS SHOULD WORK. It leverages all the 
work put in the catalog.

Is Spotter or any other part of Pharo perfect ? No.

For many people, Spotter make a huge functional difference, we use it every 
minute. If it would hang or block the image even once a day, any of us would 
complain loudly.

Conclusion: it works for 99% of the people/cases.

Even in the 1% where there is a problem, it is not 100% sure it is related to 
the catalog searching. In the last concrete issue reported, the guy tried 
disabling the catalog searching AND IT MADE NO DIFFERENCE !

So again, why turn it off ? It is an overreaction, not engineering.

The underlying problem is that in some very rare, hard to reproduce cases we 
cannot reliably detect that there is no network. That's about it.

Note also that almost every application or app today will do some network 
calls, this is how the world work - we should be able to do the same with 
Pharo, not run away and kill every feature that does a network call.


On 06 Jul 2016, at 18:14, stepharo  wrote:

Who vote to put it in?

Seriously I think that my main concern is about getting Pharo stable in any 
occasion and not giving

a bad impression of the system. I takes enough time to build traction and such 
glitches can spoil

our effort in no time. "Yes Pharo froze."

So it would be nice to care take of such aspect.

I do not understand why super users do not manage to put a reference to on in 
the preferences.

Sorry esteban but I do not buy your argument that something off is remove. No 
it is off.

Stef

On 06 Jul 2016, at 09:52, GitHub  wrote:

18674 Turn spotter catalog off by default
https://pharo.fogbugz.com/f/cases/18674

We did not agree on this, at all, there was no public discussion, no vote.

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

2016-07-07 Thread Esteban Lorenzano 
I have to add here… solution is bad, because now projects are not shown EVEN if 
I activate it in settings :(

> On 06 Jul 2016, at 12:28, Esteban Lorenzano  wrote:
> 
> yes, I do not agree either but is true there where problems. 
> but IMO this would be solved just by putting a timeout in 1-2s (and then run 
> in background, and cache results) 
> not turning it off. 
> in for my experience, turning something off is equivalent to remove the 
> feature (but then is worst, because it becomes dead code inside image).
> 
> Anyway, any taker, to solve this in a proper way? 
> 
> Esteban
> 
>> On 06 Jul 2016, at 12:13, Marcus Denker  wrote:
>> 
>> 
>>> On 06 Jul 2016, at 10:12, Sven Van Caekenberghe  wrote:
>>> 
>>> 
 On 06 Jul 2016, at 09:52, GitHub  wrote:
 
 18674 Turn spotter catalog off by default
https://pharo.fogbugz.com/f/cases/18674
>>> 
>>> We did not agree on this, at all, there was no public discussion, no vote.
>>> 
>> 
>> I only know that there where problems.
>> 
>>  Marcus
>> 
>

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

2016-07-06 Thread Eliot Miranda 
Hi Ben,

On Wed, Jul 6, 2016 at 5:16 PM, Ben Coman  wrote:

> On Thu, Jul 7, 2016 at 2:19 AM, Sven Van Caekenberghe 
> wrote:
> > I'll try once more to explain.
> >
> > You like the catalog, don't you ?  It was your idea in the first place.
> With this feature you can just type XML, CSV, JSON or whatever and it will
> suggest a couple of catalog projects that you can install with just one
> click, no need to open any tool you don't even know. This is especially
> good for new people. IT IS A FANTASTIC FEATURE, IT IS THE WAY THINGS SHOULD
> WORK. It leverages all the work put in the catalog.
> >
> > Is Spotter or any other part of Pharo perfect ? No.
> >
> > For many people, Spotter make a huge functional difference, we use it
> every minute. If it would hang or block the image even once a day, any of
> us would complain loudly.
> >
> > Conclusion: it works for 99% of the people/cases.
> >
> > Even in the 1% where there is a problem, it is not 100% sure it is
> related to the catalog searching. In the last concrete issue reported, the
> guy tried disabling the catalog searching AND IT MADE NO DIFFERENCE !
> >
> > So again, why turn it off ? It is an overreaction, not engineering.
> >
> > The underlying problem is that in some very rare, hard to reproduce
> cases we cannot reliably detect that there is no network. That's about it.
>
> If the root cause is a blocking system call e.g
> "NetNameResolver class>>#addressForName: sometimes hangs when there is
> no network"
> https://pharo.fogbugz.com/default.asp?18281;
>
> this seems very hard to fix at the Image level, except maybe doing
> in-Image name resolution instead of relying on the system library. I
> found this...
> http://forum.world.st/ANN-DnsClient-More-protocol-fun-td2303225.html


It'll be child's play when we have the threaded FFI.

>
>
> and...
> http://www.squeaksource.com/dnsclient.html
> http://www.squeaksource.com/ar.html
>
> cheers -ben
>
> >
> > Note also that almost every application or app today will do some
> network calls, this is how the world work - we should be able to do the
> same with Pharo, not run away and kill every feature that does a network
> call.
> >
> >> On 06 Jul 2016, at 18:14, stepharo  wrote:
> >>
> >> Who vote to put it in?
> >>
> >> Seriously I think that my main concern is about getting Pharo stable in
> any occasion and not giving
> >>
> >> a bad impression of the system. I takes enough time to build traction
> and such glitches can spoil
> >>
> >> our effort in no time. "Yes Pharo froze."
> >>
> >> So it would be nice to care take of such aspect.
> >>
> >> I do not understand why super users do not manage to put a reference to
> on in the preferences.
> >>
> >> Sorry esteban but I do not buy your argument that something off is
> remove. No it is off.
> >>
> >> Stef
>  On 06 Jul 2016, at 09:52, GitHub  wrote:
> 
>  18674 Turn spotter catalog off by default
>  https://pharo.fogbugz.com/f/cases/18674
> >>> We did not agree on this, at all, there was no public discussion, no
> vote.
> >>>
> >>>
> >>
> >>
> >
> >
>
>


-- 
_,,,^..^,,,_
best, Eliot

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

2016-07-06 Thread Ben Coman 
On Thu, Jul 7, 2016 at 2:19 AM, Sven Van Caekenberghe  wrote:
> I'll try once more to explain.
>
> You like the catalog, don't you ?  It was your idea in the first place. With 
> this feature you can just type XML, CSV, JSON or whatever and it will suggest 
> a couple of catalog projects that you can install with just one click, no 
> need to open any tool you don't even know. This is especially good for new 
> people. IT IS A FANTASTIC FEATURE, IT IS THE WAY THINGS SHOULD WORK. It 
> leverages all the work put in the catalog.
>
> Is Spotter or any other part of Pharo perfect ? No.
>
> For many people, Spotter make a huge functional difference, we use it every 
> minute. If it would hang or block the image even once a day, any of us would 
> complain loudly.
>
> Conclusion: it works for 99% of the people/cases.
>
> Even in the 1% where there is a problem, it is not 100% sure it is related to 
> the catalog searching. In the last concrete issue reported, the guy tried 
> disabling the catalog searching AND IT MADE NO DIFFERENCE !
>
> So again, why turn it off ? It is an overreaction, not engineering.
>
> The underlying problem is that in some very rare, hard to reproduce cases we 
> cannot reliably detect that there is no network. That's about it.

If the root cause is a blocking system call e.g
"NetNameResolver class>>#addressForName: sometimes hangs when there is
no network"
https://pharo.fogbugz.com/default.asp?18281;

this seems very hard to fix at the Image level, except maybe doing
in-Image name resolution instead of relying on the system library. I
found this...
http://forum.world.st/ANN-DnsClient-More-protocol-fun-td2303225.html

and...
http://www.squeaksource.com/dnsclient.html
http://www.squeaksource.com/ar.html

cheers -ben

>
> Note also that almost every application or app today will do some network 
> calls, this is how the world work - we should be able to do the same with 
> Pharo, not run away and kill every feature that does a network call.
>
>> On 06 Jul 2016, at 18:14, stepharo  wrote:
>>
>> Who vote to put it in?
>>
>> Seriously I think that my main concern is about getting Pharo stable in any 
>> occasion and not giving
>>
>> a bad impression of the system. I takes enough time to build traction and 
>> such glitches can spoil
>>
>> our effort in no time. "Yes Pharo froze."
>>
>> So it would be nice to care take of such aspect.
>>
>> I do not understand why super users do not manage to put a reference to on 
>> in the preferences.
>>
>> Sorry esteban but I do not buy your argument that something off is remove. 
>> No it is off.
>>
>> Stef
 On 06 Jul 2016, at 09:52, GitHub  wrote:

 18674 Turn spotter catalog off by default
 https://pharo.fogbugz.com/f/cases/18674
>>> We did not agree on this, at all, there was no public discussion, no vote.
>>>
>>>
>>
>>
>
>

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

2016-07-06 Thread Andrei Chis 
+1

On Wed, Jul 6, 2016 at 8:19 PM, Sven Van Caekenberghe  wrote:

> I'll try once more to explain.
>
> You like the catalog, don't you ?  It was your idea in the first place.
> With this feature you can just type XML, CSV, JSON or whatever and it will
> suggest a couple of catalog projects that you can install with just one
> click, no need to open any tool you don't even know. This is especially
> good for new people. IT IS A FANTASTIC FEATURE, IT IS THE WAY THINGS SHOULD
> WORK. It leverages all the work put in the catalog.
>
> Is Spotter or any other part of Pharo perfect ? No.
>
> For many people, Spotter make a huge functional difference, we use it
> every minute. If it would hang or block the image even once a day, any of
> us would complain loudly.
>
> Conclusion: it works for 99% of the people/cases.
>
> Even in the 1% where there is a problem, it is not 100% sure it is related
> to the catalog searching. In the last concrete issue reported, the guy
> tried disabling the catalog searching AND IT MADE NO DIFFERENCE !
>
> So again, why turn it off ? It is an overreaction, not engineering.
>
> The underlying problem is that in some very rare, hard to reproduce cases
> we cannot reliably detect that there is no network. That's about it.
>
> Note also that almost every application or app today will do some network
> calls, this is how the world work - we should be able to do the same with
> Pharo, not run away and kill every feature that does a network call.
>
> > On 06 Jul 2016, at 18:14, stepharo  wrote:
> >
> > Who vote to put it in?
> >
> > Seriously I think that my main concern is about getting Pharo stable in
> any occasion and not giving
> >
> > a bad impression of the system. I takes enough time to build traction
> and such glitches can spoil
> >
> > our effort in no time. "Yes Pharo froze."
> >
> > So it would be nice to care take of such aspect.
> >
> > I do not understand why super users do not manage to put a reference to
> on in the preferences.
> >
> > Sorry esteban but I do not buy your argument that something off is
> remove. No it is off.
> >
> > Stef
> >>> On 06 Jul 2016, at 09:52, GitHub  wrote:
> >>>
> >>> 18674 Turn spotter catalog off by default
> >>> https://pharo.fogbugz.com/f/cases/18674
> >> We did not agree on this, at all, there was no public discussion, no
> vote.
> >>
> >>
> >
> >
>
>
>

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

2016-07-06 Thread Sven Van Caekenberghe 
I'll try once more to explain.

You like the catalog, don't you ?  It was your idea in the first place. With 
this feature you can just type XML, CSV, JSON or whatever and it will suggest a 
couple of catalog projects that you can install with just one click, no need to 
open any tool you don't even know. This is especially good for new people. IT 
IS A FANTASTIC FEATURE, IT IS THE WAY THINGS SHOULD WORK. It leverages all the 
work put in the catalog.

Is Spotter or any other part of Pharo perfect ? No.

For many people, Spotter make a huge functional difference, we use it every 
minute. If it would hang or block the image even once a day, any of us would 
complain loudly.

Conclusion: it works for 99% of the people/cases.

Even in the 1% where there is a problem, it is not 100% sure it is related to 
the catalog searching. In the last concrete issue reported, the guy tried 
disabling the catalog searching AND IT MADE NO DIFFERENCE !

So again, why turn it off ? It is an overreaction, not engineering.

The underlying problem is that in some very rare, hard to reproduce cases we 
cannot reliably detect that there is no network. That's about it.

Note also that almost every application or app today will do some network 
calls, this is how the world work - we should be able to do the same with 
Pharo, not run away and kill every feature that does a network call.

> On 06 Jul 2016, at 18:14, stepharo  wrote:
> 
> Who vote to put it in?
> 
> Seriously I think that my main concern is about getting Pharo stable in any 
> occasion and not giving
> 
> a bad impression of the system. I takes enough time to build traction and 
> such glitches can spoil
> 
> our effort in no time. "Yes Pharo froze."
> 
> So it would be nice to care take of such aspect.
> 
> I do not understand why super users do not manage to put a reference to on in 
> the preferences.
> 
> Sorry esteban but I do not buy your argument that something off is remove. No 
> it is off.
> 
> Stef
>>> On 06 Jul 2016, at 09:52, GitHub  wrote:
>>> 
>>> 18674 Turn spotter catalog off by default
>>> https://pharo.fogbugz.com/f/cases/18674
>> We did not agree on this, at all, there was no public discussion, no vote.
>> 
>> 
> 
>

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

2016-07-06 Thread stepharo 

Who vote to put it in?

Seriously I think that my main concern is about getting Pharo stable in 
any occasion and not giving


a bad impression of the system. I takes enough time to build traction 
and such glitches can spoil


our effort in no time. "Yes Pharo froze."

So it would be nice to care take of such aspect.

I do not understand why super users do not manage to put a reference to 
on in the preferences.


Sorry esteban but I do not buy your argument that something off is 
remove. No it is off.


Stef

On 06 Jul 2016, at 09:52, GitHub  wrote:

18674 Turn spotter catalog off by default
https://pharo.fogbugz.com/f/cases/18674

We did not agree on this, at all, there was no public discussion, no vote.

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

2016-07-06 Thread Sven Van Caekenberghe 

> On 06 Jul 2016, at 13:51, Andrei Chis  wrote:
> 
> 
> On Wed, Jul 6, 2016 at 12:28 PM, Esteban Lorenzano  
> wrote:
> yes, I do not agree either but is true there where problems.
> but IMO this would be solved just by putting a timeout in 1-2s (and then run 
> in background, and cache results)
> not turning it off.
> in for my experience, turning something off is equivalent to remove the 
> feature (but then is worst, because it becomes dead code inside image).
> 
> This is how it's currently implemented but it doesn't solve all issues:
> https://pharo.fogbugz.com/f/cases/18281/NetNameResolver-class-addressForName-sometimes-hangs-when-there-is-no-network

Yes, that is the core issue. 

We need a reliable, non-blocking way to determine (or discover) if we have 
network or not.

Then we can react properly at the application level.

> Anyway, any taker, to solve this in a proper way?
> 
> Esteban
> 
> > On 06 Jul 2016, at 12:13, Marcus Denker  wrote:
> >
> >
> >> On 06 Jul 2016, at 10:12, Sven Van Caekenberghe  wrote:
> >>
> >>
> >>> On 06 Jul 2016, at 09:52, GitHub  wrote:
> >>>
> >>> 18674 Turn spotter catalog off by default
> >>> https://pharo.fogbugz.com/f/cases/18674
> >>
> >> We did not agree on this, at all, there was no public discussion, no vote.
> >>
> >
> > I only know that there where problems.
> >
> >   Marcus
> >
> 
> 
>

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

2016-07-06 Thread Andrei Chis 
On Wed, Jul 6, 2016 at 12:28 PM, Esteban Lorenzano 
wrote:

> yes, I do not agree either but is true there where problems.
> but IMO this would be solved just by putting a timeout in 1-2s (and then
> run in background, and cache results)
> not turning it off.
> in for my experience, turning something off is equivalent to remove the
> feature (but then is worst, because it becomes dead code inside image).
>

This is how it's currently implemented but it doesn't solve all issues:
https://pharo.fogbugz.com/f/cases/18281/NetNameResolver-class-addressForName-sometimes-hangs-when-there-is-no-network


>
> Anyway, any taker, to solve this in a proper way?
>
> Esteban
>
> > On 06 Jul 2016, at 12:13, Marcus Denker  wrote:
> >
> >
> >> On 06 Jul 2016, at 10:12, Sven Van Caekenberghe  wrote:
> >>
> >>
> >>> On 06 Jul 2016, at 09:52, GitHub  wrote:
> >>>
> >>> 18674 Turn spotter catalog off by default
> >>> https://pharo.fogbugz.com/f/cases/18674
> >>
> >> We did not agree on this, at all, there was no public discussion, no
> vote.
> >>
> >
> > I only know that there where problems.
> >
> >   Marcus
> >
>
>
>

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

2016-07-06 Thread Esteban Lorenzano 
yes, I do not agree either but is true there where problems. 
but IMO this would be solved just by putting a timeout in 1-2s (and then run in 
background, and cache results) 
not turning it off. 
in for my experience, turning something off is equivalent to remove the feature 
(but then is worst, because it becomes dead code inside image).

Anyway, any taker, to solve this in a proper way? 

Esteban

> On 06 Jul 2016, at 12:13, Marcus Denker  wrote:
> 
> 
>> On 06 Jul 2016, at 10:12, Sven Van Caekenberghe  wrote:
>> 
>> 
>>> On 06 Jul 2016, at 09:52, GitHub  wrote:
>>> 
>>> 18674 Turn spotter catalog off by default
>>> https://pharo.fogbugz.com/f/cases/18674
>> 
>> We did not agree on this, at all, there was no public discussion, no vote.
>> 
> 
> I only know that there where problems.
> 
>   Marcus
>

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

2016-07-06 Thread Marcus Denker 

> On 06 Jul 2016, at 10:12, Sven Van Caekenberghe  wrote:
> 
> 
>> On 06 Jul 2016, at 09:52, GitHub  wrote:
>> 
>> 18674 Turn spotter catalog off by default
>>  https://pharo.fogbugz.com/f/cases/18674
> 
> We did not agree on this, at all, there was no public discussion, no vote.
> 

I only know that there where problems.

Marcus

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

2016-07-06 Thread Sven Van Caekenberghe 

> On 06 Jul 2016, at 09:52, GitHub  wrote:
> 
> 18674 Turn spotter catalog off by default
>   https://pharo.fogbugz.com/f/cases/18674

We did not agree on this, at all, there was no public discussion, no vote.

[Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

2016-07-06 Thread GitHub 
  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: ec7b0efd3372758bb785c059576ee2264986477b
  
https://github.com/pharo-project/pharo-core/commit/ec7b0efd3372758bb785c059576ee2264986477b
  Author: Jenkins Build Server 
  Date:   2016-07-06 (Wed, 06 Jul 2016)

  Changed paths:
M 
Epicea.package/EpClassRemoval.class/instance/accessing/behaviorAffectedName.st
M Epicea.package/extension/Class/instance/asEpiceaRingDefinition.st
M 
Graphics-Canvas.package/FormCanvas.class/instance/other/warpFrom_toRect_.st
M Graphics-Display 
Objects.package/Form.class/instance/analyzing/rectangleEnclosingPixelsNotOfColor_.st
M Graphics-Display Objects.package/Form.class/instance/scaling%2C 
rotation/magnify_by_smoothing_.st
M Graphics-Primitives.package/BitBlt.class/class/deprecated/current.st
M 
OpalCompiler-Core.package/DebuggerMethodMapOpal.class/instance/public/tempNamed_in_.st
M 
OpalCompiler-Core.package/DebuggerMethodMapOpal.class/instance/public/tempNamed_in_put_.st
M 
OpalCompiler-Core.package/DebuggerMethodMapOpal.class/instance/public/tempNamesForContext_.st
A OpalCompiler-Tests.package/OCContextTempMappingTest.class/instance/test - 
block arguments/testAccessingBlockArgumentNoneOptimizedBlock.st
A OpalCompiler-Tests.package/OCContextTempMappingTest.class/instance/test - 
block arguments/testAccessingBlockArgumentOptimizedBlock.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60136.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60137.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60136.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60137.st
M 
ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  60137
18690 deprecated BitBlt class>>#current
https://pharo.fogbugz.com/f/cases/18690

17434 debugger missing block local var for optimized blocks
https://pharo.fogbugz.com/f/cases/17434

18674 Turn spotter catalog off by default
https://pharo.fogbugz.com/f/cases/18674

18608 Impossible to delete a class
https://pharo.fogbugz.com/f/cases/18608

http://files.pharo.org/image/60/60137.zip