- Pharo-dev - lists.pharo.org

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

by Ben Coman

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] Debugger "reporting" feature

by Denis Kudriashov

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 actually 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] Debugger "reporting" feature

by Peter UhnÃ¡k

Is this functionality actually 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

Debugger "reporting" feature

by Ben Coman

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] Baseline/Configuration loading bars

by jtstowell

Most packages seem to write to the system transcript during the install process, with a fairly clear "all done" message upon completion. That's one way to keep tabs on the longer installs. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Nov. 2, 2017

OSWindow OS X VM bug

by Ronie Salgado

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] Baseline/Configuration loading bars

by Dale Henrichs

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 <mailto:stepharo.self@gmail.com>> wrote: > > Agreed! > > > On Tue, Oct 31, 2017 at 9:42 PM, Jan BlizniÄenko > <bliznjan(a)fit.cvut.cz <mailto: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 > <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 > <http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html> > > > >

Nov. 1, 2017

Re: [Pharo-dev] Layout for placing widgets

by Ben Coman

On Wed, Nov 1, 2017 at 7:14 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi stephan > > can you republish it with your fixes > > Now I was a bit disappointed by the speed of the examples. > I also had some concerns. It did seem a bit to be more sluggish getting started, and not too bad once moving. On the other hand, windows aren't resized very often. Also I wonder that a linear solver *must* have some strong hotspots, and may be a good candidate for sista/scorch optimization. cheers -ben > Stef > > On Tue, Oct 31, 2017 at 9:31 AM, stephan <stephan(a)stack.nl> wrote: > > On 28-10-17 16:26, Stephane Ducasse wrote: > >> > >> I was reading ... > >> I will see if I can load cassowary in Pharo. > > > > > > I could get the squeaksource cassowary for morphic working without a > > problem, just needed some extensions and fixes for changes we made in > Pharo. > > > > Stephan > > > > > >

Nov. 1, 2017

Re: [Pharo-dev] Layout for placing widgets

by Stephane Ducasse

Hi stephan can you republish it with your fixes Now I was a bit disappointed by the speed of the examples. Stef On Tue, Oct 31, 2017 at 9:31 AM, stephan <stephan(a)stack.nl> wrote: > On 28-10-17 16:26, Stephane Ducasse wrote: >> >> I was reading ... >> I will see if I can load cassowary in Pharo. > > > I could get the squeaksource cassowary for morphic working without a > problem, just needed some extensions and fixes for changes we made in Pharo. > > Stephan > >

Nov. 1, 2017

Re: [Pharo-dev] [Pharo-users] potentially useful diagrams

by Stephane Ducasse

> Hi Stef, > just one thing troubles me: there are two working copies: files on disk and > the image by itself. Yes :) > What are the possible modes of operation? > - operate exclusively from Pharo IDE - and that will take care of allways > synching the two copies (user never have to care of the one on disk) This is what you do when you load or merge code. > - operate exlcusively from Pharo IDE and interact with low level git API to > completely avoid the working copy on disk (the next step) I do not think that you can. > - operate either from Pharo IDE or any other git client (including command > line) and manage to sync the two working copies > > 2017-11-01 1:38 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >> >> Thanks Stef. They will be very useful. >> I presume the simpler one is for projects you own, and the other is >> contributing to third-party projects. It would be good to be explicit by >> adding such a title to distinguish them. >> >> If your software allows, it might be enhanced by: >> * adding sequence numbers >> * draw a line to text like "clone" to a bitmap of the matching Pharo menu >> item >> >> cheers -ben >> >> On Tue, Oct 31, 2017 at 11:36 PM, Stephane Ducasse >> <stepharo.self(a)gmail.com> wrote: >>> >>> Hi >>> >>> during the last sprint we were brainstorming how we can help people to >>> understand the git hub setup. >>> I produced these two diagrams with christophe. >>> >>> Are they useful for you? >>> >>> Stef >> >> >

Nov. 1, 2017