- Pharo-dev - lists.pharo.org

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

by Christophe Demarey

> Le 18 avr. 2018 Ã 09:52, Christophe Demarey <christophe.demarey(a)inria.fr> a Ã©crit : > > >> Le 18 avr. 2018 Ã 05:05, monty <monty2(a)programmer.net> a Ã©crit : >> >> Not quite fixed: https://ci.inria.fr/pharo-contribution/job/ZincHTTPComponents/1822/PHARO=30… >> >> Should we start reconfiguring jobs to keep fewer builds? > > I do not think so. > The problem here is that the root partition of the slaves are full because /tmp has thousands of zip files that are downloaded by metacello from github. > There is no problem with job workspace or the number of builds to keep. > I will define a job running on slaves daily to remove tmp folder content. done: https://ci.inria.fr/pharo-contribution/job/temp-folder-cleaner/

April 18, 2018

Re: [Pharo-dev] Fun with AST evaluation

by Denis Kudriashov

2018-04-18 7:41 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Now clement what is the difference with a plain AST interpreter? > Together with #evaluate we can also have #debug message. With interpreter approach it would be tricky to implement it with standard debugger. > > > 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 Christophe Demarey

> Le 18 avr. 2018 Ã 05:05, monty <monty2(a)programmer.net> a Ã©crit : > > Not quite fixed: https://ci.inria.fr/pharo-contribution/job/ZincHTTPComponents/1822/PHARO=30… > > Should we start reconfiguring jobs to keep fewer builds? I do not think so. The problem here is that the root partition of the slaves are full because /tmp has thousands of zip files that are downloaded by metacello from github. There is no problem with job workspace or the number of builds to keep. I will define a job running on slaves daily to remove tmp folder content.

April 18, 2018

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