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

Re: [Pharo-dev] Manifest class values - instance or class side

by Sergio Fedi

Why scary? It seems that it was a part of the system not used. Maybe the scary part was to have something implemented that wasn't used?

May 19, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50050 Home: https://github.com/pharo-project/pharo-core

May 19, 2015

[pharo-project/pharo-core] 019fca: 50050

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 019fca41ad12300d99e400a0be82a7cf18129606 https://github.com/pharo-project/pharo-core/commit/019fca41ad12300d99e400a0… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-05-19 (Tue, 19 May 2015) Changed paths: R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50049.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50050.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50049.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50050.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Spec-MorphicAdapters.package/SpecTreeNodeModel.class/instance/protocol/content.st A System-Support.package/ClassQueryTest.class/README.md A System-Support.package/ClassQueryTest.class/definition.st A System-Support.package/ClassQueryTest.class/instance/tests/testAllCallsOn.st A System-Support.package/ClassQueryTest.class/instance/tests/testAllCallsOnASymbol.st A System-Support.package/ClassQueryTest.class/instance/tests/testReferencedClasses.st A System-Support.package/MethodQueryTest.class/README.md A System-Support.package/MethodQueryTest.class/definition.st A System-Support.package/MethodQueryTest.class/instance/tests/testReferencedClasses.st A System-Support.package/extension/CompiledMethod/instance/referencedClasses.st M System-Support.package/extension/TBehavior/instance/referencedClasses.st R Tests.package/ClassQueryTest.class/README.md R Tests.package/ClassQueryTest.class/definition.st R Tests.package/ClassQueryTest.class/instance/dependencies/testReferencedClasses.st R Tests.package/ClassQueryTest.class/instance/tests/testAllCallsOn.st R Tests.package/ClassQueryTest.class/instance/tests/testAllCallsOnASymbol.st M Tool-Base.package/AbstractTool.class/instance/category/removeCategory_inClass_.st A Tool-Base.package/AbstractTool.class/instance/private/confirmAndRemoveCategory_inClass_.st Log Message: ----------- 50050 12358 Even if ---all--- can not be removed, all the methods can ... https://pharo.fogbugz.com/f/cases/12358 15550 TBehavior>>referencedClasses is wrong https://pharo.fogbugz.com/f/cases/15550 15500 SpecTreeNodeModel(Object)>>doesNotUnderstand: #content https://pharo.fogbugz.com/f/cases/15500 http://files.pharo.org/image/50/50050.zip

May 19, 2015

Re: [Pharo-dev] Code generation for ASTs with syntax errors

by Thierry Goubier

2015-05-19 11:22 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > > On 19 May 2015, at 10:32, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > > 2015-05-19 10:27 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > >> >> >>> >> And that view get the selection wrong ;) >> >> >> No, the ErrorNode has "all the rest" as it's extend for Shout so it can >> color the error just the same as people are used to. >> > > Ok. > > But I'd really like Shout not to color red the rest of the code when I > start to modify code half way through a method :) > > Is that inherent to the way ErrorNode instances are generated or is it > just done to maintain as it was? > > > I am not entirely sure... it sets the code of the ErrorNode to be just from > where we are to the end of the to be parsed text. > At that point it is hard to know the real extend of the error... needs to be > checked how to do it nicer. > In the example you give, the parser is able to trigger an error, go up the ast tree, and restart correct parsing further down the source code, no? Is that the way you are doing it? I'm interested in a general parsing theory for that kind of error detection / recovery. Thierry > > I think we should first get it in a state that we can replace the shout > parser (both for syntax highlight and code completion). > > Marcus >

May 19, 2015

Re: [Pharo-dev] Code generation for ASTs with syntax errors

by Damien Pollet

On 18 May 2015 at 21:33, Marcus Denker <marcus.denker(a)inria.fr> wrote: > As for finding them: the nice property of syntax errors is that they are > trivial to detect staticallyâ¦ so e.g. we can add that people never can > commit code like that NOPE. The problem I had was that NBExternalStructure was changed from a variable bytes class to a normal one. So subclasses were committed without error but still couldn't be loaded with a more recent NB. Errors WILL happen, and fixing those is where plain text beats objectsâ¦ -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

May 19, 2015

Re: [Pharo-dev] Code generation for ASTs with syntax errors

by Marcus Denker

> On 19 May 2015, at 10:32, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2015-05-19 10:27 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>: > >> >> And that view get the selection wrong ;) >> > > No, the ErrorNode has âall the restâ as itâs extend for Shout so it can color the error just the same as people are used to. > > Ok. > > But I'd really like Shout not to color red the rest of the code when I start to modify code half way through a method :) > > Is that inherent to the way ErrorNode instances are generated or is it just done to maintain as it was? > I am not entirely sureâ¦ it sets the code of the ErrorNode to be just from where we are to the end of the to be parsed text. At that point it is hard to know the real extend of the errorâ¦ needs to be checked how to do it nicer. I think we should first get it in a state that we can replace the shout parser (both for syntax highlight and code completion). Marcus

May 19, 2015

Re: [Pharo-dev] Code generation for ASTs with syntax errors

by Thierry Goubier

2015-05-19 10:27 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > > >> > And that view get the selection wrong ;) > > > No, the ErrorNode has "all the rest" as it's extend for Shout so it can > color the error just the same as people are used to. > Ok. But I'd really like Shout not to color red the rest of the code when I start to modify code half way through a method :) Is that inherent to the way ErrorNode instances are generated or is it just done to maintain as it was? Thierry > > Marcus > >

May 19, 2015

Re: [Pharo-dev] Code generation for ASTs with syntax errors

by Marcus Denker

> > And that view get the selection wrong ;) > No, the ErrorNode has âall the restâ as itâs extend for Shout so it can color the error just the same as people are used to. Marcus

May 19, 2015

Re: [Pharo-dev] Code generation for ASTs with syntax errors

by Thierry Goubier

Ok. Now I need to evaluate if the time spent writing a GT presentation is worth the performance impact of using the GT Inspector use compared to writing a dedicated version of a faster tree viewer ;) Thierry 2015-05-19 10:18 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > It's already available :). > > > [image: Inline image 1] > > Doru > > > On Tue, May 19, 2015 at 10:18 AM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > >> >> > >> > with the GT inspector, it has a very nice AST view: >> > >> > >> > The AST view of the GT Inspector is useless for serious work. >> > >> > >> > I've been spending the past weeks and months looking at ASTs, SSA and >> > CFGs of code and I allways need a twin view: node + source code (and >> > selecting one of those node select the relevant portion of the code). >> >> Agree, something like this would be even nicer... >> >> Jan >> >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

May 19, 2015

Re: [Pharo-dev] Code generation for ASTs with syntax errors

by Thierry Goubier

2015-05-19 10:16 GMT+02:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > > > On Tue, May 19, 2015 at 10:02 AM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > >> >> >> 2015-05-19 7:49 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: >> >>> >>> On 13 May 2015, at 11:21, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >>> >>> Thanks's Marcus. It is beautiful thing. >>> >>> Is parsing locate errors by "dot"s? I mean how it will parse "3+. 1+2"? >>> It will be super cool if we have only "3+." as error but remains code as >>> good one >>> >>> >>> You can just look at >>> >>> OpalCompiler new >>> source: 'method 3+. 1+2'; >>> useFaultyForParsing: true; >>> parse. >>> >> >> Impressive ! >> >> >>> >>> with the GT inspector, it has a very nice AST view: >>> >> >> The AST view of the GT Inspector is useless for serious work. >> >> I've been spending the past weeks and months looking at ASTs, SSA and >> CFGs of code and I allways need a twin view: node + source code (and >> selecting one of those node select the relevant portion of the code). >> > > Switching to the 'Source code' view in the second pane gives you exactly > that > > [image: Inline image 1] > > And that view get the selection wrong ;) Thierry

May 19, 2015