Catalog loading in Spotter
In the past in Pharo it was possible to open Spotter, type in the name of a framework/project to load from catalog, perform a search and just hit ENTER to easily install the project. This was following the Spotter idea that it is easy to access most informations of Pharo with the Spotter tool. There always was and still is a setting in "Settings" -> "Catalog" -> "Display catalog projects in Spotter". This setting is ENABLED BY DEFAULT but could be switched off in the settings tool or custom preference scripts if this is problematic for someone. Now in Pharo 6 there is an additional class "GTSpotterExtensionSettings" to activate/deactivate Spotter extensions. While nearly all of the Spotter extensions are enabled the one for the catalog integration is DISABLED BY DEFAULT. This leads to several effects: 1. While in the past it was possible in a fresh Pharo image to search and install out of the box it is (as of today in the not yet released Pharo 6) not possible anymore to quickly start by searching and installing from catalog using Spotter. 2. It is very confusing that in the settings "Display catalog projects in Spotter" is enabled but a search in Spotter gives no results. Most people will not not know about the second setting and easily get lost and think this behavior is just broken. Also this second setting for the Spotter extension is much more hidden between all the other Spotter extension enablements very and hard to find. 3. Several of my youtube videos demonstrating Goodies like DesktopManager, QuickAccess, MessageFlowBrowser, ... directly start by loading the tools from Spotter. Anyone newbee who will follow these will not only be confused - but also stuck in trying Pharo when he learns from these videos. I was asked several times on Slack and via Mail from people who were not able to reproduce ... this is really annyoing. Especially this gives the wrong impression to newbees. Things should be easy not complicated. To my knowledge disabling the Spotter search in Pharo 6 came up due to some Pharo teaching in regions with slow internet connection. I understand that we would like to support these Pharo users too as best as possible in their out of the box experience ... but (without being able to prove) I think that 90% or more Pharo users have a regular internet connection. Otherwise it would be hard to work with updates, project loading, PharoLauncher, STHub or Iceberg/GitHub. Also my own personal experience is that even on low bandwidth network this Catalog Spotter search for me was always fast enough (as I often use Pharo in trains with slow connections or on a Pi with slow connections and less processing power). I do not know about all others from the community. I invested hours in the past in developing and introducing the initial configuration browser to Pharo, later improved and helped shaping its replacement CatalogBrowser, also contributed this spotter search for the catalog items so things are more accessible, easy and enjoyable. That's why I also invested hours in udpating configs or pushing you to put things into catalog. Because accessibility is key. Only when things are easy to access and understandable people will enjoy Pharo. Currently in an out-of the box image this easy access to the projects via Spotter is blocked. Additionally I have to explain to anyone who asks me that there is a second non-obvious/more hidden setting leaving an unpleasant feeling how many others unknown to me will struggle with this issue. I see two solutions: A) We enable both settings by DEFAULT to bring back the Spotter search and installation of catalog items - with the clear benefit of having - the previous behavior in Pharo back - the out of the box ability to search for catalog projects in any fresh image - no confusion among the user base anymore regarding the settings - we have unbroken Youtube videos that newbees can continue to follow - if a user asks (like often) how to get Seaside, Artefact, Mongo, Teapot or other projects we can just tell him "search in Spotter and you should be fine" as most of them have a config in the catalog. Remember that not all of us know about all the github pages or nice Metacello expressions. So the easier things are found and accessible the better it is. B) If A is still a "No go" for the community we should at a minimum switch the defaults of the two settings: => we ENABLE the Spotter extension (GTSpotterExtensionSettings perform: #GTSpotter_spotterCatalogProjectsFor: with: true) => we DISABLE the catalog setting (CatalogSettings displayCatalogProjectsInSpotter: false) With this at least we have no confusion among the user base anymore regarding the settings. I would clearly and strongly vote for option A as my preferred one. I agree there are regions/continents with very low bandwidth - but Pharo will rival with state of the art technologies where loading/installation megabytes from the web is often not seen as an issue. There are many package registries out there (from debian packages) up to Maven, npm in JS, ... or look at Docker. Shuffling megabytes around is a reality in todays technologies. So to be honest I never understood this whole "bandwidth" discussion and even if this comes up it could be solved with a note in the download/welcome screen or pointing to a custom preference script for low bandwidth situations. Sorry for having to bring this up again ... but I would like this to be solved BEFORE Pharo 6 will be pushed out of the door. Keeping it like it is without further actions would be really stupid. Thanks for you comments, ideas or votes. Thanks T.
I understand completely, I agree and strongly vote for A as well.
On 19 Feb 2017, at 21:05, Torsten Bergmann <astares@gmx.de> wrote:
In the past in Pharo it was possible to open Spotter, type in the name of a framework/project to load from catalog, perform a search and just hit ENTER to easily install the project.
This was following the Spotter idea that it is easy to access most informations of Pharo with the Spotter tool.
There always was and still is a setting in "Settings" -> "Catalog" -> "Display catalog projects in Spotter". This setting is ENABLED BY DEFAULT but could be switched off in the settings tool or custom preference scripts if this is problematic for someone.
Now in Pharo 6 there is an additional class "GTSpotterExtensionSettings" to activate/deactivate Spotter extensions. While nearly all of the Spotter extensions are enabled the one for the catalog integration is DISABLED BY DEFAULT.
This leads to several effects:
1. While in the past it was possible in a fresh Pharo image to search and install out of the box it is (as of today in the not yet released Pharo 6) not possible anymore to quickly start by searching and installing from catalog using Spotter.
2. It is very confusing that in the settings "Display catalog projects in Spotter" is enabled but a search in Spotter gives no results. Most people will not not know about the second setting and easily get lost and think this behavior is just broken. Also this second setting for the Spotter extension is much more hidden between all the other Spotter extension enablements very and hard to find.
3. Several of my youtube videos demonstrating Goodies like DesktopManager, QuickAccess, MessageFlowBrowser, ... directly start by loading the tools from Spotter. Anyone newbee who will follow these will not only be confused - but also stuck in trying Pharo when he learns from these videos.
I was asked several times on Slack and via Mail from people who were not able to reproduce ... this is really annyoing. Especially this gives the wrong impression to newbees. Things should be easy not complicated.
To my knowledge disabling the Spotter search in Pharo 6 came up due to some Pharo teaching in regions with slow internet connection. I understand that we would like to support these Pharo users too as best as possible in their out of the box experience ... but (without being able to prove) I think that 90% or more Pharo users have a regular internet connection. Otherwise it would be hard to work with updates, project loading, PharoLauncher, STHub or Iceberg/GitHub.
Also my own personal experience is that even on low bandwidth network this Catalog Spotter search for me was always fast enough (as I often use Pharo in trains with slow connections or on a Pi with slow connections and less processing power). I do not know about all others from the community.
I invested hours in the past in developing and introducing the initial configuration browser to Pharo, later improved and helped shaping its replacement CatalogBrowser, also contributed this spotter search for the catalog items so things are more accessible, easy and enjoyable. That's why I also invested hours in udpating configs or pushing you to put things into catalog.
Because accessibility is key. Only when things are easy to access and understandable people will enjoy Pharo.
Currently in an out-of the box image this easy access to the projects via Spotter is blocked. Additionally I have to explain to anyone who asks me that there is a second non-obvious/more hidden setting leaving an unpleasant feeling how many others unknown to me will struggle with this issue.
I see two solutions:
A) We enable both settings by DEFAULT to bring back the Spotter search and installation of catalog items - with the clear benefit of having - the previous behavior in Pharo back - the out of the box ability to search for catalog projects in any fresh image - no confusion among the user base anymore regarding the settings - we have unbroken Youtube videos that newbees can continue to follow - if a user asks (like often) how to get Seaside, Artefact, Mongo, Teapot or other projects we can just tell him "search in Spotter and you should be fine" as most of them have a config in the catalog.
Remember that not all of us know about all the github pages or nice Metacello expressions. So the easier things are found and accessible the better it is.
B) If A is still a "No go" for the community we should at a minimum switch the defaults of the two settings:
=> we ENABLE the Spotter extension (GTSpotterExtensionSettings perform: #GTSpotter_spotterCatalogProjectsFor: with: true) => we DISABLE the catalog setting (CatalogSettings displayCatalogProjectsInSpotter: false)
With this at least we have no confusion among the user base anymore regarding the settings.
I would clearly and strongly vote for option A as my preferred one.
I agree there are regions/continents with very low bandwidth - but Pharo will rival with state of the art technologies where loading/installation megabytes from the web is often not seen as an issue. There are many package registries out there (from debian packages) up to Maven, npm in JS, ... or look at Docker. Shuffling megabytes around is a reality in todays technologies.
So to be honest I never understood this whole "bandwidth" discussion and even if this comes up it could be solved with a note in the download/welcome screen or pointing to a custom preference script for low bandwidth situations.
Sorry for having to bring this up again ... but I would like this to be solved BEFORE Pharo 6 will be pushed out of the door. Keeping it like it is without further actions would be really stupid.
Thanks for you comments, ideas or votes.
Thanks T.
A. Phil On Sun, Feb 19, 2017 at 10:40 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I understand completely, I agree and strongly vote for A as well.
On 19 Feb 2017, at 21:05, Torsten Bergmann <astares@gmx.de> wrote:
In the past in Pharo it was possible to open Spotter, type in the name of a framework/project to load from catalog, perform a search and just hit ENTER to easily install the project.
This was following the Spotter idea that it is easy to access most informations of Pharo with the Spotter tool.
There always was and still is a setting in "Settings" -> "Catalog" -> "Display catalog projects in Spotter". This setting is ENABLED BY DEFAULT but could be switched off in the settings tool or custom preference scripts if this is problematic for someone.
Now in Pharo 6 there is an additional class "GTSpotterExtensionSettings" to activate/deactivate Spotter extensions. While nearly all of the Spotter extensions are enabled the one for the catalog integration is DISABLED BY DEFAULT.
This leads to several effects:
1. While in the past it was possible in a fresh Pharo image to search and install out of the box it is (as of today in the not yet released Pharo 6) not possible anymore to quickly start by searching and installing from catalog using Spotter.
2. It is very confusing that in the settings "Display catalog projects in Spotter" is enabled but a search in Spotter gives no results. Most people will not not know about the second setting and easily get lost and think this behavior is just broken. Also this second setting for the Spotter extension is much more hidden between all the other Spotter extension enablements very and hard to find.
3. Several of my youtube videos demonstrating Goodies like DesktopManager, QuickAccess, MessageFlowBrowser, ... directly start by loading the tools from Spotter. Anyone newbee who will follow these will not only be confused - but also stuck in trying Pharo when he learns from these videos.
I was asked several times on Slack and via Mail from people who were not able to reproduce ... this is really annyoing. Especially this gives the wrong impression to newbees. Things should be easy not complicated.
To my knowledge disabling the Spotter search in Pharo 6 came up due to some Pharo teaching in regions with slow internet connection. I understand that we would like to support these Pharo users too as best as possible in their out of the box experience ... but (without being able to prove) I think that 90% or more Pharo users have a regular internet connection. Otherwise it would be hard to work with updates, project loading, PharoLauncher, STHub or Iceberg/GitHub.
Also my own personal experience is that even on low bandwidth network this Catalog Spotter search for me was always fast enough (as I often use Pharo in trains with slow connections or on a Pi with slow connections and less processing power). I do not know about all others from the community.
I invested hours in the past in developing and introducing the initial configuration browser to Pharo, later improved and helped shaping its replacement CatalogBrowser, also contributed this spotter search for the catalog items so things are more accessible, easy and enjoyable. That's why I also invested hours in udpating configs or pushing you to put things into catalog.
Because accessibility is key. Only when things are easy to access and understandable people will enjoy Pharo.
Currently in an out-of the box image this easy access to the projects via Spotter is blocked. Additionally I have to explain to anyone who asks me that there is a second non-obvious/more hidden setting leaving an unpleasant feeling how many others unknown to me will struggle with this issue.
I see two solutions:
A) We enable both settings by DEFAULT to bring back the Spotter search and installation of catalog items - with the clear benefit of having - the previous behavior in Pharo back - the out of the box ability to search for catalog projects in any fresh image - no confusion among the user base anymore regarding the settings - we have unbroken Youtube videos that newbees can continue to follow - if a user asks (like often) how to get Seaside, Artefact, Mongo, Teapot or other projects we can just tell him "search in Spotter and you should be fine" as most of them have a config in the catalog.
Remember that not all of us know about all the github pages or nice Metacello expressions. So the easier things are found and accessible the better it is.
B) If A is still a "No go" for the community we should at a minimum switch the defaults of the two settings:
=> we ENABLE the Spotter extension (GTSpotterExtensionSettings perform: #GTSpotter_spotterCatalogProjectsFor: with: true) => we DISABLE the catalog setting (CatalogSettings displayCatalogProjectsInSpotter: false)
With this at least we have no confusion among the user base anymore regarding the settings.
I would clearly and strongly vote for option A as my preferred one.
I agree there are regions/continents with very low bandwidth - but Pharo will rival with state of the art technologies where loading/installation megabytes from the web is often not seen as an issue. There are many package registries out there (from debian packages) up to Maven, npm in JS, ... or look at Docker. Shuffling megabytes around is a reality in todays technologies.
So to be honest I never understood this whole "bandwidth" discussion and even if this comes up it could be solved with a note in the download/welcome screen or pointing to a custom preference script for low bandwidth situations.
Sorry for having to bring this up again ... but I would like this to be solved BEFORE Pharo 6 will be pushed out of the door. Keeping it like it is without further actions would be really stupid.
Thanks for you comments, ideas or votes.
Thanks T.
On Mon, Feb 20, 2017 at 4:05 AM, Torsten Bergmann <astares@gmx.de> wrote:
In the past in Pharo it was possible to open Spotter, type in the name of a framework/project to load from catalog, perform a search and just hit ENTER to easily install the project.
This was following the Spotter idea that it is easy to access most informations of Pharo with the Spotter tool.
There always was and still is a setting in "Settings" -> "Catalog" -> "Display catalog projects in Spotter". This setting is ENABLED BY DEFAULT but could be switched off in the settings tool or custom preference scripts if this is problematic for someone.
Now in Pharo 6 there is an additional class "GTSpotterExtensionSettings" to activate/deactivate Spotter extensions. While nearly all of the Spotter extensions are enabled the one for the catalog integration is DISABLED BY DEFAULT.
This leads to several effects:
1. While in the past it was possible in a fresh Pharo image to search and install out of the box it is (as of today in the not yet released Pharo 6) not possible anymore to quickly start by searching and installing from catalog using Spotter.
2. It is very confusing that in the settings "Display catalog projects in Spotter" is enabled but a search in Spotter gives no results. Most people will not not know about the second setting and easily get lost and think this behavior is just broken. Also this second setting for the Spotter extension is much more hidden between all the other Spotter extension enablements very and hard to find.
Generally its not good to have two settings for the one thing.
3. Several of my youtube videos demonstrating Goodies like DesktopManager, QuickAccess, MessageFlowBrowser, ... directly start by loading the tools from Spotter. Anyone newbee who will follow these will not only be confused - but also stuck in trying Pharo when he learns from these videos.
UI things do evolve and videos date. But these seem worthwhile to keep current.
I was asked several times on Slack and via Mail from people who were not able to reproduce ... this is really annyoing. Especially this gives the wrong impression to newbees. Things should be easy not complicated.
To my knowledge disabling the Spotter search in Pharo 6 came up due to some Pharo teaching in regions with slow internet connection.
This made sense at the time. It is a worse first impression if UI lags when this central part of the UI is interfaced. How often would it access the network? Every time? Or did it cache the result for a day, etc?
I understand that we would like to support these Pharo users too as best as possible in their out of the box experience ... but (without being able to prove) I think that 90% or more Pharo users have a regular internet connection. Otherwise it would be hard to work with updates, project loading, PharoLauncher, STHub or Iceberg/GitHub.
Also my own personal experience is that even on low bandwidth network this Catalog Spotter search for me was always fast enough (as I often use Pharo in trains with slow connections or on a Pi with slow connections and less processing power). I do not know about all others from the community.
I invested hours in the past in developing and introducing the initial configuration browser to Pharo, later improved and helped shaping its replacement CatalogBrowser, also contributed this spotter search for the catalog items so things are more accessible, easy and enjoyable. That's why I also invested hours in udpating configs or pushing you to put things into catalog.
Because accessibility is key. Only when things are easy to access and understandable people will enjoy Pharo.
Currently in an out-of the box image this easy access to the projects via Spotter is blocked. Additionally I have to explain to anyone who asks me that there is a second non-obvious/more hidden setting leaving an unpleasant feeling how many others unknown to me will struggle with this issue.
I see two solutions:
A) We enable both settings by DEFAULT to bring back the Spotter search and installation of catalog items - with the clear benefit of having - the previous behavior in Pharo back - the out of the box ability to search for catalog projects in any fresh image - no confusion among the user base anymore regarding the settings - we have unbroken Youtube videos that newbees can continue to follow - if a user asks (like often) how to get Seaside, Artefact, Mongo, Teapot or other projects we can just tell him "search in Spotter and you should be fine" as most of them have a config in the catalog.
Remember that not all of us know about all the github pages or nice Metacello expressions. So the easier things are found and accessible the better it is.
B) If A is still a "No go" for the community we should at a minimum switch the defaults of the two settings:
=> we ENABLE the Spotter extension (GTSpotterExtensionSettings perform: #GTSpotter_spotterCatalogProjectsFor: with: true) => we DISABLE the catalog setting (CatalogSettings displayCatalogProjectsInSpotter: false)
With this at least we have no confusion among the user base anymore regarding the settings.
C) Could a STON file of the catalog be cached in the zip of Image/Changes files? That zip might be updated daily to keep it current. Then in a fresh image Spotter searches the cached file for a instant response, while the Catalog is updated from the network in the background. Even with fast Internet the Catalog should only need to auto-update once a day, with results cached in a common file to be accessed when fresh images are started. The Spotter UI might display the last update date as part of the Catalog sub-heading in its results. cheers -ben
I would clearly and strongly vote for option A as my preferred one.
I agree there are regions/continents with very low bandwidth - but Pharo will rival with state of the art technologies where loading/installation megabytes from the web is often not seen as an issue. There are many package registries out there (from debian packages) up to Maven, npm in JS, ... or look at Docker. Shuffling megabytes around is a reality in todays technologies.
So to be honest I never understood this whole "bandwidth" discussion and even if this comes up it could be solved with a note in the download/welcome screen or pointing to a custom preference script for low bandwidth situations.
Sorry for having to bring this up again ... but I would like this to be solved BEFORE Pharo 6 will be pushed out of the door. Keeping it like it is without further actions would be really stupid.
Thanks for you comments, ideas or votes.
Thanks T.
As far as I remember, the main problem was not bandwidth but a blocking and non-responsive UI. Imagine I'm in the university, or in a company with a proxy. And I forget to set the proxy. Then, while spotter tries to fetch catalog entries, it would block the image and throw a timeout error some minutes after. So, maybe for the future and besides Ben's C option (which I like) I have a D) Load catalog entries in background in a non-blocking way - and while catalog entries are not yet available, they should not be shown Even further, It would make sense a solution that mixes Ben's caching with background loading of the catalog entries... Guille On Mon, Feb 20, 2017 at 1:03 AM, Ben Coman <btc@openinworld.com> wrote:
On Mon, Feb 20, 2017 at 4:05 AM, Torsten Bergmann <astares@gmx.de> wrote:
In the past in Pharo it was possible to open Spotter, type in the name of a framework/project to load from catalog, perform a search and just hit ENTER to easily install the project.
This was following the Spotter idea that it is easy to access most informations of Pharo with the Spotter tool.
There always was and still is a setting in "Settings" -> "Catalog" -> "Display catalog projects in Spotter". This setting is ENABLED BY DEFAULT but could be switched off in the settings tool or custom preference scripts if this is problematic for someone.
Now in Pharo 6 there is an additional class "GTSpotterExtensionSettings" to activate/deactivate Spotter extensions. While nearly all of the Spotter extensions are enabled the one for the catalog integration is DISABLED BY DEFAULT.
This leads to several effects:
1. While in the past it was possible in a fresh Pharo image to search and install out of the box it is (as of today in the not yet released Pharo 6) not possible anymore to quickly start by searching and installing from catalog using Spotter.
2. It is very confusing that in the settings "Display catalog projects in Spotter" is enabled but a search in Spotter gives no results. Most people will not not know about the second setting and easily get lost and think this behavior is just broken. Also this second setting for the Spotter extension is much more hidden between all the other Spotter extension enablements very and hard to find.
Generally its not good to have two settings for the one thing.
3. Several of my youtube videos demonstrating Goodies like
DesktopManager, QuickAccess,
MessageFlowBrowser, ... directly start by loading the tools from
Spotter. Anyone newbee who will
follow these will not only be confused - but also stuck in trying
Pharo when he learns
from these videos.
UI things do evolve and videos date. But these seem worthwhile to keep current.
I was asked several times on Slack and via Mail from people who
were not able to reproduce ... this
is really annyoing. Especially this gives the wrong impression to
newbees. Things should be easy
not complicated.
To my knowledge disabling the Spotter search in Pharo 6 came up due to
some Pharo teaching in regions
with slow internet connection.
This made sense at the time. It is a worse first impression if UI lags when this central part of the UI is interfaced. How often would it access the network? Every time? Or did it cache the result for a day, etc?
I understand that we would like to support these Pharo users too as best as possible in their out of the box experience ... but (without being able to prove) I think that 90% or more Pharo users have a regular internet connection. Otherwise it would be hard to work with updates, project loading, PharoLauncher, STHub or Iceberg/GitHub.
Also my own personal experience is that even on low bandwidth network this Catalog Spotter search for me was always fast enough (as I often use Pharo in trains with slow connections or on a Pi with slow connections and less processing power). I do not know about all others from the community.
I invested hours in the past in developing and introducing the initial configuration browser to Pharo, later improved and helped shaping its replacement CatalogBrowser, also contributed this spotter search for the catalog items so things are more accessible, easy and enjoyable. That's why I also invested hours in udpating configs or pushing you to put things into catalog.
Because accessibility is key. Only when things are easy to access and understandable people will enjoy Pharo.
Currently in an out-of the box image this easy access to the projects via Spotter is blocked. Additionally I have to explain to anyone who asks me that there is a second non-obvious/more hidden setting leaving an unpleasant feeling how many others unknown to me will struggle with this issue.
I see two solutions:
A) We enable both settings by DEFAULT to bring back the Spotter search and installation of catalog items - with the clear benefit of having - the previous behavior in Pharo back - the out of the box ability to search for catalog projects in any fresh image - no confusion among the user base anymore regarding the settings - we have unbroken Youtube videos that newbees can continue to follow - if a user asks (like often) how to get Seaside, Artefact, Mongo, Teapot or other projects we can just tell him "search in Spotter and you should be fine" as most of them have a config in the catalog.
Remember that not all of us know about all the github pages or nice Metacello expressions. So the easier things are found and accessible the better it is.
B) If A is still a "No go" for the community we should at a minimum switch the defaults of the two settings:
=> we ENABLE the Spotter extension (GTSpotterExtensionSettings perform: #GTSpotter_spotterCatalogProjectsFor: with: true) => we DISABLE the catalog setting (CatalogSettings displayCatalogProjectsInSpotter: false)
With this at least we have no confusion among the user base anymore regarding the settings.
C) Could a STON file of the catalog be cached in the zip of Image/Changes files? That zip might be updated daily to keep it current. Then in a fresh image Spotter searches the cached file for a instant response, while the Catalog is updated from the network in the background.
Even with fast Internet the Catalog should only need to auto-update once a day, with results cached in a common file to be accessed when fresh images are started.
The Spotter UI might display the last update date as part of the Catalog sub-heading in its results.
cheers -ben
I would clearly and strongly vote for option A as my preferred one.
I agree there are regions/continents with very low bandwidth - but Pharo
will rival with state of the art
technologies where loading/installation megabytes from the web is often not seen as an issue. There are many package registries out there (from debian packages) up to Maven, npm in JS, ... or look at Docker. Shuffling megabytes around is a reality in todays technologies.
So to be honest I never understood this whole "bandwidth" discussion and even if this comes up it could be solved with a note in the download/welcome screen or pointing to a custom preference script for low bandwidth situations.
Sorry for having to bring this up again ... but I would like this to be solved BEFORE Pharo 6 will be pushed out of the door. Keeping it like it is without further actions would be really stupid.
Thanks for you comments, ideas or votes.
Thanks T.
2017-02-20 10:27 GMT+01:00 Guillermo Polito <guillermopolito@gmail.com>:
As far as I remember, the main problem was not bandwidth but a blocking and non-responsive UI. Imagine I'm in the university, or in a company with a proxy. And I forget to set the proxy. Then, while spotter tries to fetch catalog entries, it would block the image and throw a timeout error some minutes after.
So, maybe for the future and besides Ben's C option (which I like) I have a
D) Load catalog entries in background in a non-blocking way - and while catalog entries are not yet available, they should not be shown
AFIK the main problem was that there was not possilbe to do it non-blocking way. -- Pavel
Even further, It would make sense a solution that mixes Ben's caching with background loading of the catalog entries...
Guille
On Mon, Feb 20, 2017 at 1:03 AM, Ben Coman <btc@openinworld.com> wrote:
On Mon, Feb 20, 2017 at 4:05 AM, Torsten Bergmann <astares@gmx.de> wrote:
In the past in Pharo it was possible to open Spotter, type in the name of a framework/project to load from catalog, perform a search and just hit ENTER to easily install the project.
This was following the Spotter idea that it is easy to access most informations of Pharo with the Spotter tool.
There always was and still is a setting in "Settings" -> "Catalog" -> "Display catalog projects in Spotter". This setting is ENABLED BY DEFAULT but could be switched off in the settings tool or custom preference scripts if this is problematic for someone.
Now in Pharo 6 there is an additional class "GTSpotterExtensionSettings" to activate/deactivate Spotter extensions. While nearly all of the Spotter extensions are enabled the one for the catalog integration is DISABLED BY DEFAULT.
This leads to several effects:
1. While in the past it was possible in a fresh Pharo image to search and install out of the box it is (as of today in the not yet released Pharo 6) not possible anymore to quickly start by searching and installing from catalog using Spotter.
2. It is very confusing that in the settings "Display catalog projects in Spotter" is enabled but a search in Spotter gives no results. Most people will not not know about the second setting and easily get lost and think this behavior is just broken. Also this second setting for the Spotter extension is much more hidden between all the other Spotter extension enablements very and hard to find.
Generally its not good to have two settings for the one thing.
3. Several of my youtube videos demonstrating Goodies like
DesktopManager, QuickAccess,
MessageFlowBrowser, ... directly start by loading the tools from
Spotter. Anyone newbee who will
follow these will not only be confused - but also stuck in trying
Pharo when he learns
from these videos.
UI things do evolve and videos date. But these seem worthwhile to keep current.
I was asked several times on Slack and via Mail from people who
were not able to reproduce ... this
is really annyoing. Especially this gives the wrong impression to
newbees. Things should be easy
not complicated.
To my knowledge disabling the Spotter search in Pharo 6 came up due to
some Pharo teaching in regions
with slow internet connection.
This made sense at the time. It is a worse first impression if UI lags when this central part of the UI is interfaced. How often would it access the network? Every time? Or did it cache the result for a day, etc?
I understand that we would like to support these Pharo users too as best as possible in their out of the box experience ... but (without being able to prove) I think that 90% or more Pharo users have a regular internet connection. Otherwise it would be hard to work with updates, project loading, PharoLauncher, STHub or Iceberg/GitHub.
Also my own personal experience is that even on low bandwidth network this Catalog Spotter search for me was always fast enough (as I often use Pharo in trains with slow connections or on a Pi with slow connections and less processing power). I do not know about all others from the community.
I invested hours in the past in developing and introducing the initial configuration browser to Pharo, later improved and helped shaping its replacement CatalogBrowser, also contributed this spotter search for the catalog items so things are more accessible, easy and enjoyable. That's why I also invested hours in udpating configs or pushing you to put things into catalog.
Because accessibility is key. Only when things are easy to access and understandable people will enjoy Pharo.
Currently in an out-of the box image this easy access to the projects via Spotter is blocked. Additionally I have to explain to anyone who asks me that there is a second non-obvious/more hidden setting leaving an unpleasant feeling how many others unknown to me will struggle with this issue.
I see two solutions:
A) We enable both settings by DEFAULT to bring back the Spotter search and installation of catalog items - with the clear benefit of having - the previous behavior in Pharo back - the out of the box ability to search for catalog projects in any fresh image - no confusion among the user base anymore regarding the settings - we have unbroken Youtube videos that newbees can continue to follow - if a user asks (like often) how to get Seaside, Artefact, Mongo, Teapot or other projects we can just tell him "search in Spotter and you should be fine" as most of them have a config in the catalog.
Remember that not all of us know about all the github pages or nice Metacello expressions. So the easier things are found and accessible the better it is.
B) If A is still a "No go" for the community we should at a minimum switch the defaults of the two settings:
=> we ENABLE the Spotter extension (GTSpotterExtensionSettings perform: #GTSpotter_spotterCatalogProjectsFor: with: true) => we DISABLE the catalog setting (CatalogSettings displayCatalogProjectsInSpotter: false)
With this at least we have no confusion among the user base anymore regarding the settings.
C) Could a STON file of the catalog be cached in the zip of Image/Changes files? That zip might be updated daily to keep it current. Then in a fresh image Spotter searches the cached file for a instant response, while the Catalog is updated from the network in the background.
Even with fast Internet the Catalog should only need to auto-update once a day, with results cached in a common file to be accessed when fresh images are started.
The Spotter UI might display the last update date as part of the Catalog sub-heading in its results.
cheers -ben
I would clearly and strongly vote for option A as my preferred one.
I agree there are regions/continents with very low bandwidth - but
Pharo will rival with state of the art
technologies where loading/installation megabytes from the web is often not seen as an issue. There are many package registries out there (from debian packages) up to Maven, npm in JS, ... or look at Docker. Shuffling megabytes around is a reality in todays technologies.
So to be honest I never understood this whole "bandwidth" discussion and even if this comes up it could be solved with a note in the download/welcome screen or pointing to a custom preference script for low bandwidth situations.
Sorry for having to bring this up again ... but I would like this to be solved BEFORE Pharo 6 will be pushed out of the door. Keeping it like it is without further actions would be really stupid.
Thanks for you comments, ideas or votes.
Thanks T.
On 20 Feb 2017, at 10:30, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
2017-02-20 10:27 GMT+01:00 Guillermo Polito <guillermopolito@gmail.com>: As far as I remember, the main problem was not bandwidth but a blocking and non-responsive UI. Imagine I'm in the university, or in a company with a proxy. And I forget to set the proxy. Then, while spotter tries to fetch catalog entries, it would block the image and throw a timeout error some minutes after.
So, maybe for the future and besides Ben's C option (which I like) I have a
D) Load catalog entries in background in a non-blocking way - and while catalog entries are not yet available, they should not be shown
AFIK the main problem was that there was not possilbe to do it non-blocking way.
Yes that is true. (It is actually DNS resolving that is blocked in some freak case). But the thing is, the problematic situation only occurs for a very small percentage of people, like less than 1%, probably even much less. (Remember, nobody can produce a repeatable case for it). So the question is, is that enough reason to act as if we are still in the 90's when internet was a luxury and cut features that depend on it ? If you have no network today, you're in big trouble anyway. (Again, if you turn off your network, no blocking will happen at all, try it). So what is more important ? The general functionality of the 99.xxx % or the unreproducible freak case ?
-- Pavel
Even further, It would make sense a solution that mixes Ben's caching with background loading of the catalog entries...
Guille
On Mon, Feb 20, 2017 at 1:03 AM, Ben Coman <btc@openinworld.com> wrote: On Mon, Feb 20, 2017 at 4:05 AM, Torsten Bergmann <astares@gmx.de> wrote:
In the past in Pharo it was possible to open Spotter, type in the name of a framework/project to load from catalog, perform a search and just hit ENTER to easily install the project.
This was following the Spotter idea that it is easy to access most informations of Pharo with the Spotter tool.
There always was and still is a setting in "Settings" -> "Catalog" -> "Display catalog projects in Spotter". This setting is ENABLED BY DEFAULT but could be switched off in the settings tool or custom preference scripts if this is problematic for someone.
Now in Pharo 6 there is an additional class "GTSpotterExtensionSettings" to activate/deactivate Spotter extensions. While nearly all of the Spotter extensions are enabled the one for the catalog integration is DISABLED BY DEFAULT.
This leads to several effects:
1. While in the past it was possible in a fresh Pharo image to search and install out of the box it is (as of today in the not yet released Pharo 6) not possible anymore to quickly start by searching and installing from catalog using Spotter.
2. It is very confusing that in the settings "Display catalog projects in Spotter" is enabled but a search in Spotter gives no results. Most people will not not know about the second setting and easily get lost and think this behavior is just broken. Also this second setting for the Spotter extension is much more hidden between all the other Spotter extension enablements very and hard to find.
Generally its not good to have two settings for the one thing.
3. Several of my youtube videos demonstrating Goodies like DesktopManager, QuickAccess, MessageFlowBrowser, ... directly start by loading the tools from Spotter. Anyone newbee who will follow these will not only be confused - but also stuck in trying Pharo when he learns from these videos.
UI things do evolve and videos date. But these seem worthwhile to keep current.
I was asked several times on Slack and via Mail from people who were not able to reproduce ... this is really annyoing. Especially this gives the wrong impression to newbees. Things should be easy not complicated.
To my knowledge disabling the Spotter search in Pharo 6 came up due to some Pharo teaching in regions with slow internet connection.
This made sense at the time. It is a worse first impression if UI lags when this central part of the UI is interfaced. How often would it access the network? Every time? Or did it cache the result for a day, etc?
I understand that we would like to support these Pharo users too as best as possible in their out of the box experience ... but (without being able to prove) I think that 90% or more Pharo users have a regular internet connection. Otherwise it would be hard to work with updates, project loading, PharoLauncher, STHub or Iceberg/GitHub.
Also my own personal experience is that even on low bandwidth network this Catalog Spotter search for me was always fast enough (as I often use Pharo in trains with slow connections or on a Pi with slow connections and less processing power). I do not know about all others from the community.
I invested hours in the past in developing and introducing the initial configuration browser to Pharo, later improved and helped shaping its replacement CatalogBrowser, also contributed this spotter search for the catalog items so things are more accessible, easy and enjoyable. That's why I also invested hours in udpating configs or pushing you to put things into catalog.
Because accessibility is key. Only when things are easy to access and understandable people will enjoy Pharo.
Currently in an out-of the box image this easy access to the projects via Spotter is blocked. Additionally I have to explain to anyone who asks me that there is a second non-obvious/more hidden setting leaving an unpleasant feeling how many others unknown to me will struggle with this issue.
I see two solutions:
A) We enable both settings by DEFAULT to bring back the Spotter search and installation of catalog items - with the clear benefit of having - the previous behavior in Pharo back - the out of the box ability to search for catalog projects in any fresh image - no confusion among the user base anymore regarding the settings - we have unbroken Youtube videos that newbees can continue to follow - if a user asks (like often) how to get Seaside, Artefact, Mongo, Teapot or other projects we can just tell him "search in Spotter and you should be fine" as most of them have a config in the catalog.
Remember that not all of us know about all the github pages or nice Metacello expressions. So the easier things are found and accessible the better it is.
B) If A is still a "No go" for the community we should at a minimum switch the defaults of the two settings:
=> we ENABLE the Spotter extension (GTSpotterExtensionSettings perform: #GTSpotter_spotterCatalogProjectsFor: with: true) => we DISABLE the catalog setting (CatalogSettings displayCatalogProjectsInSpotter: false)
With this at least we have no confusion among the user base anymore regarding the settings.
C) Could a STON file of the catalog be cached in the zip of Image/Changes files? That zip might be updated daily to keep it current. Then in a fresh image Spotter searches the cached file for a instant response, while the Catalog is updated from the network in the background.
Even with fast Internet the Catalog should only need to auto-update once a day, with results cached in a common file to be accessed when fresh images are started.
The Spotter UI might display the last update date as part of the Catalog sub-heading in its results.
cheers -ben
I would clearly and strongly vote for option A as my preferred one.
I agree there are regions/continents with very low bandwidth - but Pharo will rival with state of the art technologies where loading/installation megabytes from the web is often not seen as an issue. There are many package registries out there (from debian packages) up to Maven, npm in JS, ... or look at Docker. Shuffling megabytes around is a reality in todays technologies.
So to be honest I never understood this whole "bandwidth" discussion and even if this comes up it could be solved with a note in the download/welcome screen or pointing to a custom preference script for low bandwidth situations.
Sorry for having to bring this up again ... but I would like this to be solved BEFORE Pharo 6 will be pushed out of the door. Keeping it like it is without further actions would be really stupid.
Thanks for you comments, ideas or votes.
Thanks T.
As there were no further objections I guess we should do the following steps as a compromise: 1. We switch back to how it was by selecting Solution A as it is the old behavior and the pragmatic approach. This avoids the confusion, allows to quickly search for the catalog items and also renders the videos valid again. 2. Pharo 6 is still not released. People can still be testing and if this really gives trouble again (maybe next time in a reproducible way) we can try to fix it/find another solution. In the worst case we can disable it by disabeling the Catalog setting (not the GT extension itself) so it is not confusing or hidden again in the Pharo settings. I've opened issue https://pharo.fogbugz.com/f/cases/edit/19732 and will fix it. Lets see how it goes. Thanks T.
Gesendet: Montag, 20. Februar 2017 um 11:27 Uhr Von: "Sven Van Caekenberghe" <sven@stfx.eu> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: Re: [Pharo-dev] Catalog loading in Spotter
On 20 Feb 2017, at 10:30, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
2017-02-20 10:27 GMT+01:00 Guillermo Polito <guillermopolito@gmail.com>: As far as I remember, the main problem was not bandwidth but a blocking and non-responsive UI. Imagine I'm in the university, or in a company with a proxy. And I forget to set the proxy. Then, while spotter tries to fetch catalog entries, it would block the image and throw a timeout error some minutes after.
So, maybe for the future and besides Ben's C option (which I like) I have a
D) Load catalog entries in background in a non-blocking way - and while catalog entries are not yet available, they should not be shown
AFIK the main problem was that there was not possilbe to do it non-blocking way.
Yes that is true. (It is actually DNS resolving that is blocked in some freak case).
But the thing is, the problematic situation only occurs for a very small percentage of people, like less than 1%, probably even much less. (Remember, nobody can produce a repeatable case for it).
So the question is, is that enough reason to act as if we are still in the 90's when internet was a luxury and cut features that depend on it ? If you have no network today, you're in big trouble anyway. (Again, if you turn off your network, no blocking will happen at all, try it).
So what is more important ? The general functionality of the 99.xxx % or the unreproducible freak case ?
-- Pavel
Even further, It would make sense a solution that mixes Ben's caching with background loading of the catalog entries...
Guille
On Mon, Feb 20, 2017 at 1:03 AM, Ben Coman <btc@openinworld.com> wrote: On Mon, Feb 20, 2017 at 4:05 AM, Torsten Bergmann <astares@gmx.de> wrote:
In the past in Pharo it was possible to open Spotter, type in the name of a framework/project to load from catalog, perform a search and just hit ENTER to easily install the project.
This was following the Spotter idea that it is easy to access most informations of Pharo with the Spotter tool.
There always was and still is a setting in "Settings" -> "Catalog" -> "Display catalog projects in Spotter". This setting is ENABLED BY DEFAULT but could be switched off in the settings tool or custom preference scripts if this is problematic for someone.
Now in Pharo 6 there is an additional class "GTSpotterExtensionSettings" to activate/deactivate Spotter extensions. While nearly all of the Spotter extensions are enabled the one for the catalog integration is DISABLED BY DEFAULT.
This leads to several effects:
1. While in the past it was possible in a fresh Pharo image to search and install out of the box it is (as of today in the not yet released Pharo 6) not possible anymore to quickly start by searching and installing from catalog using Spotter.
2. It is very confusing that in the settings "Display catalog projects in Spotter" is enabled but a search in Spotter gives no results. Most people will not not know about the second setting and easily get lost and think this behavior is just broken. Also this second setting for the Spotter extension is much more hidden between all the other Spotter extension enablements very and hard to find.
Generally its not good to have two settings for the one thing.
3. Several of my youtube videos demonstrating Goodies like DesktopManager, QuickAccess, MessageFlowBrowser, ... directly start by loading the tools from Spotter. Anyone newbee who will follow these will not only be confused - but also stuck in trying Pharo when he learns from these videos.
UI things do evolve and videos date. But these seem worthwhile to keep current.
I was asked several times on Slack and via Mail from people who were not able to reproduce ... this is really annyoing. Especially this gives the wrong impression to newbees. Things should be easy not complicated.
To my knowledge disabling the Spotter search in Pharo 6 came up due to some Pharo teaching in regions with slow internet connection.
This made sense at the time. It is a worse first impression if UI lags when this central part of the UI is interfaced. How often would it access the network? Every time? Or did it cache the result for a day, etc?
I understand that we would like to support these Pharo users too as best as possible in their out of the box experience ... but (without being able to prove) I think that 90% or more Pharo users have a regular internet connection. Otherwise it would be hard to work with updates, project loading, PharoLauncher, STHub or Iceberg/GitHub.
Also my own personal experience is that even on low bandwidth network this Catalog Spotter search for me was always fast enough (as I often use Pharo in trains with slow connections or on a Pi with slow connections and less processing power). I do not know about all others from the community.
I invested hours in the past in developing and introducing the initial configuration browser to Pharo, later improved and helped shaping its replacement CatalogBrowser, also contributed this spotter search for the catalog items so things are more accessible, easy and enjoyable. That's why I also invested hours in udpating configs or pushing you to put things into catalog.
Because accessibility is key. Only when things are easy to access and understandable people will enjoy Pharo.
Currently in an out-of the box image this easy access to the projects via Spotter is blocked. Additionally I have to explain to anyone who asks me that there is a second non-obvious/more hidden setting leaving an unpleasant feeling how many others unknown to me will struggle with this issue.
I see two solutions:
A) We enable both settings by DEFAULT to bring back the Spotter search and installation of catalog items - with the clear benefit of having - the previous behavior in Pharo back - the out of the box ability to search for catalog projects in any fresh image - no confusion among the user base anymore regarding the settings - we have unbroken Youtube videos that newbees can continue to follow - if a user asks (like often) how to get Seaside, Artefact, Mongo, Teapot or other projects we can just tell him "search in Spotter and you should be fine" as most of them have a config in the catalog.
Remember that not all of us know about all the github pages or nice Metacello expressions. So the easier things are found and accessible the better it is.
B) If A is still a "No go" for the community we should at a minimum switch the defaults of the two settings:
=> we ENABLE the Spotter extension (GTSpotterExtensionSettings perform: #GTSpotter_spotterCatalogProjectsFor: with: true) => we DISABLE the catalog setting (CatalogSettings displayCatalogProjectsInSpotter: false)
With this at least we have no confusion among the user base anymore regarding the settings.
C) Could a STON file of the catalog be cached in the zip of Image/Changes files? That zip might be updated daily to keep it current. Then in a fresh image Spotter searches the cached file for a instant response, while the Catalog is updated from the network in the background.
Even with fast Internet the Catalog should only need to auto-update once a day, with results cached in a common file to be accessed when fresh images are started.
The Spotter UI might display the last update date as part of the Catalog sub-heading in its results.
cheers -ben
I would clearly and strongly vote for option A as my preferred one.
I agree there are regions/continents with very low bandwidth - but Pharo will rival with state of the art technologies where loading/installation megabytes from the web is often not seen as an issue. There are many package registries out there (from debian packages) up to Maven, npm in JS, ... or look at Docker. Shuffling megabytes around is a reality in todays technologies.
So to be honest I never understood this whole "bandwidth" discussion and even if this comes up it could be solved with a note in the download/welcome screen or pointing to a custom preference script for low bandwidth situations.
Sorry for having to bring this up again ... but I would like this to be solved BEFORE Pharo 6 will be pushed out of the door. Keeping it like it is without further actions would be really stupid.
Thanks for you comments, ideas or votes.
Thanks T.
The compromise is that people add an expression in one line in their startup preferences. It sounds reasonable to me. Stef On Tue, 21 Feb 2017 12:26:43 +0100, Torsten Bergmann <astares@gmx.de> wrote:
As there were no further objections I guess we should do the following steps as a compromise:
1. We switch back to how it was by selecting Solution A as it is the old behavior and the pragmatic approach. This avoids the confusion, allows to quickly search for the catalog items and also renders the videos valid again.
2. Pharo 6 is still not released. People can still be testing and if this really gives trouble again (maybe next time in a reproducible way) we can try to fix it/find another solution. In the worst case we can disable it by disabeling the Catalog setting (not the GT extension itself) so it is not confusing or hidden again in the Pharo settings.
I've opened issue https://pharo.fogbugz.com/f/cases/edit/19732 and will fix it. Lets see how it goes.
Thanks T.
Gesendet: Montag, 20. Februar 2017 um 11:27 Uhr Von: "Sven Van Caekenberghe" <sven@stfx.eu> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: Re: [Pharo-dev] Catalog loading in Spotter
On 20 Feb 2017, at 10:30, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
2017-02-20 10:27 GMT+01:00 Guillermo Polito <guillermopolito@gmail.com>: As far as I remember, the main problem was not bandwidth but a blocking and non-responsive UI. Imagine I'm in the university, or in a company with a proxy. And I forget to set the proxy. Then, while spotter tries to fetch catalog entries, it would block the image and throw a timeout error some minutes after.
So, maybe for the future and besides Ben's C option (which I like) I have a
D) Load catalog entries in background in a non-blocking way - and while catalog entries are not yet available, they should not be shown
AFIK the main problem was that there was not possilbe to do it non-blocking way.
Yes that is true. (It is actually DNS resolving that is blocked in some freak case).
But the thing is, the problematic situation only occurs for a very small percentage of people, like less than 1%, probably even much less. (Remember, nobody can produce a repeatable case for it).
So the question is, is that enough reason to act as if we are still in the 90's when internet was a luxury and cut features that depend on it ? If you have no network today, you're in big trouble anyway. (Again, if you turn off your network, no blocking will happen at all, try it).
So what is more important ? The general functionality of the 99.xxx % or the unreproducible freak case ?
-- Pavel
Even further, It would make sense a solution that mixes Ben's caching with background loading of the catalog entries...
Guille
On Mon, Feb 20, 2017 at 1:03 AM, Ben Coman <btc@openinworld.com> wrote: On Mon, Feb 20, 2017 at 4:05 AM, Torsten Bergmann <astares@gmx.de> wrote:
In the past in Pharo it was possible to open Spotter, type in the name of a framework/project to load from catalog, perform a search and just hit ENTER to easily install the project.
This was following the Spotter idea that it is easy to access most informations of Pharo with the Spotter tool.
There always was and still is a setting in "Settings" -> "Catalog" -> "Display catalog projects in Spotter". This setting is ENABLED BY DEFAULT but could be switched off in the settings tool or custom preference scripts if this is problematic for someone.
Now in Pharo 6 there is an additional class "GTSpotterExtensionSettings" to activate/deactivate Spotter extensions. While nearly all of the Spotter extensions are enabled the one for the catalog integration is DISABLED BY DEFAULT.
This leads to several effects:
1. While in the past it was possible in a fresh Pharo image to search and install out of the box it is (as of today in the not yet released Pharo 6) not possible anymore to quickly start by searching and installing from catalog using Spotter.
2. It is very confusing that in the settings "Display catalog projects in Spotter" is enabled but a search in Spotter gives no results. Most people will not not know about the second setting and easily get lost and think this behavior is just broken. Also this second setting for the Spotter extension is much more hidden between all the other Spotter extension enablements very and hard to find.
Generally its not good to have two settings for the one thing.
3. Several of my youtube videos demonstrating Goodies like
DesktopManager, QuickAccess,
MessageFlowBrowser, ... directly start by loading the tools
from Spotter. Anyone newbee who will
follow these will not only be confused - but also stuck in
trying Pharo when he learns
from these videos.
UI things do evolve and videos date. But these seem worthwhile to keep current.
I was asked several times on Slack and via Mail from people
who were not able to reproduce ... this
is really annyoing. Especially this gives the wrong impression
to newbees. Things should be easy
not complicated.
To my knowledge disabling the Spotter search in Pharo 6 came up due
to some Pharo teaching in regions
with slow internet connection.
This made sense at the time. It is a worse first impression if UI lags when this central part of the UI is interfaced. How often would it access the network? Every time? Or did it cache the result for a day, etc?
I understand that we would like to support these Pharo users too as best as possible in their out of the box experience ... but (without being able to prove) I think that 90% or more Pharo users have a regular internet connection. Otherwise it would be hard to work with updates, project loading, PharoLauncher, STHub or Iceberg/GitHub.
Also my own personal experience is that even on low bandwidth network this Catalog Spotter search for me was always fast enough (as I often use Pharo in trains with slow connections or on a Pi with slow connections and less processing power). I do not know about all others from the community.
I invested hours in the past in developing and introducing the initial configuration browser to Pharo, later improved and helped shaping its replacement CatalogBrowser, also contributed this spotter search for the catalog items so things are more accessible, easy and enjoyable. That's why I also invested hours in udpating configs or pushing you to put things into catalog.
Because accessibility is key. Only when things are easy to access and understandable people will enjoy Pharo.
Currently in an out-of the box image this easy access to the projects via Spotter is blocked. Additionally I have to explain to anyone who asks me that there is a second non-obvious/more hidden setting leaving an unpleasant feeling how many others unknown to me will struggle with this issue.
I see two solutions:
A) We enable both settings by DEFAULT to bring back the Spotter search and installation of catalog items - with the clear benefit of having - the previous behavior in Pharo back - the out of the box ability to search for catalog projects in any fresh image - no confusion among the user base anymore regarding the settings - we have unbroken Youtube videos that newbees can continue to follow - if a user asks (like often) how to get Seaside, Artefact, Mongo, Teapot or other projects we can just tell him "search in Spotter and you should be fine" as most of them have a config in the catalog.
Remember that not all of us know about all the github pages or nice Metacello expressions. So the easier things are found and accessible the better it is.
B) If A is still a "No go" for the community we should at a minimum switch the defaults of the two settings:
=> we ENABLE the Spotter extension (GTSpotterExtensionSettings perform: #GTSpotter_spotterCatalogProjectsFor: with: true) => we DISABLE the catalog setting (CatalogSettings displayCatalogProjectsInSpotter: false)
With this at least we have no confusion among the user base anymore regarding the settings.
C) Could a STON file of the catalog be cached in the zip of Image/Changes files? That zip might be updated daily to keep it current. Then in a fresh image Spotter searches the cached file for a instant response, while the Catalog is updated from the network in the background.
Even with fast Internet the Catalog should only need to auto-update once a day, with results cached in a common file to be accessed when fresh images are started.
The Spotter UI might display the last update date as part of the Catalog sub-heading in its results.
cheers -ben
I would clearly and strongly vote for option A as my preferred one.
I agree there are regions/continents with very low bandwidth - but
Pharo will rival with state of the art
technologies where loading/installation megabytes from the web is often not seen as an issue. There are many package registries out there (from debian packages) up to Maven, npm in JS, ... or look at Docker. Shuffling megabytes around is a reality in todays technologies.
So to be honest I never understood this whole "bandwidth" discussion and even if this comes up it could be solved with a note in the download/welcome screen or pointing to a custom preference script for low bandwidth situations.
Sorry for having to bring this up again ... but I would like this to be solved BEFORE Pharo 6 will be pushed out of the door. Keeping it like it is without further actions would be really stupid.
Thanks for you comments, ideas or votes.
Thanks T.
-- Using Opera's mail client: http://www.opera.com/mail/
On Mon, Feb 20, 2017 at 6:27 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 20 Feb 2017, at 10:30, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
2017-02-20 10:27 GMT+01:00 Guillermo Polito <guillermopolito@gmail.com>: As far as I remember, the main problem was not bandwidth but a blocking and non-responsive UI. Imagine I'm in the university, or in a company with a proxy. And I forget to set the proxy. Then, while spotter tries to fetch catalog entries, it would block the image and throw a timeout error some minutes after.
So, maybe for the future and besides Ben's C option (which I like) I have a
D) Load catalog entries in background in a non-blocking way - and while catalog entries are not yet available, they should not be shown
AFIK the main problem was that there was not possilbe to do it non-blocking way.
Yes that is true. (It is actually DNS resolving that is blocked in some freak case).
In sqUnixSocket.c I read... * Notes: * Sockets are completely asynchronous, but the resolver is still synchronous. So does this mean that if for any reason the resolver primitive takes a long time to respond, the whole VM is blocked? Thus forking the Catalog loading in another thread would have no benefit? Would having the resolver coded purely in-Image behave better? So a slow name resolution would not hold up the whole image if it happened in a forked thread. I found such an implementation in OpenCobalt and after some minor cleanup basic operations work fine. http://smalltalkhub.com/#!/~BenComan/DNS/ cheers -ben
But the thing is, the problematic situation only occurs for a very small percentage of people, like less than 1%, probably even much less. (Remember, nobody can produce a repeatable case for it).
So the question is, is that enough reason to act as if we are still in the 90's when internet was a luxury and cut features that depend on it ? If you have no network today, you're in big trouble anyway. (Again, if you turn off your network, no blocking will happen at all, try it).
So what is more important ? The general functionality of the 99.xxx % or the unreproducible freak case ?
On 24 Feb 2017, at 18:14, Ben Coman <btc@openinworld.com> wrote:
On Mon, Feb 20, 2017 at 6:27 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 20 Feb 2017, at 10:30, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
2017-02-20 10:27 GMT+01:00 Guillermo Polito <guillermopolito@gmail.com>: As far as I remember, the main problem was not bandwidth but a blocking and non-responsive UI. Imagine I'm in the university, or in a company with a proxy. And I forget to set the proxy. Then, while spotter tries to fetch catalog entries, it would block the image and throw a timeout error some minutes after.
So, maybe for the future and besides Ben's C option (which I like) I have a
D) Load catalog entries in background in a non-blocking way - and while catalog entries are not yet available, they should not be shown
AFIK the main problem was that there was not possilbe to do it non-blocking way.
Yes that is true. (It is actually DNS resolving that is blocked in some freak case).
In sqUnixSocket.c I read... * Notes: * Sockets are completely asynchronous, but the resolver is still synchronous.
So does this mean that if for any reason the resolver primitive takes a long time to respond, the whole VM is blocked? Thus forking the Catalog loading in another thread would have no benefit?
Yes and yes.
Would having the resolver coded purely in-Image behave better?
Yes (probably).
So a slow name resolution would not hold up the whole image if it happened in a forked thread.
Yes.
I found such an implementation in OpenCobalt and after some minor cleanup basic operations work fine.
Well, I did one myself too (I have not looked at the one above, I will), but my conclusion was that it is not that difficult to get basic lookup working, but edge cases (like concurrent requests with intermixed answers) are not so easy. There is also a chicken/egg problem: what DNS resolver (host) will you contact ? How to find out the one configured by your OS ? My idea was to use the Google ones (8.8.8.8), but there is also a more open one (80.80.80.80) and probably others. We are often accused of reinventing the wheel and carrying the burden of maintaining all that infrastructure. Doing our own DNS client would add to that. But I like the general idea, the question is one about development risk.
cheers -ben
But the thing is, the problematic situation only occurs for a very small percentage of people, like less than 1%, probably even much less. (Remember, nobody can produce a repeatable case for it).
So the question is, is that enough reason to act as if we are still in the 90's when internet was a luxury and cut features that depend on it ? If you have no network today, you're in big trouble anyway. (Again, if you turn off your network, no blocking will happen at all, try it).
So what is more important ? The general functionality of the 99.xxx % or the unreproducible freak case ?
On 24 Feb 2017, at 18:56, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 24 Feb 2017, at 18:14, Ben Coman <btc@openinworld.com> wrote:
On Mon, Feb 20, 2017 at 6:27 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 20 Feb 2017, at 10:30, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
2017-02-20 10:27 GMT+01:00 Guillermo Polito <guillermopolito@gmail.com>: As far as I remember, the main problem was not bandwidth but a blocking and non-responsive UI. Imagine I'm in the university, or in a company with a proxy. And I forget to set the proxy. Then, while spotter tries to fetch catalog entries, it would block the image and throw a timeout error some minutes after.
So, maybe for the future and besides Ben's C option (which I like) I have a
D) Load catalog entries in background in a non-blocking way - and while catalog entries are not yet available, they should not be shown
AFIK the main problem was that there was not possilbe to do it non-blocking way.
Yes that is true. (It is actually DNS resolving that is blocked in some freak case).
In sqUnixSocket.c I read... * Notes: * Sockets are completely asynchronous, but the resolver is still synchronous.
So does this mean that if for any reason the resolver primitive takes a long time to respond, the whole VM is blocked? Thus forking the Catalog loading in another thread would have no benefit?
Yes and yes.
Would having the resolver coded purely in-Image behave better?
Yes (probably).
So a slow name resolution would not hold up the whole image if it happened in a forked thread.
Yes.
I found such an implementation in OpenCobalt and after some minor cleanup basic operations work fine.
Well, I did one myself too (I have not looked at the one above, I will), but my conclusion was that it is not that difficult to get basic lookup working, but edge cases (like concurrent requests with intermixed answers) are not so easy.
There is also a chicken/egg problem: what DNS resolver (host) will you contact ? How to find out the one configured by your OS ? My idea was to use the Google ones (8.8.8.8), but there is also a more open one (80.80.80.80) and probably others.
We are often accused of reinventing the wheel and carrying the burden of maintaining all that infrastructure. Doing our own DNS client would add to that.
But I like the general idea, the question is one about development risk.
So Ben, I could not get the code to run (on Pharo 6) using UDP, it remained stuck on sending the UDP packet, which is really weird. I found my old code, turns out it was based on the same message/packets hierarchy. And it still worked. I committed it to your repo: === Name: Net-Protocols-DNS-SvenVanCaekenberghe.15 Author: SvenVanCaekenberghe Time: 24 February 2017, 8:08:54.299786 pm UUID: 9b8fa332-ad05-0d00-8577-5adb00d43870 Ancestors: Net-Protocols-DNS-BenComan.14 Added NeoDNSClient to Net-Protocols-DNS-Experimental === You should be able to do NeoDNSClient default addressForName: 'stfx.eu'. There is no caching yet, but there is a simple #beThreadSafe provided. (My other comments remain valid, also for my own code). Sven
cheers -ben
But the thing is, the problematic situation only occurs for a very small percentage of people, like less than 1%, probably even much less. (Remember, nobody can produce a repeatable case for it).
So the question is, is that enough reason to act as if we are still in the 90's when internet was a luxury and cut features that depend on it ? If you have no network today, you're in big trouble anyway. (Again, if you turn off your network, no blocking will happen at all, try it).
So what is more important ? The general functionality of the 99.xxx % or the unreproducible freak case ?
Guillermo such people do not know what is ti teach in the university with a fucking proxy like you and me. It is super easy when you are not expose to the view of newbies. PHARO IS NOT WELL PACKAGED guys. Try to get out our confort zone. The world is different and working. Stef > As far as I remember, the main problem was not bandwidth but a blocking > and non-responsive UI. > Imagine I'm in the university, or in a company with a proxy. And I > forget to set the proxy. Then, while spotter tries to fetch catalog > entries, it would block the image and throw a timeout error >some > minutes after. > > So, maybe for the future and besides Ben's C option (which I like) I > have a > > D) Load catalog entries in background in a non-blocking way > - and while catalog entries are not yet available, they should not be > shown > > Even further, It would make sense a solution that mixes Ben's caching > with background loading of the catalog entries... > Guille > > On Mon, Feb 20, 2017 at 1:03 AM, Ben Coman <btc@openinworld.com> wrote: >> On Mon, Feb 20, 2017 at 4:05 AM, Torsten Bergmann <astares@gmx.de> >> wrote: >>> In the past in Pharo it was possible to open Spotter, type in the name >>> of a framework/project to load >>> from catalog, perform a search and just hit ENTER to easily install >>> the project. >>> >>> This was following the Spotter idea that it is easy to access most >>> informations of Pharo >>> with the Spotter tool. >>> >>> There always was and still is a setting in "Settings" -> "Catalog" -> >>> "Display catalog projects in Spotter". >>> This setting is ENABLED BY DEFAULT but could be switched off in the >>> settings tool or custom preference >>> scripts if this is problematic for someone. >>> >>> >>> Now in Pharo 6 there is an additional class >>> "GTSpotterExtensionSettings" to activate/deactivate >>> Spotter extensions. While nearly all of the Spotter extensions are >>> enabled the one for the catalog >>> integration is DISABLED BY DEFAULT. >>> >>> This leads to several effects: >>> >>> 1. While in the past it was possible in a fresh Pharo image to >>> search and install out of >>> the box it is (as of today in the not yet released Pharo 6) not >>> possible anymore to quickly >>> start by searching and installing from catalog using Spotter. >>> >>> 2. It is very confusing that in the settings "Display catalog >>> projects in Spotter" is enabled but a search >>> in Spotter gives no results. Most people will not not know about >>> the second setting and easily >>> get lost and think this behavior is just broken. >>> Also this second setting for the Spotter extension is much more >>> hidden between all the other >>> Spotter extension enablements very and hard to find. >> >> Generally its not good to have two settings for the one thing. >> >>>>> >>> 3. Several of my youtube videos demonstrating Goodies like >>> DesktopManager, QuickAccess, >>> MessageFlowBrowser, ... directly start by loading the tools from >>> Spotter. Anyone newbee who will >>> follow these will not only be confused - but also stuck in trying >>> Pharo when he learns >>> from these videos. >> >> UI things do evolve and videos date. But these seem worthwhile to keep >> current. >> >>>>> >>> I was asked several times on Slack and via Mail from people who >>> were not able to reproduce ... this >>> is really annyoing. Especially this gives the wrong impression to >>> newbees. Things should be easy >>> not complicated. >>> >>> To my knowledge disabling the Spotter search in Pharo 6 came up due to >>> some Pharo teaching in regions >>> with slow internet connection. >> >> This made sense at the time. It is a worse first impression if UI >> lags when this central part of the UI is interfaced. >> How often would it access the network? Every time? Or did it cache >> the result for a day, etc? >> >>> I understand that we would like to support these Pharo users too as >>> best >>> as possible in their out of the box experience ... but (without being >>> able to prove) I think that 90% or >>> more Pharo users have a regular internet connection. Otherwise it >>> would be hard to work with updates, >>> project loading, PharoLauncher, STHub or Iceberg/GitHub. >>> >>> Also my own personal experience is that even on low bandwidth network >>> this Catalog Spotter search for >>> me was always fast enough (as I often use Pharo in trains with slow >>> connections or on a Pi with slow >>> connections and less processing power). I do not know about all others >>> from the community. >>> >>> I invested hours in the past in developing and introducing the initial >>> configuration browser to Pharo, >>> later improved and helped shaping its replacement CatalogBrowser, also >>> contributed this spotter search >>> for the catalog items so things are more accessible, easy and >>> enjoyable. That's why I also invested >>> hours in udpating configs or pushing you to put things into catalog. >>> >>> Because accessibility is key. Only when things are easy to access and >>> understandable people will >>> enjoy Pharo. >>> >>> Currently in an out-of the box image this easy access to the projects >>> via Spotter is blocked. >>> Additionally I have to explain to anyone who asks me that there is a >>> second non-obvious/more hidden setting >>> leaving an unpleasant feeling how many others unknown to me will >>> struggle with this issue. >>> >>> I see two solutions: >>> >>> A) We enable both settings by DEFAULT to bring back the Spotter >>> search and installation >>> of catalog items - with the clear benefit of having >>> - the previous behavior in Pharo back >>> - the out of the box ability to search for catalog projects >>> in any fresh image >>> - no confusion among the user base anymore regarding the >>> settings >>> - we have unbroken Youtube videos that newbees can continue >>> to follow >>> - if a user asks (like often) how to get Seaside, Artefact, >>> Mongo, Teapot or other projects we can >>> just tell him "search in Spotter and you should be fine" as >>> most of them have a config in >>> the catalog. >>> >>> Remember that not all of us know about all the github pages >>> or nice Metacello expressions. >>> So the easier things are found and accessible the better it >>> is. >>> >>> B) If A is still a "No go" for the community we should at a minimum >>> switch the defaults of >>> the two settings: >>> >>> => we ENABLE the Spotter extension (GTSpotterExtensionSettings >>> perform: #GTSpotter_spotterCatalogProjectsFor: with: true) >>> => we DISABLE the catalog setting (CatalogSettings >>> displayCatalogProjectsInSpotter: false) >>> >>> With this at least we have no confusion among the user base >>> anymore regarding the settings. >> >> C) Could a STON file of the catalog be cached in the zip of >> Image/Changes files? >> That zip might be updated daily to keep it current. >> Then in a fresh image Spotter searches the cached file for a instant >> response, >> while the Catalog is updated from the network in the background. >> >> Even with fast Internet the Catalog should only need to auto-update >> once a day, >> with results cached in a common file to be accessed when fresh images >> are started. >> >> The Spotter UI might display the last update date as part of the >> Catalog sub-heading in its results. >> >> cheers -ben >> >>> >>> I would clearly and strongly vote for option A as my preferred one. >>> >>> I agree there are regions/continents with very low bandwidth - but >>> Pharo will rival with state of the art >>> technologies where loading/installation megabytes from the web is >>> often not seen as an issue. There are >>> many package registries out there (from debian packages) up to Maven, >>> npm in JS, ... or look at Docker. >>> Shuffling megabytes around is a reality in todays technologies. >>> >>> So to be honest I never understood this whole "bandwidth" discussion >>> and even if this comes up it could >>> be solved with a note in the download/welcome screen or pointing to a >>> custom preference script for low bandwidth >>> situations. >>> >>> Sorry for having to bring this up again ... but I would like this to >>> be solved BEFORE Pharo 6 will >>> be pushed out of the door. Keeping it like it is without further >>> actions would be really stupid. >>> >>> Thanks for you comments, ideas or votes. >>> >>> Thanks >>> T. >>> >> > -- Using Opera's mail client: http://www.opera.com/mail/
You are telling me that expert developers cannot have a script that automatically set this. I cannot believe. I hope that your confort zone is not too disruptive. I'm really sad. I'm currently writing a book for newbies and I spent my morning talking to people in liberia. Poor guys. Stef
Apparently you do not know the amount of time we have to explain to students in FRANCE with internet blocked over a proxy that No Pharo is not dead. It is just a time out. So don't be egoist be adults and use the infrastructure. Use a preference in your system. Stef
participants (8)
-
Ben Coman -
Guillermo Polito -
Pavel Krivanek -
phil＠highoctane.be -
Stephan Eggermont -
stepharong -
Sven Van Caekenberghe -
Torsten Bergmann