June 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Test request

by john pfersich

I followed the steps in your mail and it seems to work fine in Ubuntu 16.04 LTS, though I've never tried Dr Geo and the app is mostly in French. It's been 47 years since I've used French extensively, so YMMV. Let you know if I have problems. On Mon, Jun 12, 2017 at 12:59 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > Hi, > > > A Dr. Geo user on Ubuntu 16.04 reported to me instability problem I do > not meet on my 12.04 config. It seems related to Cairo or FreeType. I > will likely update my system on 16.04 later this summer, but I can't > just tweak it as this is the end of the school year with several admin > tasks to conduct. > > Will any one of you with a Ubuntu 16.04 system wish to test Dr. Geo and > report to me any problem? > > If so, here is what to do: > > 1. Download and unzip > https://launchpad.net/drgeo/trunk/17.07/+download/DrGeo.app-17.07a.zip > > 2. Adjust system to 32 bits compatibility if necessary, follow > instructions at > http://www.drgeo.eu/faq#TOC-Debian-Jessie-Ubuntu-LinuxMint-12.04-LTS1 > > 3. Experiment freely then drag'n drop the TortueOrange.fgeo found in the > zip file at > https://www.dropbox.com/s/2n3taeev9mdphdm/TortueOrange.fgeo.zip?dl=0 > > Does it went fine? > > Thanks > > Hilaire > > -- > Dr. Geo > http://drgeo.eu > > > >

June 13, 2017

Test request

by Hilaire

Hi, A Dr. Geo user on Ubuntu 16.04 reported to me instability problem I do not meet on my 12.04 config. It seems related to Cairo or FreeType. I will likely update my system on 16.04 later this summer, but I can't just tweak it as this is the end of the school year with several admin tasks to conduct. Will any one of you with a Ubuntu 16.04 system wish to test Dr. Geo and report to me any problem? If so, here is what to do: 1. Download and unzip https://launchpad.net/drgeo/trunk/17.07/+download/DrGeo.app-17.07a.zip 2. Adjust system to 32 bits compatibility if necessary, follow instructions at http://www.drgeo.eu/faq#TOC-Debian-Jessie-Ubuntu-LinuxMint-12.04-LTS1 3. Experiment freely then drag'n drop the TortueOrange.fgeo found in the zip file at https://www.dropbox.com/s/2n3taeev9mdphdm/TortueOrange.fgeo.zip?dl=0 Does it went fine? Thanks Hilaire -- Dr. Geo http://drgeo.eu

June 12, 2017

Re: [Pharo-users] A question of style - pass a context or embed one?

by phil＠highoctane.be

A dynamic variable could work too. But domain objects are somewhat hard to do in my view because we are dealing with an API that has tons of options and customizability in its results + people can define their own types and fields. That's why I went for a JiraBuilder thing that has a reference to a Jira instance. That builder is allowing one to make higher level queries for the users (like doing Epics, Stories, links, custom fields resolution, meta data grabbing, prototype creation etc). I didn't want to have an Epic class, a Story class, etc. Because my idea of an Epic may not be your idea, so we may end up with a PluggableEpic etc and it will never end. My take is that it is better to use the vocabulary of the domain in the method names but still work with dynamic structures like dictionaries and some helpers. I am still curious to see those domain objects because I understand that they would ease inspection etc. Maybe we should have a generator for these so that we can regenerate the classes based on the metadata provided by Jira. Phil On Mon, Jun 12, 2017 at 9:28 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Hello Tim, > > 2017-06-12 16:15 GMT-03:00 Tim Mackinnon <tim(a)testit.works>: > > Hi - Iâm after some ideas or maybe previous examples that might guide me > in the best approach of wrapping a low level library (essentially the Jira > connector that Phil demoâd at Pharo days this year). > > > > There are some low level commands that will fetch json arrays for you > given a âliraâ instance- e.g: > > > > board := JiraBoard fromJira: jira named: âProject'. > > sprints := board sprintsFrom: jira. > > > > My question is related to building on top of this - and its a style > question. > > > > I want model objects that wrap the json arrays and let me navigate > things a bit more simply, and query details more naturally - however I > canât decide whether my model objects should âcontainâ a jira when you > instantiate them - which can be re-used for subsequent queries - OR - > whether I should view jira as a from of context, and keep passing it to > methods when I need to retrieve more details, or child objects? > > > > e.g. > > myBoard := ModelBoard fromJira: jira named: âProjectâ. > > mySprints := myBoard sprints. âNo need to pass the jira againâ. > > > > vs. > > > > mySprints :- myBoard sprintsIn: jira. > > > > > > Iâm wondering if anything might guide me one way or the other? Is one > more tasteful/elegant than the other? > > > I'd go for the first option. It is, every JIRA object knows the "jira" > it belongs to. > > Although the second option is better for decoupling, not having to > pass objects around to obtain properties allows you to better > integrate with the tools (think GTInspector with specific inspector > for cards). > > I don't understand what the "jira" is exactly, if a whole JSON object > (a Dictionary) containing everything, a connection to JIRA API, or > just the JSON object/Dictionary branch containing the attributes > specific of the "wraping" object (the board, in this case). > > Regards! > > Esteban A. Maringolo > > >

June 12, 2017

Re: [Pharo-users] A question of style - pass a context or embed one?

by Esteban A. Maringolo

Hello Tim, 2017-06-12 16:15 GMT-03:00 Tim Mackinnon <tim(a)testit.works>: > Hi - Iâm after some ideas or maybe previous examples that might guide me in the best approach of wrapping a low level library (essentially the Jira connector that Phil demoâd at Pharo days this year). > > There are some low level commands that will fetch json arrays for you given a âliraâ instance- e.g: > > board := JiraBoard fromJira: jira named: âProject'. > sprints := board sprintsFrom: jira. > > My question is related to building on top of this - and its a style question. > > I want model objects that wrap the json arrays and let me navigate things a bit more simply, and query details more naturally - however I canât decide whether my model objects should âcontainâ a jira when you instantiate them - which can be re-used for subsequent queries - OR - whether I should view jira as a from of context, and keep passing it to methods when I need to retrieve more details, or child objects? > > e.g. > myBoard := ModelBoard fromJira: jira named: âProjectâ. > mySprints := myBoard sprints. âNo need to pass the jira againâ. > > vs. > > mySprints :- myBoard sprintsIn: jira. > > > Iâm wondering if anything might guide me one way or the other? Is one more tasteful/elegant than the other? I'd go for the first option. It is, every JIRA object knows the "jira" it belongs to. Although the second option is better for decoupling, not having to pass objects around to obtain properties allows you to better integrate with the tools (think GTInspector with specific inspector for cards). I don't understand what the "jira" is exactly, if a whole JSON object (a Dictionary) containing everything, a connection to JIRA API, or just the JSON object/Dictionary branch containing the attributes specific of the "wraping" object (the board, in this case). Regards! Esteban A. Maringolo

June 12, 2017

A question of style - pass a context or embed one?

by Tim Mackinnon

Hi - Iâm after some ideas or maybe previous examples that might guide me in the best approach of wrapping a low level library (essentially the Jira connector that Phil demoâd at Pharo days this year). There are some low level commands that will fetch json arrays for you given a âliraâ instance- e.g: board := JiraBoard fromJira: jira named: âProject'. sprints := board sprintsFrom: jira. My question is related to building on top of this - and its a style question. I want model objects that wrap the json arrays and let me navigate things a bit more simply, and query details more naturally - however I canât decide whether my model objects should âcontainâ a jira when you instantiate them - which can be re-used for subsequent queries - OR - whether I should view jira as a from of context, and keep passing it to methods when I need to retrieve more details, or child objects? e.g. myBoard := ModelBoard fromJira: jira named: âProjectâ. mySprints := myBoard sprints. âNo need to pass the jira againâ. vs. mySprints :- myBoard sprintsIn: jira. Iâm wondering if anything might guide me one way or the other? Is one more tasteful/elegant than the other? Tim

June 12, 2017

Re: [Pharo-users] Remote debugger: do i need identical images ?

by Steven Costiou

Le 2017-06-12 16:27, Denis Kudriashov a Ã©crit : > Hi. > > 2017-06-12 16:03 GMT+02:00 Steven Costiou <steven.costiou(a)kloum.io>: > >> Hi, >> >> when using the Pharo remote debugger, we have a server side (the remote application) and a client side (the local computer used to debug). >> >> Apart from the remote debugger itself, do both images need to have exactly the same code - especially the application itself - or could they be different ? >> >> More specifically, to debug a program, do i need a local "clone" image dedicated to debug the remote image ? > No. Client development image not needs any code of your remote application. > > Only requirement is same version of PharmIDE related projects on both images. Thanks :)

June 12, 2017

Re: [Pharo-users] Remote debugger: do i need identical images ?

by Denis Kudriashov

Hi. 2017-06-12 16:03 GMT+02:00 Steven Costiou <steven.costiou(a)kloum.io>: > Hi, > > when using the Pharo remote debugger, we have a server side (the remote > application) and a client side (the local computer used to debug). > > Apart from the remote debugger itself, do both images need to have exactly > the same code - especially the application itself - or could they be > different ? > > More specifically, to debug a program, do i need a local "clone" image > dedicated to debug the remote image ? > No. Client development image not needs any code of your remote application. Only requirement is same version of PharmIDE related projects on both images.

June 12, 2017

Remote debugger: do i need identical images ?

by Steven Costiou

Hi, when using the Pharo remote debugger, we have a server side (the remote application) and a client side (the local computer used to debug). Apart from the remote debugger itself, do both images need to have exactly the same code - especially the application itself - or could they be different ? More specifically, to debug a program, do i need a local "clone" image dedicated to debug the remote image ? Steven.

June 12, 2017

Re: [Pharo-users] Wiring objects, IoC and Service Locator

by Vitor Medina Cruz

> > I don't think it should. If you have a small cluster of objects where you > can manage the dependencies yourself, you can compose larger objects from > them and manage the dependencies the same way. By doing so, you'll get an > object that is simpler from the outside than it's parts in the inside, and > you'll need to solve the smaller problem again. In other words we shouldn't > write large software, but compose large software from smaller ones. But the > same can be done with objects (that's why I'm not a big fan of > microservices > despite they solve this problem similarly). > If you have a flat structure (where objects don't form higher level > abstractions) and everything needs to know about everything else, then the > DI container will make it easier to work with this structure. But I don't > think this is the right way to organize a software. Yes, that makes sense.... 1. Blocks (i.e. anonymous functions) means that one needs not necessarily > implement a /Class/ (MovieFinder), in order to vary alternative behavior, > unlike Java (before 8). > 2. If one does want a number of "finders" (as Classes), then one will > typically see one "injected" (constructor or method injection), where each > understands some common "find" message. > Is the real question for 2 above, "what (or who) decides" which will be > injected? Finder is just an illustration of the problem, that finder class can have much more behavior in a real example, such as a DAO or a Repository would have, and blocks could't be used properly to deal with that. cheers, Vitor On Sat, Jun 10, 2017 at 8:59 AM, aryehof <pharodev(a)aryeh.sent.com> wrote: > In SmallTalk:- > > 1. Blocks (i.e. anonymous functions) means that one needs not necessarily > implement a /Class/ (MovieFinder), in order to vary alternative behavior, > unlike Java (before 8). > > 2. If one does want a number of "finders" (as Classes), then one will > typically see one "injected" (constructor or method injection), where each > understands some common "find" message. > > Is the real question for 2 above, "what (or who) decides" which will be > injected? > > > > -- > View this message in context: http://forum.world.st/Wiring- > objects-IoC-and-Service-Locator-tp4949280p4950768.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

June 12, 2017

Re: [Pharo-users] Rewriting question

by werner kassens

Hi Nicolai, thanks, yes, i can see that basically more or less solves the problem i had. werner On 06/12/2017 09:15 AM, Nicolai Hess wrote: > > > 2017-06-10 21:16 GMT+02:00 werner kassens <wkassens(a)libello.com > <mailto:wkassens@libello.com>>: > > On 06/10/2017 04:07 PM, werner kassens wrote: > > On 06/10/2017 03:37 PM, werner kassens wrote: > > Hi, > > i have a private rewriting rule. unfortunately it shows up > in the lower pane of the SystemBrowser which makes no > sense at all, since it is not intended for use outside of > the program using it. how do i make it invisible for that > part of the systembrowser? and btw where are the rules > collected for that part? > > werner > > i should add that it only shows up after i used it. > werner > > and i use this way: > b:=MyRBTransformationRule new runOnEnvironment: a. > b builder changes do:[:r|r execute]. > and afterwards MyRBTransformationRule also appears in the lower > SystemBrowser pane if applicable. > > > > Maybe all transformation rules are defaults to "visible rule classes" > (see ReRuleManager allRules) > > @Yuriy > can you check > ReRuleManager classAdded: aClassAddedAnnouncement > I am not sure the (aClassAddedAnnouncement classAdded isKindOf: > RBLintRule) works as intended. >

June 12, 2017