February 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Catalog loading in Spotter

by Guillermo Polito

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(a)openinworld.com> wrote: > On Mon, Feb 20, 2017 at 4:05 AM, Torsten Bergmann <astares(a)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. > > > >

Feb. 20, 2017

Re: [Pharo-dev] Esteban's ChangeLog week of 13 February 2017

by Esteban Lorenzano

> On 20 Feb 2017, at 08:00, estebanlm(a)gmail.com wrote: > > Hello! > > This is my weekly ChangeLog, from 13 February 2017 to 19 February 2017. > You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=13/2/2017&to=19/2/2017 > > ChangeLog > ========= > > 17 February 2017: > ----------------- > > * I spent sometime working on UFFI and 64bits. > > Sometime ago I started this and found a problem that I talked with Eliot, you can found the rational > [here](http://forum.world.st/Support-for-LP64-amp-LLP64-in-FFI-Kernel-td4929946.html) (we need to model > in some way the fact that longs have different sizes in different platforms, notably LP64 and LLP64). > > In that discussion, with Eliot we proposed to add a new FFI type, a +platformLong+ who will behave as > expected. I started to implement but didn't have the time to finish it and I needed to jump to other > stuff. In the mean time, Ronie found a different workaround: instead adding support in the VM, just map > in image the type to correct size. > > This is how it will work: > > |=== > |Platform > |type > |size > |FFI type > | > > |i386 > |long > |4 > |long > | > > |LP64 > |long > |8 > |long long > | > > |LLP64 > |long > |4 > |long > | > |=== I guess I need to work on the exporter for tables ;) > Ensuring this mappings happens when compiling an UFFI method (and a structure, etc.) we can workaround > the plugin limitation. > > So I worked taking Ronie's work, extended it to structures and added my own work on mapping structures > in a 'platform-agnostic' way: the idea is to take values by 'offset' instead the constant value as > it was done up to now. On 'structure-compilation time' (it happens first time structure is used on a > session), it calculates also the correct field access offsets and structure size. > > This is mostly working, it just lacks some testing and pushing it to image... then I can start prepare > Athens, SDL2 and libgit2 bindings to work both in 32 and 64 bits :) > > > 16 February 2017: > ----------------- > > * I continue enhancing [iceberg](https://github.com/npasserini/iceberg/pull/277) as much as I can, waiting to > +0.4 release+ (that should be very soon). > > I added a couple of new things: > > * capability of plugins to extend "remotes panel" of repositories browser (so we can have options there) > * added a new GitHub option: remove old branches dialog. > * and I started a refactor of GitHub plugin to use a command-pattern hierarchy instead polluting the plugin. > > Rationale of plugin action addition is simple: if we receive a lot of bugfixes in the form of a pull request, > it means people will be spawning branches all over the place, those branches can stay there a lot of time > but eventually, is good to clean up a bit. Now we can do this cleaning from Pharo :) > > This is not just useful but it shows the power we can achieve by extending iceberg with plugins for different > purposes ;) > > > 15 February 2017: > ----------------- > > * I spent some time bringing back some functionality I implemented for [voyage](https://github.com/pharo-nosql/voyage) > a lot of time ago (like 4 years) that went missing because of lack of use. > > This is a "dinamic singleton access strategy"... something like that, more or less... > > The idea of this is, sometimes you need to have more than one repository active in an image, but you still > want to use the singleton strategy (because is a lot cooler doing something like +Person selectOne: [ ... ]+ > instead of +myRepository selectOne: Person where: [...]+. > > Voyage always allowed different container strategies, even if in master implementation there is just one, > +VOSingletonContainer+. Now I added another called +VODynamicContainer+ and this allow to take the > repostory from a 'dynamic variable' called +VOCurrentRepository+. > > So, for instance, when you have a seaside application where each user works on his own database, you can create > a filter of the way: > > ---- > VoyageFilter>>handleFiltered: aRequestContext > VOCurrentRepository > value: self obtainUserRepository > during: [ self next handleFiltered: aRequestContext ] > > VoyageFilter>>obtainUserRepository > ^ self session > propertyAt: #voyageRepository > ifAbsentPut: [ VOMongoRepository database: (self session propertyAt: #username) ] > ---- > > ... adn you will handle your application as if your repository would be a singleton. > > To make this work, the only thing you need is to configure your repository this way: > > ---- > VORepository repositoryContainer: VODynamicContainer new > ---- > > > 14 February 2017: > ----------------- > > * I lost all day digging the problem with +FFICallbackTests+ on windows platforms. > > The problem occurs when going back to the image from a callback context 'when calling the tests'. Is > important to remark this because other systems using a lot of callbacks are working fine (notably iceberg, > the libgit2 bindings use callbacks as an important part of his design). Also +Athens+ (who uses callbacks > to provide some values cairo lib needs) is working correctly too. > > So, I'm tempted to think it may be a problem with +MinGW+ implementation of +qsort+ function, and we use it > to test the callbacks... anyway, I will keep digging when I find some more time, for now is enough to constate > it is not being a problem for windows users (unless, of course, they need to use qsort ;) ) > > > 13 February 2017: > ----------------- > > * I worked on a plugin for iceberg that will take the place of the old "create SLICE"... so far is a very simple > plugin that does exactly wjat the slice creator did: takes an issue number and gets the title from it, to > conform a branch name called +12345-issue-title-here+. > > With this change (pull request [here](https://github.com/npasserini/iceberg/pull/277)) all pieces to replace > the old fix process are there: > > * adding remotes (so you can clone pharo and use your remote as temporal destination) > * creating pull requests (so you can submit your changes in a fancy way) > * creating branches that conforms to our convention (so you can create branches as we like them ;) > > ... all this in an easy way (at least for me, heh). > > It remains, of course, test everything and enhance it with user feedback, but we will be starting that next > week. > > * I finally finished restoring testing phase to [VM building](https://github.com/pharo-project/pharo-vm). > The purpose of this is, of course, to notice regressions on VMs as soon as we can, and of course, I found > some regressions I needed to fix before being able to have a green build. Most of them were details but: > > * there was an important problem with +String+ primitives I needed to dealt with. > * there is a problem on +FFICallback+ for windows who make the test crash (but callbacks works most of the time) > > There are, however, still some important problems to fix: > > * threaded VM linux cannot be tested because they requiere changing some linux configuration. > * 64bits VMs still cannot be tested because I need to prepare a special image for it. > > I will try to fix some of this problems soon, but at least now we are "as we were before" :) > > > cheers! > Esteban

Feb. 20, 2017

[pharo-project/pharo-core] c37833: 50769

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: c378335143a126714852fb8df52b7a78d4cdb6f7 https://github.com/pharo-project/pharo-core/commit/c378335143a126714852fb8d… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-02-20 (Mon, 20 Feb 2017) Changed paths: M Polymorph-Widgets.package/Pharo3DarkTheme.class/instance/initialize-release/initialize.st A Polymorph-Widgets.package/Pharo3Theme.class/instance/initialize-release/initialize.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50768.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50769.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50768.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50769.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50769 19310 Backport Pharo 5.0: Wrong border after dragging out of a window group (backport 19299) https://pharo.fogbugz.com/f/cases/19310 http://files.pharo.org/image/50/50769.zip

Feb. 20, 2017

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50769 Home: https://github.com/pharo-project/pharo-core

Feb. 20, 2017

[Pharo6][Issue Tracker] Please check Issues tagged Milestone-6.0

by denker

Hi, We have right now 112 issues tagged to be fixed before we can release Pharo6: https://pharo.fogbugz.com/f/filters/1192/6-0-All <https://pharo.fogbugz.com/f/filters/1192/6-0-All> It would be nice if everyone could check the issues and help deciding: âis this a blocking issue that holds up release?â If no â> remove Pharo6 milestone. Do not put it on Pharo7, just âLaterâ. Marcus

Feb. 20, 2017

Esteban's ChangeLog week of 13 February 2017

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 13 February 2017 to 19 February 2017. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=13/2/2017&to=19/2/2017 ChangeLog ========= 17 February 2017: ----------------- * I spent sometime working on UFFI and 64bits. Sometime ago I started this and found a problem that I talked with Eliot, you can found the rational [here](http://forum.world.st/Support-for-LP64-amp-LLP64-in-FFI-Kernel-td4929946.html) (we need to model in some way the fact that longs have different sizes in different platforms, notably LP64 and LLP64). In that discussion, with Eliot we proposed to add a new FFI type, a +platformLong+ who will behave as expected. I started to implement but didn't have the time to finish it and I needed to jump to other stuff. In the mean time, Ronie found a different workaround: instead adding support in the VM, just map in image the type to correct size. This is how it will work: |=== |Platform |type |size |FFI type | |i386 |long |4 |long | |LP64 |long |8 |long long | |LLP64 |long |4 |long | |=== Ensuring this mappings happens when compiling an UFFI method (and a structure, etc.) we can workaround the plugin limitation. So I worked taking Ronie's work, extended it to structures and added my own work on mapping structures in a 'platform-agnostic' way: the idea is to take values by 'offset' instead the constant value as it was done up to now. On 'structure-compilation time' (it happens first time structure is used on a session), it calculates also the correct field access offsets and structure size. This is mostly working, it just lacks some testing and pushing it to image... then I can start prepare Athens, SDL2 and libgit2 bindings to work both in 32 and 64 bits :) 16 February 2017: ----------------- * I continue enhancing [iceberg](https://github.com/npasserini/iceberg/pull/277) as much as I can, waiting to +0.4 release+ (that should be very soon). I added a couple of new things: * capability of plugins to extend "remotes panel" of repositories browser (so we can have options there) * added a new GitHub option: remove old branches dialog. * and I started a refactor of GitHub plugin to use a command-pattern hierarchy instead polluting the plugin. Rationale of plugin action addition is simple: if we receive a lot of bugfixes in the form of a pull request, it means people will be spawning branches all over the place, those branches can stay there a lot of time but eventually, is good to clean up a bit. Now we can do this cleaning from Pharo :) This is not just useful but it shows the power we can achieve by extending iceberg with plugins for different purposes ;) 15 February 2017: ----------------- * I spent some time bringing back some functionality I implemented for [voyage](https://github.com/pharo-nosql/voyage) a lot of time ago (like 4 years) that went missing because of lack of use. This is a "dinamic singleton access strategy"... something like that, more or less... The idea of this is, sometimes you need to have more than one repository active in an image, but you still want to use the singleton strategy (because is a lot cooler doing something like +Person selectOne: [ ... ]+ instead of +myRepository selectOne: Person where: [...]+. Voyage always allowed different container strategies, even if in master implementation there is just one, +VOSingletonContainer+. Now I added another called +VODynamicContainer+ and this allow to take the repostory from a 'dynamic variable' called +VOCurrentRepository+. So, for instance, when you have a seaside application where each user works on his own database, you can create a filter of the way: ---- VoyageFilter>>handleFiltered: aRequestContext VOCurrentRepository value: self obtainUserRepository during: [ self next handleFiltered: aRequestContext ] VoyageFilter>>obtainUserRepository ^ self session propertyAt: #voyageRepository ifAbsentPut: [ VOMongoRepository database: (self session propertyAt: #username) ] ---- ... adn you will handle your application as if your repository would be a singleton. To make this work, the only thing you need is to configure your repository this way: ---- VORepository repositoryContainer: VODynamicContainer new ---- 14 February 2017: ----------------- * I lost all day digging the problem with +FFICallbackTests+ on windows platforms. The problem occurs when going back to the image from a callback context 'when calling the tests'. Is important to remark this because other systems using a lot of callbacks are working fine (notably iceberg, the libgit2 bindings use callbacks as an important part of his design). Also +Athens+ (who uses callbacks to provide some values cairo lib needs) is working correctly too. So, I'm tempted to think it may be a problem with +MinGW+ implementation of +qsort+ function, and we use it to test the callbacks... anyway, I will keep digging when I find some more time, for now is enough to constate it is not being a problem for windows users (unless, of course, they need to use qsort ;) ) 13 February 2017: ----------------- * I worked on a plugin for iceberg that will take the place of the old "create SLICE"... so far is a very simple plugin that does exactly wjat the slice creator did: takes an issue number and gets the title from it, to conform a branch name called +12345-issue-title-here+. With this change (pull request [here](https://github.com/npasserini/iceberg/pull/277)) all pieces to replace the old fix process are there: * adding remotes (so you can clone pharo and use your remote as temporal destination) * creating pull requests (so you can submit your changes in a fancy way) * creating branches that conforms to our convention (so you can create branches as we like them ;) ... all this in an easy way (at least for me, heh). It remains, of course, test everything and enhance it with user feedback, but we will be starting that next week. * I finally finished restoring testing phase to [VM building](https://github.com/pharo-project/pharo-vm). The purpose of this is, of course, to notice regressions on VMs as soon as we can, and of course, I found some regressions I needed to fix before being able to have a green build. Most of them were details but: * there was an important problem with +String+ primitives I needed to dealt with. * there is a problem on +FFICallback+ for windows who make the test crash (but callbacks works most of the time) There are, however, still some important problems to fix: * threaded VM linux cannot be tested because they requiere changing some linux configuration. * 64bits VMs still cannot be tested because I need to prepare a special image for it. I will try to fix some of this problems soon, but at least now we are "as we were before" :) cheers! Esteban

Feb. 20, 2017

Re: [Pharo-dev] Catalog loading in Spotter

by Ben Coman

On Mon, Feb 20, 2017 at 4:05 AM, Torsten Bergmann <astares(a)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. >

Feb. 20, 2017

Re: [Pharo-dev] Catalog loading in Spotter

by phil＠highoctane.be

A. Phil On Sun, Feb 19, 2017 at 10:40 PM, Sven Van Caekenberghe <sven(a)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(a)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. > > > > >

Feb. 19, 2017

Re: [Pharo-dev] Catalog loading in Spotter

by Sven Van Caekenberghe

I understand completely, I agree and strongly vote for A as well. > On 19 Feb 2017, at 21:05, Torsten Bergmann <astares(a)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. >

Feb. 19, 2017

Re: [Pharo-dev] confused about printString and printIt

by John Brant

On 02/19/2017 09:14 AM, stepharong wrote: > > Hi John > >> The tools aren't the ones putting the quotes around the string. >> Calling #printString on a String puts the quotes around the string. If >> you were to put quotes around other printString's then you would need >> to special case String to not put the quotes around twice. > > I do not understand your printString point. > to me printString contract is: return a string to represent the receiver > (not talking about self evaluating objects here). > > so why when I have > > (MFDirectory new name: 'comics') printIt > > I do not get why I do not get > 'comics' but comics > since printIt invokes printString? If I understand your code correctly, I think the printOn: method (invoked from printString) is calling Stream>>#<<. That method calls String>>#putOn: which calls Stream>>#nextPutAll:. That method just puts every character in the string on the stream. Now, when you invoke String>>#printString, it calls String>>#printOn: which calls String>>#storeOn:. #storeOn: adds the beginning and ending quotes (as well as doubling any quotes in the middle of the string). The printString of a string is never equal to itself since it is adding the quotes: 'a' printString = 'a' "false" However, when compiled it is equal: (Compiler evaluate: 'a' printString) = 'a' "true" > Now I probably broke myself this contract when I introduced > self-evaluating objects. > > true printIt >>>> true is probably wrong. > > May be printIt is the wrong name. > > May be this is displayResult > > I do not know there is something confusing. > > I'm confuse ;( You are not printing the string, you are printing an object which creates a string and that string is then displayed. Displaying a string doesn't add the extra quotes like printing a string does. What should be the first character of the printString of true? To me, if you have it being a quote ('), then it is wrong. The printString of true should be true (in Smalltalk literal string format 'true'). However, having the first character of a printString of a string be a quote makes it easier for me as a developer to see that the object that was printed was a string and not something else. If I didn't want the quote, then I should have probably used the displayString method. >> The current implementation looks right to me. #printString returns a >> string to help developers. #printString on some objects returns a >> string that when evaluated creates an equivalent object (e.g., String, >> Point, etc.). > > I did the self-evaluating behavior and I'm thinking that may be this is > wrong and that > we should always get a string not matter what happens. > >> However, on other objects it returns a string that only helps the >> developer see what the object is (e.g., OrderedCollection). The trick >> is to know which object's printString can be evaluated and which are >> only for display. > > This is where I think that displayString is different than printString > and that > printString no matter what should be consitent > I should return a string and the tools like the repl should display such > as a string. It is consistent. #printString returns a string. That string is then displayed. Displaying a string just puts the characters on the display without adding anything else. I think your confusion may be that printString on a string object returns another string with quotes that when evaluated returns another string equivalent to the original. What characters #printString puts in the string is up to the developer. It should be what they think is important to display when developing the code. For strings, someone decided that it would be good to return another string that when evaluated would return an equivalent string. This is not necessary -- it could have just returned itself. However, I think the choice was a good one as developers can more easily see when something is a string vs. some other object. John Brant

Feb. 19, 2017