- Pharo-users - lists.pharo.org

Re: [Pharo-users] OT: Re: Open Debugger, Save and Quit

by Stephane Ducasse

Pay attention Smalltalk at: -> Smalltalk globals at: Stef On Fri, Jan 12, 2018 at 3:15 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Wed, Nov 8, 2017 at 1:45 AM, Joachim Tuchel <jtuchel(a)objektfabrik.de> > wrote: >> >> Ben, >> >> (this is a bit off-topic) >> >> do you happen to know the purpose of that pre-debug-window? I must say >> that I find it annoying every time I get it in Pharo or VA? Why doesn't the >> debugger show up immediately? >> > > > I disabled that in all my images (via a startup setting). See > #alwaysOpenFullDebugger below: > > "Define some settings/preferences for GTDebugger" > (Smalltalk at: #GTGenericStackDebugger) perform: > #enableDebuggerWindowDistinctColor: with: true. > (Smalltalk at: #GTGenericStackDebugger) perform: #enableStackColoring: with: > true. > (Smalltalk at: #GTGenericStackDebugger) perform: #alwaysOpenFullDebugger: > with: true. > > > Cheers, > > > > >> But your suggestion is a good one, imo. In the startup phase of an image, >> the image might not be ready to provide any means of reacting to a problem, >> so why bother showing errors that early? >> >> What you describe should be quite easy to achieve with a handler that >> records and resumes errors during startup. >> >> Joachim >> >> Am 08.11.2017 03:54 schrieb Ben Coman <btc(a)openinworld.com>: >> > >> > >> > >> > On Wed, Nov 8, 2017 at 10:16 AM, Sean P. DeNigris >> > <sean(a)clipperadams.com> wrote: >> >> >> >> In a headless image, I'd like to do the following: if there's any >> >> error, >> >> arrange to have a debugger open on the next (headful) launch, and then >> >> save >> >> and quit. >> >> >> >> I'm drawing a blank - how would I do that? >> >> >> >> I explored various dead ends, the culmination of which was the >> >> image-breaking: >> >> actualWorkBlock on: Error do: [ [ Smalltalk snapshot: true andQuit: >> >> true ] >> >> fork. Halt now ] >> >> >> >> Thanks! >> > >> > >> > Sorry not a solution, but you sparked a side-thought... To avoid >> > sometimes being swamped by Pre-Debug windows. Instead of an error bringing >> > up an individual Pre-Debug window, we could have error go into a queue which >> > a singleton Pre-Debug window could have a view into. This "Error Queue >> > Viewer" would have on row per error, and you click on a row to open a >> > normal debugger, much like you click <Debug> button in the existing >> > Pre-Debug window. In a headless image, the Error Queue Viewer would not >> > appear, but the error would keep being queued until the next time the Error >> > Queue Viewer is manually opened. The same error-queue might provide a >> > similar interface point for Pharo Remote Tools, so you can see errors that >> > occurred while you were not connected. >> > >> > cheers -ben > > > > > -- > Mariano > http://marianopeck.wordpress.com

Jan. 12, 2018

Re: [Pharo-users] OT: Re: Open Debugger, Save and Quit

by Mariano Martinez Peck

On Wed, Nov 8, 2017 at 1:45 AM, Joachim Tuchel <jtuchel(a)objektfabrik.de> wrote: > Ben, > > (this is a bit off-topic) > > do you happen to know the purpose of that pre-debug-window? I must say > that I find it annoying every time I get it in Pharo or VA? Why doesn't the > debugger show up immediately? > > I disabled that in all my images (via a startup setting). See #*alwaysOpenFullDebugger *below: "Define some settings/preferences for GTDebugger" (Smalltalk at: #GTGenericStackDebugger) perform: #enableDebuggerWindowDistinctColor: with: true. (Smalltalk at: #GTGenericStackDebugger) perform: #enableStackColoring: with: true. *(Smalltalk at: #GTGenericStackDebugger) perform: #alwaysOpenFullDebugger: with: true.* Cheers, But your suggestion is a good one, imo. In the startup phase of an image, > the image might not be ready to provide any means of reacting to a problem, > so why bother showing errors that early? > > What you describe should be quite easy to achieve with a handler that > records and resumes errors during startup. > > Joachim > > Am 08.11.2017 03:54 schrieb Ben Coman <btc(a)openinworld.com>: > > > > > > > > On Wed, Nov 8, 2017 at 10:16 AM, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > >> > >> In a headless image, I'd like to do the following: if there's any error, > >> arrange to have a debugger open on the next (headful) launch, and then > save > >> and quit. > >> > >> I'm drawing a blank - how would I do that? > >> > >> I explored various dead ends, the culmination of which was the > >> image-breaking: > >> actualWorkBlock on: Error do: [ [ Smalltalk snapshot: true andQuit: > true ] > >> fork. Halt now ] > >> > >> Thanks! > > > > > > Sorry not a solution, but you sparked a side-thought... To avoid > sometimes being swamped by Pre-Debug windows. Instead of an error bringing > up an individual Pre-Debug window, we could have error go into a queue > which a singleton Pre-Debug window could have a view into. This "Error > Queue Viewer" would have on row per error, and you click on a row to open > a normal debugger, much like you click <Debug> button in the existing > Pre-Debug window. In a headless image, the Error Queue Viewer would not > appear, but the error would keep being queued until the next time the Error > Queue Viewer is manually opened. The same error-queue might provide a > similar interface point for Pharo Remote Tools, so you can see errors that > occurred while you were not connected. > > > > cheers -ben -- Mariano http://marianopeck.wordpress.com

Jan. 12, 2018

OT: Re: Open Debugger, Save and Quit

by Joachim Tuchel

Ben, (this is a bit off-topic) do you happen to know the purpose of that pre-debug-window? I must say that I find it annoying every time I get it in Pharo or VA? Why doesn't the debugger show up immediately? But your suggestion is a good one, imo. In the startup phase of an image, the image might not be ready to provide any means of reacting to a problem, so why bother showing errors that early? What you describe should be quite easy to achieve with a handler that records and resumes errors during startup. Joachim Am 08.11.2017 03:54 schrieb Ben Coman <btc(a)openinworld.com>: > > > > On Wed, Nov 8, 2017 at 10:16 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> In a headless image, I'd like to do the following: if there's any error, >> arrange to have a debugger open on the next (headful) launch, and then save >> and quit. >> >> I'm drawing a blank - how would I do that? >> >> I explored various dead ends, the culmination of which was the >> image-breaking: >> actualWorkBlock on: Error do: [ [ Smalltalk snapshot: true andQuit: true ] >> fork. Halt now ] >> >> Thanks! > > > Sorry not a solution, but you sparked a side-thought...Â To avoid sometimes being swamped by Pre-Debug windows.Â Instead of an error bringing up an individual Pre-Debug window, we could have error go into a queue which a singleton Pre-Debug window could have a view into.Â This "Error Queue Viewer"Â would have on row per error, and you click on a row to open a normal debugger, much like you click <Debug> button in the existing Pre-Debug window.Â In a headless image, the Error Queue Viewer would not appear, but the error would keep being queued until the next time the Error Queue Viewer is manually opened.Â The same error-queue might provide a similarÂ interface point for Pharo Remote Tools, so you can see errors that occurred while you were not connected. > > cheers -ben

Jan. 12, 2018

Re: [Pharo-users] Open Debugger, Save and Quit

by Joachim Tuchel

Sean, I am not a regular Pharo user, so I have no code example for you. Just an idea: why not save an image copy instead of the image itself? Thus if an error occurs that might not happen at next startup (external dependencies etc.) , you couldÂ restart the "real image" and still use the failed copies to analyse your startup problems. I guess Pharo can do a "Save image as..." ? Joachim Am 08.11.2017 03:16 schrieb "Sean P. DeNigris" <sean(a)clipperadams.com>: > > In a headless image, I'd like to do the following: if there's any error, > arrange to have a debugger open on the next (headful) launch, and then save > and quit. > > I'm drawing a blank - how would I do that? > > I explored various dead ends, the culmination of which was the > image-breaking: > actualWorkBlock on: Error do: [ [ Smalltalk snapshot: true andQuit: true ] > fork. Halt now ] > > Thanks! > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

Jan. 12, 2018

Re: [Pharo-users] [ANN] Python3Generator and MatplotLibBridge

by Stephane Ducasse

I thought so and this is good to have it around. On Thu, Jan 11, 2018 at 10:13 AM, Thierry Goubier <thierry.goubier(a)gmail.com > wrote: > Hi Stef, > > it's the one done with Damien, 3 or 4 years ago. > > Thierry > > 2018-01-11 8:23 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > >> Hi Thierry >> >> One of these days I think that I will have to have a look at it :) >> >> Stef >> >> On Wed, Jan 10, 2018 at 2:35 PM, Thierry Goubier < >> thierry.goubier(a)gmail.com> wrote: >> >>> >>> >>> 2018-01-10 14:26 GMT+01:00 Serge Stinckwich <serge.stinckwich(a)gmail.com> >>> : >>> >>>> >>>> >>>> On Wed, Jan 10, 2018 at 2:23 PM, Julien <julien.delplanque(a)inria.fr> >>>> wrote: >>>> >>>>> Hello Serge, >>>>> >>>>> Do you mean pieces of code you wrote in Python using Numpy that you >>>>> want to transform to Smalltalk code using PolyMath? >>>>> >>>>> Itâs kind of the other way around of this project. :-) >>>>> >>>>> >>>> âyes this is exactly the opposite :-(â >>>> âI guess I need a Python parser and after that I can do AST >>>> transformation ... >>>> >>> >>> Hi Serge, >>> >>> there is a Python2.7 parser with AST that could be used. >>> >>> Thierry >>> >>> >>>> Or using regex I can do basic stuff ...â >>>> >>>> -- >>>> Serge Stinckwich >>>> UMI UMMISCO 209 (IRD/UPMC/UY1) >>>> "Programs must be written for people to read, and only incidentally for >>>> machines to execute."http://www.doesnotunderstand.org/ >>>> >>> >>> >> >

Jan. 12, 2018

Re: [Pharo-users] Metacello with Git

by Sean P. DeNigris

EstebanLM wrote > yep. that seems to be a bug. 20953: Gitlab Private Project Support (via Iceberg) https://pharo.fogbugz.com/f/cases/20953/ PRs issued - https://github.com/pharo-project/pharo/pull/667 - https://github.com/pharo-vcs/iceberg/pull/559 ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Jan. 12, 2018

Re: [Pharo-users] [ANN] Python3Generator and MatplotLibBridge

by Thierry Goubier

Hi Stef, it's the one done with Damien, 3 or 4 years ago. Thierry 2018-01-11 8:23 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Hi Thierry > > One of these days I think that I will have to have a look at it :) > > Stef > > On Wed, Jan 10, 2018 at 2:35 PM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > >> >> >> 2018-01-10 14:26 GMT+01:00 Serge Stinckwich <serge.stinckwich(a)gmail.com>: >> >>> >>> >>> On Wed, Jan 10, 2018 at 2:23 PM, Julien <julien.delplanque(a)inria.fr> >>> wrote: >>> >>>> Hello Serge, >>>> >>>> Do you mean pieces of code you wrote in Python using Numpy that you >>>> want to transform to Smalltalk code using PolyMath? >>>> >>>> Itâs kind of the other way around of this project. :-) >>>> >>>> >>> âyes this is exactly the opposite :-(â >>> âI guess I need a Python parser and after that I can do AST >>> transformation ... >>> >> >> Hi Serge, >> >> there is a Python2.7 parser with AST that could be used. >> >> Thierry >> >> >>> Or using regex I can do basic stuff ...â >>> >>> -- >>> Serge Stinckwich >>> UMI UMMISCO 209 (IRD/UPMC/UY1) >>> "Programs must be written for people to read, and only incidentally for >>> machines to execute."http://www.doesnotunderstand.org/ >>> >> >> >

Jan. 11, 2018

Re: [Pharo-users] Unresponsive/frozen Gui

by Esteban Lorenzano

> On 11 Jan 2018, at 09:08, Norbert Hartl <norbert(a)hartl.name> wrote: > > > > Am 11.01.2018 um 08:31 schrieb Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > >> most probably your image got stuck doing something. >> take a look at âPharoDebug.org <http://pharodebug.org/>â in case there is one. >> > What cool domain name :) crap ;) PharoDebug.log I meant :P Esteban > > Norbert >> Esteban >> >>> On 10 Jan 2018, at 21:40, Andrei Stebakov <lispercat(a)gmail.com <mailto:lispercat@gmail.com>> wrote: >>> >>> I experience that issue once in a while when I leave the pharo 6.1 on windows and when I come back to it the UI is frozen. >>> Now I download pharo with moose image and it started to happen again (BTW I couldn't install Moose in my pharo 6.1 using Metacello command) >>> I wonder if it's something that happens to many users and I have to get used to it (ui freezes) or there ways to avoid it. >>> Again, maybe it's a windows specific problem and most of the pharo users are either on Mac or Linux. >>

Jan. 11, 2018

Re: [Pharo-users] Unresponsive/frozen Gui

by Norbert Hartl

> Am 11.01.2018 um 08:31 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > > most probably your image got stuck doing something. > take a look at âPharoDebug.orgâ in case there is one. > What cool domain name :) Norbert > Esteban > >> On 10 Jan 2018, at 21:40, Andrei Stebakov <lispercat(a)gmail.com> wrote: >> >> I experience that issue once in a while when I leave the pharo 6.1 on windows and when I come back to it the UI is frozen. >> Now I download pharo with moose image and it started to happen again (BTW I couldn't install Moose in my pharo 6.1 using Metacello command) >> I wonder if it's something that happens to many users and I have to get used to it (ui freezes) or there ways to avoid it. >> Again, maybe it's a windows specific problem and most of the pharo users are either on Mac or Linux. >

Jan. 11, 2018

Re: [Pharo-users] Unresponsive/frozen Gui

by Esteban Lorenzano

most probably your image got stuck doing something. take a look at âPharoDebug.org <http://pharodebug.org/>â in case there is one. Esteban > On 10 Jan 2018, at 21:40, Andrei Stebakov <lispercat(a)gmail.com> wrote: > > I experience that issue once in a while when I leave the pharo 6.1 on windows and when I come back to it the UI is frozen. > Now I download pharo with moose image and it started to happen again (BTW I couldn't install Moose in my pharo 6.1 using Metacello command) > I wonder if it's something that happens to many users and I have to get used to it (ui freezes) or there ways to avoid it. > Again, maybe it's a windows specific problem and most of the pharo users are either on Mac or Linux.

Jan. 11, 2018