Re: [Pharo-users] Emojis in Pharo

[Sean P. DeNigris]

Ben Coman wrote
> Do you want to display them as graphics...
> http://unicode.org/emoji/charts/full-emoji-list.html

In this case, yes. I'd like to have them properly display inside Pharo.



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Emojis-in-Pharo-tp4908461p4908573.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Emojis in Pharo

[Ben Coman]

On Thu, Jul 28, 2016 at 10:11 PM, Sean P. DeNigris
 wrote:
> Are there any available fonts which correctly display emojis? I'm playing
> with sms data...

Do you want to display them as graphics...
http://unicode.org/emoji/charts/full-emoji-list.html

or cross-platform characters...
https://github.com/Ranks/emojione/tree/master/assets/fonts

Maybe...
*  Helevetica Neue font on iPhone
   https://www.twilio.com/blog/2015/08/common-sms-problems-unicode-twilio.html
* Apple Color Emoji.ttf on OSX...
   https://support.apple.com/en-au/HT201344
* Segoe UI on Windows...
   https://support.microsoft.com/en-us/kb/2729094

btw, in Pharo how do you place characters of different fonts on one line?

cheers -ben



P.S. Actually I think I've had enough of Pharo.  I moving the next
best thing... "emojicode" (MIT licensed)...
http://thenextweb.com/dd/2016/03/04/now-you-can-use-emoji-to-code

;)  ;)
see, I've started already!

Re: [Pharo-users] XMLParser Claims U+00A0 is “Invalid UTF-8”

[Sven Van Caekenberghe]

> On 29 Jul 2016, at 00:15, monty  wrote:
> 
> Good for finding one of the fixes, but please use #parseURL:/#onURL: instead 
> of #asUrl/#asZnUrl with #retrieveContents, because that will result in Zinc 
> eagerly decoding the response without looking at the  declaration as 
> the XML spec requires.
> 
> #parseURL:/#onURL: use Zinc correctly, doing their own XML-aware encoding on 
> top of it.

Yes, you are right. Thanks for implementing all this logic, I known it is quite 
complicated and tricky.

>> Sent: Thursday, July 28, 2016 at 5:29 PM
>> From: "Sven Van Caekenberghe" 
>> To: "Any question about pharo is welcome" 
>> Subject: Re: [Pharo-users] XMLParser Claims U+00A0 is “Invalid UTF-8”
>> 
>> In my older work image, the following just works:
>> 
>> XMLDOMParser parse:
>> ('http://forum.world.st/file/n4908531/illegal-UTF-sms.xml' asUrl 
>> retrieveContents).
>> 
>> But I guess that is because my (older) XML parser version ignores the 
>> encoding, or is more lenient.
>> 
>> You could try to edit the incoming file, or have a look at 
>> #decodesCharacters: 
>> 
>> (XMLDOMParser on:
>> ('http://forum.world.st/file/n4908531/illegal-UTF-sms.xml' asUrl 
>> retrieveContents) readStream) decodesCharacters: false; parseDocument.
>> 
>> But I am no expert in the deeper aspects of XML Support.
>> 
>>> On 28 Jul 2016, at 22:29, Sean P. DeNigris  wrote:
>>> 
>>> Sven Van Caekenberghe-2 wrote
 Your XML file is not UTF-8 encoded, it is plain Unicode. At least the way
 it is served from the URL you gave.
 ..
 You see ?
>>> 
>>> Unfortunately, no! ha ha. I didn't generate the file and I took it's
>>> assertion that it was UTF-8 at face value. How do I properly feed the file
>>> into XMLParser?
>>> 
>>> 
>>> 
>>> -
>>> Cheers,
>>> Sean
>>> --
>>> View this message in context: 
>>> http://forum.world.st/XMLParser-Claims-U-00A0-is-Invalid-UTF-8-tp4908525p4908539.html
>>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>>> 
>> 
>> 
>> 
> 

Re: [Pharo-users] XMLParser Claims U+00A0 is “Invalid UTF-8”

[monty]

Also #parseURL:/#onURL: will use WebClient on Squeak (unless Zinc is present of 
course)

> Sent: Thursday, July 28, 2016 at 6:15 PM
> From: monty 
> To: pharo-users@lists.pharo.org
> Subject: Re: [Pharo-users] XMLParser Claims U+00A0 is “Invalid UTF-8”
>
> Good for finding one of the fixes, but please use #parseURL:/#onURL: instead 
> of #asUrl/#asZnUrl with #retrieveContents, because that will result in Zinc 
> eagerly decoding the response without looking at the  declaration as 
> the XML spec requires.
> 
> #parseURL:/#onURL: use Zinc correctly, doing their own XML-aware encoding on 
> top of it.
> 
> > Sent: Thursday, July 28, 2016 at 5:29 PM
> > From: "Sven Van Caekenberghe" 
> > To: "Any question about pharo is welcome" 
> > Subject: Re: [Pharo-users] XMLParser Claims U+00A0 is “Invalid UTF-8”
> >
> > In my older work image, the following just works:
> > 
> > XMLDOMParser parse:
> > ('http://forum.world.st/file/n4908531/illegal-UTF-sms.xml' asUrl 
> > retrieveContents).
> > 
> > But I guess that is because my (older) XML parser version ignores the 
> > encoding, or is more lenient.
> > 
> > You could try to edit the incoming file, or have a look at 
> > #decodesCharacters: 
> > 
> > (XMLDOMParser on:
> > ('http://forum.world.st/file/n4908531/illegal-UTF-sms.xml' asUrl 
> > retrieveContents) readStream) decodesCharacters: false; parseDocument.
> > 
> > But I am no expert in the deeper aspects of XML Support.
> > 
> > > On 28 Jul 2016, at 22:29, Sean P. DeNigris  wrote:
> > > 
> > > Sven Van Caekenberghe-2 wrote
> > >> Your XML file is not UTF-8 encoded, it is plain Unicode. At least the way
> > >> it is served from the URL you gave.
> > >> ..
> > >> You see ?
> > > 
> > > Unfortunately, no! ha ha. I didn't generate the file and I took it's
> > > assertion that it was UTF-8 at face value. How do I properly feed the file
> > > into XMLParser?
> > > 
> > > 
> > > 
> > > -
> > > Cheers,
> > > Sean
> > > --
> > > View this message in context: 
> > > http://forum.world.st/XMLParser-Claims-U-00A0-is-Invalid-UTF-8-tp4908525p4908539.html
> > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
> > > 
> > 
> > 
> >
> 
>

Re: [Pharo-users] XMLParser Claims U+00A0 is “Invalid UTF-8”

[monty]

Good for finding one of the fixes, but please use #parseURL:/#onURL: instead of 
#asUrl/#asZnUrl with #retrieveContents, because that will result in Zinc 
eagerly decoding the response without looking at the  declaration as 
the XML spec requires.

#parseURL:/#onURL: use Zinc correctly, doing their own XML-aware encoding on 
top of it.

> Sent: Thursday, July 28, 2016 at 5:29 PM
> From: "Sven Van Caekenberghe" 
> To: "Any question about pharo is welcome" 
> Subject: Re: [Pharo-users] XMLParser Claims U+00A0 is “Invalid UTF-8”
>
> In my older work image, the following just works:
> 
> XMLDOMParser parse:
> ('http://forum.world.st/file/n4908531/illegal-UTF-sms.xml' asUrl 
> retrieveContents).
> 
> But I guess that is because my (older) XML parser version ignores the 
> encoding, or is more lenient.
> 
> You could try to edit the incoming file, or have a look at 
> #decodesCharacters: 
> 
> (XMLDOMParser on:
> ('http://forum.world.st/file/n4908531/illegal-UTF-sms.xml' asUrl 
> retrieveContents) readStream) decodesCharacters: false; parseDocument.
> 
> But I am no expert in the deeper aspects of XML Support.
> 
> > On 28 Jul 2016, at 22:29, Sean P. DeNigris  wrote:
> > 
> > Sven Van Caekenberghe-2 wrote
> >> Your XML file is not UTF-8 encoded, it is plain Unicode. At least the way
> >> it is served from the URL you gave.
> >> ..
> >> You see ?
> > 
> > Unfortunately, no! ha ha. I didn't generate the file and I took it's
> > assertion that it was UTF-8 at face value. How do I properly feed the file
> > into XMLParser?
> > 
> > 
> > 
> > -
> > Cheers,
> > Sean
> > --
> > View this message in context: 
> > http://forum.world.st/XMLParser-Claims-U-00A0-is-Invalid-UTF-8-tp4908525p4908539.html
> > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
> > 
> 
> 
>

Re: [Pharo-users] XMLParser Claims U+00A0 is “Invalid UTF-8”

[Sean P. DeNigris]

monty-3 wrote
> You're double decoding

And in public, no less! Thanks. It works now with #parseFileNamed:. Minus
side - half a day wasted; plus side - I wrote a compatibility layer for
Magritte-XMLBinding to accept SoupTags to #fromXmlNode:



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/XMLParser-Claims-U-00A0-is-Invalid-UTF-8-tp4908525p4908555.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] XMLParser Claims U+00A0 is “Invalid UTF-8”

[monty]

You're double decoding. Use onFileNamed:/parseFileNamed: instead (and the DOM 
printToFileNamed: family of messages when writing) and let XMLParser take care 
this for you, or disable XMLParser decoding before parsing with 
#decodesCharacters:.

Longer explanation:

The class #on:/#parse: take either a string or a stream (read the definitions). 
You gave it a FileReference, but because the argument is tested with isString 
and sent #readStream otherwise, it didn't blowup then.

File refs sent #readStream return file streams that do automatic decoding. But 
XMLParser automatically attempts its own decoding too, if:

 The input starts with a BOM or it can be inferred by null bytes before or 
after the first non-null byte.

 There is an encoding declaration with a non-UTF-8 encoding.

 There is a UTF-8 encoding declaration but the stream is not a normal 
ReadStream (your case).

So it gets decoded twice, and the decoded value of the char causes the error. 
I'll consider changing the heuristic to make less eager to decode.

> Sent: Thursday, July 28, 2016 at 4:05 PM
> From: "Sean P. DeNigris" 
> To: pharo-users@lists.pharo.org
> Subject: Re: [Pharo-users] XMLParser Claims U+00A0 is “Invalid UTF-8”
>
> monty-3 wrote
> > Just to be sure, I manually recreated your file (with the great Bless hex
> > editor) and parsed it with no issue.
> 
> Thanks!
> 
> 
> monty-3 wrote
> > Please post your code and attach the actual source as a file separately.
> 
> The code is merely:
>   messageLog := FileLocator home / 'illegal-UTF-sms.xml'. 
>   doc := XMLDOMParser parse: messageLog.
> 
> File:  illegal-UTF-sms.xml
>   
> 
> 
> 
> -
> Cheers,
> Sean
> --
> View this message in context: 
> http://forum.world.st/XMLParser-Claims-U-00A0-is-Invalid-UTF-8-tp4908525p4908531.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
> 
>

Re: [Pharo-users] XMLParser Claims U+00A0 is “Invalid UTF-8”

[Sven Van Caekenberghe]

In my older work image, the following just works:

XMLDOMParser parse:
('http://forum.world.st/file/n4908531/illegal-UTF-sms.xml' asUrl 
retrieveContents).

But I guess that is because my (older) XML parser version ignores the encoding, 
or is more lenient.

You could try to edit the incoming file, or have a look at #decodesCharacters: 

(XMLDOMParser on:
('http://forum.world.st/file/n4908531/illegal-UTF-sms.xml' asUrl 
retrieveContents) readStream) decodesCharacters: false; parseDocument.

But I am no expert in the deeper aspects of XML Support.

> On 28 Jul 2016, at 22:29, Sean P. DeNigris  wrote:
> 
> Sven Van Caekenberghe-2 wrote
>> Your XML file is not UTF-8 encoded, it is plain Unicode. At least the way
>> it is served from the URL you gave.
>> ..
>> You see ?
> 
> Unfortunately, no! ha ha. I didn't generate the file and I took it's
> assertion that it was UTF-8 at face value. How do I properly feed the file
> into XMLParser?
> 
> 
> 
> -
> Cheers,
> Sean
> --
> View this message in context: 
> http://forum.world.st/XMLParser-Claims-U-00A0-is-Invalid-UTF-8-tp4908525p4908539.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
> 

Re: [Pharo-users] XMLParser Claims U+00A0 is “Invalid UTF-8”

[Sean P. DeNigris]

Sven Van Caekenberghe-2 wrote
> Your XML file is not UTF-8 encoded, it is plain Unicode. At least the way
> it is served from the URL you gave.
> ..
> You see ?

Unfortunately, no! ha ha. I didn't generate the file and I took it's
assertion that it was UTF-8 at face value. How do I properly feed the file
into XMLParser?



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/XMLParser-Claims-U-00A0-is-Invalid-UTF-8-tp4908525p4908539.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] XMLParser Claims U+00A0 is “Invalid UTF-8”

[Sven Van Caekenberghe]

Sean,

Your XML file is not UTF-8 encoded, it is plain Unicode. At least the way it is 
served from the URL you gave.

(('http://forum.world.st/file/n4908531/illegal-UTF-sms.xml' asUrl 
retrieveContents) at: 72 ) = 160 asCharacter. 

  "true"

Like you said,

160 asCharacter asString utf8Encoded. 

  "#[194 160]"

But

#[ 160 ] utf8Decoded.

  Boom!

You specify UTF-8 encoding inside your XML, I assume the parser then switches 
to that encoding, but your pure Unicode contents is not UTF-8 encoded and 
results in an exception. You see ?

Sven

> On 28 Jul 2016, at 22:05, Sean P. DeNigris  wrote:
> 
> monty-3 wrote
>> Just to be sure, I manually recreated your file (with the great Bless hex
>> editor) and parsed it with no issue.
> 
> Thanks!
> 
> 
> monty-3 wrote
>> Please post your code and attach the actual source as a file separately.
> 
> The code is merely:
>  messageLog := FileLocator home / 'illegal-UTF-sms.xml'. 
>  doc := XMLDOMParser parse: messageLog.
> 
> File:  illegal-UTF-sms.xml
>   
> 
> 
> 
> -
> Cheers,
> Sean
> --
> View this message in context: 
> http://forum.world.st/XMLParser-Claims-U-00A0-is-Invalid-UTF-8-tp4908525p4908531.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
> 

Re: [Pharo-users] Listing Named Play Pages

[Tudor Girba]

Hi,

Indeed, this is a missing feature.

Cheers,
Doru


> On Jul 28, 2016, at 7:47 PM, Sean P. DeNigris  wrote:
> 
> Is there another way besides via Spotter? I would expect to find a menu or
> button on the playground itself...
> 
> 
> 
> -
> Cheers,
> Sean
> --
> View this message in context: 
> http://forum.world.st/Listing-Named-Play-Pages-tp4908505.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
> 

--
www.tudorgirba.com
www.feenk.com

"Some battles are better lost than fought."

Re: [Pharo-users] XMLParser Claims U+00A0 is “Invalid UTF-8”

[Sean P. DeNigris]

monty-3 wrote
> Just to be sure, I manually recreated your file (with the great Bless hex
> editor) and parsed it with no issue.

Thanks!


monty-3 wrote
> Please post your code and attach the actual source as a file separately.

The code is merely:
  messageLog := FileLocator home / 'illegal-UTF-sms.xml'. 
  doc := XMLDOMParser parse: messageLog.

File:  illegal-UTF-sms.xml
  



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/XMLParser-Claims-U-00A0-is-Invalid-UTF-8-tp4908525p4908531.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] XMLParser Claims U+00A0 is “Invalid UTF-8”

[monty]

Just to be sure, I manually recreated your file (with the great Bless hex 
editor) and parsed it with no issue.

Please post your code and attach the actual source as a file separately.

> Sent: Thursday, July 28, 2016 at 3:12 PM
> From: "Sean P. DeNigris" 
> To: pharo-users@lists.pharo.org
> Subject: [Pharo-users] XMLParser Claims U+00A0 is “Invalid UTF-8”
>
> Posted to StackOverflow
> (https://stackoverflow.com/questions/38645553/xmlparser-in-pharo-claims-u00a0-is-invalid-utf-8):
> 
> 
> 
> Given the input:
> 
> 
> 
> 
> Where the character after the "." in the body attribute of the sms tag is
> U+00A0;
> 
> I get the error:
> 
> XMLEncodingException: Invalid UTF-8 character encoding (line 2) (column
> 13)
> 
> IIUC, the UTF-8 representation of that character is 0xC2 0xA0 per Wikipedia.
> Sure enough, bytes 72 and 73 of the input are 194 and 160 respectively.
> 
> This seems like a bug in XMLParser, or am I missing something?
> 
> 
> 
> 
> -
> Cheers,
> Sean
> --
> View this message in context: 
> http://forum.world.st/XMLParser-Claims-U-00A0-is-Invalid-UTF-8-tp4908525.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
> 
>

[Pharo-users] XMLParser Claims U+00A0 is “Invalid UTF-8”

[Sean P. DeNigris]

Posted to StackOverflow
(https://stackoverflow.com/questions/38645553/xmlparser-in-pharo-claims-u00a0-is-invalid-utf-8):



Given the input:




Where the character after the "." in the body attribute of the sms tag is
U+00A0;

I get the error:

XMLEncodingException: Invalid UTF-8 character encoding (line 2) (column
13)

IIUC, the UTF-8 representation of that character is 0xC2 0xA0 per Wikipedia.
Sure enough, bytes 72 and 73 of the input are 194 and 160 respectively.

This seems like a bug in XMLParser, or am I missing something?




-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/XMLParser-Claims-U-00A0-is-Invalid-UTF-8-tp4908525.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] OpenGLES2 binding available!

[Alexandre Bergel]

+1

> On Jul 28, 2016, at 3:52 PM, stepharo  wrote:
> 
> Thanks ronie for your analysis (especially the thread local point). 
> Stef
> 
> Le 28/7/16 à 20:36, Ronie Salgado a écrit :
>> Isn't it what Ronie is working on?
>> I am not working with OpenGL or OpenGL ES anymore. I am moving all of my 
>> efforts into Woden 2, the AbstractGPU (an abstraction layer for Vulkan, 
>> Direct3D 12 and Metal), and Dastrel (Data Stream Language) a custom shader 
>> language whose compiler I implemented in Pharo, with a backend for SpirV, 
>> GLSL and C++. I still have to implement the backends for Metal and HLSL.
>> 
>> Thibault is interested more on being able to use OpenGL ES 2.0 directly in 
>> the playground, for teaching purposes without any abstraction layer 
>> underlying. I do not agree with many of his approaches, too low level, and 
>> many of themp do not work well with Pharo VM. One of the biggest issue of 
>> OpenGL is related with vsync, which is an operation that can block all of 
>> the Pharo processes, until we get a VM with the threaded FFI, which will 
>> have in the near future. It will use the UnifiedFFI API, so we will not have 
>> to further changes to take advantage of the threaded ffi in the user code.
>> 
>> A far worse problem with OpenGL is that the current OpenGL context is a 
>> thread local variable, which do not interact at all with Pharo processes. 
>> This is the reason of why I added the OSWindowRenderThread class for 
>> serializing OSWindow and OpenGL animations. SDL2 renderers are usually 
>> implemented using OpenGL. They are two correct solution for this problem:
>> - Having a VM that maps each Pharo Process into an operating system thread, 
>> - Not using OpenGL at all.
>> 
>> The others low level graphics API (Vulkan, Direct 3D and Metal) do not rely 
>> on a global thread local storage variable. These APIs are object oriented, 
>> so handles are passed in each API call.
>> 
>> Currently, I have an Athens backend above Woden 2, which is only supporting 
>> Vulkan for now. Since this backend is for Woden 2, it has some dependencies 
>> in the Woden 2 Math and the Lowcode NativeStructure. This means that the 
>> Woden 2 Athens backend has a strong dependency in the the modified 
>> OpalCompiler that uses the Lowcode extended byte code set, and the the 
>> modified PharoVM that implements these extra bytecode in the just in time 
>> compiler.
>> 
>> Anyway, implementing a Athens backend from scratch is a really hard problem, 
>> because paths can be concave, curve and self intersecting. Drawing a path, 
>> unlike drawing a triangle is a global operation, for which GPUs were not 
>> designed for. The easiest and most robust technique for drawing a path using 
>> the GPU is to flatten the path using De Casteljau's algorithm and then using 
>> the stencil buffer technique for drawing concave polygons that was described 
>> in the OpenGL red book ( 
>> http://www.glprogramming.com/red/chapter14.html#name13 ). The problem of 
>> this technique is that involves many state changes(glStencil*)  and drawing 
>> commands(glDrawElements) per path, which are the most expensive operations 
>> when using OpenGL. The alternative is to perform a triangulation in the CPU 
>> of paths, or to use one of the newer low level APIs such as Vulkan and 
>> Direct 3D 12 which were designed to reduce or eliminate the cost of state 
>> changes and drawing commands.
>> 
>> Path stroking is an even harder problem, which I have not solved yet. The 
>> standard approach is to convert a stroked path into a path that can be 
>> filled. The problem is that bezier offset curves are not bezier curves, so 
>> they have to be approximated. Fortunately, since this operation is backend 
>> agnostic, it can be used and reused by many Athens backends. Since stroking 
>> is not critical for my needs, I do not think I will implement it soon 
>> properly. Currently I am just drawing a 1 pixel thick line, which can look 
>> horrible, but is better than nothing. One algorithm that seems to be simple 
>> to implement is one described in a paper from the Cairo people, which uses 
>> the Minkowksi  Sum between the outline of the path to be stroked, and shape 
>> of the pen that is stroking
>> the path: http://keithp.com/~keithp/talks/cairo2003.pdf
>> 
>> Soon I will merge the Lowcode instructions into the SqueakVM/Cog VM to 
>> integrate these bytecodes into the mainline VM.
>> 
>> I will not publish Woden 2 until the dependencies and Woden 2 itself can be 
>> loaded easily.  Soon I will publish properly the Dastrel shader language and 
>> the Slovim backend. Slovim name comes from Smalltalk Low levelish VIrtual 
>> Machine, an intermediate representation heavily modeled after the one used 
>> in LLVM, implemented in Pharo, some very basic optimizations(basic constant 
>> folding, inlining and some dead code generation), and a code generator 
>> backend for SpirV, GLSL and C++. My biggest issue before publishing 

Re: [Pharo-users] OpenGLES2 binding available!

[stepharo]

Anyway, implementing a Athens backend from scratch is a really hard 
problem, because paths can be concave, curve and self intersecting. 
Drawing a path, unlike drawing a triangle is a global operation, for 
which GPUs were not designed for. The easiest and most robust 
technique for drawing a path using the GPU is to flatten the path 
using De Casteljau's algorithm and then using the stencil buffer 
technique for drawing concave polygons that was described in the 
OpenGL red book ( 
http://www.glprogramming.com/red/chapter14.html#name13 ). The problem 
of this technique is that involves many state changes(glStencil*)  and 
drawing commands(glDrawElements) per path, which are the most 
expensive operations when using OpenGL. The alternative is to perform 
a triangulation in the CPU of paths, or to use one of the newer low 
level APIs such as Vulkan and Direct 3D 12 which were designed to 
reduce or eliminate the cost of state changes and drawing commands.


Path stroking is an even harder problem, which I have not solved yet. 
The standard approach is to convert a stroked path into a path that 
can be filled. The problem is that bezier offset curves are not bezier 
curves, so they have to be approximated. Fortunately, since this 
operation is backend agnostic, it can be used and reused by many 
Athens backends. Since stroking is not critical for my needs, I do not 
think I will implement it soon properly. Currently I am just drawing a 
1 pixel thick line, which can look horrible, but is better than 
nothing. One algorithm that seems to be simple to implement is one 
described in a paper from the Cairo people, which uses the Minkowksi 
 Sum between the outline of the path to be stroked, and shape of the 
pen that is stroking
the path: http://keithp.com/~keithp/talks/cairo2003.pdf 



Thanks because indeed this is a lot of work. Thanks for the reality check.




Soon I will merge the Lowcode instructions into the SqueakVM/Cog VM to 
integrate these bytecodes into the mainline VM.


I will not publish Woden 2 until the dependencies and Woden 2 itself 
can be loaded easily.  Soon I will publish properly the Dastrel shader 
language and the Slovim backend. Slovim name comes from Smalltalk Low 
levelish VIrtual Machine, an intermediate representation heavily 
modeled after the one used in LLVM, implemented in Pharo, some very 
basic optimizations(basic constant folding, inlining and some dead 
code generation), and a code generator backend for SpirV, GLSL and 
C++. My biggest issue before publishing this compiler are:

- Implementing a command line interface.
- Doing an easy to install and use package for Linux, OS X and Windows.
- Documenting the language and the compiler.

Best regards,
Ronie

2016-07-28 19:31 GMT+02:00 Alexandre Bergel >:



I would love to see an athens back-end for it.


Isn't it what Ronie is working on?

Alexandre



Le 19/7/16 à 13:19, Thibault Raffaillac a écrit :

Hi all,

My tiny binding for OpenGLES2 is ready :)
http://smalltalkhub.com/#!/~ThibaultRaffaillac/OpenGLES2/


It takes a different direction than that of NBOpenGL. I found the support 
for all versions of OpenGL overwhelming, both for beginners and to maintain. 
With a limited number of functions I could carefully name all messages.

A demo using either SDL2 or GLFW (faster) is included, supporting VSync and 
retina displays.
Tested only on Mac OSX, patches welcome!

Cheers,
Thibault

Re: [Pharo-users] OpenGLES2 binding available!

[stepharo]

Thanks ronie for your analysis (especially the thread local point).

Stef


Le 28/7/16 à 20:36, Ronie Salgado a écrit :


Isn't it what Ronie is working on?

I am not working with OpenGL or OpenGL ES anymore. I am moving all of 
my efforts into Woden 2, the AbstractGPU (an abstraction layer for 
Vulkan, Direct3D 12 and Metal), and Dastrel (Data Stream Language) a 
custom shader language whose compiler I implemented in Pharo, with a 
backend for SpirV, GLSL and C++. I still have to implement the 
backends for Metal and HLSL.


Thibault is interested more on being able to use OpenGL ES 2.0 
directly in the playground, for teaching purposes without any 
abstraction layer underlying. I do not agree with many of his 
approaches, too low level, and many of themp do not work well with 
Pharo VM. One of the biggest issue of OpenGL is related with vsync, 
which is an operation that can block all of the Pharo processes, until 
we get a VM with the threaded FFI, which will have in the near future. 
It will use the UnifiedFFI API, so we will not have to further changes 
to take advantage of the threaded ffi in the user code.


A far worse problem with OpenGL is that the current OpenGL context is 
a thread local variable, which do not interact at all with Pharo 
processes. This is the reason of why I added the OSWindowRenderThread 
class for serializing OSWindow and OpenGL animations. SDL2 renderers 
are usually implemented using OpenGL. They are two correct solution 
for this problem:
- Having a VM that maps each Pharo Process into an operating system 
thread,

- Not using OpenGL at all.

The others low level graphics API (Vulkan, Direct 3D and Metal) do not 
rely on a global thread local storage variable. These APIs are object 
oriented, so handles are passed in each API call.


Currently, I have an Athens backend above Woden 2, which is only 
supporting Vulkan for now. Since this backend is for Woden 2, it has 
some dependencies in the Woden 2 Math and the Lowcode NativeStructure. 
This means that the Woden 2 Athens backend has a strong dependency in 
the the modified OpalCompiler that uses the Lowcode extended byte code 
set, and the the modified PharoVM that implements these extra bytecode 
in the just in time compiler.


Anyway, implementing a Athens backend from scratch is a really hard 
problem, because paths can be concave, curve and self intersecting. 
Drawing a path, unlike drawing a triangle is a global operation, for 
which GPUs were not designed for. The easiest and most robust 
technique for drawing a path using the GPU is to flatten the path 
using De Casteljau's algorithm and then using the stencil buffer 
technique for drawing concave polygons that was described in the 
OpenGL red book ( 
http://www.glprogramming.com/red/chapter14.html#name13 ). The problem 
of this technique is that involves many state changes(glStencil*)  and 
drawing commands(glDrawElements) per path, which are the most 
expensive operations when using OpenGL. The alternative is to perform 
a triangulation in the CPU of paths, or to use one of the newer low 
level APIs such as Vulkan and Direct 3D 12 which were designed to 
reduce or eliminate the cost of state changes and drawing commands.


Path stroking is an even harder problem, which I have not solved yet. 
The standard approach is to convert a stroked path into a path that 
can be filled. The problem is that bezier offset curves are not bezier 
curves, so they have to be approximated. Fortunately, since this 
operation is backend agnostic, it can be used and reused by many 
Athens backends. Since stroking is not critical for my needs, I do not 
think I will implement it soon properly. Currently I am just drawing a 
1 pixel thick line, which can look horrible, but is better than 
nothing. One algorithm that seems to be simple to implement is one 
described in a paper from the Cairo people, which uses the Minkowksi 
 Sum between the outline of the path to be stroked, and shape of the 
pen that is stroking
the path: http://keithp.com/~keithp/talks/cairo2003.pdf 



Soon I will merge the Lowcode instructions into the SqueakVM/Cog VM to 
integrate these bytecodes into the mainline VM.


I will not publish Woden 2 until the dependencies and Woden 2 itself 
can be loaded easily.  Soon I will publish properly the Dastrel shader 
language and the Slovim backend. Slovim name comes from Smalltalk Low 
levelish VIrtual Machine, an intermediate representation heavily 
modeled after the one used in LLVM, implemented in Pharo, some very 
basic optimizations(basic constant folding, inlining and some dead 
code generation), and a code generator backend for SpirV, GLSL and 
C++. My biggest issue before publishing this compiler are:

- Implementing a command line interface.
- Doing an easy to install and use package for Linux, OS X and Windows.
- Documenting the language and the compiler.

Best regards,
Ronie

2016-07-28 19:31 GMT+02:00 

Re: [Pharo-users] Pharo-users Digest, Vol 39, Issue 126

[Sven Van Caekenberghe]

e: 1
> Date: Thu, 28 Jul 2016 13:43:52 +0200
> From: Yann Dubois <yann59.dub...@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_qzybuuqze1szh0onuswe...@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.cost...@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: <bc8fc09bd496425f4dc95cf029322...@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 <dionisi...@gmail.com>:
> >
> > Hi
> >
> > 2016-07-27 22:19 GMT+02:00 Steven Costiou <steven.cost...@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 thi

Re: [Pharo-users] OpenGLES2 binding available!

[Ronie Salgado]

>
> Isn't it what Ronie is working on?

I am not working with OpenGL or OpenGL ES anymore. I am moving all of my
efforts into Woden 2, the AbstractGPU (an abstraction layer for
Vulkan, Direct3D 12 and Metal), and Dastrel (Data Stream Language) a custom
shader language whose compiler I implemented in Pharo, with a backend for
SpirV, GLSL and C++. I still have to implement the backends for Metal and
HLSL.

Thibault is interested more on being able to use OpenGL ES 2.0 directly in
the playground, for teaching purposes without any abstraction layer
underlying. I do not agree with many of his approaches, too low level, and
many of themp do not work well with Pharo VM. One of the biggest issue of
OpenGL is related with vsync, which is an operation that can block all of
the Pharo processes, until we get a VM with the threaded FFI, which will
have in the near future. It will use the UnifiedFFI API, so we will not
have to further changes to take advantage of the threaded ffi in the user
code.

A far worse problem with OpenGL is that the current OpenGL context is a
thread local variable, which do not interact at all with Pharo processes.
This is the reason of why I added the OSWindowRenderThread class for
serializing OSWindow and OpenGL animations. SDL2 renderers are usually
implemented using OpenGL. They are two correct solution for this problem:
- Having a VM that maps each Pharo Process into an operating system thread,
- Not using OpenGL at all.

The others low level graphics API (Vulkan, Direct 3D and Metal) do not rely
on a global thread local storage variable. These APIs are object oriented,
so handles are passed in each API call.

Currently, I have an Athens backend above Woden 2, which is only supporting
Vulkan for now. Since this backend is for Woden 2, it has some dependencies
in the Woden 2 Math and the Lowcode NativeStructure. This means that the
Woden 2 Athens backend has a strong dependency in the the modified
OpalCompiler that uses the Lowcode extended byte code set, and the the
modified PharoVM that implements these extra bytecode in the just in time
compiler.

Anyway, implementing a Athens backend from scratch is a really hard
problem, because paths can be concave, curve and self intersecting. Drawing
a path, unlike drawing a triangle is a global operation, for which GPUs
were not designed for. The easiest and most robust technique for drawing a
path using the GPU is to flatten the path using De Casteljau's algorithm
and then using the stencil buffer technique for drawing concave polygons
that was described in the OpenGL red book (
http://www.glprogramming.com/red/chapter14.html#name13 ). The problem of
this technique is that involves many state changes(glStencil*)  and drawing
commands(glDrawElements) per path, which are the most expensive operations
when using OpenGL. The alternative is to perform a triangulation in the CPU
of paths, or to use one of the newer low level APIs such as Vulkan and
Direct 3D 12 which were designed to reduce or eliminate the cost of state
changes and drawing commands.

Path stroking is an even harder problem, which I have not solved yet. The
standard approach is to convert a stroked path into a path that can be
filled. The problem is that bezier offset curves are not bezier curves, so
they have to be approximated. Fortunately, since this operation is backend
agnostic, it can be used and reused by many Athens backends. Since stroking
is not critical for my needs, I do not think I will implement it soon
properly. Currently I am just drawing a 1 pixel thick line, which can look
horrible, but is better than nothing. One algorithm that seems to be simple
to implement is one described in a paper from the Cairo people, which uses
the Minkowksi  Sum between the outline of the path to be stroked, and shape
of the pen that is stroking
the path: http://keithp.com/~keithp/talks/cairo2003.pdf

Soon I will merge the Lowcode instructions into the SqueakVM/Cog VM to
integrate these bytecodes into the mainline VM.

I will not publish Woden 2 until the dependencies and Woden 2 itself can be
loaded easily.  Soon I will publish properly the Dastrel shader language
and the Slovim backend. Slovim name comes from Smalltalk Low levelish
VIrtual Machine, an intermediate representation heavily modeled after the
one used in LLVM, implemented in Pharo, some very basic optimizations(basic
constant folding, inlining and some dead code generation), and a code
generator backend for SpirV, GLSL and C++. My biggest issue before
publishing this compiler are:
- Implementing a command line interface.
- Doing an easy to install and use package for Linux, OS X and Windows.
- Documenting the language and the compiler.

Best regards,
Ronie

2016-07-28 19:31 GMT+02:00 Alexandre Bergel :

> I would love to see an athens back-end for it.
>
> Isn't it what Ronie is working on?
>
> Alexandre
>
>
> Le 19/7/16 à 13:19, Thibault Raffaillac a écrit :
>
> Hi all,
>
> My tiny binding for 

[Pharo-users] Listing Named Play Pages

[Sean P. DeNigris]

Is there another way besides via Spotter? I would expect to find a menu or
button on the playground itself...



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Listing-Named-Play-Pages-tp4908505.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] OpenGLES2 binding available!

[Alexandre Bergel]

> I would love to see an athens back-end for it.
> 
Isn't it what Ronie is working on?

Alexandre

> 
> Le 19/7/16 à 13:19, Thibault Raffaillac a écrit :
>> Hi all,
>> 
>> My tiny binding for OpenGLES2 is ready :)
>> http://smalltalkhub.com/#!/~ThibaultRaffaillac/OpenGLES2/ 
>> 
>> 
>> It takes a different direction than that of NBOpenGL. I found the support 
>> for all versions of OpenGL overwhelming, both for beginners and to maintain. 
>> With a limited number of functions I could carefully name all messages.
>> 
>> A demo using either SDL2 or GLFW (faster) is included, supporting VSync and 
>> retina displays.
>> Tested only on Mac OSX, patches welcome!
>> 
>> Cheers,
>> Thibault
>> 
> 

Re: [Pharo-users] OpenGLES2 binding available!

[stepharo]

Hi thibault


I took some times to look at your project. Nice.

Now the GLW example is not working.

I understand that this is a binding. I do not want to have to work that 
low level.


I'm curious to see what people will be able to build on top of it.


Stef


Le 19/7/16 à 13:19, Thibault Raffaillac a écrit :

Hi all,

My tiny binding for OpenGLES2 is ready :)
http://smalltalkhub.com/#!/~ThibaultRaffaillac/OpenGLES2/

It takes a different direction than that of NBOpenGL. I found the support for 
all versions of OpenGL overwhelming, both for beginners and to maintain. With a 
limited number of functions I could carefully name all messages.

A demo using either SDL2 or GLFW (faster) is included, supporting VSync and 
retina displays.
Tested only on Mac OSX, patches welcome!

Cheers,
Thibault

Re: [Pharo-users] Pharo-users Digest, Vol 39, Issue 126

[Alejandro Adgi Romano]

Good morning!

Okey, so, i must create an object from Ghost?

I am sendig all of you the data from cvs file.

What I need is generate a code in Pharo for Read this information, (because
i need work with the pays, or the credits notes), so I need, in a variable
for example, put the value of the cell X, which contains the $Total.

The information from csv file is like the next. I tried to use NeoCsv but i
don´t understood. Is good NeoCsv or is better the way using Ghost how you
say?

Día Evento Registrado Número Originante Moneda (*) Monto (*) Fecha de
Ejecución (pago, cobro o congelamiento) Frecuencia de Pago Comprobante
Asociado (**)
1 Factura F1 Propia Pesos 1000 Día 10 - -
1 Factura F2 Propia Pesos 500 Día 11 - -
2 Factura F3 Terceros Pesos 250 Día 11 - -
3 Factura F4 Propia Dólares 5000 Día 10 - -
4 Factura F5 Propia Dólares 5000 Día 22 - -
5 Factura F6 Terceros Dólares 5000 Día 23 - -
6 Factura F7 Propia Dólares 5000 Día 35 - -
7 Factura Recurrente FR8 Propia Pesos 100 Día 11 3 veces, cada 10 días. -
8 Factura Recurrente FR9 Propia Pesos 150 Día 15 3 veces, cada 5 días. -
10 Congelamiento FR FR9 - - - Día 22 - -
10 Factura (Real) F81 Propia Pesos 100 Día 11 - FR8
14 Factura (Real) F91 Propia Pesos 150 Día 15 - FR9
19 Factura (Real) F92 Propia Pesos 150 Día 20 - FR9
20 Factura (Real) F82 Propia Pesos 100 Día 21 - FR8
30 Factura (Real) F83 Propia Pesos 100 Día 31 - FR8

2016-07-28 9:06 GMT-03:00 <pharo-users-requ...@lists.pharo.org>:

> 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-requ...@lists.pharo.org
>
> You can reach the person managing the list at
> pharo-users-ow...@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.dub...@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_qzybuuqze1szh0onuswe...@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.cost...@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: <bc8fc09bd496425f4dc95cf029322...@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 :
&

[Pharo-users] Emojis in Pharo

[Sean P. DeNigris]

Are there any available fonts which correctly display emojis? I'm playing
with sms data...



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Emojis-in-Pharo-tp4908461.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

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

[Guille Polito]

Denis,

I recommend that you read carefully the paper that Steven sent (the one 
about message passing, that Stef wrote many years ago :)). If you read 
carefully, you'll see that what you call object virus is already there, 
and falls into the category "anonymous classes".


Maybe you can get some ideas for names in there. Some ideas that come to 
my mind: - Your virus *intercepts* messages, it does .
- Your virus actually allows you to change the *meta-object* of an 
object (and thus how it receives messages).
- Moreover you can handle several meta-levels, so it's not a single 
meta-object.


 Original Message 


2016-07-28 12:56 GMT+02:00 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.


virus := GHObjectVirus behaviour: GHGhostBehaviourStub new.

victim := 0@0 corner: 3@4.
virus infect: victim.


As any framework you need to know something about it. And description 
here is quite simple: virus is a guy who changes behaviour of infected 
objects.

What you think about renaming virus to mutation?

mutation := GHObjectMutation behaviour: GHGhostBehaviourStub new.
victim := 0@0 corner: 3@4.
mutation infect: victim.


Is it makes any sense for you?

You should understand that ObjectVirus is specific kind of ghost for 
real object interception. It is not general proxy because it make 
concrete decisions about class side behaviour of infected instances 
and about their meta level. Also there are other "real object ghosts" 
(I remember Guille is implementing Membrane).


I try to say that it is quite difficult to call different kind of 
ghosts without distinguishing them by some kind of metaphor. It is 
easy to be lost inside many "general" proxy names.

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

[Denis Kudriashov]

2016-07-28 12:56 GMT+02:00 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.
>

virus := GHObjectVirus behaviour: GHGhostBehaviourStub new.
>
> victim := 0@0 corner: 3@4.
> virus infect: victim.


As any framework you need to know something about it. And description here
is quite simple: virus is a guy who changes behaviour of infected objects.
What you think about renaming virus to mutation?


mutation := GHObjectMutation behaviour: GHGhostBehaviourStub new.
victim := 0@0 corner: 3@4.
mutation infect: victim.


Is it makes any sense for you?

You should understand that ObjectVirus is specific kind of ghost for real
object interception. It is not general proxy because it make concrete
decisions about class side behaviour of infected instances and about their
meta level. Also there are other "real object ghosts" (I remember Guille is
implementing Membrane).

I try to say that it is quite difficult to call different kind of ghosts
without distinguishing them by some kind of metaphor. It is easy to be lost
inside many "general" proxy names.

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

[stepharo]

Le 28/7/16 à 12:11, Guille Polito a écrit :

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 :)

+ 100

 - 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)#Examples

 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 >:


Hi

2016-07-27 22:19 GMT+02:00 Steven Costiou :

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.

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

[Steven Costiou]

Thank you very much =) 

It works perfectly ! 

Steven. 

Le 2016-07-28 14:05, Denis Kudriashov a écrit :

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

  

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

[Denis Kudriashov]

And stable version 2.2.2 is done

2016-07-28 14:05 GMT+02:00 Denis Kudriashov :

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

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

[Denis Kudriashov]

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 :

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

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

[Steven Costiou]

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

[Pharo-users] Update CI books written in Pillar

[Yann Dubois]

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

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

[Norbert Hartl]

> Am 28.07.2016 um 12:56 schrieb 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.
> 
+100

Norbert

> Esteban
> 
>> On 28 Jul 2016, at 12:33, Steven Costiou > > 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 >> >:
>>> Hi
>>> 
>>> 2016-07-27 22:19 GMT+02:00 Steven Costiou >> >:
>>> 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.
>>>  
> 

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

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

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

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

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

[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)#Examples

 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 >:


Hi

2016-07-27 22:19 GMT+02:00 Steven Costiou >:

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.

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

[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 :

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

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

[Denis Kudriashov]

Hi

2016-07-27 22:19 GMT+02:00 Steven Costiou :

> 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.

Re: [Pharo-users] Questions

[Sven Van Caekenberghe]

And there is this chapter in the new book:

https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfulBuild/artifact/book-result/NeoCSV/NeoCSV.html

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  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-protocols
> 
> 
> 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!!!
>> 
> 
> 

Re: [Pharo-users] Questions

[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-protocols



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!!!

[Pharo-users] Questions

[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!!!