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

Re: [Pharo-dev] [Pharo-users] SmalltalkCI now supports loading tonel-based projects

by Gabriel Cotelli

Yes, that failure it's the same I reported in https://github.com/pharo-vcs/ iceberg/issues/643. On Wed, Apr 18, 2018 at 1:48 PM, Damien Pollet < damien.pollet+pharo(a)gmail.com> wrote: > I can confirm coverage is back. I think the drop is at least partly due to > the changes I did while it was broken. > > However the Pharo 7 builds seem to be broken now, with what looks like a > libgit issueâ¦ https://travis-ci.org/cdlm/clap-st > > On 18 April 2018 at 13:24, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > >> Hi, >> We managed to implement the coveralls support for Tonel based repos, and >> fixed the problem loading dependencies in Tonel format (by enabling the >> Iceberg-Metacello integration). >> >> So feel free to test it and report any problem detected (it's now merged >> in smalltalkCI/master). >> >> By now the only open issue we known is: https://github.com/pharo-vcs/i >> ceberg/issues/643. >> >> Regards, >> Gabriel >> >> >> On Sat, Apr 7, 2018 at 6:28 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >>> Hi, >>> >>> SmalltalkCI now supports loading tonel-based projects, so feel free to >>> start using it. >>> >>> The configuration is still the same. >>> >>> Please note that coveralls support for tonel is not yet in place, but >>> that's just a cherry on top. :-) >>> >>> Cheers, >>> Peter >>> >> >> >

April 18, 2018

Re: [Pharo-dev] [Pharo-users] SmalltalkCI now supports loading tonel-based projects

by Damien Pollet

I can confirm coverage is back. I think the drop is at least partly due to the changes I did while it was broken. However the Pharo 7 builds seem to be broken now, with what looks like a libgit issueâ¦ https://travis-ci.org/cdlm/clap-st On 18 April 2018 at 13:24, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > Hi, > We managed to implement the coveralls support for Tonel based repos, and > fixed the problem loading dependencies in Tonel format (by enabling the > Iceberg-Metacello integration). > > So feel free to test it and report any problem detected (it's now merged > in smalltalkCI/master). > > By now the only open issue we known is: https://github.com/pharo-vcs/ > iceberg/issues/643. > > Regards, > Gabriel > > > On Sat, Apr 7, 2018 at 6:28 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >> Hi, >> >> SmalltalkCI now supports loading tonel-based projects, so feel free to >> start using it. >> >> The configuration is still the same. >> >> Please note that coveralls support for tonel is not yet in place, but >> that's just a cherry on top. :-) >> >> Cheers, >> Peter >> > >

April 18, 2018

[Pharo 7.0-dev] Build #780: 21725-Class-builder-does-not-take-into-account-slot-definition-changes

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

There is a new Pharo build available! The status of the build #780 was: SUCCESS. The Pull Request #1213 was integrated: "21725-Class-builder-does-not-take-into-account-slot-definition-changes" Pull request url: https://github.com/pharo-project/pharo/pull/1213 Issue Url: https://pharo.fogbugz.com/f/cases/21725 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 18, 2018

Re: [Pharo-dev] Fun with AST evaluation

by Marcus Denker

> On 17 Apr 2018, at 17:45, 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? > I have committed the code (with tests) here: https://github.com/pharo-project/pharo/pull/1214 <https://github.com/pharo-project/pharo/pull/1214> Marcus

April 18, 2018

[Pharo 7.0-dev] Build #779: 21711-Monticello-does-not-have-support-for-traits-with-slots

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

There is a new Pharo build available! The status of the build #779 was: SUCCESS. The Pull Request #1208 was integrated: "21711-Monticello-does-not-have-support-for-traits-with-slots" Pull request url: https://github.com/pharo-project/pharo/pull/1208 Issue Url: https://pharo.fogbugz.com/f/cases/21711 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 18, 2018

Re: [Pharo-dev] [Pharo-users] SmalltalkCI now supports loading tonel-based projects

by Gabriel Cotelli

Hi, We managed to implement the coveralls support for Tonel based repos, and fixed the problem loading dependencies in Tonel format (by enabling the Iceberg-Metacello integration). So feel free to test it and report any problem detected (it's now merged in smalltalkCI/master). By now the only open issue we known is: https://github.com/pharo-vcs/iceberg/issues/643. Regards, Gabriel On Sat, Apr 7, 2018 at 6:28 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Hi, > > SmalltalkCI now supports loading tonel-based projects, so feel free to > start using it. > > The configuration is still the same. > > Please note that coveralls support for tonel is not yet in place, but > that's just a cherry on top. :-) > > Cheers, > Peter >

April 18, 2018

[Pharo 7.0-dev] Build #778: 21727-move-sendNodes-to-RBProgramNode-implement-send-selfMessages-and-superMessages-like-on-CM-the-just-call-it-there

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

There is a new Pharo build available! The status of the build #778 was: FAILURE. The Pull Request #1215 was integrated: "21727-move-sendNodes-to-RBProgramNode-implement-send-selfMessages-and-superMessages-like-on-CM-the-just-call-it-there" Pull request url: https://github.com/pharo-project/pharo/pull/1215 Issue Url: https://pharo.fogbugz.com/f/cases/21727 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 18, 2018

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