June 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] How to debug code using DynamicVariable?

by Norbert Hartl

Hi Eliot, thank you very much. I imported your changes in a pharo 3 image and it works awesome. So I'm preparing a slice for pharo. Thanks again, a very annoying problem seems to be solved, Norbert Am 23.06.2014 um 19:29 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: > and here are the changes I've just committed to Squeak trunk. > > > On Mon, Jun 23, 2014 at 10:05 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Norbert, > > [ let me try again. never try and get code out too early in the morning ;-) ] > > it is the debugger that needs fixing, not your code !! :-). The debugger needs to respect process identity. Andreas and I (mostly Andreas) came up with the following changes at Qwaq. Your message is a good reminder that I need to add this to Squeak asap. > > The idea is for Process to have an additional inst var 'effectiveProcess' that holds the actual process running code. For the most part this is self, but in the debugger we substitute the process being debugged: > > Process methods for accessing > effectiveProcess > "effectiveProcess is a mechanism to allow process-faithful debugging. The debugger executes code > on behalf of processes, so unless some effort is made the identity of Processor activeProcess is not > correctly maintained when debugging code. The debugger uses evaluate:onBehalfOf: to assign the > debugged process as the effectiveProcess of the process executing the code, preserving process > identity." > ^effectiveProcess ifNil: [self] > > then the relevant methods in Process and processorScheduler defer to effectiveProcess, e.g. > > ProcessorScheduler methods for process state change > terminateActive > "Terminate the process that is currently running." > > activeProcess effectiveProcess terminate > > and the debugging methods use evaluate:onBehalfOf: to install the process being debugged: > > Process methods for private > evaluate: aBlock onBehalfOf: aProcess > "Evaluate aBlock setting effectiveProcess to aProcess. Used > in the execution simulation machinery to ensure that > Processor activeProcess evaluates correctly when debugging." > | oldEffectiveProcess | > oldEffectiveProcess := effectiveProcess. > effectiveProcess := aProcess. > ^aBlock ensure: [effectiveProcess := oldEffectiveProcess] > > Process methods for changing suspended state > step > > ^Processor activeProcess > evaluate: [suspendedContext := suspendedContext step] > onBehalfOf: self > > stepToCallee > "Step until top context changes" > > Processor activeProcess > evaluate: > [| ctxt | > ctxt := suspendedContext. > [ctxt == suspendedContext] whileTrue: [ > suspendedContext := suspendedContext step]] > onBehalfOf: self. > ^suspendedContext > > etc. Changes from a Qwaq image attached. > > HTH > > > On Mon, Jun 23, 2014 at 4:50 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > In my code I'm using a DynamicVariable to request a context object when needed. Until now I knew the name DynamicVariable only from seaside. There it is called WADynamicVariable and it is an exception. So I blindly assumed the pharo DynamicVariable works the same. > I thought this might be a good optimization not to travel the stack all the time but put in the process. > Now that I am using it I can see the difference. I find it real hard using it because I don't know how to debug/step in code. DynamicVariable is a process specific variable but as soon as a debugger opens it is very likely to be in another process. This makes stepping in method using the DynamicVariable impossible. The only way round is to set break points after the dynamic lookup and step from there. But this feels just wrong. > What would be the best way to have DynamicVariable and be able to debug anything? Or is there a variant that uses the stack instead of the "active" process? > > thanks, > > Norbert > > > > > > -- > best, > Eliot > > > > -- > best, > Eliot > <trunk4.6EffectiveProcessMethods.st>

June 23, 2014

Re: [Pharo-dev] Stepping through with GLORP Proxies

by Esteban A. Maringolo

Eliot, I never installed your proposed changes in a Pharo 3 image because there is a significant change in ContextPart. Your proposed changeset changes classVars of ContextPart. Your proposal: classVariableNames: 'MaxLengthForASingleDebugLogReport MaxStackDepthForASingleDebugLogReport PrimitiveFailToken QuickStep ValueIndex' Current vars: classVariableNames: 'PrimitiveFailToken QuickStep SpecialPrimitiveSimulators TryNamedPrimitiveTemplateMethod' Would you mind adapting your mirror methods changes to work also in Pharo 3 (and maybe in Pharo 4 too?). Esteban A. Maringolo 2014-02-26 14:40 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Esteban, > > find attached. Let me know of any problems. > > > On Wed, Feb 26, 2014 at 8:32 AM, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: >> >> Hi Eliot, >> >> >> 2013-11-30 18:30 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> > On Fri, Nov 29, 2013 at 2:22 PM, Esteban A. Maringolo >> > <emaringolo(a)gmail.com> >> > wrote: >> >> 2013/11/29 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >> >> > I'll either prepare a change set or submit. It'll get done. >> >> >> I can continue stepping into until the change is ready. >> >> >> Please make it compatible with Pharo 2 (whatever that means in term of >> >> code) :) >> > >> > >> > OK, the code is now in Squeak trunk. What image should I use to >> > integrate >> > into Pharo 2? A url please... >> >> I'm coming back late to this. Because the change wasn't integrated in >> Pharo 2. >> >> Do you have the changeset applied to Squeak Trunk? I'd like to reapply >> it in my Pharo 2 image (at my own risk). >> Can you send it to may email address? >> >> Thank you! >> >> Esteban A. Maringolo >> > > > > -- > best, > Eliot

June 23, 2014

Re: [Pharo-dev] How to debug code using DynamicVariable?

by stepharo

Thanks Eliot. Sven, Norbert if you package that nicely (BTW having some tests would be great) we can include that in 4.0 Stef On 23/6/14 19:29, Eliot Miranda wrote: > and here are the changes I've just committed to Squeak trunk. > > > On Mon, Jun 23, 2014 at 10:05 AM, Eliot Miranda > <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: > > Hi Norbert, > > [ let me try again. never try and get code out too early in > the morning ;-) ] > > it is the debugger that needs fixing, not your code !! :-). > The debugger needs to respect process identity. Andreas and I > (mostly Andreas) came up with the following changes at Qwaq. Your > message is a good reminder that I need to add this to Squeak asap. > > The idea is for Process to have an additional inst var > 'effectiveProcess' that holds the actual process running code. > For the most part this is self, but in the debugger we substitute > the process being debugged: > > /Process methods for accessing/ > *effectiveProcess* > "effectiveProcess is a mechanism to allow process-faithful > debugging. The debugger executes code > on behalf of processes, so unless some effort is made the > identity of Processor activeProcess is not > correctly maintained when debugging code. The debugger uses > evaluate:onBehalfOf: to assign the > debugged process as the effectiveProcess of the process executing > the code, preserving process > identity." > ^effectiveProcess ifNil: [self] > > then the relevant methods in Process and processorScheduler defer > to effectiveProcess, e.g. > > /ProcessorScheduler methods for process state change/ > *terminateActive* > "Terminate the process that is currently running." > > activeProcess effectiveProcess terminate > > and the debugging methods use evaluate:onBehalfOf: to install the > process being debugged: > > /Process methods for private/ > *evaluate: aBlock onBehalfOf: aProcess* > "Evaluate aBlock setting effectiveProcess to aProcess. Used > in the execution simulation machinery to ensure that > Processor activeProcess evaluates correctly when debugging." > | oldEffectiveProcess | > oldEffectiveProcess := effectiveProcess. > effectiveProcess := aProcess. > ^aBlock ensure: [effectiveProcess := oldEffectiveProcess] > > /Process methods for changing suspended state/ > *step* > > ^Processor activeProcess > evaluate: [suspendedContext := suspendedContext step] > onBehalfOf: self > > *stepToCallee* > "Step until top context changes" > > Processor activeProcess > evaluate: > [| ctxt | > ctxt := suspendedContext. > [ctxt == suspendedContext] whileTrue: [ > suspendedContext := suspendedContext step]] > onBehalfOf: self. > ^suspendedContext > > etc. Changes from a Qwaq image attached. > > HTH > > > On Mon, Jun 23, 2014 at 4:50 AM, Norbert Hartl <norbert(a)hartl.name > <mailto:norbert@hartl.name>> wrote: > > In my code I'm using a DynamicVariable to request a context > object when needed. Until now I knew the name DynamicVariable > only from seaside. There it is called WADynamicVariable and it > is an exception. So I blindly assumed the pharo > DynamicVariable works the same. > I thought this might be a good optimization not to travel the > stack all the time but put in the process. > Now that I am using it I can see the difference. I find it > real hard using it because I don't know how to debug/step in > code. DynamicVariable is a process specific variable but as > soon as a debugger opens it is very likely to be in another > process. This makes stepping in method using the > DynamicVariable impossible. The only way round is to set break > points after the dynamic lookup and step from there. But this > feels just wrong. > What would be the best way to have DynamicVariable and be able > to debug anything? Or is there a variant that uses the stack > instead of the "active" process? > > thanks, > > Norbert > > > > > > -- > best, > Eliot > > > > > -- > best, > Eliot

June 23, 2014

Re: [Pharo-dev] prepared inclusion of OSWindow

by stepharo

Thanks ronie. I will integrate it soon. Stef On 23/6/14 19:25, Ronie Salgado wrote: > Hi Stef, > > indicates > package: 'NBXLib-Core'; and I wonder why > > Why do we need also the OSWindow-X11 if we use SDL > Stef > > Edited and remove that line in fogbugz. It was a copy paste mistake. > > As for OSWindow-X11, it is keep for history purposes. We don't need it. > > Now to fully work I imagine that SDL2 should be linked to the VM > so that it can work. > I need to know which package make sense to be loaded > > For Linux, it is linked in an external plugin. For Windows, it > requires full linking with the VM. As for Mac, I don't know yet. > > Greetings, > Ronie > > > > 2014-06-23 5:29 GMT-04:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > Hi Igor and Ronie > > following igor advice I'm preparing to integration OSWindow in > Pharo. I copied all the packages to Pharo/OSWindow. > > Now to fully work I imagine that SDL2 should be linked to the VM > so that it can work. > I need to know which package make sense to be loaded > > > I imagine that this is > OSWindow-Core > OSWindow-SDL2 > > https://pharo.fogbugz.com/default.asp?12743#103040 > > indicates > package: 'NBXLib-Core'; and I wonder why > > Why do we need also the OSWindow-X11 if we use SDL > Stef > >

June 23, 2014

Re: [Pharo-dev] How to debug code using DynamicVariable?

by Eliot Miranda

and here are the changes I've just committed to Squeak trunk. On Mon, Jun 23, 2014 at 10:05 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Norbert, > > [ let me try again. never try and get code out too early in the > morning ;-) ] > > it is the debugger that needs fixing, not your code !! :-). The > debugger needs to respect process identity. Andreas and I (mostly Andreas) > came up with the following changes at Qwaq. Your message is a good > reminder that I need to add this to Squeak asap. > > The idea is for Process to have an additional inst var 'effectiveProcess' > that holds the actual process running code. For the most part this is > self, but in the debugger we substitute the process being debugged: > > *Process methods for accessing* > *effectiveProcess* > "effectiveProcess is a mechanism to allow process-faithful debugging. The > debugger executes code > on behalf of processes, so unless some effort is made the identity of > Processor activeProcess is not > correctly maintained when debugging code. The debugger uses > evaluate:onBehalfOf: to assign the > debugged process as the effectiveProcess of the process executing the > code, preserving process > identity." > ^effectiveProcess ifNil: [self] > > then the relevant methods in Process and processorScheduler defer to > effectiveProcess, e.g. > > *ProcessorScheduler methods for process state change* > *terminateActive* > "Terminate the process that is currently running." > > activeProcess effectiveProcess terminate > > and the debugging methods use evaluate:onBehalfOf: to install the process > being debugged: > > *Process methods for private* > *evaluate: aBlock onBehalfOf: aProcess* > "Evaluate aBlock setting effectiveProcess to aProcess. Used > in the execution simulation machinery to ensure that > Processor activeProcess evaluates correctly when debugging." > | oldEffectiveProcess | > oldEffectiveProcess := effectiveProcess. > effectiveProcess := aProcess. > ^aBlock ensure: [effectiveProcess := oldEffectiveProcess] > > *Process methods for changing suspended state* > *step* > > ^Processor activeProcess > evaluate: [suspendedContext := suspendedContext step] > onBehalfOf: self > > *stepToCallee* > "Step until top context changes" > > Processor activeProcess > evaluate: > [| ctxt | > ctxt := suspendedContext. > [ctxt == suspendedContext] whileTrue: [ > suspendedContext := suspendedContext step]] > onBehalfOf: self. > ^suspendedContext > > etc. Changes from a Qwaq image attached. > > HTH > > > On Mon, Jun 23, 2014 at 4:50 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> In my code I'm using a DynamicVariable to request a context object when >> needed. Until now I knew the name DynamicVariable only from seaside. There >> it is called WADynamicVariable and it is an exception. So I blindly assumed >> the pharo DynamicVariable works the same. >> I thought this might be a good optimization not to travel the stack all >> the time but put in the process. >> Now that I am using it I can see the difference. I find it real hard >> using it because I don't know how to debug/step in code. DynamicVariable is >> a process specific variable but as soon as a debugger opens it is very >> likely to be in another process. This makes stepping in method using the >> DynamicVariable impossible. The only way round is to set break points after >> the dynamic lookup and step from there. But this feels just wrong. >> What would be the best way to have DynamicVariable and be able to debug >> anything? Or is there a variant that uses the stack instead of the "active" >> process? >> >> thanks, >> >> Norbert >> >> >> > > > -- > best, > Eliot > -- best, Eliot

June 23, 2014

Re: [Pharo-dev] prepared inclusion of OSWindow

by Ronie Salgado

Hi Stef, indicates > package: 'NBXLib-Core'; and I wonder why > > Why do we need also the OSWindow-X11 if we use SDL > Stef Edited and remove that line in fogbugz. It was a copy paste mistake. As for OSWindow-X11, it is keep for history purposes. We don't need it. Now to fully work I imagine that SDL2 should be linked to the VM so that it > can work. > I need to know which package make sense to be loaded > For Linux, it is linked in an external plugin. For Windows, it requires full linking with the VM. As for Mac, I don't know yet. Greetings, Ronie 2014-06-23 5:29 GMT-04:00 stepharo <stepharo(a)free.fr>: > Hi Igor and Ronie > > following igor advice I'm preparing to integration OSWindow in Pharo. I > copied all the packages to Pharo/OSWindow. > > Now to fully work I imagine that SDL2 should be linked to the VM so that > it can work. > I need to know which package make sense to be loaded > > > I imagine that this is > OSWindow-Core > OSWindow-SDL2 > > https://pharo.fogbugz.com/default.asp?12743#103040 > > indicates > package: 'NBXLib-Core'; and I wonder why > > Why do we need also the OSWindow-X11 if we use SDL > Stef > >

June 23, 2014

Re: [Pharo-dev] How to debug code using DynamicVariable?

by Eliot Miranda

Hi Norbert, [ let me try again. never try and get code out too early in the morning ;-) ] it is the debugger that needs fixing, not your code !! :-). The debugger needs to respect process identity. Andreas and I (mostly Andreas) came up with the following changes at Qwaq. Your message is a good reminder that I need to add this to Squeak asap. The idea is for Process to have an additional inst var 'effectiveProcess' that holds the actual process running code. For the most part this is self, but in the debugger we substitute the process being debugged: *Process methods for accessing* *effectiveProcess* "effectiveProcess is a mechanism to allow process-faithful debugging. The debugger executes code on behalf of processes, so unless some effort is made the identity of Processor activeProcess is not correctly maintained when debugging code. The debugger uses evaluate:onBehalfOf: to assign the debugged process as the effectiveProcess of the process executing the code, preserving process identity." ^effectiveProcess ifNil: [self] then the relevant methods in Process and processorScheduler defer to effectiveProcess, e.g. *ProcessorScheduler methods for process state change* *terminateActive* "Terminate the process that is currently running." activeProcess effectiveProcess terminate and the debugging methods use evaluate:onBehalfOf: to install the process being debugged: *Process methods for private* *evaluate: aBlock onBehalfOf: aProcess* "Evaluate aBlock setting effectiveProcess to aProcess. Used in the execution simulation machinery to ensure that Processor activeProcess evaluates correctly when debugging." | oldEffectiveProcess | oldEffectiveProcess := effectiveProcess. effectiveProcess := aProcess. ^aBlock ensure: [effectiveProcess := oldEffectiveProcess] *Process methods for changing suspended state* *step* ^Processor activeProcess evaluate: [suspendedContext := suspendedContext step] onBehalfOf: self *stepToCallee* "Step until top context changes" Processor activeProcess evaluate: [| ctxt | ctxt := suspendedContext. [ctxt == suspendedContext] whileTrue: [ suspendedContext := suspendedContext step]] onBehalfOf: self. ^suspendedContext etc. Changes from a Qwaq image attached. HTH On Mon, Jun 23, 2014 at 4:50 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > In my code I'm using a DynamicVariable to request a context object when > needed. Until now I knew the name DynamicVariable only from seaside. There > it is called WADynamicVariable and it is an exception. So I blindly assumed > the pharo DynamicVariable works the same. > I thought this might be a good optimization not to travel the stack all > the time but put in the process. > Now that I am using it I can see the difference. I find it real hard using > it because I don't know how to debug/step in code. DynamicVariable is a > process specific variable but as soon as a debugger opens it is very likely > to be in another process. This makes stepping in method using the > DynamicVariable impossible. The only way round is to set break points after > the dynamic lookup and step from there. But this feels just wrong. > What would be the best way to have DynamicVariable and be able to debug > anything? Or is there a variant that uses the stack instead of the "active" > process? > > thanks, > > Norbert > > > -- best, Eliot

June 23, 2014

Re: [Pharo-dev] How to debug code using DynamicVariable?

by Eliot Miranda

oops. I guess I hsould add those changes ;-) On Mon, Jun 23, 2014 at 9:58 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Norbert, > > it is the debugger that needs fixing, not your code !! :-). The > debugger needs to respect process identity. Andreas and I (mostly Andreas) > came up with the following changes at Qwaq. Your message is a good > reminder that I need to add this to Squeak asap. > > The idea is for Process to have an additional inst var 'effectiveProcess' > that holds the actual process running code. For the most part this is > self, but in the debugger we substitute the process being debugged: > > *Process methods for accessing* > *effectiveProcess* > "effectiveProcess is a mechanism to allow process-faithful debugging. The > debugger executes code > on behalf of processes, so unless some effort is made the identity of > Processor activeProcess is not > correctly maintained when debugging code. The debugger uses > evaluate:onBehalfOf: to assign the > debugged process as the effectiveProcess of the process executing the > code, preserving process > identity." > ^effectiveProcess ifNil: [self] > > then the relevant methods in Process and processorScheduler defer to > effectiveProcess, e.g. > > *ProcessorScheduler methods for process state change* > *terminateActive* > "Terminate the process that is currently running." > > activeProcess effectiveProcess terminate > > and the debugging methods use evaluate:onBehalfOf: to install the process > being debugged: > > *Process methods for private* > *evaluate: aBlock onBehalfOf: aProcess* > "Evaluate aBlock setting effectiveProcess to aProcess. Used > in the execution simulation machinery to ensure that > Processor activeProcess evaluates correctly when debugging." > | oldEffectiveProcess | > oldEffectiveProcess := effectiveProcess. > effectiveProcess := aProcess. > ^aBlock ensure: [effectiveProcess := oldEffectiveProcess] > > *Process methods for changing suspended state* > *step* > > ^Processor activeProcess > evaluate: [suspendedContext := suspendedContext step] > onBehalfOf: self > > *stepToCallee* > "Step until top context changes" > > Processor activeProcess > evaluate: > [| ctxt | > ctxt := suspendedContext. > [ctxt == suspendedContext] whileTrue: [ > suspendedContext := suspendedContext step]] > onBehalfOf: self. > ^suspendedContext > > etc. Changes from a Qwaq image attached. > > HTH > > > On Mon, Jun 23, 2014 at 4:50 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> In my code I'm using a DynamicVariable to request a context object when >> needed. Until now I knew the name DynamicVariable only from seaside. There >> it is called WADynamicVariable and it is an exception. So I blindly assumed >> the pharo DynamicVariable works the same. >> I thought this might be a good optimization not to travel the stack all >> the time but put in the process. >> Now that I am using it I can see the difference. I find it real hard >> using it because I don't know how to debug/step in code. DynamicVariable is >> a process specific variable but as soon as a debugger opens it is very >> likely to be in another process. This makes stepping in method using the >> DynamicVariable impossible. The only way round is to set break points after >> the dynamic lookup and step from there. But this feels just wrong. >> What would be the best way to have DynamicVariable and be able to debug >> anything? Or is there a variant that uses the stack instead of the "active" >> process? >> >> thanks, >> >> Norbert >> >> >> > > > -- > best, > Eliot > -- best, Eliot

June 23, 2014

Re: [Pharo-dev] How to debug code using DynamicVariable?

by Eliot Miranda

Hi Norbert, it is the debugger that needs fixing, not your code !! :-). The debugger needs to respect process identity. Andreas and I (mostly Andreas) came up with the following changes at Qwaq. Your message is a good reminder that I need to add this to Squeak asap. The idea is for Process to have an additional inst var 'effectiveProcess' that holds the actual process running code. For the most part this is self, but in the debugger we substitute the process being debugged: *Process methods for accessing* *effectiveProcess* "effectiveProcess is a mechanism to allow process-faithful debugging. The debugger executes code on behalf of processes, so unless some effort is made the identity of Processor activeProcess is not correctly maintained when debugging code. The debugger uses evaluate:onBehalfOf: to assign the debugged process as the effectiveProcess of the process executing the code, preserving process identity." ^effectiveProcess ifNil: [self] then the relevant methods in Process and processorScheduler defer to effectiveProcess, e.g. *ProcessorScheduler methods for process state change* *terminateActive* "Terminate the process that is currently running." activeProcess effectiveProcess terminate and the debugging methods use evaluate:onBehalfOf: to install the process being debugged: *Process methods for private* *evaluate: aBlock onBehalfOf: aProcess* "Evaluate aBlock setting effectiveProcess to aProcess. Used in the execution simulation machinery to ensure that Processor activeProcess evaluates correctly when debugging." | oldEffectiveProcess | oldEffectiveProcess := effectiveProcess. effectiveProcess := aProcess. ^aBlock ensure: [effectiveProcess := oldEffectiveProcess] *Process methods for changing suspended state* *step* ^Processor activeProcess evaluate: [suspendedContext := suspendedContext step] onBehalfOf: self *stepToCallee* "Step until top context changes" Processor activeProcess evaluate: [| ctxt | ctxt := suspendedContext. [ctxt == suspendedContext] whileTrue: [ suspendedContext := suspendedContext step]] onBehalfOf: self. ^suspendedContext etc. Changes from a Qwaq image attached. HTH On Mon, Jun 23, 2014 at 4:50 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > In my code I'm using a DynamicVariable to request a context object when > needed. Until now I knew the name DynamicVariable only from seaside. There > it is called WADynamicVariable and it is an exception. So I blindly assumed > the pharo DynamicVariable works the same. > I thought this might be a good optimization not to travel the stack all > the time but put in the process. > Now that I am using it I can see the difference. I find it real hard using > it because I don't know how to debug/step in code. DynamicVariable is a > process specific variable but as soon as a debugger opens it is very likely > to be in another process. This makes stepping in method using the > DynamicVariable impossible. The only way round is to set break points after > the dynamic lookup and step from there. But this feels just wrong. > What would be the best way to have DynamicVariable and be able to debug > anything? Or is there a variant that uses the stack instead of the "active" > process? > > thanks, > > Norbert > > > -- best, Eliot

June 23, 2014

Re: [Pharo-dev] English Dr. Geo user guide

by Nicolai Hess

2014-06-23 9:46 GMT+02:00 Hilaire Fernandes <hilaire.fernandes(a)gmail.com>: > Hello, > > It has been a very long task to produce a good quality English user > guide (and a French one, but it was easier for me), but we did it. Of > course it talks about Pharo programming as well! > > Read, speak about, forward from > http://forum.drgeo.eu/New-user-guides-tt4024325.html > > Thanks to read. > > Hilaire > > -- > Dr. Geo - http://drgeo.eu > iStoa - https://launchpad.net/istoa > > > Hi hilaire, some notes on the new user guide: page 6 Arc by trois points should be: Arc by three points page 19 apostroph is above the s. should be: DR. GeoÂ´s page 28 "... Furthermore, in the use a script dialog, scripts seem to be ordered in random order. It is certainly not alphabetical or temporal order." Yes, it looks strange. It is ordered based on the values of a dictionary (methodictonary) not not ordered based on its keys. But it should be simple to sort this list afterwards. page 58 strange double backslash in the example for animated figures This is a really great application. Looks much better with athens rendering. And I like that with the scripts and sketches, it supports the power of smalltalk. nicolai

June 23, 2014