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

Re: [Pharo-dev] Fun with AST evaluation

by Sven Van Caekenberghe

> On 18 Apr 2018, at 08:34, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > >> On 18 Apr 2018, at 08:11, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >> >>> On 18 Apr 2018, at 07:41, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>> >>> So this means that we could also have a simple hover showing the variable values when debugging. >>> >> It could be used for that, but then we did have already lookupSymbol: on context (we added that so we >> can easily use any valid variable in the condition for conditional breakpoints). >> > Hmmâ¦ now that I think about itâ¦ I guess evaluateWithContext: could even be used to simplify the > code that creates the condition block for conditional breakpoints. > > This was not even the goalâ¦ to be checked. > > Marcus You have to do enough fun stuff, that is very important.

April 18, 2018

Re: [Pharo-dev] Fun with AST evaluation

by Marcus Denker

> On 18 Apr 2018, at 08:11, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > >> On 18 Apr 2018, at 07:41, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> So this means that we could also have a simple hover showing the variable values when debugging. >> > It could be used for that, but then we did have already lookupSymbol: on context (we added that so we > can easily use any valid variable in the condition for conditional breakpoints). > Hmmâ¦ now that I think about itâ¦ I guess evaluateWithContext: could even be used to simplify the code that creates the condition block for conditional breakpoints. This was not even the goalâ¦ to be checked. Marcus

April 18, 2018

Re: [Pharo-dev] Fun with AST evaluation

by Marcus Denker

> On 18 Apr 2018, at 07:41, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > So this means that we could also have a simple hover showing the variable values when debugging. > It could be used for that, but then we did have already lookupSymbol: on context (we added that so we can easily use any valid variable in the condition for conditional breakpoints). > > Now clement what is the difference with a plain AST interpreter? > For larger ASTs it should be faster (especially with loops), for just reading a var the compilation overhead should be quite high. Did not measure it, though. The nice thing that is is not a lot of code *and* it is the same code we use to evaluate DoIts already, so with some refactoring is would be (from a LOC perspective) completely free and even simplify the Doit logic. Marcus

April 18, 2018

Re: [Pharo-dev] pharo-contribution CI machines out of disk space

by Stephane Ducasse

Yes we should. I started to keep the minimum on mine and remove some obsolete ones. The problem we have is that people forgot to remove their job when they do not need them anymore. Stef On Wed, Apr 18, 2018 at 5:05 AM, monty <monty2(a)programmer.net> wrote: > Not quite fixed: https://ci.inria.fr/pharo-contribution/job/ZincHTTPComponents/1822/PHARO=30… > > Should we start reconfiguring jobs to keep fewer builds? > >> Sent: Tuesday, April 17, 2018 at 6:08 AM >> From: "Christophe Demarey" <christophe.demarey(a)inria.fr> >> To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> Subject: Re: [Pharo-dev] pharo-contribution CI machines out of disk space >> >> >> > Le 17 avr. 2018 Ã 06:02, monty <monty2(a)programmer.net> a Ã©crit : >> > >> > https://ci.inria.fr/pharo-contribution/job/ZincHTTPComponents/1820/console >> > >> >> Youâre right. >> I did some cleaning and put slaves back on line. >> >> Thanks for the report. >> >

April 18, 2018

Re: [Pharo-dev] Fun with AST evaluation

by Stephane Ducasse

So this means that we could also have a simple hover showing the variable values when debugging. Now clement what is the difference with a plain AST interpreter? On Tue, Apr 17, 2018 at 6:57 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Starting from here you can build a full AST interpreter that mutates a > context instance that you create by interpreting MessageNode... > > On Tue, Apr 17, 2018 at 5:45 PM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > >> Hi, >> >> This is fun experiment: >> >> Every RBValueNode subclass evaluates to something. So why not implement a >> #evaluate method? >> >> This is especially fun to do for a specific context, as this means that >> you could evaluate every RBVariableNode to see the value. >> >> So lets implement a method in RBValueNode: >> >> evaluateWithContext: aContext >> >> | methodNode | >> >> If we want to compile a method for it, we need to wrap it into a return >> and a method. Like when evaluating in the debugger, we create a #DoItIn: >> method that >> will get the context as a parameter to read the values from (temps from >> the context, ivars from context receiver). >> >> This works like this: >> >> methodNode := RBMethodNode >> selector: #DoItIn: >> arguments: { RBVariableNode named: 'ThisContext' } >> body: (RBReturnNode value: self) asSequenceNode. >> >> to read temps from the context parameter, we use the rewrite method that >> is used by doits already: >> methodNode rewriteTempsForContext: aContext. >> >> and now we can execute: >> >> ^methodNode generate valueWithReceiver: aContext receiver arguments: >> {aContext}. >> >> For testing, I put a #haltOnce into Rectangle>>#area and then use the >> inspector on the context to evaluate a AST node that is a temporary >> variable. >> The screenshot shows executing >> >> self method ast assignmentNodes first variable evaluateWithContext: self >> >> and it returns correctly 104: >> >> >> >> >> Of course there are simpler ways to read variables by name from a context >> (e.g. we added #lookupSymbol: ), but #evaluateWithContext: can be called on >> other Nodes, too. >> E.g. just a #evaluate could be nice for creating Blocks programmatically >> (instead of calling the compiler on a Pretty-Print result like >> #createBlockFor: in the ParseTreeSearcher). >> >> A version that does not take context and receiver into account is this: >> >> evaluate >> | methodNode | >> methodNode := RBMethodNode >> selector: #DoIt >> body: (RBReturnNode value: self) asSequenceNode. >> ^methodNode generate valueWithReceiver: nil arguments: #(). >> >> >> and then you can do things like >> >> blockNode: = RBBlockNode >> body: (RBLiteralNode value: 5) asSequenceNode >> >> blockNode evaluate >> >> to create blocks. >> >> >> Marcus >> >> > > > -- > ClÃ©ment BÃ©ra > https://clementbera.github.io/ > https://clementbera.wordpress.com/ >

April 18, 2018

Re: [Pharo-dev] pharo-contribution CI machines out of disk space

by monty

Not quite fixed: https://ci.inria.fr/pharo-contribution/job/ZincHTTPComponents/1822/PHARO=30… Should we start reconfiguring jobs to keep fewer builds? > Sent: Tuesday, April 17, 2018 at 6:08 AM > From: "Christophe Demarey" <christophe.demarey(a)inria.fr> > To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] pharo-contribution CI machines out of disk space > > > > Le 17 avr. 2018 Ã 06:02, monty <monty2(a)programmer.net> a Ã©crit : > > > > https://ci.inria.fr/pharo-contribution/job/ZincHTTPComponents/1820/console > > > > Youâre right. > I did some cleaning and put slaves back on line. > > Thanks for the report. >

April 18, 2018

[Pharo 7.0-dev] Build #777: 21723-Opal-compiler-instances-are-created-in-huge-amount-during-a-method-compilation-from-the-browser

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #777 was: FAILURE. The Pull Request #1212 was integrated: "21723-Opal-compiler-instances-are-created-in-huge-amount-during-a-method-compilation-from-the-browser" Pull request url: https://github.com/pharo-project/pharo/pull/1212 Issue Url: https://pharo.fogbugz.com/f/cases/21723 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 17, 2018

Re: [Pharo-dev] Fun with AST evaluation

by ClÃ©ment Bera

Starting from here you can build a full AST interpreter that mutates a context instance that you create by interpreting MessageNode... On Tue, Apr 17, 2018 at 5:45 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > This is fun experiment: > > Every RBValueNode subclass evaluates to something. So why not implement a > #evaluate method? > > This is especially fun to do for a specific context, as this means that > you could evaluate every RBVariableNode to see the value. > > So lets implement a method in RBValueNode: > > evaluateWithContext: aContext > > | methodNode | > > If we want to compile a method for it, we need to wrap it into a return > and a method. Like when evaluating in the debugger, we create a #DoItIn: > method that > will get the context as a parameter to read the values from (temps from > the context, ivars from context receiver). > > This works like this: > > methodNode := RBMethodNode > selector: #DoItIn: > arguments: { RBVariableNode named: 'ThisContext' } > body: (RBReturnNode value: self) asSequenceNode. > > to read temps from the context parameter, we use the rewrite method that > is used by doits already: > methodNode rewriteTempsForContext: aContext. > > and now we can execute: > > ^methodNode generate valueWithReceiver: aContext receiver arguments: > {aContext}. > > For testing, I put a #haltOnce into Rectangle>>#area and then use the > inspector on the context to evaluate a AST node that is a temporary > variable. > The screenshot shows executing > > self method ast assignmentNodes first variable evaluateWithContext: self > > and it returns correctly 104: > > > > > Of course there are simpler ways to read variables by name from a context > (e.g. we added #lookupSymbol: ), but #evaluateWithContext: can be called on > other Nodes, too. > E.g. just a #evaluate could be nice for creating Blocks programmatically > (instead of calling the compiler on a Pretty-Print result like > #createBlockFor: in the ParseTreeSearcher). > > A version that does not take context and receiver into account is this: > > evaluate > | methodNode | > methodNode := RBMethodNode > selector: #DoIt > body: (RBReturnNode value: self) asSequenceNode. > ^methodNode generate valueWithReceiver: nil arguments: #(). > > > and then you can do things like > > blockNode: = RBBlockNode > body: (RBLiteralNode value: 5) asSequenceNode > > blockNode evaluate > > to create blocks. > > > Marcus > > -- ClÃ©ment BÃ©ra https://clementbera.github.io/ https://clementbera.wordpress.com/

April 17, 2018

Fun with AST evaluation

by Marcus Denker

Hi, This is fun experiment: Every RBValueNode subclass evaluates to something. So why not implement a #evaluate method? This is especially fun to do for a specific context, as this means that you could evaluate every RBVariableNode to see the value. So lets implement a method in RBValueNode: evaluateWithContext: aContext | methodNode | If we want to compile a method for it, we need to wrap it into a return and a method. Like when evaluating in the debugger, we create a #DoItIn: method that will get the context as a parameter to read the values from (temps from the context, ivars from context receiver). This works like this: methodNode := RBMethodNode selector: #DoItIn: arguments: { RBVariableNode named: 'ThisContext' } body: (RBReturnNode value: self) asSequenceNode. to read temps from the context parameter, we use the rewrite method that is used by doits already: methodNode rewriteTempsForContext: aContext. and now we can execute: ^methodNode generate valueWithReceiver: aContext receiver arguments: {aContext}. For testing, I put a #haltOnce into Rectangle>>#area and then use the inspector on the context to evaluate a AST node that is a temporary variable. The screenshot shows executing self method ast assignmentNodes first variable evaluateWithContext: self and it returns correctly 104: Of course there are simpler ways to read variables by name from a context (e.g. we added #lookupSymbol: ), but #evaluateWithContext: can be called on other Nodes, too. E.g. just a #evaluate could be nice for creating Blocks programmatically (instead of calling the compiler on a Pretty-Print result like #createBlockFor: in the ParseTreeSearcher). A version that does not take context and receiver into account is this: evaluate | methodNode | methodNode := RBMethodNode selector: #DoIt body: (RBReturnNode value: self) asSequenceNode. ^methodNode generate valueWithReceiver: nil arguments: #(). and then you can do things like blockNode: = RBBlockNode body: (RBLiteralNode value: 5) asSequenceNode blockNode evaluate to create blocks. Marcus

April 17, 2018

[Pharo 7.0-dev] Build #776: 21722-Small-Cleanup-Syntax-highlighting-remove-a-reference-to-SHParserST80

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #776 was: SUCCESS. The Pull Request #1210 was integrated: "21722-Small-Cleanup-Syntax-highlighting-remove-a-reference-to-SHParserST80" Pull request url: https://github.com/pharo-project/pharo/pull/1210 Issue Url: https://pharo.fogbugz.com/f/cases/21722 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 17, 2018