January 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Any perspective of Woden in Pharo 6.1/7 ?????

by Alexandre Bergel

Excellent! Let us know how it goes. We will be happy to help Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Jan 12, 2018, at 1:47 PM, casimiro barreto <casimiro.barreto(a)gmail.com> wrote: > > Will try. Currently on 2 projects involving pharo. The most pressing one is a system for the calculation of uncertainties in measures. This system is part of a homologation system for smart card readers and smart card chips. The other is a simulation system thatÂ´s under non disclosure clause. Woden would be used in a third incoming project (simulations in crowd management in airports). > > Best regards, > > Casimiro > > 2018-01-10 19:43 GMT-02:00 Alexandre Bergel <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>>: > Hi Casimiro! > > Sorry for the late reply. > We do have a working version of Woden for Pharo 7. > It would be great if you could try. > https://github.com/ronsaldo/woden2 <https://github.com/ronsaldo/woden2> > > On OSX, I did: > -=-=-=-=-=-=-=-=-= > git clone https://github.com/ronsaldo/woden2.git <https://github.com/ronsaldo/woden2.git> > cd woden2 > ./loadWoden2.sh > -=-=-=-=-=-=-=-=-= > > It takes time to install & compile (~ 10 minutes?), but it works well > > Alexandre > > > > On Jan 2, 2018, at 5:21 AM, Casimiro - GMAIL <casimiro.barreto(a)gmail.com <mailto:casimiro.barreto@gmail.com>> wrote: > > > > Is there any perspective of Woden working in Pharo 6.1 or later versions (7)???? > > > > Best regards, > > > > > > Casimiro > > -- > > The information contained in this message is confidential and intended to the recipients specified in the headers. If you received this message by error, notify the sender immediately. The unauthorized use, disclosure, copy or alteration of this message are strictly forbidden and subjected to civil and criminal sanctions. > > > > == > > > > This email may be signed using PGP key ID: 0x4134A417 > > > > > -- > The information contained in this message is confidential and > intended to the recipients specified in the headers. If you received > this message by error, notify the sender immediately. The > unauthorized use, disclosure, copy or alteration of this message > are strictly forbidden and subjected to civil and criminal sanctions.

Jan. 12, 2018

Re: [Pharo-users] Any perspective of Woden in Pharo 6.1/7 ?????

by Ronie Salgado

> > Do you have a travis or jenkins for woden in Pharo 7? This is on my big todo list. In fact I need the travis to be able to support Windows. During the last months I have been rewriting the core of Woden 2 in order to improve stability and reduce dependencies. By using Lowtalk for the math library, I removed the requirement on Lowcode. During the weekend I am gonna spend some time on implementing the scripts for Travis. Best regards, Ronie 2018-01-12 13:47 GMT-03:00 casimiro barreto <casimiro.barreto(a)gmail.com>: > Will try. Currently on 2 projects involving pharo. The most pressing one > is a system for the calculation of uncertainties in measures. This system > is part of a homologation system for smart card readers and smart card > chips. The other is a simulation system thatÂ´s under non disclosure clause. > Woden would be used in a third incoming project (simulations in crowd > management in airports). > > Best regards, > > Casimiro > > 2018-01-10 19:43 GMT-02:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > >> Hi Casimiro! >> >> Sorry for the late reply. >> We do have a working version of Woden for Pharo 7. >> It would be great if you could try. >> https://github.com/ronsaldo/woden2 >> >> On OSX, I did: >> -=-=-=-=-=-=-=-=-= >> git clone https://github.com/ronsaldo/woden2.git >> cd woden2 >> ./loadWoden2.sh >> -=-=-=-=-=-=-=-=-= >> >> It takes time to install & compile (~ 10 minutes?), but it works well >> >> Alexandre >> >> >> > On Jan 2, 2018, at 5:21 AM, Casimiro - GMAIL < >> casimiro.barreto(a)gmail.com> wrote: >> > >> > Is there any perspective of Woden working in Pharo 6.1 or later >> versions (7)???? >> > >> > Best regards, >> > >> > >> > Casimiro >> > -- >> > The information contained in this message is confidential and intended >> to the recipients specified in the headers. If you received this message by >> error, notify the sender immediately. The unauthorized use, disclosure, >> copy or alteration of this message are strictly forbidden and subjected to >> civil and criminal sanctions. >> > >> > == >> > >> > This email may be signed using PGP key ID: 0x4134A417 >> >> > > > -- > The information contained in this message is confidential and > intended to the recipients specified in the headers. If you received > this message by error, notify the sender immediately. The > unauthorized use, disclosure, copy or alteration of this message > are strictly forbidden and subjected to civil and criminal sanctions. >

Jan. 12, 2018

Re: [Pharo-users] Any perspective of Woden in Pharo 6.1/7 ?????

by casimiro barreto

Will try. Currently on 2 projects involving pharo. The most pressing one is a system for the calculation of uncertainties in measures. This system is part of a homologation system for smart card readers and smart card chips. The other is a simulation system thatÂ´s under non disclosure clause. Woden would be used in a third incoming project (simulations in crowd management in airports). Best regards, Casimiro 2018-01-10 19:43 GMT-02:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > Hi Casimiro! > > Sorry for the late reply. > We do have a working version of Woden for Pharo 7. > It would be great if you could try. > https://github.com/ronsaldo/woden2 > > On OSX, I did: > -=-=-=-=-=-=-=-=-= > git clone https://github.com/ronsaldo/woden2.git > cd woden2 > ./loadWoden2.sh > -=-=-=-=-=-=-=-=-= > > It takes time to install & compile (~ 10 minutes?), but it works well > > Alexandre > > > > On Jan 2, 2018, at 5:21 AM, Casimiro - GMAIL <casimiro.barreto(a)gmail.com> > wrote: > > > > Is there any perspective of Woden working in Pharo 6.1 or later versions > (7)???? > > > > Best regards, > > > > > > Casimiro > > -- > > The information contained in this message is confidential and intended > to the recipients specified in the headers. If you received this message by > error, notify the sender immediately. The unauthorized use, disclosure, > copy or alteration of this message are strictly forbidden and subjected to > civil and criminal sanctions. > > > > == > > > > This email may be signed using PGP key ID: 0x4134A417 > > -- The information contained in this message is confidential and intended to the recipients specified in the headers. If you received this message by error, notify the sender immediately. The unauthorized use, disclosure, copy or alteration of this message are strictly forbidden and subjected to civil and criminal sanctions.

Jan. 12, 2018

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

by Ben Coman

On 12 January 2018 at 22:15, 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) >> > Sorry I didn't reply earlier. For some reason you email from 8 Nov didn't show up in my inbox until the same time just now that Mariano's did. > >> 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 don't know, but could speculate that it performs the function of an error message - with some additional context seeing the top of the call stack. cheers -ben 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] Any perspective of Woden in Pharo 6.1/7 ?????

by Stephane Ducasse

Do you have a travis or jenkins for woden in Pharo 7? Stef On Wed, Jan 10, 2018 at 10:43 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi Casimiro! > > Sorry for the late reply. > We do have a working version of Woden for Pharo 7. > It would be great if you could try. > https://github.com/ronsaldo/woden2 > > On OSX, I did: > -=-=-=-=-=-=-=-=-= > git clone https://github.com/ronsaldo/woden2.git > cd woden2 > ./loadWoden2.sh > -=-=-=-=-=-=-=-=-= > > It takes time to install & compile (~ 10 minutes?), but it works well > > Alexandre > > >> On Jan 2, 2018, at 5:21 AM, Casimiro - GMAIL <casimiro.barreto(a)gmail.com> wrote: >> >> Is there any perspective of Woden working in Pharo 6.1 or later versions (7)???? >> >> Best regards, >> >> >> Casimiro >> -- >> The information contained in this message is confidential and intended to the recipients specified in the headers. If you received this message by error, notify the sender immediately. The unauthorized use, disclosure, copy or alteration of this message are strictly forbidden and subjected to civil and criminal sanctions. >> >> == >> >> This email may be signed using PGP key ID: 0x4134A417 > >

Jan. 12, 2018

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