- Pharo-users - lists.pharo.org

Pharo 4: Setting values from within an inspector

by Johan Fabry

Hi all, there was a cool feature of inspectors in Pharo 3 that seems to be gone in 4. You could inspect an object, say a ValueHolder, click on a variable, e.g. value, and that would show the value of the value variable :-P in the right hand pane. OK nothing fundamentally changed in Pharo 4, that still happens. But, in Pharo 3, I could enter an expression in that pane, e.g. âabc', and hit cmd-s (accept). This would *change* the contents of value to the result of the evaluation, i.e. the string abc. I donât see how I can do that in Pharo 4, there is no menu item and no keyboard shortcut. I would really love to have that back, it can be very useful at times... ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

Jan. 5, 2015

Re: [Pharo-users] Charting graphs

by Hilaire

Nice! Le 05/01/2015 00:22, Alexandre Bergel a Ã©crit : > > RTGraphBuilder went through major improvements. > - min and max may be specified. > - plugins to add some decoration (average line, standard deviation > range, ticks lines, â¦) > -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

Jan. 5, 2015

Charting graphs

by Alexandre Bergel

Hi! RTGraphBuilder went through major improvements. - min and max may be specified. - plugins to add some decoration (average line, standard deviation range, ticks lines, â¦) Here are some examples, with some examples, which should illustrate these points: Is obtained with: -=-=-=-=-=-= -=-=-=-=-=-= -=-=-=-=-=-= -=-=-=-=-=-= -=-=-=-=-=-= | b ds | b := RTGrapherBuilder new. ds := RTDataSet new. ds points: (0 to: 100 by: 0.1). ds y: [ :x | (0.1 * x) sin ]. ds noDot. ds interaction popupText: 'sinus'. ds connectColor: Color blue. b add: ds. ds := RTDataSet new. ds points: (0 to: 100 by: 0.1). ds y: [ :x | (0.2 * x) cos * 2 ]. ds noDot. ds interaction popupText: 'cosinus'. ds connectColor: Color red. b add: ds. b minY: -4. b maxY: 4. b minX: -25. b build. -=-=-=-=-=-= -=-=-=-=-=-= -=-=-=-=-=-= -=-=-=-=-=-= -=-=-=-=-=-= -=-=-=-=-=-= -=-=-=-=-=-= -=-=-=-=-=-= -=-=-=-=-=-= -=-=-=-=-=-= b := RTGrapherBuilder new. ds := RTStackedDataSet new. ds interaction popup. ds points: #(600 470 170 430 300). ds barShape width: 20; color: Color lightGreen. b add: ds. b axisX noLabel; noTick. b axisY noDecimals. b addPlugin: RTMeanDevVarPlugin new. b build -=-=-=-=-=-= -=-=-=-=-=-= -=-=-=-=-=-= -=-=-=-=-=-= -=-=-=-=-=-= Another example: -=-=-=-=-=-= -=-=-=-=-=-= -=-=-=-=-=-= -=-=-=-=-=-= -=-=-=-=-=-= b := RTGrapherBuilder new. b extent: 300 @ 200. 5 timesRepeat: [ ds := RTStackedDataSet new. ds noDot. ds points: ((1 to: 500) collect: [ :i | 50 atRandom - 25 ]) cumsum. ds connectColor: Color green. b add: ds. ]. b addPlugin: RTMeanDevVarPlugin new. b build. -=-=-=-=-=-= -=-=-=-=-=-= -=-=-=-=-=-= -=-=-=-=-=-= -=-=-=-=-=-= The plugin framework exposes to a plugin all the necessary to define a whole range of decorations. For example, variable average lines, linear regression should be trivial to add... Happy new year! Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 4, 2015

[story] using the inspector to debug a metacello configuration problem

by Tudor Girba

Hi, Happy New Year! The GTInspector reaches its full potential when it is being extended to meet custom needs. I will try to document more scenarios to show how this works in practice and how programming changes as a result. Here is a story that describes a session of debugging a Metacello configuration problem: http://www.humane-assessment.com/blog/identifying-a-configuration-problem-w… Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

Jan. 4, 2015

Re: [Pharo-users] Metacello does not load the expected version from ConfigOf

by Dale Henrichs

Usman, It is likely that Pharo3.0 is not using the latest version of Metacello. You should be able to upgrade to the latest versions following the install instructions for Pharo3.0[1]. Dale [1] https://github.com/dalehenrich/metacello-work#pharo30 On 1/2/15 6:23 AM, Usman Bhatti wrote: > Dale, > > Thanks for your detailed explanations. > > Metacello class in my image does not seem to define the messages > described in the documentation for handling downgrading and upgrading > conflicts: > https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse… > > I am using Pharo 3.0 with Moose. > > Inline image 1 > > Did I miss something? > > regards, > Usman > > On Fri, Dec 19, 2014 at 7:00 PM, Dale Henrichs > <dale.henrichs(a)gemtalksystems.com > <mailto:dale.henrichs@gemtalksystems.com>> wrote: > > Usman, > > With classic Metacello (using the `(ConfigurationOfxxx project > version: 'xxx') load` pattern) you can only downgrade via an > explicit load of a particular version of the project. When loading > projects indirectly via a project reference from another project > Metacello is biased towards upgrade. > > With the Metacello Scripting API[1], you may include an > #onDowngradeUseIncoming: clause to selectively permit downgrades: > > Metacello new > configuration: 'DummyParser'; > version: '1.0'; > repository: '???'; > onDowngradeUseIncoming: #('PetitParser'); > load. > > For additional downgrade options see[2]. > > Since you are interested in using a specific version of a project > you may also be interested in locking the project[3][4]. With a > `lock` Metacello will not upgrade or downgrade the project but > always `honor` the lock unless an #onLock: clause is used ... > > Note that for `locking` to work, you must use the Metacello > Scripting API to do all of your project loads ... > > Dale > > [1] > https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse… > [2] > https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse… > [3] > https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse… > [4] > https://github.com/dalehenrich/metacello-work/blob/master/docs/LockCommandR… > > > > On 12/19/2014 07:44 AM, Usman Bhatti wrote: >> Hi all, >> >> I am trying to load a specific version of PetitParser in a Moose >> image. A Moose image comes with the latest development version of >> PetitParser. So, I am trying to downgrade to an older version. >> So, when I load the version manually, older versions of the >> packages are loaded: >> (ConfigurationOfPetitParser project version: '1.51') load >> >> But when I try to load the same version within my ConfigOf the >> expected packages are not loaded and list of the PetitParser >> packages loaded remains unchanged. Here is how my baseline looks >> like: >> >> ConfigurationOfDummyParser>>baseline01: spec >> <version: '0.1-baseline'> >> >> spec for: #'common' do: [ >> spec blessing: #'baseline'. >> spec project: 'PetitParser' with: [ >> spec >> className: #ConfigurationOfPetitParser; >> versionString: '1.51'; >> repository: 'http://smalltalkhub.com/mc/Moose/PetitParser/main/' >> ]. ]. >> >> I also tried creating a version but it didn't help. >> >> ConfigurationOfDummyParser>>version10: spec >> <version: '1.0' imports: #('0.1-baseline' )> >> >> spec for: #'common' do: [ >> spec blessing: #'stable'. >> spec description: 'version 1.0'. >> spec author: 'usmanbhatti'. >> spec timestamp: '12/19/2014 16:35'. >> spec project: 'PetitParser' with: '1.51'. ]. >> >> I also had a look at the package the configuration tries to load >> and the list shows correct packages to be loaded (see screenshot). >> >> Does anyone have an idea what may be problematic in my code or >> that of Metacello? I am attaching the code of my ConfigOf for a >> Moose image. >> >> Thanks in advance. >> >> UsmanInline image 1 >> >> > >

Jan. 2, 2015

Re: [Pharo-users] Metacello does not load the expected version from ConfigOf

by Usman Bhatti

Dale, Thanks for your detailed explanations. Metacello class in my image does not seem to define the messages described in the documentation for handling downgrading and upgrading conflicts: https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse… I am using Pharo 3.0 with Moose. [image: Inline image 1] Did I miss something? regards, Usman On Fri, Dec 19, 2014 at 7:00 PM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > Usman, > > With classic Metacello (using the `(ConfigurationOfxxx project version: > 'xxx') load` pattern) you can only downgrade via an explicit load of a > particular version of the project. When loading projects indirectly via a > project reference from another project Metacello is biased towards upgrade. > > With the Metacello Scripting API[1], you may include an > #onDowngradeUseIncoming: clause to selectively permit downgrades: > > Metacello new > configuration: 'DummyParser'; > version: '1.0'; > repository: '???'; > onDowngradeUseIncoming: #('PetitParser'); > load. > > For additional downgrade options see[2]. > > Since you are interested in using a specific version of a project you may > also be interested in locking the project[3][4]. With a `lock` Metacello > will not upgrade or downgrade the project but always `honor` the lock > unless an #onLock: clause is used ... > > Note that for `locking` to work, you must use the Metacello Scripting API > to do all of your project loads ... > > Dale > > [1] > https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse… > [2] > https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse… > [3] > https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse… > [4] > https://github.com/dalehenrich/metacello-work/blob/master/docs/LockCommandR… > > > On 12/19/2014 07:44 AM, Usman Bhatti wrote: > > Hi all, > > I am trying to load a specific version of PetitParser in a Moose image. > A Moose image comes with the latest development version of PetitParser. So, > I am trying to downgrade to an older version. So, when I load the version > manually, older versions of the packages are loaded: > (ConfigurationOfPetitParser project version: '1.51') load > > But when I try to load the same version within my ConfigOf the expected > packages are not loaded and list of the PetitParser packages loaded remains > unchanged. Here is how my baseline looks like: > > ConfigurationOfDummyParser>>baseline01: spec > <version: '0.1-baseline'> > > spec for: #'common' do: [ > spec blessing: #'baseline'. > spec project: 'PetitParser' with: [ > spec > className: #ConfigurationOfPetitParser; > versionString: '1.51'; > repository: 'http://smalltalkhub.com/mc/Moose/PetitParser/main/' ]. ]. > > I also tried creating a version but it didn't help. > > ConfigurationOfDummyParser>>version10: spec > <version: '1.0' imports: #('0.1-baseline' )> > > spec for: #'common' do: [ > spec blessing: #'stable'. > spec description: 'version 1.0'. > spec author: 'usmanbhatti'. > spec timestamp: '12/19/2014 16:35'. > spec project: 'PetitParser' with: '1.51'. ]. > > I also had a look at the package the configuration tries to load and the > list shows correct packages to be loaded (see screenshot). > > Does anyone have an idea what may be problematic in my code or that of > Metacello? I am attaching the code of my ConfigOf for a Moose image. > > Thanks in advance. > > Usman[image: Inline image 1] > > > > >

Jan. 2, 2015

Re: [Pharo-users] [ANN] Spec documentation in PFTE book finished

by stepharo

thanks I will have a look. Now busy building furnitures :) Le 2/1/15 08:36, Daniel Lyons a Ã©crit : > >> On Dec 28, 2014, at 3:17 PM, stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>> wrote: >> >> I would be interested by having an example that I could use to >> rewrite the spec documentation: >> - would be good to have a kind of container relationships >> to be able to display multiple list >> - the model should not be too complex to explain. >> >> So if you have data and idea I'm all ears. > > I have about 1/2 of an application written to implement PERT, which is > something management types study for doing project cost estimation, > but usually don't use in reality. It has a nice container hierarchy > (Project > Phase > Task > Task > ... > Task). I have part of the UI > written in Glamour and part in Spec, but it isn't finished. I'm using > this as a tutorial to teach my wife Pharoâalthough I'm probably not so > great at it that I should be teaching anybody. :) The tutorial isn't > as far along as the application and is probably wrongly titled at this > point. > > I'm happy to give away the code and the tutorial but I'm a little > stuck now since we have just had a baby and are now preparing to move > in three weeks. So I apologize for the rough state of affairs, but > since you asked I only hope it may be better than nothing. > > The tutorial can be read here: http://st.7gf.org/PERT/ > PDF: http://st.7gf.org/PERT/PERT.pdf > Markdown source: http://st.7gf.org/PERT/PERT.md > > Additionally I have a whiteboard capture of the interface I envision > with Glamour (which may or may not be appropriate). The size is quite > large despite the low quality, my apologies: > > http://st.7gf.org/PERT/project-window.jpg > http://st.7gf.org/PERT/simulation-window.jpg > http://st.7gf.org/PERT/project-graph-diagram.jpg > > It would be hard to come up with a more "boring" and "business" > application domain than thisâ¦ but for management people the problem is > pretty well-known and for my wife, her only prior programming > experience (not counting Excel) is C and the experience has been > positive for her so far. She's also greatly enjoying going through my > paper copy of Pharo by Example and the built-in tutorial. > > The basic concept, in case anyone is interested, is that you can form > a directed acyclic graph between subtasks and then using min/max cost > estimates, determine which tasks are "critical" and which tasks can be > late without affecting the deadline or budget. The "project window" > above uses a GLFinder-like approach to allow drilling down into > subtasks from projects and phases. This means you're stuck with a tree > instead of a DAG. > > The target level of sophistication for the final application is one > that can use expected costs and a beta distribution to simulate > thousands of different possible outcomes and then aggregate from there > to see which tasks are likely to be troublesome or have bad estimates. > This is what is pictured in the simulation-window mockup. > > The project graph diagram is just a sketch of something that would be > trivial to do with Roassal. > > The project and task/activity objects should be fairly obvious. Phase > is just recognition of the idea that projects are usually implemented > in phases, and you usually have to complete one phase before starting > the next: e.g., you must have made the prototype before you can put it > into production. This layer is unnecessary from a computational point > of view (there's nothing like it in the wiki page for PERT either) but > it's a helpful organizational tool, plus it lets you create a nice > boundary to get back some of the nice things about having a DAG that > you lose with a tree representation. > > I don't know if this is what you're looking for or not but here it is. > > All the best, > > â > Daniel Lyons > > >

Jan. 2, 2015

Re: [Pharo-users] Traveling from Pharo Days to FOSDEM

by Rafael Luque

Thank you guys! Phil thank you for your offer. We talk about it in Pharo Days. See you soon. 2014-12-31 17:33 GMT+01:00 FranÃ§ois Stephany <tulipe.moutarde(a)gmail.com>: > With the high speed train "Lille Europe" to "Brussels South" takes around > 40 minutes. > You can check fares and book tickets on https://www.b-europe.com > > @Phil do you go back to Brussels from Lille on Friday night? > > On Wed, Dec 31, 2014 at 1:37 PM, Rafael Luque < > rafael.luque.leiva(a)gmail.com> wrote: > >> Hi Pharoers, >> >> I will attend Pharo Days with a friend and after the conference we'd like >> to attend FOSDEM. Which the best way to travel to Brussels from Lille? >> >> Thank you and see you in Pharo Days. >> > >

Jan. 2, 2015

Re: [Pharo-users] [ANN] Spec documentation in PFTE book finished

by Daniel Lyons

All that and I forgot to include the link to the code. http://smalltalkhub.com/#!/~DanielLyons/PERT <http://smalltalkhub.com/#!/~DanielLyons/PERT> â Daniel Lyons

Jan. 2, 2015

Re: [Pharo-users] [ANN] Spec documentation in PFTE book finished

by Daniel Lyons

> On Dec 28, 2014, at 3:17 PM, stepharo <stepharo(a)free.fr> wrote: > > I would be interested by having an example that I could use to rewrite the spec documentation: > - would be good to have a kind of container relationships > to be able to display multiple list > - the model should not be too complex to explain. > > So if you have data and idea I'm all ears. I have about 1/2 of an application written to implement PERT, which is something management types study for doing project cost estimation, but usually don't use in reality. It has a nice container hierarchy (Project > Phase > Task > Task > ... > Task). I have part of the UI written in Glamour and part in Spec, but it isn't finished. I'm using this as a tutorial to teach my wife Pharoâalthough I'm probably not so great at it that I should be teaching anybody. :) The tutorial isn't as far along as the application and is probably wrongly titled at this point. I'm happy to give away the code and the tutorial but I'm a little stuck now since we have just had a baby and are now preparing to move in three weeks. So I apologize for the rough state of affairs, but since you asked I only hope it may be better than nothing. The tutorial can be read here: http://st.7gf.org/PERT/ <http://st.7gf.org/PERT/> PDF: http://st.7gf.org/PERT/PERT.pdf <http://st.7gf.org/PERT/PERT.pdf> Markdown source: http://st.7gf.org/PERT/PERT.md <http://st.7gf.org/PERT/PERT.md> Additionally I have a whiteboard capture of the interface I envision with Glamour (which may or may not be appropriate). The size is quite large despite the low quality, my apologies: http://st.7gf.org/PERT/project-window <http://st.7gf.org/PERT/project-window>.jpg http://st.7gf.org/PERT/simulation-window.jpg <http://st.7gf.org/PERT/simulation-window.jpg> http://st.7gf.org/PERT/project-graph-diagram.jpg It would be hard to come up with a more "boring" and "business" application domain than thisâ¦ but for management people the problem is pretty well-known and for my wife, her only prior programming experience (not counting Excel) is C and the experience has been positive for her so far. She's also greatly enjoying going through my paper copy of Pharo by Example and the built-in tutorial. The basic concept, in case anyone is interested, is that you can form a directed acyclic graph between subtasks and then using min/max cost estimates, determine which tasks are "critical" and which tasks can be late without affecting the deadline or budget. The "project window" above uses a GLFinder-like approach to allow drilling down into subtasks from projects and phases. This means you're stuck with a tree instead of a DAG. The target level of sophistication for the final application is one that can use expected costs and a beta distribution to simulate thousands of different possible outcomes and then aggregate from there to see which tasks are likely to be troublesome or have bad estimates. This is what is pictured in the simulation-window mockup. The project graph diagram is just a sketch of something that would be trivial to do with Roassal. The project and task/activity objects should be fairly obvious. Phase is just recognition of the idea that projects are usually implemented in phases, and you usually have to complete one phase before starting the next: e.g., you must have made the prototype before you can put it into production. This layer is unnecessary from a computational point of view (there's nothing like it in the wiki page for PERT either) but it's a helpful organizational tool, plus it lets you create a nice boundary to get back some of the nice things about having a DAG that you lose with a tree representation. I don't know if this is what you're looking for or not but here it is. All the best, â Daniel Lyons

Jan. 2, 2015