[Pharo-dev] Speed up #embeddSourceInTrailer read and write

[Marcus Denker]

Right now #embeddSourceInTrailer encoded and decodes every method to utf8. This 
is fairly slow.

We do not need to actually use utf8, the only thing important is that we 
interpret the bits correctly when we decode (wide string or not?).
As a first step we then can even just utf8 encode the widestrings, there are 
not many in the image.

Benchmark:
[SystemNavigation default browseMethodsWithSourceString: 'Method source with 
it' matchCase: true] timeToRun.

sources from Disk:
"0:00:00:02.103" "0:00:00:02.265"

CompiledMethod allInstances do: #embeddSourceInTrailer.

"embedded sources"
"0:00:00:02.442" "0:00:00:02.924" 

embedded after speed improvements (already in Pharo7):
 "0:00:00:01.273" "0:00:00:01.345"

(fun thing a lot of that time is spend in the progress bar... without that and 
not sorting twice, we are at ~0.8 seconds for full image search over all 
source…)

Interesting:

[Smalltalk compiler evaluate: '3+4'] bench 

before: "'4,673 per second'"
after: "'6,008 per second'"

This is because we embedd sources of Doit Methods so we can debug DoIts without 
the need to decompile. After thinking about it,
I think the embedding for Doit was wrong. As the AST for Doits is transformed 
(return added, temp access via arg for DoItIn:), we
have to pretty-print the AST, which is not a good idea as eval speed should be 
optimised for.

We just gain temp names, which we can do differently if we really need them.
-> we should just rely on the decompiler. I wild that change later this week.

Marcus

Re: [Pharo-dev] Speed up #embeddSourceInTrailer read and write

[Marcus Denker]

ah, and another small improvement: Last week we realised that we recompile 
meta-classes twice with #recompile.

Changing this dropped the time for full recompile from sources on my MacBooAir 
from 60 seconds to 50 seconds.

Marcus

> On 29 Jan 2018, at 09:18, Marcus Denker  wrote:
> 
> Right now #embeddSourceInTrailer encoded and decodes every method to utf8. 
> This is fairly slow.
> 
> We do not need to actually use utf8, the only thing important is that we 
> interpret the bits correctly when we decode (wide string or not?).
> As a first step we then can even just utf8 encode the widestrings, there are 
> not many in the image.
> 
> Benchmark:
> [SystemNavigation default browseMethodsWithSourceString: 'Method source with 
> it' matchCase: true] timeToRun.
> 
> sources from Disk:
> "0:00:00:02.103" "0:00:00:02.265"
> 
> CompiledMethod allInstances do: #embeddSourceInTrailer.
> 
> "embedded sources"
> "0:00:00:02.442" "0:00:00:02.924" 
> 
> embedded after speed improvements (already in Pharo7):
> "0:00:00:01.273" "0:00:00:01.345"
> 
> (fun thing a lot of that time is spend in the progress bar... without that 
> and not sorting twice, we are at ~0.8 seconds for full image search over all 
> source…)
> 
> Interesting:
> 
> [Smalltalk compiler evaluate: '3+4'] bench 
> 
> before: "'4,673 per second'"
> after: "'6,008 per second'"
> 
> This is because we embedd sources of Doit Methods so we can debug DoIts 
> without the need to decompile. After thinking about it,
> I think the embedding for Doit was wrong. As the AST for Doits is transformed 
> (return added, temp access via arg for DoItIn:), we
> have to pretty-print the AST, which is not a good idea as eval speed should 
> be optimised for.
> 
> We just gain temp names, which we can do differently if we really need them.
> -> we should just rely on the decompiler. I wild that change later this week.
> 
>   Marcus

[Pharo-dev] [JOB][PhD] Infrastructure and Language Kernels for IoT Systems

[Marcus Denker]

[JOB][PhD] Infrastructure and Language Kernels for IoT Systems


The RMOD team of INRIA Lille and the CAR theme of IMT Lille Douai have an open 
position for a PhD student on Infrastructure and language kernels for IoT 
Systems.

Description
==
Over the last years, the RMOD team of INRIA Lille and the CAR theme of IMT 
Lille Douai have been working together on creating tiny language core. For 
example, Guillermo Polito demonstrated in his PhD a fully reflective kernel 
that fits into 80 kb of memory and that it is possible to have hyper 
specialized kernels down to 11 kb. We have also worked on remote debugging (PhD 
of N. Papoulias) and dynamic code updates (PhD of P. Tesone) of such kernels. 
All of these works are prototyped in Pharo. More recently, RMOD have been 
working on advanced probes mechanisms (M. Denker) and a solid remote debugging 
infrastructure (D. Kudriashov). The goal of this PhD is to revisit the 
architecture around such mini-kernels for building IoT applications. 

The plan is to:
=

• improve the tools to edit, compile, debug, deploy and update such kernels on 
IoT devices. Learn how to debug remotely and dynamically update such IoT 
systems using the TelePharo/PharoThings environment. This task will be in 
cooperation with M. Denker and D. Kudriashov on remote debugging for IoT and G. 
Polito for the kernel edition and tooling.

• define some language extensions to manage groups of IoT devices to program 
them at once. Managing hundreds or even thousands of IoT devices is a 
challenging task. We want to explore different solutions to help deploying and 
updating groups of IoT devices using some registration mechanism in a cloud 
server or some groups/roles based approaches for example. Note that ZweiDenker 
GmbH http://zweidenker.de/en/ is interested in collaboration on the IoT cloud 
management infrastructure

• expressing the architecture of IoT applications. We would like to explore 
also how to express IoT architectures and what are the abstractions that should 
be offered to developers such as expressing event-driven architectures with 
declarative ECA (Event-Conditions-Actions) rules. But we will study a couple of 
typical IoT applications.

• dynamically update an IoT application. An IoT application needs to adapt 
itself because unreachable or faulty devices or the diminution of available 
bandwith. We would like that the whole application can reconfigure itself in 
such situations as Guillaume Grondin proposes it in its PhD. 

• explore Lightweight Virtual Machines. Virtual machines in the IoT context are 
very powerful for incremental deployment or dynamic updates. In this task, we 
would like to investigate what is the minimal memory consumption that we can 
reach for a VM usable for IoT.

Application
=
To apply, please send us : 

• a CV, 
• a copy of your Master diploma 
• a copy of your Master thesis 
• 2 (two) reference letters, with the contact details of the referents 
• links to videos of demos of your experiments and/or simulations

The application materials should be sent by email to Prof. S. Ducasse 
stephane.duca...@inria.fr. Email subject must start with : [PhD-RMoD-CAR-2018].

Bibliography 
=
• Guillermo Polito, Stephane Ducasse, N Bouraqadi, L Fabresse, M 
Mattone. Virtualization Support for Dynamic Core Library Update. Onward !, 
  Oct 2015, Pittsburg, USA. 
• Guillermo Polito. Virtualization Support for Application Runtime 
Virtualization and Extension. Ph.D. Thesis 2015. Co-delivree par l’Universite 
   de Lille et l’Ecole des Mines de Douai. 
• Extended results of Tornado : A Run-Fail-Grow approach for Dynamic 
Application Tayloring. Ecole des mines de Douai, France. 50p, July 2014
• Nick Papoulias, Noury Bouraqadi, Luc Fabresse, Stephane Ducasse and 
Marcus Denker, Mercury: Properties and Design of a Remote Debugging
   Solution using Reflection, Journal of Object Technology, 14, 1 
:1-36, 2015


Links
=
• Pharo: http://www.pharo.org
• PharoThings: https://github.com/pharo-iot/PharoThings
• INRIA RMOD: http://rmod.lille.inria.fr
• INRIA Lille: http://www.inria.fr/lille
• INRIA in General: http://www.inria.fr
• Lille:
• http://en.wikipedia.org/wiki/Lille
• http://wikitravel.org/en/Lille

Permanent Link: https://rmod.inria.fr/web/blog/2018-01-25

[Pharo-dev] [Pharo 7.0-dev] Build #476: 21117 Super tearDown need to be called as last message in tearDown of…

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #476 was: SUCCESS.

The Pull Request #716 was integrated: "21117 Super tearDown need to be called 
as last message in tearDown of…"
Pull request url: https://github.com/pharo-project/pharo/pull/716

Issue Url: https://pharo.fogbugz.com/f/cases/21117
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/476/

Re: [Pharo-dev] Speed up #embeddSourceInTrailer read and write

[Sven Van Caekenberghe]

Great results, Marcus.

> On 29 Jan 2018, at 09:18, Marcus Denker  wrote:
> 
> Right now #embeddSourceInTrailer encoded and decodes every method to utf8. 
> This is fairly slow.
> 
> We do not need to actually use utf8, the only thing important is that we 
> interpret the bits correctly when we decode (wide string or not?).
> As a first step we then can even just utf8 encode the widestrings, there are 
> not many in the image.

As a speedup it is certainly a good strategy to encode ByteStrings into Latin1 
ByteStrings, since this is a no-op. But I would always encode WideStrings as 
UTF-8 since that is a much more efficient, variable length encoding. Storing a 
WideStrings as 32-bit characters would be quite wasteful.

Intuitively it feels like a simple compression scheme with a shared dictionary 
of a couple of thousand of the most common substrings in method source code 
would be able to compress sources quite a bit. Such compression would not break 
literal searching.

> Benchmark:
> [SystemNavigation default browseMethodsWithSourceString: 'Method source with 
> it' matchCase: true] timeToRun.
> 
> sources from Disk:
> "0:00:00:02.103" "0:00:00:02.265"
> 
> CompiledMethod allInstances do: #embeddSourceInTrailer.
> 
> "embedded sources"
> "0:00:00:02.442" "0:00:00:02.924" 
> 
> embedded after speed improvements (already in Pharo7):
> "0:00:00:01.273" "0:00:00:01.345"
> 
> (fun thing a lot of that time is spend in the progress bar... without that 
> and not sorting twice, we are at ~0.8 seconds for full image search over all 
> source…)
> 
> Interesting:
> 
> [Smalltalk compiler evaluate: '3+4'] bench 
> 
> before: "'4,673 per second'"
> after: "'6,008 per second'"
> 
> This is because we embedd sources of Doit Methods so we can debug DoIts 
> without the need to decompile. After thinking about it,
> I think the embedding for Doit was wrong. As the AST for Doits is transformed 
> (return added, temp access via arg for DoItIn:), we
> have to pretty-print the AST, which is not a good idea as eval speed should 
> be optimised for.
> 
> We just gain temp names, which we can do differently if we really need them.
> -> we should just rely on the decompiler. I wild that change later this week.
> 
>   Marcus

Re: [Pharo-dev] Speed up #embeddSourceInTrailer read and write

[Marcus Denker]

> On 29 Jan 2018, at 09:59, Sven Van Caekenberghe  wrote:
> 
> Great results, Marcus.
> 
>> On 29 Jan 2018, at 09:18, Marcus Denker  wrote:
>> 
>> Right now #embeddSourceInTrailer encoded and decodes every method to utf8. 
>> This is fairly slow.
>> 
>> We do not need to actually use utf8, the only thing important is that we 
>> interpret the bits correctly when we decode (wide string or not?).
>> As a first step we then can even just utf8 encode the widestrings, there are 
>> not many in the image.
> 
> As a speedup it is certainly a good strategy to encode ByteStrings into 
> Latin1 ByteStrings, since this is a no-op. But I would always encode 
> WideStrings as UTF-8 since that is a much more efficient, variable length 
> encoding. Storing a WideStrings as 32-bit characters would be quite wasteful.
> 
> Intuitively it feels like a simple compression scheme with a shared 
> dictionary of a couple of thousand of the most common substrings in method 
> source code would be able to compress sources quite a bit. Such compression 
> would not break literal searching.


Yes, and for real search speed we could look again into indexing… It should be 
possible to build a search index on demand before the first search and
cache it (so it would never be saved in the image and never waste memory in 
deployment).

With the we could be even get real time full text search. That is, it would be 
faster then “senders of” is now.

Marcus

[Pharo-dev] Pavel's ChangeLog week of 2018-01-22

[Pavel Krivanek]

Hi,

this week not much time left for some interesting work on Pharo. Some notes:

With Marcus, we were looking at the resurrecting of the old
possibility to place method source code directly into the method
trailer so it is stored as byte array at the end of the compiled
method. Because no new object is needed for the method code, it does
not cause more stress on the GC and it is the very natural way how to
store code. Surprisingly it was slower than currently used access to
the method source stored on disk. It shows how optimized the current
way is.
Because most of the time was spent on UTF-8 conversion of the code, we
decided to introduce a new method trailer kind for the wide strings
and for the standard strings to do not do any conversion at all. For
details see the e-mail "Speed up #embeddSourceInTrailer read and
write" by Marcus.

I came across an interesting case when the internal representation of
a dictionary and hash construction has an unexpected performance
effect. Let's have an identity set where keys are words and values are
identity sets of sentences that contain these words. Then you want to
sort them by value size to see what words are the most used. The
performance is surprisingly dependent on sorting order.

[ identityWordsDict associations asSortedCollection: [ :a :b |
a value size <= b value size ] ] timeToRun.
 "0:00:09:26.149"

..but if you swap order:

[ identityWordsDict associations asSortedCollection: [ :a :b |
a value size > b value size ] ] timeToRun.
 "0:00:00:00.476"

I find it during analysis of about 4.5 millions of french sentences
from a large set of books. The goal was to gain the frequency analysis
of the word forms and be able to collect supporting study material for
foreign words learning. You can select the words you know and find a
large set of long example sentences that contain only them to see the
words in usage and practice them. Then you can select a new word and
generate a new set of sentences that contain it together with words
you already know. And this way to incrementally learn the language.

The image with the data has over 2 GB so it was a nice opportunity to
see how Pharo and the collections behave in such conditions.

Cheers,
-- Pavel

Re: [Pharo-dev] CI Hickups ...

[Juraj Kubelka]

Hi Marcus,

Thanks for the report. I have opened an issue: 
https://pharo.manuscript.com/f/cases/21173/Some-test-cases-fail-occasionally 
 
I will check them this week. 

Cheers,
Juraj

> On Jan 26, 2018, at 11:06, Marcus Denker  wrote:
> 
> 
> 
>> On 26 Jan 2018, at 14:42, Juraj Kubelka  wrote:
>> 
>> 
>> 
>>> On Jan 26, 2018, at 09:13, Marcus Denker  wrote:
>>> 
>>> Hello,
>>> 
>>> Yes… I try to make notes about all failing test so we can detect patterns
>>> 
>> 
>> Will you share the notes? 
>> 
> 
> Here are some from todays reviews:
> 
> testPatch – MacOS32.Zinc.Tests.ZnClientTests
>   Failed to start server on port 1719. Is there one already?
>   
>   
> testTwiceDeliveredDataSholdBeDetected – 
> MacOS32.GT.EventRecorder.Tests.Core.GTEventRecorderTest
> testTwiceDeliveredDataSholdBeDetected – 
> Windows32.GT.EventRecorder.Tests.Core.GTEventRecorderTest
> testDeliverNow3 – Windows32.GT.EventRecorder.Tests.Core.GTEventRecorderTest
> testDeliverNow2 – Windows32.GT.EventRecorder.Tests.Core.GTEventRecorderTest
> testAddCollector3 – Windows32.GT.EventRecorder.Tests.Core.GTEventRecorderTest
> testNotDeliveredDataShouldBeResent – 
> Windows32.GT.EventRecorder.Tests.Core.GTEventRecorderTest
> 
> 
> testGetPharoVersion – MacOS32.Zinc.Zodiac.ZnHTTPSTests
> 
> testExecuteOnceAfterSchedulingMultipleTimes – MacOS32.OmbuTests.OmDeferrerTest
> 
> 
> 

Re: [Pharo-dev] How to add a new rule?

[Yuriy Tymchuk]

Sent from my iPad

> On 28 Jan 2018, at 22:50, Stephane Ducasse  wrote:
> 
> Ok I will add your email next time.
> 
> 
>> On Sun, Jan 28, 2018 at 8:57 AM, Yuriy Tymchuk  wrote:
>> Hi Stef.
>> 
>> First of all, please include my email in the recipients list. I’m committed 
>> to maintain the Rule infrastructure, but I rarely manage to read through 
>> Pharo dev. I was nice that Myroslava told me about this email.
> 
> Ok I will add your email next time.
> 
>> Secondly I suppose that you are working on Pharo 7, because Pharo 6 mostly 
>> follows the old approach.
> 
> I do not know since it was not on my machine but most probably pharo 70

If it is Pharo 6 then you can just follow the old smalllint strategy, but you 
may need to reset the cache. 

> 
>> 
>> One thing that can cause a rule not showing up is caching, and although it 
>> should be automatically invalidated upon the addition of a new rule, you can 
>> manually clear it by searching for “Renraku” in settings and pressing the 
>> “Reset rule cache” button.
> 
> Ahh this is what we suspected.
> 
>> You should not subclass RBTransformationRule, you should subclass 
>> ReNodeRewriteRule. In fact if you check, there are no subclasses of 
>> RBTransformationRule.
> 
> This is strange because I remember that ifNotNilDo was a subclass.
> But again is was on a machine with super small fonts :)
> 
>> 
>> Now about documentation. I suspect that my IWST presentation and the Renraku 
>> paper (Thesis chapter) are not enough, but the problem is that nobody tried 
>> to create rules and give me a feedback about that so far. As you are adding 
>> new rules, I think that this is a nice opportunity to write some kind of a 
>> booklet, because rules are really powerful and we should share the knowledge 
>> of how to create them (and we should also simplify the creation process).
> 
> Yes I would love to have a booklet on that. Do you want to join effort?

Yes, but I need user experience. Because I already tried to document Renraku 
here and there but I don’t know what is not clear. Also I expect that Myroslava 
can join. 

> 
> 
>> Right now there is a “Renraku Quality Rules” help group in the main Pharo 
>> help browser that provides a brief description of how to create rules and 
>> run them. I think that this is a good starting point because I tried to put 
>> there the essential information needed to start with rule creation.
> 
> Excellent we will read it.
> 
> 
>> P.S. what would be nice is to generate booklets from Pharo help, because I 
>> does not make sense to have 2 sources of documentation.
> 
> Yes we are working on Pillar and we will get there. Now a booklet for
> three or four pages of description is not worth.
> So may be the inverse is better. What we could do is to extend the
> help to display the pillar booklet inside the image. But slowing
> 
> 
>> Cheers.
>> Uko
>> 
>>> On 27 Jan 2018, at 16:19, Stephane Ducasse  wrote:
>>> 
>>> Hi yuriy
>>> 
>>> We defined a new rule subclass of RBTransformationRule and we did not
>>> get why the rule
>>> was not taken into account.
>>> 
>>> We put an halt in another class such as ifNotNilDo: in
>>>  - initialize (is there a cache)?
>>>  - checkMethod:
>>> 
>>> and it did not stop.
>>> We started to
>>>   to watch your ESUG videos
>>>   to read your PhD
>>> 
>>> but it did not help us.
>>> 
>>> Stef
>>> 
>> 
>> 
> 

Re: [Pharo-dev] How to get rid of empty XML nodes?

[monty]

I attached a commit patch (apply with `git am ...`) to the 'books.pharo.org' 
repo to update the Scraping .pdf link. (The .pdf it links to now is obsolete.)

> Sent: Friday, January 26, 2018 at 2:30 PM
> From: "Stephane Ducasse" 
> To: "Pharo Development List" 
> Subject: Re: [Pharo-dev] How to get rid of empty XML nodes?
>
> Tx Monty!
> This is a really important addition :)
> Because a super frequent scenario.
> 
> Stef
> 
> On Fri, Jan 26, 2018 at 8:37 AM, monty  wrote:
> > See #removeAllFormattingNodes and its comment in the latest version.
> >
> > And instances of SAXHandler and subclasses are meant to be created with 
> > #on: (or another "instance creation" message), _not #new_, otherwise they 
> > won't be properly initialized. The class comment is clear about this, but I 
> > should have overridden #new to raise an error like Stream does. Your misuse 
> > was helpful in bringing this to my attention, and I added a Stream-like 
> > #new implementation to SAXHandler.
> >
> >> Sent: Friday, December 08, 2017 at 9:21 AM
> >> From: "Stephane Ducasse" 
> >> To: "Pharo Development List" 
> >> Subject: Re: [Pharo-dev] How to get rid of empty XML nodes?
> >>
> >> Hi monty
> >>
> >>
> >> On Fri, Dec 8, 2017 at 9:03 AM, monty  wrote:
> >> > By "empty XML nodes," do you mean whitespace-only string nodes?
> >>
> >> Yes
> >>
> >> > Those are included because all in-element whitespace is assumed 
> >> > significant by the spec: https://www.w3.org/TR/xml/#sec-white-space
> >>
> >> I know. There was a discussion a while ago. I just lost a couple of
> >> hours understanding that :(
> >>
> >> But this is a super super super annoying practices.
> >> We had to test each nodes to see if it is a empty nodes so it makes
> >> everything a lot more complex without real justification
> >> beside the fact that these standardizers probably never implemented
> >> some real cases.
> >> This standard is a really out of reality from that perspective.
> >>
> >> > The exception is if the element is declared in the DTD as only having 
> >> > element children ("element content"): 
> >> > https://www.w3.org/TR/xml/#dt-elemcontent
> >>
> >> Well the XML files that I had (I did not choose XML because I would
> >> have prefer JSON :) ), had no DTD :(
> >>
> >> So at the end of the day, this wonderful standard puts all the stress
> >> and burden to people.
> >>
> >> >
> >> > For example, if you declare an element like this:
> >> >
> >> > 
> >> >
> >> > Any whitespace around a "two," "three," or "four" element child of a 
> >> > "one" element is insignificant and ignored (unless 
> >> > #preservesIgnorableWhitespace: is true). Other parsers, like LibXML2 and 
> >> > Xerces, behave the same way.
> >> >
> >> > I'll see if I can come up with some easier way to deal with this, like 
> >> > an optional parser setting, new enumeration methods, or maybe a tree 
> >> > transformation.
> >>
> >> It would be A HUGE PLUS!!
> >>
> >>
> >> Because reality is that people have XML files with just nodes and no
> >> empty nodes and they are forced to
> >> Let me know because I could try.
> >>
> >> I was showing how to use Pharo to import code to pharo learners and
> >> this was a big drag.
> >>
> >> Stef
> >>
> >>
> >> I tried to set some values in the parser but it did not work.
> >> BTW I saw that the configuration logic forces to write the following
> >>
> >> | parser doc visitor |
> >> parser := XMLDOMParser new
> >>on: self xmlContents;
> >>preservesIgnorableWhitespace: true.
> >>
> >> and not
> >>
> >> | parser doc visitor |
> >> parser := XMLDOMParser new
> >> preservesIgnorableWhitespace: true.
> >> on: self xmlContents;
> >>
> >>
> >> >
> >> >> Sent: Tuesday, December 05, 2017 at 8:29 AM
> >> >> From: "Stephane Ducasse" 
> >> >> To: "Pharo Development List" 
> >> >> Subject: [Pharo-dev] How to get rid of empty XML nodes?
> >> >>
> >> >> )Hi
> >> >>
> >> >> we are manipulating an XML document and I would like to get rid of the
> >> >> spurious empty string.
> >> >> We saw that the gt panes are doing it.
> >> >>
> >> >> (aNodeWithElements isStringNode
> >> >> and: [aNodeWithElements isEmpty
> >> >> or: [aNodeWithElements isWhitespace]]
> >> >>
> >> >> Is there a way not to produce empty nodes?
> >> >> Is there a simple way not to have to handle them
> >> >>
> >> >> Now each time we are dealing with a node with have to check.
> >> >>
> >> >> Stef
> >> >>
> >> >>
> >> >
> >>
> >>
> >
> 
> >From 32a11bd48135e23907ca3efce95d8e8347c65c04 Mon Sep 17 00:00:00 2001
From: monty 
Date: Mon, 29 Jan 2018 07:48:42 -0500
Subject: [PATCH] updated Scraping booklet .pdf link

---
 index.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/index.html b/index.html
index 5aa9aba..e5729ff 100644
--- a/index.html
+++ b/index.html
@@ -76,7 +76,7 @@
 
 
 	
-		https://files.pharo.org/books-pdfs/booklet-Scraping/2017-09-29-scrapingbook.pdf"; title="Scraping with XPath"> 
+		https://bintray.com/squarebracketassociates/wip/do

[Pharo-dev] Iceberg UI feedback - synchronise v. status

[Ben Coman]

I hear Iceberg UI is getting a redesign.
To feed into that... I'm trying to analyse myself, why I've not been
comfortable with the "Synchronise..." menu item.   I think maybe its
because that term feels like an "action" that going to "do something"
when I'm not sure what that something is.But as I'm getting
familiar with Iceberg it seems that "Synchronise" might not change the
state of anything, but first shows current "status" like a combination
of  `git status` and `git diff`  from the shell, and presents buttons
and tabs where you *then* perform actions that actually change the
state of the system.

So I may have the wrong end of the stick, but perhaps replacing
"Synchronise..." with "Status..." might seem less intimidating.


HTH,
cheers -ben

Re: [Pharo-dev] Iceberg UI feedback - synchronise v. status

[Christophe Demarey]

> Le 29 janv. 2018 à 14:16, Ben Coman  a écrit :
> 
> I hear Iceberg UI is getting a redesign.
> To feed into that... I'm trying to analyse myself, why I've not been
> comfortable with the "Synchronise..." menu item.   I think maybe its
> because that term feels like an "action" that going to "do something"
> when I'm not sure what that something is.But as I'm getting
> familiar with Iceberg it seems that "Synchronise" might not change the
> state of anything, but first shows current "status" like a combination
> of  `git status` and `git diff`  from the shell, and presents buttons
> and tabs where you *then* perform actions that actually change the
> state of the system.
> 
> So I may have the wrong end of the stick, but perhaps replacing
> "Synchronise..." with "Status..." might seem less intimidating.

Why not « Synchronization view » like in Eclipse?

Re: [Pharo-dev] Iceberg UI feedback - synchronise v. status

[Ben Coman]

On 29 January 2018 at 21:32, Christophe Demarey
 wrote:
>
>> Le 29 janv. 2018 à 14:16, Ben Coman  a écrit :
>>
>> I hear Iceberg UI is getting a redesign.
>> To feed into that... I'm trying to analyse myself, why I've not been
>> comfortable with the "Synchronise..." menu item.   I think maybe its
>> because that term feels like an "action" that going to "do something"
>> when I'm not sure what that something is.But as I'm getting
>> familiar with Iceberg it seems that "Synchronise" might not change the
>> state of anything, but first shows current "status" like a combination
>> of  `git status` and `git diff`  from the shell, and presents buttons
>> and tabs where you *then* perform actions that actually change the
>> state of the system.
>>
>> So I may have the wrong end of the stick, but perhaps replacing
>> "Synchronise..." with "Status..." might seem less intimidating.
>
> Why not « Synchronization view » like in Eclipse?

I don't know Eclipse, only `git`   ;P
But yes, that seems less like system state might change immediately
and I'll have time to consider my next move.

cheers -ben

Re: [Pharo-dev] [ANN] Fog - Ethereum driver

[Rafael Luque]

Hi Santiago,

I'm currently playing with Dapps on Ethereum using Truffle and web3.js, but
it would be great to be able to use Pharo.

I've downloaded Fog and started to read the tests and code, but I don't see
support for events that is something I need for my current use cases. Maybe
I don't know where to look or events are not (yet) supported?

In any case, thank you for this contribution.


2017-03-14 9:51 GMT+00:00 Santiago Bragagnolo 
:

> You are welcome :). We are doing some experiments for looking some
> research branches on it.
> So, writing some Dapps but not really productive. or not yet.
> Any way, we still using solidity as language for the contracts.
>
> Santiago
>
>
>
> On Mon, 13 Mar 2017 at 19:44 Esteban A. Maringolo 
> wrote:
>
>> Very Nice! Thank you for building it.
>>
>> I started a similar project for the Bitcoin blockchain, but then I
>> drifted away and never got back to it.
>>
>> Are you writing DAPPs?
>>
>> Best regards,
>>
>> Esteban A. Maringolo
>>
>>
>> 2017-03-13 12:00 GMT-03:00 Santiago Bragagnolo <
>> santiagobragagn...@gmail.com>:
>> > Hi all. Im happy to announce a pre release of the Fog ethereum driver
>> that
>> > we develop in the space of an Inria project.
>> >
>> > It still not complete but is already usable for some experiments and
>> simple
>> > projects.
>> >
>> > You can downloadit from
>> > https://github.com/sbragagnolo/Fog/
>> > (https://github.com/sbragagnolo/Fog/releases/tag/v0.1.1.1)
>> >
>> > Dependencies
>> >
>> > RHash
>> >
>> >  sudo apt-get install rhash
>> >
>> > Solidity
>> >
>> >  npm install solc
>> >
>> > Download code
>> >
>> > Iceberg / Baseline
>> >
>> > Metacello
>> > new
>> > baseline: 'Fog';
>> > repository:  'github://sbragagnolo/Fog:v0.1.1.1/src';
>> > load.
>> >
>> > By hand
>> >
>> > You may want to use this version for having access to some scripts and
>> > contracts samples.
>> >
>> > git checkout g...@github.com:sbragagnolo/Fog.git
>> >
>> > git checkout v0.1.1.1
>> >
>> > Metacello
>> > new
>> > baseline: 'Fog';
>> > repository: 'filetree:///path/to/git-repository/Fog/src';;
>> > load.
>> >
>> >
>> > It's based on the standar API for javascript
>> > (https://github.com/ethereum/wiki/wiki/JavaScript-API) .
>> >
>> > It provides interaction with remote contracts, it do as well provides a
>> way
>> > for navigating the architecture objects: blocks, transactions, accounts
>> and
>> > contracts.
>> >
>> > I hope you find it useful.
>> >
>> > Feel free to fill the github issue tracker with anything you find :).
>> >
>> >
>> > I will come to you with some new exciting news about ethereum soon :)
>> >
>> > Santiago.
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>

Re: [Pharo-dev] [ANN] Fog - Ethereum driver

[Santiago Bragagnolo]

Hi Rafael!
Events are not yet supported sadly.
If you are willing to do something about, we can discuss. By my side I will
be kind of busy during february.

I hope to be able to do something about on march, but i cannot guarantee it

Santiago


On Mon, 29 Jan 2018 at 17:40 Rafael Luque 
wrote:

> Hi Santiago,
>
> I'm currently playing with Dapps on Ethereum using Truffle and web3.js,
> but it would be great to be able to use Pharo.
>
> I've downloaded Fog and started to read the tests and code, but I don't
> see support for events that is something I need for my current use cases.
> Maybe I don't know where to look or events are not (yet) supported?
>
> In any case, thank you for this contribution.
>
>
> 2017-03-14 9:51 GMT+00:00 Santiago Bragagnolo <
> santiagobragagn...@gmail.com>:
>
>> You are welcome :). We are doing some experiments for looking some
>> research branches on it.
>> So, writing some Dapps but not really productive. or not yet.
>> Any way, we still using solidity as language for the contracts.
>>
>> Santiago
>>
>>
>>
>> On Mon, 13 Mar 2017 at 19:44 Esteban A. Maringolo 
>> wrote:
>>
>>> Very Nice! Thank you for building it.
>>>
>>> I started a similar project for the Bitcoin blockchain, but then I
>>> drifted away and never got back to it.
>>>
>>> Are you writing DAPPs?
>>>
>>> Best regards,
>>>
>>> Esteban A. Maringolo
>>>
>>>
>>> 2017-03-13 12:00 GMT-03:00 Santiago Bragagnolo <
>>> santiagobragagn...@gmail.com>:
>>> > Hi all. Im happy to announce a pre release of the Fog ethereum driver
>>> that
>>> > we develop in the space of an Inria project.
>>> >
>>> > It still not complete but is already usable for some experiments and
>>> simple
>>> > projects.
>>> >
>>> > You can downloadit from
>>> > https://github.com/sbragagnolo/Fog/
>>> > (https://github.com/sbragagnolo/Fog/releases/tag/v0.1.1.1)
>>> >
>>> > Dependencies
>>> >
>>> > RHash
>>> >
>>> >  sudo apt-get install rhash
>>> >
>>> > Solidity
>>> >
>>> >  npm install solc
>>> >
>>> > Download code
>>> >
>>> > Iceberg / Baseline
>>> >
>>> > Metacello
>>> > new
>>> > baseline: 'Fog';
>>> > repository:  'github://sbragagnolo/Fog:v0.1.1.1/src';
>>> > load.
>>> >
>>> > By hand
>>> >
>>> > You may want to use this version for having access to some scripts and
>>> > contracts samples.
>>> >
>>> > git checkout g...@github.com:sbragagnolo/Fog.git
>>> >
>>> > git checkout v0.1.1.1
>>> >
>>> > Metacello
>>> > new
>>> > baseline: 'Fog';
>>> > repository: 'filetree:///path/to/git-repository/Fog/src';;
>>> > load.
>>> >
>>> >
>>> > It's based on the standar API for javascript
>>> > (https://github.com/ethereum/wiki/wiki/JavaScript-API) .
>>> >
>>> > It provides interaction with remote contracts, it do as well provides
>>> a way
>>> > for navigating the architecture objects: blocks, transactions,
>>> accounts and
>>> > contracts.
>>> >
>>> > I hope you find it useful.
>>> >
>>> > Feel free to fill the github issue tracker with anything you find :).
>>> >
>>> >
>>> > I will come to you with some new exciting news about ethereum soon :)
>>> >
>>> > Santiago.
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>>
>>>
>

Re: [Pharo-dev] How to get rid of empty XML nodes?

[Stephane Ducasse]

Tx monty.
I will update it because I do not want to lose all the pds if bintray collapse.
I plan to revise all the booklets since I will put them on lulu so
that people can get them printed.

Stef


On Mon, Jan 29, 2018 at 2:00 PM, monty  wrote:
> I attached a commit patch (apply with `git am ...`) to the 'books.pharo.org' 
> repo to update the Scraping .pdf link. (The .pdf it links to now is obsolete.)
>
>> Sent: Friday, January 26, 2018 at 2:30 PM
>> From: "Stephane Ducasse" 
>> To: "Pharo Development List" 
>> Subject: Re: [Pharo-dev] How to get rid of empty XML nodes?
>>
>> Tx Monty!
>> This is a really important addition :)
>> Because a super frequent scenario.
>>
>> Stef
>>
>> On Fri, Jan 26, 2018 at 8:37 AM, monty  wrote:
>> > See #removeAllFormattingNodes and its comment in the latest version.
>> >
>> > And instances of SAXHandler and subclasses are meant to be created with 
>> > #on: (or another "instance creation" message), _not #new_, otherwise they 
>> > won't be properly initialized. The class comment is clear about this, but 
>> > I should have overridden #new to raise an error like Stream does. Your 
>> > misuse was helpful in bringing this to my attention, and I added a 
>> > Stream-like #new implementation to SAXHandler.
>> >
>> >> Sent: Friday, December 08, 2017 at 9:21 AM
>> >> From: "Stephane Ducasse" 
>> >> To: "Pharo Development List" 
>> >> Subject: Re: [Pharo-dev] How to get rid of empty XML nodes?
>> >>
>> >> Hi monty
>> >>
>> >>
>> >> On Fri, Dec 8, 2017 at 9:03 AM, monty  wrote:
>> >> > By "empty XML nodes," do you mean whitespace-only string nodes?
>> >>
>> >> Yes
>> >>
>> >> > Those are included because all in-element whitespace is assumed 
>> >> > significant by the spec: https://www.w3.org/TR/xml/#sec-white-space
>> >>
>> >> I know. There was a discussion a while ago. I just lost a couple of
>> >> hours understanding that :(
>> >>
>> >> But this is a super super super annoying practices.
>> >> We had to test each nodes to see if it is a empty nodes so it makes
>> >> everything a lot more complex without real justification
>> >> beside the fact that these standardizers probably never implemented
>> >> some real cases.
>> >> This standard is a really out of reality from that perspective.
>> >>
>> >> > The exception is if the element is declared in the DTD as only having 
>> >> > element children ("element content"): 
>> >> > https://www.w3.org/TR/xml/#dt-elemcontent
>> >>
>> >> Well the XML files that I had (I did not choose XML because I would
>> >> have prefer JSON :) ), had no DTD :(
>> >>
>> >> So at the end of the day, this wonderful standard puts all the stress
>> >> and burden to people.
>> >>
>> >> >
>> >> > For example, if you declare an element like this:
>> >> >
>> >> > 
>> >> >
>> >> > Any whitespace around a "two," "three," or "four" element child of a 
>> >> > "one" element is insignificant and ignored (unless 
>> >> > #preservesIgnorableWhitespace: is true). Other parsers, like LibXML2 
>> >> > and Xerces, behave the same way.
>> >> >
>> >> > I'll see if I can come up with some easier way to deal with this, like 
>> >> > an optional parser setting, new enumeration methods, or maybe a tree 
>> >> > transformation.
>> >>
>> >> It would be A HUGE PLUS!!
>> >>
>> >>
>> >> Because reality is that people have XML files with just nodes and no
>> >> empty nodes and they are forced to
>> >> Let me know because I could try.
>> >>
>> >> I was showing how to use Pharo to import code to pharo learners and
>> >> this was a big drag.
>> >>
>> >> Stef
>> >>
>> >>
>> >> I tried to set some values in the parser but it did not work.
>> >> BTW I saw that the configuration logic forces to write the following
>> >>
>> >> | parser doc visitor |
>> >> parser := XMLDOMParser new
>> >>on: self xmlContents;
>> >>preservesIgnorableWhitespace: true.
>> >>
>> >> and not
>> >>
>> >> | parser doc visitor |
>> >> parser := XMLDOMParser new
>> >> preservesIgnorableWhitespace: true.
>> >> on: self xmlContents;
>> >>
>> >>
>> >> >
>> >> >> Sent: Tuesday, December 05, 2017 at 8:29 AM
>> >> >> From: "Stephane Ducasse" 
>> >> >> To: "Pharo Development List" 
>> >> >> Subject: [Pharo-dev] How to get rid of empty XML nodes?
>> >> >>
>> >> >> )Hi
>> >> >>
>> >> >> we are manipulating an XML document and I would like to get rid of the
>> >> >> spurious empty string.
>> >> >> We saw that the gt panes are doing it.
>> >> >>
>> >> >> (aNodeWithElements isStringNode
>> >> >> and: [aNodeWithElements isEmpty
>> >> >> or: [aNodeWithElements isWhitespace]]
>> >> >>
>> >> >> Is there a way not to produce empty nodes?
>> >> >> Is there a simple way not to have to handle them
>> >> >>
>> >> >> Now each time we are dealing with a node with have to check.
>> >> >>
>> >> >> Stef
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >
>>
>>

Re: [Pharo-dev] How to add a new rule?

[Stephane Ducasse]

Ok vincent told me that he succeeded and we can use its example.
We can also ask benoit how he extended renaku.
I will set up a booklet.



On Mon, Jan 29, 2018 at 1:42 PM, Yuriy Tymchuk  wrote:
>
>
> Sent from my iPad
>
>> On 28 Jan 2018, at 22:50, Stephane Ducasse  wrote:
>>
>> Ok I will add your email next time.
>>
>>
>>> On Sun, Jan 28, 2018 at 8:57 AM, Yuriy Tymchuk  wrote:
>>> Hi Stef.
>>>
>>> First of all, please include my email in the recipients list. I’m committed 
>>> to maintain the Rule infrastructure, but I rarely manage to read through 
>>> Pharo dev. I was nice that Myroslava told me about this email.
>>
>> Ok I will add your email next time.
>>
>>> Secondly I suppose that you are working on Pharo 7, because Pharo 6 mostly 
>>> follows the old approach.
>>
>> I do not know since it was not on my machine but most probably pharo 70
>
> If it is Pharo 6 then you can just follow the old smalllint strategy, but you 
> may need to reset the cache.
>
>>
>>>
>>> One thing that can cause a rule not showing up is caching, and although it 
>>> should be automatically invalidated upon the addition of a new rule, you 
>>> can manually clear it by searching for “Renraku” in settings and pressing 
>>> the “Reset rule cache” button.
>>
>> Ahh this is what we suspected.
>>
>>> You should not subclass RBTransformationRule, you should subclass 
>>> ReNodeRewriteRule. In fact if you check, there are no subclasses of 
>>> RBTransformationRule.
>>
>> This is strange because I remember that ifNotNilDo was a subclass.
>> But again is was on a machine with super small fonts :)
>>
>>>
>>> Now about documentation. I suspect that my IWST presentation and the 
>>> Renraku paper (Thesis chapter) are not enough, but the problem is that 
>>> nobody tried to create rules and give me a feedback about that so far. As 
>>> you are adding new rules, I think that this is a nice opportunity to write 
>>> some kind of a booklet, because rules are really powerful and we should 
>>> share the knowledge of how to create them (and we should also simplify the 
>>> creation process).
>>
>> Yes I would love to have a booklet on that. Do you want to join effort?
>
> Yes, but I need user experience. Because I already tried to document Renraku 
> here and there but I don’t know what is not clear. Also I expect that 
> Myroslava can join.
>
>>
>>
>>> Right now there is a “Renraku Quality Rules” help group in the main Pharo 
>>> help browser that provides a brief description of how to create rules and 
>>> run them. I think that this is a good starting point because I tried to put 
>>> there the essential information needed to start with rule creation.
>>
>> Excellent we will read it.
>>
>>
>>> P.S. what would be nice is to generate booklets from Pharo help, because I 
>>> does not make sense to have 2 sources of documentation.
>>
>> Yes we are working on Pillar and we will get there. Now a booklet for
>> three or four pages of description is not worth.
>> So may be the inverse is better. What we could do is to extend the
>> help to display the pillar booklet inside the image. But slowing
>>
>>
>>> Cheers.
>>> Uko
>>>
 On 27 Jan 2018, at 16:19, Stephane Ducasse  wrote:

 Hi yuriy

 We defined a new rule subclass of RBTransformationRule and we did not
 get why the rule
 was not taken into account.

 We put an halt in another class such as ifNotNilDo: in
  - initialize (is there a cache)?
  - checkMethod:

 and it did not stop.
 We started to
   to watch your ESUG videos
   to read your PhD

 but it did not help us.

 Stef

>>>
>>>
>>
>

Re: [Pharo-dev] [ANN] Fog - Ethereum driver

[Ben Coman]

btw, I started doing this course...
https://www.udemy.com/ethereum-dapp/
and hopefully this knowledge can transfer over to Pharo.

Can anyone recommend other learning resources?

cheers -ben

On 30 January 2018 at 02:55, Santiago Bragagnolo
 wrote:
> Hi Rafael!
> Events are not yet supported sadly.
> If you are willing to do something about, we can discuss. By my side I will
> be kind of busy during february.
>
> I hope to be able to do something about on march, but i cannot guarantee it
>
> Santiago
>
>
> On Mon, 29 Jan 2018 at 17:40 Rafael Luque 
> wrote:
>>
>> Hi Santiago,
>>
>> I'm currently playing with Dapps on Ethereum using Truffle and web3.js,
>> but it would be great to be able to use Pharo.
>>
>> I've downloaded Fog and started to read the tests and code, but I don't
>> see support for events that is something I need for my current use cases.
>> Maybe I don't know where to look or events are not (yet) supported?
>>
>> In any case, thank you for this contribution.
>>
>>
>> 2017-03-14 9:51 GMT+00:00 Santiago Bragagnolo
>> :
>>>
>>> You are welcome :). We are doing some experiments for looking some
>>> research branches on it.
>>> So, writing some Dapps but not really productive. or not yet.
>>> Any way, we still using solidity as language for the contracts.
>>>
>>> Santiago
>>>
>>>
>>>
>>> On Mon, 13 Mar 2017 at 19:44 Esteban A. Maringolo 
>>> wrote:

 Very Nice! Thank you for building it.

 I started a similar project for the Bitcoin blockchain, but then I
 drifted away and never got back to it.

 Are you writing DAPPs?

 Best regards,

 Esteban A. Maringolo


 2017-03-13 12:00 GMT-03:00 Santiago Bragagnolo
 :
 > Hi all. Im happy to announce a pre release of the Fog ethereum driver
 > that
 > we develop in the space of an Inria project.
 >
 > It still not complete but is already usable for some experiments and
 > simple
 > projects.
 >
 > You can downloadit from
 > https://github.com/sbragagnolo/Fog/
 > (https://github.com/sbragagnolo/Fog/releases/tag/v0.1.1.1)
 >
 > Dependencies
 >
 > RHash
 >
 >  sudo apt-get install rhash
 >
 > Solidity
 >
 >  npm install solc
 >
 > Download code
 >
 > Iceberg / Baseline
 >
 > Metacello
 > new
 > baseline: 'Fog';
 > repository:  'github://sbragagnolo/Fog:v0.1.1.1/src';
 > load.
 >
 > By hand
 >
 > You may want to use this version for having access to some scripts and
 > contracts samples.
 >
 > git checkout g...@github.com:sbragagnolo/Fog.git
 >
 > git checkout v0.1.1.1
 >
 > Metacello
 > new
 > baseline: 'Fog';
 > repository: 'filetree:///path/to/git-repository/Fog/src';;
 > load.
 >
 >
 > It's based on the standar API for javascript
 > (https://github.com/ethereum/wiki/wiki/JavaScript-API) .
 >
 > It provides interaction with remote contracts, it do as well provides
 > a way
 > for navigating the architecture objects: blocks, transactions,
 > accounts and
 > contracts.
 >
 > I hope you find it useful.
 >
 > Feel free to fill the github issue tracker with anything you find :).
 >
 >
 > I will come to you with some new exciting news about ethereum soon :)
 >
 > Santiago.
 >
 >
 >
 >
 >
 >

>>
>

[Pharo-dev] [Pharo 7.0-dev] Build #477: 21175-ReleaseTest-testUndeclared-should-allow-stubs-for-test-purpose

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #477 was: SUCCESS.

The Pull Request #773 was integrated: 
"21175-ReleaseTest-testUndeclared-should-allow-stubs-for-test-purpose"
Pull request url: https://github.com/pharo-project/pharo/pull/773

Issue Url: https://pharo.fogbugz.com/f/cases/21175
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/477/

Re: [Pharo-dev] How to add a new rule?

[Yuriy Tymchuk]

Cool, let me know how it goes!

Sent from my iPad

> On 29 Jan 2018, at 21:12, Stephane Ducasse  wrote:
> 
> Ok vincent told me that he succeeded and we can use its example.
> We can also ask benoit how he extended renaku.
> I will set up a booklet.
> 
> 
> 
>> On Mon, Jan 29, 2018 at 1:42 PM, Yuriy Tymchuk  wrote:
>> 
>> 
>> Sent from my iPad
>> 
>>> On 28 Jan 2018, at 22:50, Stephane Ducasse  wrote:
>>> 
>>> Ok I will add your email next time.
>>> 
>>> 
 On Sun, Jan 28, 2018 at 8:57 AM, Yuriy Tymchuk  
 wrote:
 Hi Stef.
 
 First of all, please include my email in the recipients list. I’m 
 committed to maintain the Rule infrastructure, but I rarely manage to read 
 through Pharo dev. I was nice that Myroslava told me about this email.
>>> 
>>> Ok I will add your email next time.
>>> 
 Secondly I suppose that you are working on Pharo 7, because Pharo 6 mostly 
 follows the old approach.
>>> 
>>> I do not know since it was not on my machine but most probably pharo 70
>> 
>> If it is Pharo 6 then you can just follow the old smalllint strategy, but 
>> you may need to reset the cache.
>> 
>>> 
 
 One thing that can cause a rule not showing up is caching, and although it 
 should be automatically invalidated upon the addition of a new rule, you 
 can manually clear it by searching for “Renraku” in settings and pressing 
 the “Reset rule cache” button.
>>> 
>>> Ahh this is what we suspected.
>>> 
 You should not subclass RBTransformationRule, you should subclass 
 ReNodeRewriteRule. In fact if you check, there are no subclasses of 
 RBTransformationRule.
>>> 
>>> This is strange because I remember that ifNotNilDo was a subclass.
>>> But again is was on a machine with super small fonts :)
>>> 
 
 Now about documentation. I suspect that my IWST presentation and the 
 Renraku paper (Thesis chapter) are not enough, but the problem is that 
 nobody tried to create rules and give me a feedback about that so far. As 
 you are adding new rules, I think that this is a nice opportunity to write 
 some kind of a booklet, because rules are really powerful and we should 
 share the knowledge of how to create them (and we should also simplify the 
 creation process).
>>> 
>>> Yes I would love to have a booklet on that. Do you want to join effort?
>> 
>> Yes, but I need user experience. Because I already tried to document Renraku 
>> here and there but I don’t know what is not clear. Also I expect that 
>> Myroslava can join.
>> 
>>> 
>>> 
 Right now there is a “Renraku Quality Rules” help group in the main Pharo 
 help browser that provides a brief description of how to create rules and 
 run them. I think that this is a good starting point because I tried to 
 put there the essential information needed to start with rule creation.
>>> 
>>> Excellent we will read it.
>>> 
>>> 
 P.S. what would be nice is to generate booklets from Pharo help, because I 
 does not make sense to have 2 sources of documentation.
>>> 
>>> Yes we are working on Pillar and we will get there. Now a booklet for
>>> three or four pages of description is not worth.
>>> So may be the inverse is better. What we could do is to extend the
>>> help to display the pillar booklet inside the image. But slowing
>>> 
>>> 
 Cheers.
 Uko
 
> On 27 Jan 2018, at 16:19, Stephane Ducasse  
> wrote:
> 
> Hi yuriy
> 
> We defined a new rule subclass of RBTransformationRule and we did not
> get why the rule
> was not taken into account.
> 
> We put an halt in another class such as ifNotNilDo: in
> - initialize (is there a cache)?
> - checkMethod:
> 
> and it did not stop.
> We started to
>  to watch your ESUG videos
>  to read your PhD
> 
> but it did not help us.
> 
> Stef
> 
 
 
>>> 
>> 
>