Re: [Pharo-dev] Catalog projects in Spotter

[stepharong]

On Fri, 10 Mar 2017 20:38:27 +0100, Nicolai Hess   
wrote:





2017-03-10 20:18 GMT+01:00 stepharong :

Torsten

Why are you full of bad energy?
Having a setting is perfectly ok. Why all this bad energy.


The problem is not having a setting, the problem is to have *two*  
distinct settings for the same thing.


Yes and this can be fixed to have only one.
I do not see the problem.
And I'm in favor to have one and I was never against it.

Stef







Do you think that this is nice to hear that I push solution for fucking  
african idiots?

I spent so much time writing and producing solutions for newbies.
I just spent three months fixing the Pharo by example book and THIS IS  
NOT MY JOB.
Do you think that writing a full mooc that we can use to promote Pharo  
all over the world
is not important? I was not in the mood to write it. For my CV a mooc  
is nothing.

Zero impact.
You see when people evaluate my CV I got feedback like
   "stephane is a brillant researcher but he is focusing too much  
on poor languages."

And many other things.
So now you can be aggressive and pissed. I decided long time ago that I  
do Pharo for positive

energy. Now if you do not like what I'm doing I cannot do much.

Stef





Uko wrote:
If there is a rule not to duplicate preferences, why is catalog not  
following it?


Because at the time when I implemented it for catalog there was no  
other setting.


The enabling/disabling for all GT extension was introduced later. Also  
the confusing
default was introduced later (with the more hidden spotter extension  
disabled and

leaving the Catalog setting enabled) leading to this whole mess.

To be honest I dont care or respond anymore on the whole issue because  
as we now know from

the long discussion the only outcome is that:


 - most of us should be knowledgable enough to know that two settings  
exist
 - most of us should become experts in fixing deficencies with startup  
scripts
 - most of us should accept that we have to hide features as deep as  
possible in the settings tree
 - most of us should accept that we have to make it as complicated as  
possible to load catalog projects
 - most of us should accept that we can display and access anything in  
spotter except catalog projects
 - most of us should accept that Pharo videos get broken and never  
match reality

 - most of us should continue to "rest in their comfort zone"
 - most of us should continue to be "an egoist instead of being an  
adult"
 - most of us should be allowed to speak up only when they presented  
Pharo at a university

 - most of us should start working with slow networks


Fixing it by removing Spotter and Catalog completely from Pharo would  
possibly be the

best solution. Anyone up for a slice?

Bye
T.




--Using Opera's mail client: http://www.opera.com/mail/







--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-dev] Catalog projects in Spotter

[Nicolai Hess]

2017-03-10 20:18 GMT+01:00 stepharong :

> Torsten
>
> Why are you full of bad energy?
> Having a setting is perfectly ok. Why all this bad energy.
>

The problem is not having a setting, the problem is to have *two* distinct
settings for the same thing.


>
> Do you think that this is nice to hear that I push solution for fucking
> african idiots?
> I spent so much time writing and producing solutions for newbies.
> I just spent three months fixing the Pharo by example book and THIS IS NOT
> MY JOB.
> Do you think that writing a full mooc that we can use to promote Pharo all
> over the world
> is not important? I was not in the mood to write it. For my CV a mooc is
> nothing.
> Zero impact.
> You see when people evaluate my CV I got feedback like
> "stephane is a brillant researcher but he is focusing too much on
> poor languages."
> And many other things.
> So now you can be aggressive and pissed. I decided long time ago that I do
> Pharo for positive
> energy. Now if you do not like what I'm doing I cannot do much.
>
> Stef
>
>
>
>
> Uko wrote:
>>
>>> If there is a rule not to duplicate preferences, why is catalog not
>>> following it?
>>>
>>
>> Because at the time when I implemented it for catalog there was no other
>> setting.
>>
>> The enabling/disabling for all GT extension was introduced later. Also
>> the confusing
>> default was introduced later (with the more hidden spotter extension
>> disabled and
>> leaving the Catalog setting enabled) leading to this whole mess.
>>
>> To be honest I dont care or respond anymore on the whole issue because as
>> we now know from
>> the long discussion the only outcome is that:
>>
>> 
>>   - most of us should be knowledgable enough to know that two settings
>> exist
>>   - most of us should become experts in fixing deficencies with startup
>> scripts
>>   - most of us should accept that we have to hide features as deep as
>> possible in the settings tree
>>   - most of us should accept that we have to make it as complicated as
>> possible to load catalog projects
>>   - most of us should accept that we can display and access anything in
>> spotter except catalog projects
>>   - most of us should accept that Pharo videos get broken and never match
>> reality
>>   - most of us should continue to "rest in their comfort zone"
>>   - most of us should continue to be "an egoist instead of being an adult"
>>   - most of us should be allowed to speak up only when they presented
>> Pharo at a university
>>   - most of us should start working with slow networks
>> 
>>
>> Fixing it by removing Spotter and Catalog completely from Pharo would
>> possibly be the
>> best solution. Anyone up for a slice?
>>
>> Bye
>> T.
>>
>>
>
> --
> Using Opera's mail client: http://www.opera.com/mail/
>
>

Re: [Pharo-dev] Catalog projects in Spotter

[stepharong]

Torsten

Why are you full of bad energy?
Having a setting is perfectly ok. Why all this bad energy.

Do you think that this is nice to hear that I push solution for fucking  
african idiots?

I spent so much time writing and producing solutions for newbies.
I just spent three months fixing the Pharo by example book and THIS IS NOT  
MY JOB.
Do you think that writing a full mooc that we can use to promote Pharo all  
over the world
is not important? I was not in the mood to write it. For my CV a mooc is  
nothing.

Zero impact.
You see when people evaluate my CV I got feedback like
	"stephane is a brillant researcher but he is focusing too much on poor  
languages."

And many other things.
So now you can be aggressive and pissed. I decided long time ago that I do  
Pharo for positive

energy. Now if you do not like what I'm doing I cannot do much.

Stef




Uko wrote:
If there is a rule not to duplicate preferences, why is catalog not  
following it?


Because at the time when I implemented it for catalog there was no other  
setting.


The enabling/disabling for all GT extension was introduced later. Also  
the confusing
default was introduced later (with the more hidden spotter extension  
disabled and

leaving the Catalog setting enabled) leading to this whole mess.

To be honest I dont care or respond anymore on the whole issue because  
as we now know from

the long discussion the only outcome is that:


  - most of us should be knowledgable enough to know that two settings  
exist
  - most of us should become experts in fixing deficencies with startup  
scripts
  - most of us should accept that we have to hide features as deep as  
possible in the settings tree
  - most of us should accept that we have to make it as complicated as  
possible to load catalog projects
  - most of us should accept that we can display and access anything in  
spotter except catalog projects
  - most of us should accept that Pharo videos get broken and never  
match reality

  - most of us should continue to "rest in their comfort zone"
  - most of us should continue to be "an egoist instead of being an  
adult"
  - most of us should be allowed to speak up only when they presented  
Pharo at a university

  - most of us should start working with slow networks


Fixing it by removing Spotter and Catalog completely from Pharo would  
possibly be the

best solution. Anyone up for a slice?

Bye
T.




--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-dev] Catalog projects in Spotter

[Sven Van Caekenberghe]

I understand, Torten, but we wil get there, one day.

> On 9 Mar 2017, at 23:04, Torsten Bergmann  wrote:
> 
> Uko wrote:
>> If there is a rule not to duplicate preferences, why is catalog not 
>> following it?
> 
> Because at the time when I implemented it for catalog there was no other 
> setting. 
> 
> The enabling/disabling for all GT extension was introduced later. Also the 
> confusing 
> default was introduced later (with the more hidden spotter extension disabled 
> and 
> leaving the Catalog setting enabled) leading to this whole mess.
> 
> To be honest I dont care or respond anymore on the whole issue because as we 
> now know from
> the long discussion the only outcome is that:
> 
> 
>  - most of us should be knowledgable enough to know that two settings exist
>  - most of us should become experts in fixing deficencies with startup scripts
>  - most of us should accept that we have to hide features as deep as possible 
> in the settings tree
>  - most of us should accept that we have to make it as complicated as 
> possible to load catalog projects
>  - most of us should accept that we can display and access anything in 
> spotter except catalog projects
>  - most of us should accept that Pharo videos get broken and never match 
> reality
>  - most of us should continue to "rest in their comfort zone" 
>  - most of us should continue to be "an egoist instead of being an adult" 
>  - most of us should be allowed to speak up only when they presented Pharo at 
> a university
>  - most of us should start working with slow networks
> 
> 
> Fixing it by removing Spotter and Catalog completely from Pharo would 
> possibly be the 
> best solution. Anyone up for a slice? 
> 
> Bye
> T.
> 

Re: [Pharo-dev] Catalog projects in Spotter

[Torsten Bergmann]

Uko wrote:
>If there is a rule not to duplicate preferences, why is catalog not following 
>it?

Because at the time when I implemented it for catalog there was no other 
setting. 

The enabling/disabling for all GT extension was introduced later. Also the 
confusing 
default was introduced later (with the more hidden spotter extension disabled 
and 
leaving the Catalog setting enabled) leading to this whole mess.

To be honest I dont care or respond anymore on the whole issue because as we 
now know from
the long discussion the only outcome is that:


  - most of us should be knowledgable enough to know that two settings exist
  - most of us should become experts in fixing deficencies with startup scripts
  - most of us should accept that we have to hide features as deep as possible 
in the settings tree
  - most of us should accept that we have to make it as complicated as possible 
to load catalog projects
  - most of us should accept that we can display and access anything in spotter 
except catalog projects
  - most of us should accept that Pharo videos get broken and never match 
reality
  - most of us should continue to "rest in their comfort zone" 
  - most of us should continue to be "an egoist instead of being an adult" 
  - most of us should be allowed to speak up only when they presented Pharo at 
a university
  - most of us should start working with slow networks


Fixing it by removing Spotter and Catalog completely from Pharo would possibly 
be the 
best solution. Anyone up for a slice? 

Bye
T.

Re: [Pharo-dev] Catalog projects in Spotter

[Yuriy Tymchuk]

Hi,

yes, I know that the Spotter checkbox is a generic implementation and it is 
really cool. My point(s) is (are):

1) why are the checkboxes out of sync? When I added a checkbox to disable the 
QA Spotter plugin from within the QA settings, I reused spotters functionality, 
so enabling or disabling with change the status of both checkboxes and you 
don’t have to enable the functionality twice.
2) why are there 2 checkboxes? Because Esteban told me that it is confusing 
that when you search for critiques in settings you get duplicated results. 
That’s why I removed my other checkbox and rely only on Spotter settings. If 
there is a rule not to duplicate preferences, why is catalog not following it?

Uko

> On 9 Mar 2017, at 15:27, Tudor Girba  wrote:
> 
> Hi,
> 
>> On Mar 9, 2017, at 3:22 PM, Yuriy Tymchuk > > wrote:
>> 
>> Yes, you are right Sven.
>> 
>> When I disable network the Spotter is not freezing. Do we have a way to do 
>> the DNS resolution asynchronously? I mean, is it doable in Pharo 7 or it is 
>> a big problem. I’m not an expert in the questions that require VM, but it 
>> seams that http requests can be executed without blocking the UI thread, is 
>> it possible to resolve DNS in the same way?
>> 
>> Uko
>> 
>> P.S. why there are TWO checkboxes in Settings for the catalog plugin in 
>> Spotter? And they are not synchronized by the way, so you need to turn on 
>> both.
> 
> Each spotter extension comes with checkbox to disable them. This is a generic 
> mechanism that is important for cases when people want to replace an existing 
> extension with another variation. For example, people might have different 
> preferred strategies to search for implementors (e.g., also search for class 
> names).
> 
> Cheers,
> Doru
> 
> 
>> 
>> 
>>> On 9 Mar 2017, at 09:41, Sven Van Caekenberghe  wrote:
>>> 
>>> Guys,
>>> 
>>> Please stop speculating, no it is not Monticello, no it is not HTTP access, 
>>> no it is not networking itself, it is DNS resolution, in a very specific 
>>> situation:
>>> 
>>> https://pharo.fogbugz.com/f/cases/18281/NetNameResolver-class-addressForName-sometimes-hangs-when-there-is-no-network
>>> 
>>> Note also that many, many people deploy Pharo in production contexts with 
>>> heavy multi threading and networking loads with great success - that would 
>>> not be possible if we did not get the basics right.
>>> 
>>> Sven
>>> 
 On 9 Mar 2017, at 09:31, Yuriy Tymchuk  wrote:
 
 Dimitris,
 
 but AFAIK when Spotter freezes it’s not using Metacello. It does an http 
 request to pharo catalog. Isn’t this a problem with http request blocking 
 the only thread that we have?
 
 Uko
 
> On 9 Mar 2017, at 08:23, Dimitris Chloupis  wrote:
> 
> I do not need to, the problem is obvious as the sun when one uses 
> Monticello which can easily freeze the image on a slow connection. Still 
> it's a Monticello problem, not a Pharo problem. But then that's not the 
> most serious problem with Monticello. 
> 
> On Tue, 7 Mar 2017 at 17:04, p...@highoctane.be  
> wrote:
> I see you are not teaching to people or running demos in a crowd with 
> Pharo.
> 
> Otherwise, you would get the point I can tell you 100%
> 
> Phil
> 
> On Tue, Mar 7, 2017 at 3:19 PM, Dimitris Chloupis  
> wrote:
> Frankly I fail to see the problem, if a tool connects to the internet and 
> does not have some sort of timeout or speed check then is the obligation 
> of the tool to fix that and not of Pharo to offer an airplane mode. Its 
> would make an already complex pharo environment even more complex. Not to 
> exclude the fact that having two mode will create useless confusion for 
> beginners. 
> 
> Offer a new mode for Pharo ? No
> Offer methods that check internet connectivity and internet speed for 
> pharo tool developers to use ? Yes
> 
> I feel that Pharo can be simplified down to 1% without the need for a big 
> compromise on features. Maybe it does not matter for us that are used to 
> working with Blender but its a huge deal for beginners and if we want to 
> attract a lot more new users. 
> 
> My dream is that version 8 be dedicated ONLY to simplifying the Pharo 
> code, by removing all the extra fat. No new bug fixes (unless created by 
> the removal of the code), no new features. I know we have bootstrap , but 
> thats a completely different thing.
> 
> On Tue, Mar 7, 2017 at 3:15 PM p...@highoctane.be  
> wrote:
> https://pharo.fogbugz.com/f/cases/19818/Support-for-Airplane-mode-in-Pharo
>  for keeping track of this
> 
> On Tue, Mar 7, 2017 at 1:02 AM, Ben Coman  wrote:
> On 

Re: [Pharo-dev] Catalog projects in Spotter

[Tudor Girba]

Hi,

> On Mar 9, 2017, at 3:22 PM, Yuriy Tymchuk  wrote:
> 
> Yes, you are right Sven.
> 
> When I disable network the Spotter is not freezing. Do we have a way to do 
> the DNS resolution asynchronously? I mean, is it doable in Pharo 7 or it is a 
> big problem. I’m not an expert in the questions that require VM, but it seams 
> that http requests can be executed without blocking the UI thread, is it 
> possible to resolve DNS in the same way?
> 
> Uko
> 
> P.S. why there are TWO checkboxes in Settings for the catalog plugin in 
> Spotter? And they are not synchronized by the way, so you need to turn on 
> both.

Each spotter extension comes with checkbox to disable them. This is a generic 
mechanism that is important for cases when people want to replace an existing 
extension with another variation. For example, people might have different 
preferred strategies to search for implementors (e.g., also search for class 
names).

Cheers,
Doru


> 
> 
>> On 9 Mar 2017, at 09:41, Sven Van Caekenberghe  wrote:
>> 
>> Guys,
>> 
>> Please stop speculating, no it is not Monticello, no it is not HTTP access, 
>> no it is not networking itself, it is DNS resolution, in a very specific 
>> situation:
>> 
>> https://pharo.fogbugz.com/f/cases/18281/NetNameResolver-class-addressForName-sometimes-hangs-when-there-is-no-network
>> 
>> Note also that many, many people deploy Pharo in production contexts with 
>> heavy multi threading and networking loads with great success - that would 
>> not be possible if we did not get the basics right.
>> 
>> Sven
>> 
>>> On 9 Mar 2017, at 09:31, Yuriy Tymchuk  wrote:
>>> 
>>> Dimitris,
>>> 
>>> but AFAIK when Spotter freezes it’s not using Metacello. It does an http 
>>> request to pharo catalog. Isn’t this a problem with http request blocking 
>>> the only thread that we have?
>>> 
>>> Uko
>>> 
 On 9 Mar 2017, at 08:23, Dimitris Chloupis  wrote:
 
 I do not need to, the problem is obvious as the sun when one uses 
 Monticello which can easily freeze the image on a slow connection. Still 
 it's a Monticello problem, not a Pharo problem. But then that's not the 
 most serious problem with Monticello. 
 
 On Tue, 7 Mar 2017 at 17:04, p...@highoctane.be  wrote:
 I see you are not teaching to people or running demos in a crowd with 
 Pharo.
 
 Otherwise, you would get the point I can tell you 100%
 
 Phil
 
 On Tue, Mar 7, 2017 at 3:19 PM, Dimitris Chloupis  
 wrote:
 Frankly I fail to see the problem, if a tool connects to the internet and 
 does not have some sort of timeout or speed check then is the obligation 
 of the tool to fix that and not of Pharo to offer an airplane mode. Its 
 would make an already complex pharo environment even more complex. Not to 
 exclude the fact that having two mode will create useless confusion for 
 beginners. 
 
 Offer a new mode for Pharo ? No
 Offer methods that check internet connectivity and internet speed for 
 pharo tool developers to use ? Yes
 
 I feel that Pharo can be simplified down to 1% without the need for a big 
 compromise on features. Maybe it does not matter for us that are used to 
 working with Blender but its a huge deal for beginners and if we want to 
 attract a lot more new users. 
 
 My dream is that version 8 be dedicated ONLY to simplifying the Pharo 
 code, by removing all the extra fat. No new bug fixes (unless created by 
 the removal of the code), no new features. I know we have bootstrap , but 
 thats a completely different thing. 
 
 On Tue, Mar 7, 2017 at 3:15 PM p...@highoctane.be  
 wrote:
 https://pharo.fogbugz.com/f/cases/19818/Support-for-Airplane-mode-in-Pharo 
 for keeping track of this
 
 On Tue, Mar 7, 2017 at 1:02 AM, Ben Coman  wrote:
 On Tue, Mar 7, 2017 at 6:35 AM, p...@highoctane.be  
 wrote:
> This is not only when teaching.
> 
> I was at a conference today and showcased some Grafoscopio.
> 
> Spotty wifi and crowded bandwith makes it bad looking.
> 
> We need an "Airplane mode" switch.
 
 That is a cool way to describe it.  A well know paradigm.
 Its a setting that probably would change daya to day more than any other,
 so perhaps it would even be reasonable to have this as a permanent
 mode button on the background,
 or the task bar much like MS Windows taskbar status icons.
 
 cheers -ben
 
> 
> Maybe can we have that available in the session from the settings.
> 
> Phil
> 
> On Mon, Mar 6, 2017 at 10:55 PM, Yuriy Tymchuk  
> wrote:
>> 
>> The problem is that there are people who give lectures in universities

Re: [Pharo-dev] Catalog projects in Spotter

[Yuriy Tymchuk]

Yes, you are right Sven.

When I disable network the Spotter is not freezing. Do we have a way to do the 
DNS resolution asynchronously? I mean, is it doable in Pharo 7 or it is a big 
problem. I’m not an expert in the questions that require VM, but it seams that 
http requests can be executed without blocking the UI thread, is it possible to 
resolve DNS in the same way?

Uko

P.S. why there are TWO checkboxes in Settings for the catalog plugin in 
Spotter? And they are not synchronized by the way, so you need to turn on both.



> On 9 Mar 2017, at 09:41, Sven Van Caekenberghe  wrote:
> 
> Guys,
> 
> Please stop speculating, no it is not Monticello, no it is not HTTP access, 
> no it is not networking itself, it is DNS resolution, in a very specific 
> situation:
> 
> https://pharo.fogbugz.com/f/cases/18281/NetNameResolver-class-addressForName-sometimes-hangs-when-there-is-no-network
> 
> Note also that many, many people deploy Pharo in production contexts with 
> heavy multi threading and networking loads with great success - that would 
> not be possible if we did not get the basics right.
> 
> Sven
> 
>> On 9 Mar 2017, at 09:31, Yuriy Tymchuk  wrote:
>> 
>> Dimitris,
>> 
>> but AFAIK when Spotter freezes it’s not using Metacello. It does an http 
>> request to pharo catalog. Isn’t this a problem with http request blocking 
>> the only thread that we have?
>> 
>> Uko
>> 
>>> On 9 Mar 2017, at 08:23, Dimitris Chloupis  wrote:
>>> 
>>> I do not need to, the problem is obvious as the sun when one uses 
>>> Monticello which can easily freeze the image on a slow connection. Still 
>>> it's a Monticello problem, not a Pharo problem. But then that's not the 
>>> most serious problem with Monticello. 
>>> 
>>> On Tue, 7 Mar 2017 at 17:04, p...@highoctane.be  wrote:
>>> I see you are not teaching to people or running demos in a crowd with Pharo.
>>> 
>>> Otherwise, you would get the point I can tell you 100%
>>> 
>>> Phil
>>> 
>>> On Tue, Mar 7, 2017 at 3:19 PM, Dimitris Chloupis  
>>> wrote:
>>> Frankly I fail to see the problem, if a tool connects to the internet and 
>>> does not have some sort of timeout or speed check then is the obligation of 
>>> the tool to fix that and not of Pharo to offer an airplane mode. Its would 
>>> make an already complex pharo environment even more complex. Not to exclude 
>>> the fact that having two mode will create useless confusion for beginners. 
>>> 
>>> Offer a new mode for Pharo ? No
>>> Offer methods that check internet connectivity and internet speed for pharo 
>>> tool developers to use ? Yes
>>> 
>>> I feel that Pharo can be simplified down to 1% without the need for a big 
>>> compromise on features. Maybe it does not matter for us that are used to 
>>> working with Blender but its a huge deal for beginners and if we want to 
>>> attract a lot more new users. 
>>> 
>>> My dream is that version 8 be dedicated ONLY to simplifying the Pharo code, 
>>> by removing all the extra fat. No new bug fixes (unless created by the 
>>> removal of the code), no new features. I know we have bootstrap , but thats 
>>> a completely different thing. 
>>> 
>>> On Tue, Mar 7, 2017 at 3:15 PM p...@highoctane.be  
>>> wrote:
>>> https://pharo.fogbugz.com/f/cases/19818/Support-for-Airplane-mode-in-Pharo 
>>> for keeping track of this
>>> 
>>> On Tue, Mar 7, 2017 at 1:02 AM, Ben Coman  wrote:
>>> On Tue, Mar 7, 2017 at 6:35 AM, p...@highoctane.be  
>>> wrote:
 This is not only when teaching.
 
 I was at a conference today and showcased some Grafoscopio.
 
 Spotty wifi and crowded bandwith makes it bad looking.
 
 We need an "Airplane mode" switch.
>>> 
>>> That is a cool way to describe it.  A well know paradigm.
>>> Its a setting that probably would change daya to day more than any other,
>>> so perhaps it would even be reasonable to have this as a permanent
>>> mode button on the background,
>>> or the task bar much like MS Windows taskbar status icons.
>>> 
>>> cheers -ben
>>> 
 
 Maybe can we have that available in the session from the settings.
 
 Phil
 
 On Mon, Mar 6, 2017 at 10:55 PM, Yuriy Tymchuk  
 wrote:
> 
> The problem is that there are people who give lectures in universities
> with bad internet (internet is bad in most of the universities I tried) 
> and
> they done want freezes. On the other hand we have people who sit in their
> offices with fast machines, fast internet and they want features. Until 
> now
> we were looking at how to satisfy one of the groups and which one exactly.
> Why not to try finding a solution for both. For example we can have the
> plugging enabled by default and have Spotter measuring the time needed to 
> do
> a query. Whenever the time surpasses frustration