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

Re: [Pharo-dev] Baseline/Configuration loading bars

by Dale Henrichs

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(a)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-Pla… >> >> >> 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(a)gmail.com> >> wrote: >>> Agreed! >>> >>> >>> On Tue, Oct 31, 2017 at 9:42 PM, Jan BlizniÄenko <bliznjan(a)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 >>>> >>

Nov. 2, 2017

Re: [Pharo-dev] Baseline/Configuration loading bars

by Stephane Ducasse

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(a)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-Pla… > > > 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(a)gmail.com> > wrote: >> >> Agreed! >> >> >> On Tue, Oct 31, 2017 at 9:42 PM, Jan BlizniÄenko <bliznjan(a)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 >> > >> > >

Nov. 2, 2017

Re: [Pharo-dev] OSWindow OS X VM bug

by Stephane Ducasse

Thanks ronie! This is important for the future of Pharo. On Thu, Nov 2, 2017 at 2:48 AM, Ronie Salgado <roniesalg(a)gmail.com> wrote: > Hi, > > I finally managed to track the problem with keyboard events with OSWindow. > However, I cannot fix it without introducing a crash in an autorelease, or a > memory leak. > > The SDL2 problem can be fixed by applying the following patch: > > diff --git a/platforms/iOS/vm/Common/Classes/sqSqueakEventsAPI.m > b/platforms/iOS/vm/Common/Classes/sqSqueakEventsAPI.m > index 94c3c4c82..4b5aec8c5 100644 > --- a/platforms/iOS/vm/Common/Classes/sqSqueakEventsAPI.m > +++ b/platforms/iOS/vm/Common/Classes/sqSqueakEventsAPI.m > @@ -100,9 +100,7 @@ sqInt ioProcessEvents(void) { > > // We need to run the vmIOProcessEvents even if we are using SDL2, > // otherwise we end with some double free errors in an autorelease pool. > - vmIOProcessEvents(); > - if(ioProcessEventsHandler && ioProcessEventsHandler != > vmIOProcessEvents) > - ioProcessEventsHandler(); > + ioProcessEventsHandler(); > > However, this introduces a crash in an Objective-C autorelease pool, in at > leas two locations: > > diff --git a/platforms/iOS/vm/OSX/sqSqueakOSXApplication+events.m > b/platforms/iOS/vm/OSX/sqSqueakOSXApplication+events.m > index 4f2ac06ea..c1ec3e1ea 100644 > --- a/platforms/iOS/vm/OSX/sqSqueakOSXApplication+events.m > +++ b/platforms/iOS/vm/OSX/sqSqueakOSXApplication+events.m > @@ -152,9 +152,10 @@ - (void) recordCharEvent:(NSString *) unicodeString > fromView: (NSView <sqSqueakO > } > } > > - NSString *lookupString = AUTORELEASEOBJ([[NSString alloc] > initWithCharacters: &unicode length: 1]); > + NSString *lookupString = [[NSString alloc] initWithCharacters: &unicode > length: 1]; > [lookupString getBytes: &macRomanCharacter maxLength: 1 usedLength: NULL > encoding: NSMacOSRomanStringEncoding > options: 0 range: picker remainingRange: NULL]; > + [lookupString release]; > > evt.pressCode = EventKeyDown; > unsigned short keyCodeRemembered = evt.charCode; > > diff --git a/platforms/iOS/vm/OSX/sqSqueakOSXOpenGLView.m > b/platforms/iOS/vm/OSX/sqSqueakOSXOpenGLView.m > index c441332a3..72aa8c42d 100644 > --- a/platforms/iOS/vm/OSX/sqSqueakOSXOpenGLView.m > +++ b/platforms/iOS/vm/OSX/sqSqueakOSXOpenGLView.m > @@ -747,7 +747,7 @@ - (NSString *) dealWithOpenStepChars: (NSString *) > openStep { > > > -(void)keyDown:(NSEvent*)theEvent { > - keyBoardStrokeDetails *aKeyBoardStrokeDetails = > AUTORELEASEOBJ([[keyBoardStrokeDetails alloc] init]); > + keyBoardStrokeDetails *aKeyBoardStrokeDetails = ([[keyBoardStrokeDetails > alloc] init]); > aKeyBoardStrokeDetails.keyCode = [theEvent keyCode]; > aKeyBoardStrokeDetails.modifierFlags = [theEvent modifierFlags]; > > @@ -757,6 +757,8 @@ -(void)keyDown:(NSEvent*)theEvent { > [self interpretKeyEvents: down]; > self.lastSeenKeyBoardStrokeDetails = NULL; > } > + > + //[aKeyBoardStrokeDetails release]; > } > > In the last location I had to comment my attempt on doing a manual release > because it introduces a crash. > > OSWindow can be tested in a fresh Pharo image by doing the following in a > workspace: > >> FFIExternalStructure allSubclassesDo: #rebuildFieldAccessors. >> SDL_Event initialize. >> SDL2 findSDL2. >> OSWindowWorldMorph new open. > > > I have attached the full diff with my bug fix attempt. I hope that someone > that is more familiar with the OS X platform code and Objective-C can remove > these autoreleases without introducing crashes. > > When executed in a debugger, the crash is detected in SDL2 Cocoa_PumpEvents: > >>> void >>> >>> Cocoa_PumpEvents(_THIS) >>> >>> { @autoreleasepool >>> >>> { >>> >>> /* Update activity every 30 seconds to prevent screensaver */ >>> >>> SDL_VideoData *data = (SDL_VideoData *)_this->driverdata; >>> >>> if (_this->suspend_screensaver && !data->screensaver_use_iopm) { >>> >>> Uint32 now = SDL_GetTicks(); >>> >>> if (!data->screensaver_activity || >>> >>> SDL_TICKS_PASSED(now, data->screensaver_activity + 30000)) { >>> >>> UpdateSystemActivity(UsrActivity); >>> >>> data->screensaver_activity = now; >>> >>> } >>> >>> } >>> >>> >>> for ( ; ; ) { >>> >>> NSEvent *event = [NSApp nextEventMatchingMask:NSAnyEventMask >>> untilDate:[NSDate distantPast] inMode:NSDefaultRunLoopMode dequeue:YES ]; >>> >>> if ( event == nil ) { >>> >>> break; >>> >>> } >>> >>> >>> if (!s_bShouldHandleEventsInSDLApplication) { >>> >>> Cocoa_DispatchEvent(event); >>> >>> } >>> >>> >>> // Pass events down to SDLApplication to be handled in sendEvent: >>> >>> [NSApp sendEvent:event]; >>> >>> } >>> >>> }} >> >> > > For tracking these actual calls to #autorelease, I had to set a breakpoint > on the #autorelease Objective-C selector, and log the stacktrace to find > where it is called in our code. > > Best regards, > Ronie >

Nov. 2, 2017

Re: [Pharo-dev] Debugger "reporting" feature

by Stephane Ducasse

Can you open a bug entry? On Thu, Nov 2, 2017 at 4:16 PM, Ben Coman <btc(a)openinworld.com> wrote: > sounds good. > cheers -ben > > On Thu, Nov 2, 2017 at 10:55 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: >> >> Maybe we should name and implement it as "copy stack to clipboard"? >> >> 2017-11-02 13:19 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >>> >>> I've never used it to auto-report to any remote remote server. That part >>> can go. >>> But as I stated, I do find it useful for getting a text representation of >>> the stack for manually pasting into fogbugz issues, instead of having to dig >>> through the halos into the morph contents. >>> Can this part be kept and moved into the stack-context-menu? >>> >>> cheers -ben >>> >>> On Thu, Nov 2, 2017 at 5:59 PM, Denis Kudriashov <dionisiydk(a)gmail.com> >>> wrote: >>>> >>>> I think it is outdated feature and we should remove it to not confuse >>>> people. >>>> >>>> 2017-11-02 9:10 GMT+01:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: >>>>> >>>>> Is this functionality actuaat part can golly used? Where do the reports >>>>> end up? What is contained in the report? >>>>> >>>>> Peter >>>>> >>>>> On Thu, Nov 2, 2017 at 4:35 AM, Ben Coman <btc(a)openinworld.com> wrote: >>>>>> >>>>>> In the Pre-Debug window there is the <Report> button that coverts the >>>>>> call stack to text that can be pasted into an email. But when you proceed >>>>>> into the main debugger it seems you lose access to that feature. >>>>>> >>>>>> Would it be worth adding <Report> to the debugger context menu? >>>>>> >>>>>> cheers -ben >>>>> >>>>> >>>> >>> >> >

Nov. 2, 2017

Re: [Pharo-dev] [Pharo 7.0-dev] Build #251: 20616-Convert-file-format-to-tonel

by Esteban Lorenzano

Hi! this means you can go-back to contribute :) keep in mind: - you will need a new image. - you will need to have up-to-date your fork and clone. enjoy, Esteban > On 2 Nov 2017, at 16:12, ci-pharo-ci-jenkins2(a)inria.fr wrote: > > There is a new Pharo build available! > > The status of the build #251 was: SUCCESS. > > The Pull Request #423 was integrated: "20616-Convert-file-format-to-tonel" > Pull request url: https://github.com/pharo-project/pharo/pull/423 > > Issue Url: https://pharo.fogbugz.com/f/cases/20616 > Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 2, 2017

Re: [Pharo-dev] Debugger "reporting" feature

by Ben Coman

sounds good. cheers -ben On Thu, Nov 2, 2017 at 10:55 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Maybe we should name and implement it as "copy stack to clipboard"? > > 2017-11-02 13:19 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > >> I've never used it to auto-report to any remote remote server. That part >> can go. >> But as I stated, I do find it useful for getting a text representation of >> the stack for manually pasting into fogbugz issues, instead of having to >> dig through the halos into the morph contents. >> Can this part be kept and moved into the stack-context-menu? >> >> cheers -ben >> >> On Thu, Nov 2, 2017 at 5:59 PM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >>> I think it is outdated feature and we should remove it to not confuse >>> people. >>> >>> 2017-11-02 9:10 GMT+01:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: >>> >>>> Is this functionality actuaat part can golly used? Where do the reports >>>> end up? What is contained in the report? >>>> >>>> Peter >>>> >>>> On Thu, Nov 2, 2017 at 4:35 AM, Ben Coman <btc(a)openinworld.com> wrote: >>>> >>>>> In the Pre-Debug window there is the <Report> button that coverts the >>>>> call stack to text that can be pasted into an email. But when you proceed >>>>> into the main debugger it seems you lose access to that feature. >>>>> >>>>> Would it be worth adding <Report> to the debugger context menu? >>>>> >>>>> cheers -ben >>>>> >>>> >>>> >>> >> >

Nov. 2, 2017

[Pharo 7.0-dev] Build #251: 20616-Convert-file-format-to-tonel

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #251 was: SUCCESS. The Pull Request #423 was integrated: "20616-Convert-file-format-to-tonel" Pull request url: https://github.com/pharo-project/pharo/pull/423 Issue Url: https://pharo.fogbugz.com/f/cases/20616 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 2, 2017

Re: [Pharo-dev] Debugger "reporting" feature

by Denis Kudriashov

Maybe we should name and implement it as "copy stack to clipboard"? 2017-11-02 13:19 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > I've never used it to auto-report to any remote remote server. That part > can go. > But as I stated, I do find it useful for getting a text representation of > the stack for manually pasting into fogbugz issues, instead of having to > dig through the halos into the morph contents. > Can this part be kept and moved into the stack-context-menu? > > cheers -ben > > On Thu, Nov 2, 2017 at 5:59 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> I think it is outdated feature and we should remove it to not confuse >> people. >> >> 2017-11-02 9:10 GMT+01:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: >> >>> Is this functionality actuaat part can golly used? Where do the reports >>> end up? What is contained in the report? >>> >>> Peter >>> >>> On Thu, Nov 2, 2017 at 4:35 AM, Ben Coman <btc(a)openinworld.com> wrote: >>> >>>> In the Pre-Debug window there is the <Report> button that coverts the >>>> call stack to text that can be pasted into an email. But when you proceed >>>> into the main debugger it seems you lose access to that feature. >>>> >>>> Would it be worth adding <Report> to the debugger context menu? >>>> >>>> cheers -ben >>>> >>> >>> >> >

Nov. 2, 2017

Re: [Pharo-dev] [Pharo 7.0-dev] Build #250: 20616-Convert-file-format-to-tonel

by Esteban Lorenzano

> On 2 Nov 2017, at 15:34, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Fixed thanks! > > On Thu, Nov 2, 2017 at 3:10 PM, tesonep(a)gmail.com <mailto:tesonep@gmail.com> <tesonep(a)gmail.com <mailto:tesonep@gmail.com>> wrote: > This is a problem in the network, Guille is going to restart the nodes. > > On Thu, Nov 2, 2017 at 3:08 PM, <ci-pharo-ci-jenkins2(a)inria.fr <mailto:ci-pharo-ci-jenkins2@inria.fr>> wrote: > There is a new Pharo build available! > > The status of the build #250 was: FAILURE. > > The Pull Request #423 was integrated: "20616-Convert-file-format-to-tonel" > Pull request url: https://github.com/pharo-project/pharo/pull/423 <https://github.com/pharo-project/pharo/pull/423> > > Issue Url: https://pharo.fogbugz.com/f/cases/20616 <https://pharo.fogbugz.com/f/cases/20616> > Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> > > > > -- > Pablo Tesone. > tesonep(a)gmail.com <mailto:tesonep@gmail.com> > > > -- > > Guille Polito > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > CRIStAL - UMR 9189 > French National Center for Scientific Research - http://www.cnrs.fr <http://www.cnrs.fr/> > > Web: http://guillep.github.io <http://guillep.github.io/> > Phone: +33 06 52 70 66 13

Nov. 2, 2017

Re: [Pharo-dev] [Pharo 7.0-dev] Build #250: 20616-Convert-file-format-to-tonel

by Guillermo Polito

Fixed On Thu, Nov 2, 2017 at 3:10 PM, tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: > This is a problem in the network, Guille is going to restart the nodes. > > On Thu, Nov 2, 2017 at 3:08 PM, <ci-pharo-ci-jenkins2(a)inria.fr> wrote: > >> There is a new Pharo build available! >> >> The status of the build #250 was: FAILURE. >> >> The Pull Request #423 was integrated: "20616-Convert-file-format-to- >> tonel" >> Pull request url: https://github.com/pharo-project/pharo/pull/423 >> >> Issue Url: https://pharo.fogbugz.com/f/cases/20616 >> Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20p >> ull%20request%20and%20branch%20Pipeline/job/development/250/ >> > > > > -- > Pablo Tesone. > tesonep(a)gmail.com > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Nov. 2, 2017