Send Pharo-users mailing list submissions to
�� �� �� �� pharo-users@lists.pharo.org

To subscribe or unsubscribe via the World Wide Web, visit
�� �� �� �� http://lists.pharo.org/mailman/listinfo/pharo-users_lists.pharo.org
or, via email, send a message with subject or body 'help' to
�� �� �� �� pharo-users-request@lists.pharo.org

You can reach the person managing the list at
�� �� �� �� pharo-users-owner@lists.pharo.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Pharo-users digest..."


Today's Topics:

�� ��1. Update CI books written in Pillar (Yann Dubois)
�� ��2. Re: "self problem" with Ghost (virus) (Steven Costiou)
�� ��3. Re: "self problem" with Ghost (virus) (Denis Kudriashov)


----------------------------------------------------------------------

Message: 1
Date: Thu, 28 Jul 2016 13:43:52 +0200
From: Yann Dubois <yann59.dubois@gmail.com>
To: Any question about pharo is welcome <pharo-users@lists.pharo.org>
Subject: [Pharo-users] Update CI books written in Pillar
Message-ID:
�� �� �� �� <CALbP1jtHe9GefP7s9KwAnD6QaB_qzyBuUqzE1sZH0oNuSWESAA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi !

In the last version of Pillar (4.0.x), Pillar don't manage the compilation
cycle. So the ./compile.sh does not work anymore.

To update our CI, we use a Makefile (I advise you to use this too). You
have an example on :
https://github.com/pillar-markup/Pillar-Archetype/blob/master/welcome/Makefile
.

In this Makefile, we create symbolic links pointing on the output
directory. It causes "out of memory" on Jenkins. To solve this problem, you
need to remove the symbolic links after the compilation. Personnaly, I had

*find book-result -type l -exec unlink {} \;*


at the end of the EnterprisePharo's Jenkins script.

Cheers, Yann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20160728/aac41a4c/attachment-0001.html>

------------------------------

Message: 2
Date: Thu, 28 Jul 2016 13:46:01 +0200
From: Steven Costiou <steven.costiou@kloum.io>
To: Any question about pharo is welcome <pharo-users@lists.pharo.org>
Subject: Re: [Pharo-users] "self problem" with Ghost (virus)
Message-ID: <bc8fc09bd496425f4dc95cf029322b40@kloum.io>
Content-Type: text/plain; charset="utf-8"

Ok by digging a bit, i found that it was a problem in my behavior though
i don't understand it.

When sending message to self, the #isMetaMessage: returns always true
when evaluating the first test condition GHCurrentMetaLevelDepth value >
0 ifTrue: [ ^true ]. The value returns something higher than 0 and my
"self messages" are considered to be meta-messages. It is very sensible
to modifications, as just removing this test or try to bend it can
freezes the image (just tried to see what would happen).

I'm a bit lost, what should i do to consider "self messages" not "meta"
in the behavior ?

Le 2016-07-28 12:33, Steven Costiou a ?crit :

> 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@gmail.com>:
>
> Hi
>
> 2016-07-27 22:19 GMT+02:00 Steven Costiou <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.

--
kloum.io
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20160728/74d445a7/attachment-0001.html>

------------------------------

Message: 3
Date: Thu, 28 Jul 2016 14:05:33 +0200
From: Denis Kudriashov <dionisiydk@gmail.com>
To: Any question about pharo is welcome <pharo-users@lists.pharo.org>
Subject: Re: [Pharo-users] "self problem" with Ghost (virus)
Message-ID:
�� �� �� �� <CAG0zXM4TGAPxzF0pthrPU7jmr+t5id0E726vx_Fv4xGNMtnEYw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Steven, I fixed it.
Load development version (or just this:
Ghost-ObjectVirus-DenisKudryashov.12).

I will update stable soon

2016-07-28 13:46 GMT+02:00 Steven Costiou <steven.costiou@kloum.io>:

> Ok by digging a bit, i found that it was a problem in my behavior though i
> don't understand it.
>
> When sending message to self, the #isMetaMessage: returns always true when
> evaluating the first test condition GHCurrentMetaLevelDepth value > 0
> ifTrue: [ ^true ]. The value returns something higher than 0 and my "self
> messages" are considered to be meta-messages. It is very sensible to
> modifications, as just removing this test or try to bend it can freezes the
> image (just tried to see what would happen).
>
> I'm a bit lost, what should i do to consider "self messages" not "meta" in
> the behavior ?
>
>
>
>
>
> Le 2016-07-28 12:33, Steven Costiou a ?crit :
>
> 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@gmail.com>:
>
>> Hi
>>
>> 2016-07-27 22:19 GMT+02:00 Steven Costiou <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.
>>
>>
>
> --
> kloum.io
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20160728/4897722a/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
Pharo-users mailing list
Pharo-users@lists.pharo.org
http://lists.pharo.org/mailman/listinfo/pharo-users_lists.pharo.org


------------------------------

End of Pharo-users Digest, Vol 39, Issue 126
********************************************