Super tx Cyril Tx dale. I think that Camillo back then introduced Job. Stef On Thu, Nov 2, 2017 at 7:00 PM, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Cyrille has submitted a bug[1] and I believe that he is taking a crack at a fix ...
Personally I am not aware of whether or not String>>displayProgressAt:from:to:during: still exists and if not whether or not it is the approved api for interacting with progress bars ... I sort of assumed that it was dropped because the progress bar API changed, but it may have been inadvertently dropped on the floor, since it's absence is not an error ... once the correct API is identified, the fix can be merged into the master branch for Metacello.
The next step would be to ensure that the latest version of Metacello is included in new builds for Pharo6.1/7.0 and I believe that Esteban is tackling that bit...There are now 6.1/7.0 tags for Metacello that are presumably used by the Pharo build process ...
Dale
[1] https://github.com/Metacello/metacello/issues/466
On 11/02/2017 10:18 AM, Stephane Ducasse wrote:
Hi dale
I'm confused :) what we should do? I could not get it (ok I'm a doct waiting room so not a super place to check). Stef
On Wed, Nov 1, 2017 at 4:43 PM, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Ben,
I took a look at this and Metacell has wrapped the load expressions with a MetacelloPlatform>>do:displaying: call that presumably is supposed to show the progress bars continuously during a Metacello load, but a check in Pharo3.0 shows that the Pharo platform class don't override the default implementation.
The original implementation of the method was in the Metacello-Platform,pharo package ... which was for Pharo1.0 --- so Metacello progress bar display has not been properly functioning since then (about 5 years) --- and not noticed until now:)
It should be possible to implement that method for Pharo6.0/7.0 and see continuous progress bars again ...
Dale
[1]
https://github.com/Metacello/metacello/blob/master/repository/Metacello-Plat...
On 10/31/17 6:05 PM, Ben Coman wrote:
I would guess the problem with doing this pervasively is (IIUC) that Configurations are self-contained/self-bootstrapping so each Configurationhas its own copy of #load (I've no access to an Image to check right now) Perhaps it could be a use case for metalinks. When Configurations are loaded, insert a #notify: at the end of certain api methods.
cheers -ben
On Wed, Nov 1, 2017 at 4:50 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Agreed!
On Tue, Oct 31, 2017 at 9:42 PM, Jan BlizniÄenko <bliznjan@fit.cvut.cz> wrote:
Hello
I have never paid any attention to following thing, but now I use Pharo to teach students object oriented programming and there is one thing that I realized how very bad is from user experience perspective: When I am loading package with lots of dependencies, like Moose or Seaside, it may take multiple minutes (especially on Windows) and those loading bars are there half of a time, but half of a time there is nothing, just nothing - it looks like finished, but it is in fact still loading and everything is therefore sluggish. If I was not sure it is in actually still loading just fine, I would try to kill the process and try again. Example which causes such loading without much of UI is this one:
Gofer it smalltalkhubUser: 'zeroflag' project: 'Teapot'; configuration; loadStable. Metacello new repository: 'http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main'; configuration: 'Seaside3'; version: #'release3.2'; load: #('OneClick').
It would be nice to have some loading bar or something like "loading packages, please wait..." there at all times until baseline/configuration loading is completely done... also some confirming message like "ConfigurationOfSeaside3 loaded successfully" would be nice
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html