July 2016 - Pharo-users - lists.pharo.org

Re: [Pharo-users] "self problem" with Ghost (virus)

by Norbert Hartl

> Am 28.07.2016 um 12:56 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > > I do not like either the âvirusâ name. > not just because is negative in a subjective wayâ¦ also it hides what it does inside a fantasy name, and that IMO is negative to self discovery of the system. > > I meanâ¦ a framework can have a fantasy nameâ¦ but a class? A method name? (#infect:â¦ come on!) > > I know is âcool", but if I read the code below, I have NO CLUE of what is going to happen, and thatâs not good. > +100 Norbert > Esteban > >> On 28 Jul 2016, at 12:33, Steven Costiou <steven.costiou(a)kloum.io <mailto:steven.costiou@kloum.io>> wrote: >> >> Hi, >> >> I think i am missing something. >> >> For example in the following code (took from the tests): >> >> | victim virus actual | >> virus := GHObjectVirus behaviour: GHGhostBehaviourStub new. >> >> victim := 0@0 corner: 3@4. >> virus infect: victim. >> victim corner >> >> The evaluation is trapped by the send:to: method in the behavior (i've put a halt there). However if i replace the "corner" message by an inspect of the victim, and if i evaluate "self corner", then the message is processed without going through the send:to: method of the behavior. It is not halted and the victim responds immediately to the message. I have also tried to add a new method in the Rectangle class that calls "self corner". When called in the playground, my new message is trapped but not the "corner" sent to self. >> >> From what i understand it could be related to the behavior i use, but i don't see what's missing. >> >> >> Le 2016-07-28 11:35, Denis Kudriashov a Ã©crit : >> >>> I think I not understood second part of "self problem" in this paper. But self sends are covered by virus as I described. >>> >>> 2016-07-28 11:30 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: >>> Hi >>> >>> 2016-07-27 22:19 GMT+02:00 Steven Costiou <steven.costiou(a)kloum.io <mailto:steven.costiou@kloum.io>>: >>> Hi, >>> >>> I use virus from Ghost to intercept messages sent to a given object and adapt methods behaviors for this particular object only. However it would seems that doing interception this way is subject to the "self problem" described in this paper from StÃ©phane (DUCASSE, StÃ©phane. Evaluating message passing control techniques in Smalltalk. JOURNAL OF OBJECT ORIENTED PROGRAMMING, 1999, vol. 12, p. 39-50). >>> >>> I understand i could do instance based adaptation using an other technique, but i wonder if there is any way with Ghost to deal with this "self problem" problem ? >>> >>> I think "self problem" is only related to classic proxies when objects stay behind them. But ObjectVirus is not proxy in this meaning. When you infect your object by virus it is not replaced by somebody else. It is same original instance but with overridden behaviour. That's why I call it virus without any relation to proxies. >>> Any message to infected object is processed by your behaviour. All self sends are intercepted. But there are few exceptions: >>> - special messages like ==,ifTrue/ifNil are not intercepted >>> - meta messages are not intercepted. They processed by Ghost mechanics but they not passed to your behaviour. Meta messages defined by #currentMetaLevel of your behaviour. You could implement it like: >>> >>> YourGhostBehaviour>>currentMetaLevel >>> ^GHMetaLevel empty >>> >>> Empty meta level means that all messages will be passed to your behaviour. There is also "GHMetaLevel standard" which is default one. It makes most of "tool messages" not interceptable. For example #printString, #class, #instVarAt: will be not intercepted. It's messages which are usually used by tools like inspector and debugger. >>> Standard meta level simplifies debugging of new behaviours. If you make mistake somewhere standard messages will be not broken and you could debug error by tools. >>> >

July 28, 2016

Re: [Pharo-users] "self problem" with Ghost (virus)

by Esteban Lorenzano

I do not like either the âvirusâ name. not just because is negative in a subjective wayâ¦ also it hides what it does inside a fantasy name, and that IMO is negative to self discovery of the system. I meanâ¦ a framework can have a fantasy nameâ¦ but a class? A method name? (#infect:â¦ come on!) I know is âcool", but if I read the code below, I have NO CLUE of what is going to happen, and thatâs not good. Esteban > On 28 Jul 2016, at 12:33, Steven Costiou <steven.costiou(a)kloum.io> wrote: > > Hi, > > I think i am missing something. > > For example in the following code (took from the tests): > > | victim virus actual | > virus := GHObjectVirus behaviour: GHGhostBehaviourStub new. > > victim := 0@0 corner: 3@4. > virus infect: victim. > victim corner > > The evaluation is trapped by the send:to: method in the behavior (i've put a halt there). However if i replace the "corner" message by an inspect of the victim, and if i evaluate "self corner", then the message is processed without going through the send:to: method of the behavior. It is not halted and the victim responds immediately to the message. I have also tried to add a new method in the Rectangle class that calls "self corner". When called in the playground, my new message is trapped but not the "corner" sent to self. > > From what i understand it could be related to the behavior i use, but i don't see what's missing. > > > Le 2016-07-28 11:35, Denis Kudriashov a Ã©crit : > >> I think I not understood second part of "self problem" in this paper. But self sends are covered by virus as I described. >> >> 2016-07-28 11:30 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: >> Hi >> >> 2016-07-27 22:19 GMT+02:00 Steven Costiou <steven.costiou(a)kloum.io <mailto:steven.costiou@kloum.io>>: >> Hi, >> >> I use virus from Ghost to intercept messages sent to a given object and adapt methods behaviors for this particular object only. However it would seems that doing interception this way is subject to the "self problem" described in this paper from StÃ©phane (DUCASSE, StÃ©phane. Evaluating message passing control techniques in Smalltalk. JOURNAL OF OBJECT ORIENTED PROGRAMMING, 1999, vol. 12, p. 39-50). >> >> I understand i could do instance based adaptation using an other technique, but i wonder if there is any way with Ghost to deal with this "self problem" problem ? >> >> I think "self problem" is only related to classic proxies when objects stay behind them. But ObjectVirus is not proxy in this meaning. When you infect your object by virus it is not replaced by somebody else. It is same original instance but with overridden behaviour. That's why I call it virus without any relation to proxies. >> Any message to infected object is processed by your behaviour. All self sends are intercepted. But there are few exceptions: >> - special messages like ==,ifTrue/ifNil are not intercepted >> - meta messages are not intercepted. They processed by Ghost mechanics but they not passed to your behaviour. Meta messages defined by #currentMetaLevel of your behaviour. You could implement it like: >> >> YourGhostBehaviour>>currentMetaLevel >> ^GHMetaLevel empty >> >> Empty meta level means that all messages will be passed to your behaviour. There is also "GHMetaLevel standard" which is default one. It makes most of "tool messages" not interceptable. For example #printString, #class, #instVarAt: will be not intercepted. It's messages which are usually used by tools like inspector and debugger. >> Standard meta level simplifies debugging of new behaviours. If you make mistake somewhere standard messages will be not broken and you could debug error by tools. >>

July 28, 2016

Re: [Pharo-users] "self problem" with Ghost (virus)

by Steven Costiou

Hi, I think i am missing something. For example in the following code (took from the tests): | victim virus actual | virus := GHObjectVirus behaviour: GHGhostBehaviourStub new. victim := 0@0 corner: 3@4. virus infect: victim. victim corner The evaluation is trapped by the send:to: method in the behavior (i've put a halt there). However if i replace the "corner" message by an inspect of the victim, and if i evaluate "self corner", then the message is processed without going through the send:to: method of the behavior. It is not halted and the victim responds immediately to the message. I have also tried to add a new method in the Rectangle class that calls "self corner". When called in the playground, my new message is trapped but not the "corner" sent to self. >From what i understand it could be related to the behavior i use, but i don't see what's missing. Le 2016-07-28 11:35, Denis Kudriashov a Ã©crit : > I think I not understood second part of "self problem" in this paper. But self sends are covered by virus as I described. > > 2016-07-28 11:30 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > Hi > > 2016-07-27 22:19 GMT+02:00 Steven Costiou <steven.costiou(a)kloum.io>: > > Hi, > > I use virus from Ghost to intercept messages sent to a given object and adapt methods behaviors for this particular object only. However it would seems that doing interception this way is subject to the "self problem" described in this paper from StÃ©phane (DUCASSE, StÃ©phane. Evaluating message passing control techniques in Smalltalk. _JOURNAL OF OBJECT ORIENTED PROGRAMMING_, 1999, vol. 12, p. 39-50). > > I understand i could do instance based adaptation using an other technique, but i wonder if there is any way with Ghost to deal with this "self problem" problem ? I think "self problem" is only related to classic proxies when objects stay behind them. But ObjectVirus is not proxy in this meaning. When you infect your object by virus it is not replaced by somebody else. It is same original instance but with overridden behaviour. That's why I call it virus without any relation to proxies. > Any message to infected object is processed by your behaviour. All self sends are intercepted. But there are few exceptions: > - special messages like ==,ifTrue/ifNil are not intercepted > - meta messages are not intercepted. They processed by Ghost mechanics but they not passed to your behaviour. Meta messages defined by #currentMetaLevel of your behaviour. You could implement it like: > > YourGhostBehaviour>>currentMetaLevel > ^GHMetaLevel empty > > Empty meta level means that all messages will be passed to your behaviour. There is also "GHMetaLevel standard" which is default one. It makes most of "tool messages" not interceptable. For example #printString, #class, #instVarAt: will be not intercepted. It's messages which are usually used by tools like inspector and debugger. > Standard meta level simplifies debugging of new behaviours. If you make mistake somewhere standard messages will be not broken and you could debug error by tools.

July 28, 2016

Re: [Pharo-users] "self problem" with Ghost (virus)

by Guille Polito

This is the difference between Forwarding and Delegation [1]. Accessorily to this discussion, the name "Virus" does not yet convince me: - first, it has a negative connotation in informatics. People do not want to have virus installed. They do not want virus infecting their machines. People using Pharo for business will not install Viruses nor write ones :) - regarding the metaphorical aspect, a virus contaminates an organism, and moreover, we want to eliminate it not keep it... - besides, Virus might be a fancy name, but you already have a fancy/fantasy name in the project: Ghost. Thus, I would not call the class implementing such behavior a virus. The "meta" vocabulary is already complex, and specially the one around proxies. I think that adding virus to it only complexifies even more the context... I would stick with the behavior used by the rest of the world in this case. Guille [1]https://en.wikipedia.org/wiki/Forwarding_(object-oriented_programming)#Ex… -------- Original Message -------- > I think I not understood second part of "self problem" in this paper. > But self sends are covered by virus as I described. > > 2016-07-28 11:30 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com > <mailto:dionisiydk@gmail.com>>: > > Hi > > 2016-07-27 22:19 GMT+02:00 Steven Costiou <steven.costiou(a)kloum.io > <mailto:steven.costiou@kloum.io>>: > > Hi, > > I use virus from Ghost to intercept messages sent to a given > object and adapt methods behaviors for this particular object > only. However it would seems that doing interception this way > is subject to the "self problem" described in this paper from > StÃ©phane (DUCASSE, StÃ©phane. Evaluating message passing > control techniques in Smalltalk. /JOURNAL OF OBJECT ORIENTED > PROGRAMMING/, 1999, vol. 12, p. 39-50). > > I understand i could do instance based adaptation using an > other technique, but i wonder if there is any way with Ghost > to deal with this "self problem" problem ? > > I think "self problem" is only related to classic proxies when > objects stay behind them. But ObjectVirus is not proxy in this > meaning. When you infect your object by virus it is not replaced > by somebody else. It is same original instance but with overridden > behaviour. That's why I call it virus without any relation to proxies. > Any message to infected object is processed by your behaviour. All > self sends are intercepted. But there are few exceptions: > - special messages like ==,ifTrue/ifNil are not intercepted > - meta messages are not intercepted. They processed by Ghost > mechanics but they not passed to your behaviour. Meta messages > defined by #currentMetaLevel of your behaviour. You could > implement it like: > > YourGhostBehaviour>>currentMetaLevel > > ^GHMetaLevel empty > > > Empty meta level means that all messages will be passed to your > behaviour. There is also "GHMetaLevel standard" which is default > one. It makes most of "tool messages" not interceptable. For > example #printString, #class, #instVarAt: will be not intercepted. > It's messages which are usually used by tools like inspector and > debugger. > Standard meta level simplifies debugging of new behaviours. If you > make mistake somewhere standard messages will be not broken and > you could debug error by tools. > >

July 28, 2016

Re: [Pharo-users] "self problem" with Ghost (virus)

by Denis Kudriashov

I think I not understood second part of "self problem" in this paper. But self sends are covered by virus as I described. 2016-07-28 11:30 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Hi > > 2016-07-27 22:19 GMT+02:00 Steven Costiou <steven.costiou(a)kloum.io>: > >> Hi, >> >> I use virus from Ghost to intercept messages sent to a given object and >> adapt methods behaviors for this particular object only. However it would >> seems that doing interception this way is subject to the "self problem" >> described in this paper from StÃ©phane (DUCASSE, StÃ©phane. Evaluating >> message passing control techniques in Smalltalk. *JOURNAL OF OBJECT >> ORIENTED PROGRAMMING*, 1999, vol. 12, p. 39-50). >> >> I understand i could do instance based adaptation using an other >> technique, but i wonder if there is any way with Ghost to deal with this >> "self problem" problem ? >> > I think "self problem" is only related to classic proxies when objects > stay behind them. But ObjectVirus is not proxy in this meaning. When you > infect your object by virus it is not replaced by somebody else. It is same > original instance but with overridden behaviour. That's why I call it virus > without any relation to proxies. > Any message to infected object is processed by your behaviour. All self > sends are intercepted. But there are few exceptions: > - special messages like ==,ifTrue/ifNil are not intercepted > - meta messages are not intercepted. They processed by Ghost mechanics but > they not passed to your behaviour. Meta messages defined by > #currentMetaLevel of your behaviour. You could implement it like: > > > YourGhostBehaviour>>currentMetaLevel > > ^GHMetaLevel empty > > > Empty meta level means that all messages will be passed to your behaviour. > There is also "GHMetaLevel standard" which is default one. It makes most of > "tool messages" not interceptable. For example #printString, #class, > #instVarAt: will be not intercepted. It's messages which are usually used > by tools like inspector and debugger. > Standard meta level simplifies debugging of new behaviours. If you make > mistake somewhere standard messages will be not broken and you could debug > error by tools. > >

July 28, 2016

Re: [Pharo-users] "self problem" with Ghost (virus)

by Denis Kudriashov

Hi 2016-07-27 22:19 GMT+02:00 Steven Costiou <steven.costiou(a)kloum.io>: > Hi, > > I use virus from Ghost to intercept messages sent to a given object and > adapt methods behaviors for this particular object only. However it would > seems that doing interception this way is subject to the "self problem" > described in this paper from StÃ©phane (DUCASSE, StÃ©phane. Evaluating > message passing control techniques in Smalltalk. *JOURNAL OF OBJECT > ORIENTED PROGRAMMING*, 1999, vol. 12, p. 39-50). > > I understand i could do instance based adaptation using an other > technique, but i wonder if there is any way with Ghost to deal with this > "self problem" problem ? > I think "self problem" is only related to classic proxies when objects stay behind them. But ObjectVirus is not proxy in this meaning. When you infect your object by virus it is not replaced by somebody else. It is same original instance but with overridden behaviour. That's why I call it virus without any relation to proxies. Any message to infected object is processed by your behaviour. All self sends are intercepted. But there are few exceptions: - special messages like ==,ifTrue/ifNil are not intercepted - meta messages are not intercepted. They processed by Ghost mechanics but they not passed to your behaviour. Meta messages defined by #currentMetaLevel of your behaviour. You could implement it like: YourGhostBehaviour>>currentMetaLevel ^GHMetaLevel empty Empty meta level means that all messages will be passed to your behaviour. There is also "GHMetaLevel standard" which is default one. It makes most of "tool messages" not interceptable. For example #printString, #class, #instVarAt: will be not intercepted. It's messages which are usually used by tools like inspector and debugger. Standard meta level simplifies debugging of new behaviours. If you make mistake somewhere standard messages will be not broken and you could debug error by tools.

July 28, 2016

Re: [Pharo-users] Questions

by Sven Van Caekenberghe

And there is this chapter in the new book: https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessf… But I understood that Alejandro has to write a simple CSV parser from first principles himself. > On 28 Jul 2016, at 09:51, Julien Delplanque <julien(a)tamere.eu> wrote: > > Hello, > > Have a look at "NeoCSV" project from the catalog browser. > > This document [1] may help you as well. There is a dedicated section for NeoCSV. > > Regards, > Julien > > Links: > [1]: http://www.slideshare.net/philippeback/pharo-days-2016-data-formats-and-pro… > > > On 28/07/16 08:30, Alejandro Adgi Romano wrote: >> Hello, my name is Alejandro. >> >> IÂ´m writting code in Pharo 5.0. >> >> I need finish an exercise of my career. >> >> My question is: >> >> Â¿Could you tell me how can read and write a CSV File? >> >> I need the code, because i donÂ´t understand how is the use of NeoCSV or >> another tool for this. >> >> In the exercise, the text says: >> "You must Show the CashFlow por One Period with information from >> CashFlow.csv" >> >> >> Â¿How can I do this? >> >> Thanks!!! >> > >

July 28, 2016

Re: [Pharo-users] Questions

by Julien Delplanque

Hello, Have a look at "NeoCSV" project from the catalog browser. This document [1] may help you as well. There is a dedicated section for NeoCSV. Regards, Julien Links: [1]: http://www.slideshare.net/philippeback/pharo-days-2016-data-formats-and-pro… On 28/07/16 08:30, Alejandro Adgi Romano wrote: > Hello, my name is Alejandro. > > IÂ´m writting code in Pharo 5.0. > > I need finish an exercise of my career. > > My question is: > > Â¿Could you tell me how can read and write a CSV File? > > I need the code, because i donÂ´t understand how is the use of NeoCSV or > another tool for this. > > In the exercise, the text says: > "You must Show the CashFlow por One Period with information from > CashFlow.csv" > > > Â¿How can I do this? > > Thanks!!! >

July 28, 2016

Questions

by Alejandro Adgi Romano

Hello, my name is Alejandro. IÂ´m writting code in Pharo 5.0. I need finish an exercise of my career. My question is: Â¿Could you tell me how can read and write a CSV File? I need the code, because i donÂ´t understand how is the use of NeoCSV or another tool for this. In the exercise, the text says: "You must Show the CashFlow por One Period with information from CashFlow.csv" Â¿How can I do this? Thanks!!!

July 28, 2016

Re: [Pharo-users] Spec: Capturing changes in a text morph

by Offray Vladimir Luna CÃ¡rdenas

Thanks Johan, now I'm in the right path. I have implemented basic persistence and now I'm working on the add/remove promote/demote node operations and I need to revisit the body persistence after that to make it work on each node. Cheers, Offray On 26/07/16 15:32, Johan Fabry wrote: > No, this is not in initializePresenter, since this is called only once, when the window is opened. Instead, you need to do this every time that the widget is changed. So in your code where you change the widget to a new one, I guess this is changeBody: , you need to configure this new widget. > > -- > Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org . > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > >> On Jul 26, 2016, at 16:08, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: >> >> Thanks Johan for your quick answer. >> >> Your hypothesis is right and the contents of (4) are cleaned by a new widget when I click at the tree (2). I'm looking at my code and documentation, but I can't find properly how to implement your recommendation. I imagine is somewhere in initializePresenter, but I can't find the place... sorry I would like to be more helpful on getting help... :-/. >> >> Any hint of how this code should look like and where it goes? "body whenTextChanged: aBlock" on initializePresenter seems doing nothing. >> >> Cheers, >> >> Offray >> >> >> On 26/07/16 11:19, Johan Fabry wrote: >>> I think the problem is that when you click on an item in the tree (2), the contents of (4) is changed to a new widget. As a result the configuration that you did in initializePresenter is lost. What you should do is when you change the contents of (4) also configure this new widget with a whenTextChanged: block. I think that will solve your problem. >>> >>> -- >>> Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org . >>> >>> Johan Fabry - http://pleiad.cl/~jfabry >>> PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile >>> >>>> On Jul 25, 2016, at 18:12, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: >>>> >>>> Hi, >>>> >>>> I'm migrating my grafoscopio interface from I'm trying to capture some changes in a text morph that is part of a Spec interface. The interface is split in 4 parts, as you can see at [a]: (1) a main menu, (2) a tree, (3) a node header input text and (4) a text morph. When you click any node on the tree (2) the name of the node, called the header is shown in (3) and the node contents, called the body are shown at (4). If you made a change in the header (pressing enter) it's reflected back to the main tree. And the node's body is changed for a text morph [b] or a and embedded playground [c] according to tags in the node. So the reading part is working and I have some partial support for persistence, at least for node headers. >>>> >>>> [a] https://offray.withknown.com/2016/grafoscopio-notebook-interface >>>> [b] https://offray.withknown.com/2016/grafoscopio-text-node >>>> [c] https://offray.withknown.com/2016/grafoscopio-code-node >>>> >>>> Now I would like to extend the persistence for node's body content, so when any changes happens in the (4) panel, be it a text panel or a playground, it is stored in a similar way to what is happening with node headers and the (3) panel, but I'm unsuccessful trying to capture those changes. >>>> >>>> My initializeWidgets and initializePresenter are implemented this way: >>>> >>>> ================= >>>> >>>> GrafoscopioNotebook>>initializeWidgets >>>> >>>> windowMainMenu := self newWindowMainMenu. >>>> tree := TreeModel new. >>>> body := self newText. >>>> header := self newTextInput. >>>> >>>> body disable. >>>> body text: '<-- Select a node in the left panel'. >>>> >>>> tree >>>> childrenBlock: [:node | node children]; >>>> displayBlock: [:node | node title ]. >>>> >>>> ================= >>>> >>>> initializePresenter >>>> >>>> tree whenSelectedItemsChanged: [ :arg | >>>> arg isEmpty ifFalse: [self changeBody: arg ]]. >>>> header whenTextChanged: [ :arg | >>>> Transcript show: arg. >>>> (tree selectedItem content header) = arg >>>> ifFalse: [ >>>> (tree selectedItem) content header: arg. >>>> tree roots: tree roots]]. >>>> body whenTextIsAccepted: [ :arg | >>>> Transcript show: arg >>>> ] >>>> >>>> ================= >>>> >>>> I'm capturing properly the changes in text with whenTextChanged on the header but using the same message on body or whenTextIsAccepted doesn't produce any change on the trascript, and of course I can't update the any tree/node contents properly. >>>> >>>> Any advice on how to solve this will be greatly appreciated. If can happen soon in this week even better, because we could show this to our hackathon/workshop attendees. >>>> >>>> Cheers, >>>> >>>> Offray >>>> >>>> >>>> >>> >> >> > >

July 28, 2016