- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

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

Feb. 20, 2017

[pharo-project/pharo-core] fa70f9: 60401

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: fa70f974f905df2af78bce55c4d9d00d732055ff https://github.com/pharo-project/pharo-core/commit/fa70f974f905df2af78bce55… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-02-20 (Mon, 20 Feb 2017) Changed paths: A STON-Tests.package/STONWriteReadTests.class/instance/tests/testUUIDs.st M STON-Tests.package/STONWriterTests.class/instance/tests/testDictionaryWithComplexKeys.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60400.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60401.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60400.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60401.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Inspector.package/EyeAbstractInspector.class/instance/menu/inspectionMenu_.st A Spec-Inspector.package/EyeTreeInspector.class/instance/menu/inspectionMenu_.st A Spec-Inspector.package/EyeTreeInspector.class/instance/smartSuggestions - support/selectedMessage.st M Tool-ExternalBrowser.package/ExternalBrowser.class/class/System-FileRegistry/serviceBrowseCode.st M Tool-ExternalBrowser.package/ExternalChangesBrowser.class/class/file service/serviceBrowseCSOrSTFile.st R Tool-FileList.package/FileList.class/class/modal dialogs/modalFolderSelector_.st M Tool-FileList.package/FileList.class/class/morphic ui/openOn_.st M Tool-FileList.package/FileList.class/definition.st R Tool-FileList.package/FileList.class/instance/accessing/brevityState.st M Tool-FileList.package/FileList.class/instance/accessing/reference_.st M Tool-FileList.package/FileList.class/instance/file list menu/fileContentsMenu_shifted_.st R Tool-FileList.package/FileList.class/instance/own services/servicesFromSelectorSpecs_.st R Tool-FileList.package/FileList.class/instance/volume menu/addServiceOn_entitled_doing_describedAs_.st R Tool-FileList.package/FileList.class/instance/volume menu/addServiceTitled_doing_describedAs_.st R Tool-FileList.package/FileList.class/instance/volume menu/addService_.st Log Message: ----------- 60401 19488 STONWriterTests>>#testDictionaryWithComplexKeys is order dependent https://pharo.fogbugz.com/f/cases/19488 18584 DNU on showing menu in PointerExplorer https://pharo.fogbugz.com/f/cases/18584 18459 FileList calls unimplemented method allRegisteredServices https://pharo.fogbugz.com/f/cases/18459 18724 DNU EyeTreeInspector workspace pane context menu https://pharo.fogbugz.com/f/cases/18724 http://files.pharo.org/image/60/60401.zip

Feb. 20, 2017

Re: [Pharo-dev] WorkingSession UUID looks "sketchy"

by Guillermo Polito

On Mon, Feb 6, 2017 at 6:54 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > 1. Regarding WorkingSession > > The WS' comment claims "On each image startup the current session is > invalidated and a new session is created.", > but in reality WS is reset only save&quit, and not on startup... isn't > that odd? > So if image crashes or I am running it headlessly without saving I am > actually still on the same session. > > Peter, how can we make this an actionable point? Guille

Feb. 20, 2017

[ANN] Pharo Sprint March 3

by Marcus Denker

Pharo Sprint March 3 We will organize a Pharo sprint / Moose dojo March, 03, starting at 10:00am. (Local Time Paris). Goals of this sprint: â¢ Clean issue tracker to prepare for release Pharo6 â¢ remove Pharo6 tag from not-important cases â¢ Check Pharo5 Issues and pending back-ports https://association.pharo.org/event-2451866 Marcus

Feb. 20, 2017

Re: [Pharo-dev] Segmentation fault while installing Scale

by Guillermo Polito

Maybe it's something to do with his gentoo's version of some library? libc? It looks like it's some problem of Pharo in gentoo, not necessarily scale. On Sun, Feb 12, 2017 at 11:05 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Note that he managed to run the System Report UI, which means his image > was running pretty normally at some point ... > > > On 12 Feb 2017, at 10:26, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Sun, Feb 12, 2017 at 5:18 AM, Andriy Tykhonov <atykhonov(a)gmail.com> > wrote: > >> Ben Coman <btc(a)openinworld.com> writes: > >> > >>> Are you on 64-bit using 32-bit Pharo? > >> > >> This is not pure 64-bit system. This is multilib setup. So, I can > execute > >> 32-bit and 64-bit programs on the same machine. This is recent system > >> installation, and Pharo doesn't work well on it. But it did work well on > >> another Gentoo Linux system with the same multilib support. > >> > >>> Can you use ldd to check the pharo binary is linking to these 32-bit > libraries? > >>> http://pharo.org/gnu-linux-installation > >> > >> $ ldd ./pharo-vm/pharo > >> > >> linux-gate.so.1 (0xf76f6000) > >> libm.so.6 => /lib32/libm.so.6 (0xf7664000) > >> libdl.so.2 => /lib32/libdl.so.2 (0xf765f000) > >> libpthread.so.0 => /lib32/libpthread.so.0 (0xf7643000) > >> libc.so.6 => /lib32/libc.so.6 (0xf7496000) > >> /lib/ld-linux.so.2 (0xf76f7000) > > > > Okay, so four out of six are obviously bound to 32bit libs. > > > > linux-gate seems okay per... > > http://man7.org/linux/man-pages/man7/vdso.7.html > > Note that the vDSO that is used is based on the ABI of your user- > > space code and not the ABI of the kernel. Thus, for example, when > > you run an i386 32-bit ELF binary, you'll get the same vDSO > > regardless of whether you run it under an i386 32-bit kernel or > under > > an x86_64 64-bit kerne l. > > > > Could you check if ld-linux symlinks to 32-bit location? > > > >> > >> This is mostly the same output (except addresses, such as 0xf76f6000, -- > >> I'm writing about this fact just because I'm not sure whether it is > >> important) which I had seen on the previous Gentoo Linux system. > >> > >>> > >>> When you get it working can you provide a recipe for the download page. > >>> > >>> Alternatively you might try either (pre-release) 64-bit VM from... > >>> http://files.pharo.org/vm/pharo-spur64/linux/ > >>> * pharo-linux-x86_64threaded-201702061308-aa78f27.zip > >>> * pharo-linux-x86_64itimer-201702030802-61970b6.zip > >> > >> I have tried both with the image downloaded from > >> http://files.pharo.org/image/60/ (Pharo-Image-6.0-latest.zip). > >> > >> I get the same result: > >> > >> $ ./pharo Pharo-60386.image > >> This interpreter (vers. 68021) cannot read image file (vers. 6521). > >> Press CR to quit... > >> zsh: exit 1 ./pharo ../tmp64/Pharo-60386.image > > > > I'm not completely sure, but I think this indicates you're using > > a 64-bit VM (68021) to open a 32-bit Image (6531). > > IIUC you need to use Pharo64-60386.image from this zip... > > > > However I guess Scale needs FFI and I'm not sure > > of 64 bit FFI status on Linux. (Esteban?) > > > >>> http://files.pharo.org/image/60/ > >>> * 60385-64.zip > > > > > >>> On Sat, Feb 11, 2017 at 5:49 AM, Andrey Tykhonov <atykhonov(a)gmail.com> > wrote: > >>>> Hi all, > >>>> > >>>>> and which VM do you use (there is a System report browser where you > can > >>>>> find the information. > >>>> > >>>> I've somehow managed to get the information from System report > browser: > >>>> > >>>> Image > >>>> ----- > >>>> /home/demi/mess/2017/06/tmp2/Pharo.image > >>>> Pharo5.0 > >>>> Latest update: #50768 > >>>> Unnamed > >>>> > >>>> Virtual Machine > >>>> --------------- > >>>> /home/demi/mess/2017/06/tmp2/pharo-vm/pharo > >>>> CoInterpreter VMMaker.oscog-eem.1855 uuid: > >>>> d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 > >>>> StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: > >>>> d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 > >>>> https://github.com/pharo-project/pharo-vm.git Commit: > >>>> b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 > +0200 By: > >>>> Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #589 > >>>> > >>>> Unix built on May 4 2016 11:54:41 Compiler: 4.6.3 > >>>> VMMaker versionString https://github.com/pharo-project/pharo-vm.git > Commit: > >>>> b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 > +0200 By: > >>>> Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #589 > >>>> CoInterpreter VMMaker.oscog-eem.1855 uuid: > >>>> d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 > >>>> StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: > >>>> d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 > >>>> > >>>> > >>>> I noticed that there are more items which could be selected (list in > the > >>>> left bar, I mean System report browser), but I cannot get more info, > because > >>>> pharo crashes each time I try to select all text from the all items. > May be > >>>> it would be helpful (and I'll be able to) to get information only > from some > >>>> particular item? But then, I need to know which exactly items would be > >>>> helpful. > >>>> > >>>> Also, I'm attaching to this email log file after execution of the > Pharo with > >>>> strace: > >>>> > >>>> strace ./pharo-ui Pharo.image > pharo-ui-with-strace.log 2>&1 > >>>> > >>>> I hope it could shed more light on the issue. > > >

Feb. 20, 2017

Re: [Pharo-dev] 2 seconds default time limit for tests

by Ben Coman

When we come to do this, could there be some mechanism to scale *all* these timeouts. For example, to investigate VM crashes we might want to run all tests under a debug VM which would greatly extend the time taken for each test, and it would be a pain to get a bundle of false positives. Perhaps it might autoscale by how many sends execute with one second in a loop before tests are run, or similar. cheers -ben On Fri, Feb 17, 2017 at 6:03 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > I moved issue to Pharo 7 > > 2017-02-16 13:33 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> >> Hi. >> >> In Pharo 6 we introduced time limit for tests. Currently it is set to 1 >> minute by default. And concrete test cases or single tests can redefine it >> with suitable value. There is also setting to change default limit globally >> which should help to not adopt external projects immediately if current >> limit is bad for them. >> >> There is issue 19105 to make limit really small. It will set default limit >> for 2 seconds. Slow tests are already marked with bigger value. So it is >> safe for integration >> >> Here I ask for your agreement with this change. Or disagreement if there >> are good reasons to not do this. >> >> I hope following story will convince you that default time limit should be >> small: >> >> I worked on tests for new project and I got hanging tests. These tests >> were waiting for some event which not happens because of bugs. They will be >> failed after 1 minutes due to timeout. >> >> But when you work on code you of course do not want to wait 1 minute. So >> it always forces manual interrupt of running tests. But then you could not >> run full test suite to see all problem tests. And also it is not really easy >> to detect current running test after interrupt. You need analyze stack in >> debugger and if you just close debugger information is lost. >> >> So to fix it I change default timeout in each of my test cases. >> If you will work on similar code you will need same approach to >> comfortably detect and fix "synchronization" bugs. >> >> So this was my story. I am sure default behaviour with small time limit >> will make SUnit much better. >> Common case is that unit tests are supposed to be fast. Users expect it by >> default. And if something is going wrong fast tests should fail fast. >> When user wrote slow test it is expected to know that test is slow. And >> for such rare cases user can mark slow tests explicitly. But SUnit should >> not expect tests to be slow by default. >> >> I think it is really good improvement for Pharo 6. It makes TDD in Pharo >> better. >> >> Best regards, >> Denis > >

Feb. 20, 2017

Re: [Pharo-dev] Catalog loading in Spotter

by Sven Van Caekenberghe

> On 20 Feb 2017, at 10:30, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > > 2017-02-20 10:27 GMT+01:00 Guillermo Polito <guillermopolito(a)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(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] Catalog loading in Spotter

by Pavel Krivanek

2017-02-20 10:27 GMT+01:00 Guillermo Polito <guillermopolito(a)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(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] 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