January 2018 - Pharo-dev - lists.pharo.org

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

by 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 <santiagobragagnolo(a)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 <emaringolo(a)gmail.com> > 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 < >> santiagobragagnolo(a)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 git@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. >> > >> > >> > >> > >> > >> > >> >>

Jan. 29, 2018

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

by Ben Coman

On 29 January 2018 at 21:32, Christophe Demarey <christophe.demarey(a)inria.fr> wrote: > >> Le 29 janv. 2018 Ã 14:16, Ben Coman <btc(a)openinworld.com> 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

Jan. 29, 2018

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

by Christophe Demarey

> Le 29 janv. 2018 Ã 14:16, Ben Coman <btc(a)openinworld.com> 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?

Jan. 29, 2018

Iceberg UI feedback - synchronise v. status

by 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

Jan. 29, 2018

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

by 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" <stepharo.self(a)gmail.com> > To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > 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 <monty2(a)programmer.net> 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" <stepharo.self(a)gmail.com> > >> To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > >> Subject: Re: [Pharo-dev] How to get rid of empty XML nodes? > >> > >> Hi monty > >> > >> > >> On Fri, Dec 8, 2017 at 9:03 AM, monty <monty2(a)programmer.net> 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: > >> > > >> > <!ELEMENT one (two,three*,four?)> > >> > > >> > 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" <stepharo.self(a)gmail.com> > >> >> To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > >> >> 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 > >> >> > >> >> > >> > > >> > >> > > > >

Jan. 29, 2018

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

by Yuriy Tymchuk

Sent from my iPad > On 28 Jan 2018, at 22:50, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Ok I will add your email next time. > > >> On Sun, Jan 28, 2018 at 8:57 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> 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. > > Ahhhhhh 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 <stepharo.self(a)gmail.com> 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 >>> >> >> >

Jan. 29, 2018

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

by 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 <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 <marcus.denker(a)inria.fr> wrote: > > > >> On 26 Jan 2018, at 14:42, Juraj Kubelka <juraj.kubelka(a)icloud.com> wrote: >> >> >> >>> On Jan 26, 2018, at 09:13, Marcus Denker <marcus.denker(a)inria.fr> 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 > > >

Jan. 29, 2018

Pavel's ChangeLog week of 2018-01-22

by 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

Jan. 29, 2018

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

by Marcus Denker

> On 29 Jan 2018, at 09:59, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Great results, Marcus. > >> On 29 Jan 2018, at 09:18, Marcus Denker <marcus.denker(a)inria.fr> 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

Jan. 29, 2018

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

by Sven Van Caekenberghe

Great results, Marcus. > On 29 Jan 2018, at 09:18, Marcus Denker <marcus.denker(a)inria.fr> 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

Jan. 29, 2018