- Pharo-dev - lists.pharo.org

[ANN] The next Pharo Sprints at Lille

by Marcus Denker

Hello, We looked at the calendar and fixed the dates for all public sprints that we will do this year here locally. These are all Fridays: Sept 11 Oct 23 Nov 27 Dec 18 Here is the invitation for this Friday: âââââââââââââââââââââââ We will organize a Pharo sprint / Moose dojo Friday, 11th September, starting at 10:00am. (Local Time Lille). It will be at the Inria Lille, Building B, third floor (RMoD offices). Remotely, you can join us on the official IRC channel #pharo on irc.freenode.net server. During the sprint, we will try to synchronize local and remote Pharo sprinters. As the building is not open to the public, please contact us before if you plan to come.

Sept. 8, 2015

Re: [Pharo-dev] WhatsUp from: 2015-09-07 until: 2015-09-20

by Stephan Eggermont

On 07-09-15 07:00, seaside(a)rmod.lille.inria.fr wrote: > Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! > > ### Here's what I've been up to since the last WhatsUp: - a few bugfixes all over the place - a lot of bug entries - improvements to PetitDelphi > ### What's next, until 2015-09-20 (*): Looking at improved/other LayoutPolicies Stephan

Sept. 8, 2015

Re: [Pharo-dev] [Pharo-users] Modifying the AST of a method

by Marcus Denker

> On 08 Sep 2015, at 03:02, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > From GÃ¼nter Khyo: > > GÃ¼nter Khyo wrote >> Hello! >> >> I want to replace particular nodes of an AST (such as Assignments or Self >> sends) with my own nodes. >> Is there an easy (high-level) way to do this without being familiar with >> the entire compiler infrastructure? >> >> The problem I am having is that AST nodes maintain internal state such as >> parent links and, in the case of RBVariables, links to scopes and >> bindings. There might be many other dependencies I am missing and missing >> one of them can trigger exceptions with stack traces buried deep in the IR >> Code-Generator and visitor calls. >> >> For example, if I want to replace an assignment such as >> >> Morph>>position: aPoint >> >> "box := self fullBounds." >> >> with something like >> >> "self assignAndNotifiyDependents: self fullBounds to: 'box' " >> >> Btw: I know there is a rewrite tool, but I want to do it programmatically. Hello, With Pharo5 there are two mechanism that can help you. 1) MetaLinks (aka reflectivity). ======================= They allow you to reflectively define that a meta object to be called before/after or instead of an AST node. as you want to do something in addition here, you can add the notification as a #before link: link := MetaLink new metaObject: #object; selector: #assignAndNotifiyDependents:; arguments: #(newValue). this is a link that when installed on an AssignmentNode, will call #assignAndNotifiyDependents on the object with the new value (the to be assigned value) as the argument. To install this on all ivar assignments, do: MyClass assignmentNodes do: [ :each | each variable isInstance ifTrue: [each link: link ]]. to get rid of the link: link uninstall But MetaLinks are very hidden: you do not see them in your design. So they should be used with care. 2) First class Instance variable (aka Slots). ================================= In your example, what you really want is a âspecialâ kind of variable that always notifies depends. Wouldnât it be nice if you could define such a special kind of Variable and, in the class definition of you class, specify that the ivar âboxâ is that special kind? In Pharo5, you can do just that. 1) define your special variable. IndexedSlot subclass: #NotifyDependsSlot slots: { } classVariables: { } category: 'Demoâ change what it means to write these kind of variables by implementing: write: aValue to: anObject super write: aValue to: anObject. anObject assignAndNotifiyDependents: aValue. Now change the class definition of your class to make âboxâ into this special kind of variable: Object subclass: #MyClass slots: { #box => NotifyDependsSlot } classVariables: { } category: âDemo' DONE. Ah, but reflective slot write is slow, so if you use this a lot, add these two method: emitValue: methodBuilder methodBuilder pushInstVar: index. emitStore: methodBuilder | tempName | tempName := Object new. methodBuilder addTemp: tempName; storeTemp: tempName; pushReceiver; pushTemp: tempName; send: #assignAndNotifiyDependents:; popTop; storeInstVar: index. These generate byte code inline for the read and write instead of calling the #write:to: method. (I attach a fillout of MyClass that i used to test this)

Sept. 8, 2015

Re: [Pharo-dev] chunk file format (unrecoverable changes)

by John Brant

On 9/8/2015 8:48 AM, Eliot Miranda wrote: > Forgive me, I don't mean to complain, but... It's rather sad now I look > at it that the specification misses a very cool thing about the format. > Glenn Krasner invented it and he's no dummy. What the specs miss out is > that the syntax for a protocol is actually a general escape mechanism. > For example in > > !Object methodsFor: 'testing'! > isUnderstood > ^false! ! > > the fileIn parser evaluates > > Object methodsFor: 'testing' > > and then asks that object to scanFrom: the stream. And the above > answers a ClassCategoryReader that reads chunks, compiling them and > adding them to the relevant category, until it finds an empty chunk > (hence ! ! is not special syntax, but actually a chunk followed by an > empty chunk). > > So one /could/, if one wanted, add another kind of reader, for example > > !Preferences loadSavedPreferences! > beCool true! > beKnowledgeable true! > rememberOnersHistorytLestOneWishesToRepeatIt true! ! > > and have this not file in, but store preferences. I think that's neat, > and it's very sad that the ANSI standard did;t define this but reduced > the mechanism to support only protocols, and thence cause people to > wonder why the syntax was so weird, when in fact it was very simple and > wonderfully extensible. Dolphin uses it to define class and method categories: !MyClass categoriesFor: #myMethod!accessing!public! ! > Now I'm not blaming the standards process; the real problem here is that > the scheme wasn't documented other than by its implementation and so the > flexibility was never made apparent to the standardizers, I think the flexibility was likely known as most (all?) other implementations at the time did it the same way and Glenn Krasner was the Vice-Chairman of the committee. However, I think some on the committee wanted a purely declarative Smalltalk so you couldn't have anything in the file that evaluated code. >and anyway > they wanted an interchange format, which is not what Squeak and Pharo > chunk readers provide; they provide an extensible format. Pharo no longer provides an extensible format. I tried to file in some Dolphin code and instead of defining a few different methods that returned chunk readers (i.e., methodsFor, categoriesForClass, categoriesFor:), I had to modify the ChunkFileFormatParser>>parseNextDeclaration method. This method has hard coded the different chunk types it accepts. John Brant

Sept. 8, 2015

Re: [Pharo-dev] when:send:to: vs. subscribe:send:to:

by Ferlicot D. Cyril

Le 08/09/2015 10:13, Stephan Eggermont a Ã©crit : > When looking at the implementation, it looks as if we should > replace all #when:send:to: by #subscribe:when:do:, not the other way > around. > > Where is this all coming from? > > Stephan > > > I think that #when:send:to: is more explicit and more understandable, but this is a personal opinion. -- Cheers Cyril

Sept. 8, 2015

Re: [Pharo-dev] WhatsUp from: 2015-09-07 until: 2015-09-20

by Damien Cassou

seaside(a)rmod.lille.inria.fr writes: > ### Here's what I've been up to since the last WhatsUp: - Misc - improve Pharo flyer - Launcher - write a student project proposal to get an intern - start mocking a new GUI - Starter kit - videos - exercices - slides - finish preparing it - send it to the usb stick creator - Mooc (new course on Pharo) - clean the build - make the build pass (fix unicode characters) - improve beamer template (for PDF slides) - new lecture with screencast (create a contact book with web interface) - Pillar - progress on PetitPillar with Cyril - rewrite the default configurations implementation - helped a bit Cyril move Pillar issues to github.com/pillar-markup/pillar - fix job - proof read changes to the documentation by Cyril - fix Pillar bash script (add missing --baseDirectory because Pharo does not know its PWD) - Books - use new Travis infrastructure (sudo: false) - proof-read of an UPBE pull request - fix jobs regarding new Pillar - redo some figures to increase print quality (300dpi) - update latex installation on a slave > ### What's next, until 2015-09-20 (*): - Pillar - release new version - some bug fixing - little enhancements -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Sept. 8, 2015

Re: [Pharo-dev] garbage on transcript

by Marcus Denker

> On 08 Sep 2015, at 15:53, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Marcus, > > On Tue, Sep 8, 2015 at 6:28 AM, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: > >> On 08 Sep 2015, at 15:19, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: >> >> >> >> On Tue, Sep 8, 2015 at 5:13 AM, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> Yes, we do name analysis on the AST before coloring itâ¦ >> >> Even worse than the transcript output are >> >> -> it adds everything into Undeclared >> -> Playground colors variables wrong that the playground knows as the name analysis does >> not setup the requestorscope correctly. >> >> I will add issue tracker entriesâ¦ >> >> Alternatively one could simply use Shout, a specialized parser for syntax highlighting that is simple, efficient, mature and customizable. >> > > The idea was to reduce the amount of Parsers (and models of methods) in the systemâ¦ > > I understand that. But parsing for code generation is very different from the quick and simple parsing for syntax highlighting that Shout provides, and if one ends up complicating the former to make it encompass the latter then maybe that's not such a good idea. I'd rather have a number of smaller simpler parsers than one great big complex difficult to understand and full of special cases parser (think... Morphic). Just a thought. Yesâ¦ but the Shout parser is actually not that simple. SHParserST80 package linesOfCode â2581â And if you then see how much work the completion system has to do to get structural information out of the token stream it that is already in a normal AST by defaultâ¦ Until now the only real change to the RB Parser is the feature to generate an error node for syntactically wrong input. (#parseFaultyExpression/#parseFaultyMethod). Everything else was ok as is. The AST is unchanged (and we therefore use the same AST for the RB Engine, the Compiler and the syntax highlighter). Marcus

Sept. 8, 2015

Re: [Pharo-dev] garbage on transcript

by Eliot Miranda

Hi Marcus, On Tue, Sep 8, 2015 at 6:28 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 08 Sep 2015, at 15:19, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Tue, Sep 8, 2015 at 5:13 AM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > >> Yes, we do name analysis on the AST before coloring itâ¦ >> >> Even worse than the transcript output are >> >> -> it adds everything into Undeclared >> -> Playground colors variables wrong that the playground knows as the >> name analysis does >> not setup the requestorscope correctly. >> >> I will add issue tracker entriesâ¦ >> > > Alternatively one could simply use Shout, a specialized parser for syntax > highlighting that is simple, efficient, mature and customizable. > > > > The idea was to reduce the amount of Parsers (and models of methods) in > the systemâ¦ > I understand that. But parsing for code generation is very different from the quick and simple parsing for syntax highlighting that Shout provides, and if one ends up complicating the former to make it encompass the latter then maybe that's not such a good idea. I'd rather have a number of smaller simpler parsers than one great big complex difficult to understand and full of special cases parser (think... Morphic). Just a thought. Marcus > _,,,^..^,,,_ best, Eliot

Sept. 8, 2015

Re: [Pharo-dev] chunk file format (unrecoverable changes)

by Eliot Miranda

Hi Nicolai, On Mon, Sep 7, 2015 at 1:21 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > 2015-09-07 20:10 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> >> >> On Sun, Sep 6, 2015 at 12:56 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >>> Do we have a documentation about the format of >>> - class definitions >>> - methods >>> - class comments >>> for the changes file ? >>> >> >> >> Google "specification of smalltalk chunk format" and you will see: >> >> Overviews: Chunk File Format >> <https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uac…> >> Smalltalk Interchange Format - Draft Smalltalk Standard v1.9 >> <https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uac…> >> The Smalltalk fileOut format - 1 >> <https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&uac…> >> >> and more. >> > > > Thank you eliot > (should have google that myself !) > > >> >> >>> >>> I am asking because some entries are using two separator >>> "! !" >>> and some only one >>> "!" >>> >> >> Indeed. It's in the spec. ! ! ends a run of methods in the same >> protocol. ! ends a method or a doit, etc. Read the spec. >> > > ah! grouping multiple methods for one protocol. > Forgive me, I don't mean to complain, but... It's rather sad now I look at it that the specification misses a very cool thing about the format. Glenn Krasner invented it and he's no dummy. What the specs miss out is that the syntax for a protocol is actually a general escape mechanism. For example in !Object methodsFor: 'testing'! isUnderstood ^false! ! the fileIn parser evaluates Object methodsFor: 'testing' and then asks that object to scanFrom: the stream. And the above answers a ClassCategoryReader that reads chunks, compiling them and adding them to the relevant category, until it finds an empty chunk (hence ! ! is not special syntax, but actually a chunk followed by an empty chunk). So one /could/, if one wanted, add another kind of reader, for example !Preferences loadSavedPreferences! beCool true! beKnowledgeable true! rememberOnersHistorytLestOneWishesToRepeatIt true! ! and have this not file in, but store preferences. I think that's neat, and it's very sad that the ANSI standard did;t define this but reduced the mechanism to support only protocols, and thence cause people to wonder why the syntax was so weird, when in fact it was very simple and wonderfully extensible. Now I'm not blaming the standards process; the real problem here is that the scheme wasn't documented other than by its implementation and so the flexibility was never made apparent to the standardizers, and anyway they wanted an interchange format, which is not what Squeak and Pharo chunk readers provide; they provide an extensible format. The ANSI standard /could/ however have specified that the syntax is indeed extensible as described, but that conforming implementations are only expected to provide ClassCategoryReaders, and are expected to raise an error if given expressions they don't recognize, or some such. Also, given this history you can see why a single ! following a method definition isn't seen anymore; we've put the stamp information in the ClassCategoryreader so it can only parse a single method. If we'd done something like this (and I'm not suggesting that's a good idea) !Object methodsFor: 'testing'! [stamp: 'mad 01/04/2015 12:00'] isUnderstood ^#barely! [stamp: 'mad 01/04/2015 12:01'] isMisunderstood ^#almostCertainly! ! we'd still see the single !'s after methods. Two key points for me are - specify carefully and visibly - extensible standards are better than fixed standards And we have a problem with the "Recover lost changes" browser >>> (https://pharo.fogbugz.com/f/cases/16498/unrecoverable-changes) >>> and I am not sure if this is a bug on the code importer >>> or if it is a bug on how we write changes to the changes file. >>> >> _,,,^..^,,,_ best, Eliot

Sept. 8, 2015

Re: [Pharo-dev] garbage on transcript

by Marcus Denker

> On 08 Sep 2015, at 15:19, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Tue, Sep 8, 2015 at 5:13 AM, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: > Yes, we do name analysis on the AST before coloring itâ¦ > > Even worse than the transcript output are > > -> it adds everything into Undeclared > -> Playground colors variables wrong that the playground knows as the name analysis does > not setup the requestorscope correctly. > > I will add issue tracker entriesâ¦ > > Alternatively one could simply use Shout, a specialized parser for syntax highlighting that is simple, efficient, mature and customizable. > The idea was to reduce the amount of Parsers (and models of methods) in the systemâ¦ Marcus

Sept. 8, 2015