September 2015 - Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] garbage on transcript

by Eliot Miranda

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. > > Marcus > > On 08 Sep 2015, at 08:09, stepharo <stepharo(a)free.fr> wrote: > > > > Hi > > > > when I define methods and the Transcript is open I get such kind of > trace and I do not get where it comes from. > > I think that this is the syntactical coloring. > > Would be good to avoid because this is annoying. > > > > StoreImporter>>messageSelectorAndArgumentNames (statements is Undeclared) > > > > UndefinedObject>>noMethod (messageSelectorAndArgumentNames is Undeclared) > > > > Stef > > > > > -- _,,,^..^,,,_ best, Eliot

Sept. 8, 2015

Re: [Pharo-dev] garbage on transcript

by Marcus Denker

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â¦ Marcus > On 08 Sep 2015, at 08:09, stepharo <stepharo(a)free.fr> wrote: > > Hi > > when I define methods and the Transcript is open I get such kind of trace and I do not get where it comes from. > I think that this is the syntactical coloring. > Would be good to avoid because this is annoying. > > StoreImporter>>messageSelectorAndArgumentNames (statements is Undeclared) > > UndefinedObject>>noMethod (messageSelectorAndArgumentNames is Undeclared) > > Stef >

Sept. 8, 2015

Re: [Pharo-dev] TextAttributes in source code or class comment?

by Henrik Johansen

> On 08 Sep 2015, at 11:03 , Martin Dias <tinchodias(a)gmail.com> wrote: > > On Sat, Sep 5, 2015 at 1:10 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: >> The same for the ]lang[ tag (see issue 15750) > > Ok. But I still don't know how to add a url to a method's source code > or comment from the UI. > > I mean, people with a non-English keyboard can produce source code > with ]lang[, but how can I produce a ]style[ ? > > MartÃn The whole mechanism is quite broken in Pharo4 upwards:

Sept. 8, 2015