- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] #literals in RBSmalllintContext

by Camille Teruel

On 2 sept. 2014, at 16:21, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi, does anybody know what #literals in RBSmalllintContext stand for? Because itâs calculated in a very weird way with the use of literalSemaphore and literalProcess variables. No, it's weird indeed. Apparently it stores all symbols and bindings founds in the literal arrays of all methods in the system... A kind of cache maybe, but only used by two methods #uses: and #isAbstract (no senders for the latter BTW) > Uko

Sept. 2, 2014

#literals in RBSmalllintContext

by Yuriy Tymchuk

Hi, does anybody know what #literals in RBSmalllintContext stand for? Because itâs calculated in a very weird way with the use of literalSemaphore and literalProcess variables. Uko

Sept. 2, 2014

Re: [Pharo-dev] NeoJSON Mapping name-changing field

by Sven Van Caekenberghe

Sean, On 01 Sep 2014, at 03:29, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > The Flickr API returns a JSON object with two fields: 'status' and > otherField, where the name of otherField depends on the API method. How do I > handle mapping this second field with NeoJSONReader? Thanks If you want all responses to have the same class, then this does indeed mean that you have to handle a dynamic response, which is hard(er). But you say that the structure of the response depends on the API call, that means that you could create a (sub)class per response, no ? I have to admit that I most often just parse into general maps/lists (Dictionary/Array) and deal with those. Creating specific classes just to hold data is so Java style ;-) but it does add more implicit documentation. Sven > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/NeoJSON-Mapping-name-changing-field-tp4775545.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Sept. 2, 2014

Re: [Pharo-dev] Rewrite rules doc?

by Yuriy Tymchuk

Thanks. This is very nice for me: http://st-www.cs.illinois.edu/users/brant/Refactory/Rewrite.html On 02 Sep 2014, at 15:25, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Tue, Sep 2, 2014 at 2:18 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> Hi guys. Is there any doc about rewrite rules besides >> https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSucces… ? > > > http://st-www.cs.illinois.edu/users/brant/Refactory/Lint.html > http://www.lukas-renggli.ch/blog/slime > http://www.lukas-renggli.ch/blog/ob-rb-3 > http://www.lukas-renggli.ch/blog/ignoring-lint-rules > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill >

Sept. 2, 2014

Re: [Pharo-dev] Rewrite rules doc?

by Damien Cassou

On Tue, Sep 2, 2014 at 2:18 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi guys. Is there any doc about rewrite rules besides > https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSucces… ? http://st-www.cs.illinois.edu/users/brant/Refactory/Lint.html http://www.lukas-renggli.ch/blog/slime http://www.lukas-renggli.ch/blog/ob-rb-3 http://www.lukas-renggli.ch/blog/ignoring-lint-rules -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Sept. 2, 2014

Re: [Pharo-dev] Jenkins builds not properly preserving artifacts?

by Tim Mackinnon

Ah - yes, thatâs what I was missing. OK - the information is there (which is good). I will look in to how to document this - but I do wonder if we can do something cheap that makes it a bit easier to see this. Ideally, this information would be in the âChangesâ link for that build. I will have to look at a Java installation and refresh my memory and how things line up for them - my recollection was that if you have the ârightâ files in the right places - it populated things better (but Iâm not sure I ever saw a matrix build setup). It is true that Jenkins is a real beast - but I think I would prefer to spend energy on Pharo vs. contributing to Jenkins ;) Tim On 2 Sep 2014, at 11:53, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 02 Sep 2014, at 11:41, Tim Mackinnon <tim(a)testit.works> wrote: > >> Marcus - how do you navigate to that view from the Build #890 of PharoLauncher? When I click on the link you show - thats that output I first saw in the console from the list of builds for Pharo Launcher (which is what I was looking for) - and when I click on âBack To Projectâ it takes me to the 890 build results page - however if I was looking at build 889 - where on that page do I click to see that output? >> > It is not niceâ¦ > > <Untitled 3.png> > > But something is strange in the setup: it only runs on windows and does not show good names. > > The Pharo build looks better: > > https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-2.1-Validation-A-L/ > > No idea, needs to be configures somehowâ¦ Jenkins is not that âniceâ from the UI as it targets developers who get used to it somehow. > >> I think if I understand that - this would give the information we would expect - and then we can either document this, or maybe put some artefact in every build (via a script) that lets people easily navigate to see what a build was composed off (as it seems that the info is there). >> >> Tim >> >> On that page, >> On 2 Sep 2014, at 09:14, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> The job is a matrix build... the outer job just triggers the matrix builds (see the link "default",), the log is there: >>> >>> https://ci.inria.fr/pharo-contribution/job/PharoLauncher/890/PHARO=30,VERSI… >>> >>> >>> On Tue, Sep 2, 2014 at 12:41 AM, Tim Mackinnon <tim(a)testit.works> wrote: >>> Guys - Iâve noticed that when a build completed on the Inria infrastructure, for a short time the console output correctly shows all the artefacts that were used to create that build - e.g. the slices loaded etc. However after a short time - the output then reverts to something like below (which isnât as useful): >>> >>> Started by upstream project " [8mha:AAAAqh+LCAAAAAAAAP9b85aBtbiIQTGjNKU4P08vOT+vOD8â¦. >>> originally caused by: >>> [URLTrigger] A change within the response URL invocation (log) >>> Building remotely on pharo-contribution-winxp in workspace C:\builds\workspace\PharoLauncher >>> >>> Deleting project workspaceâ¦ done >>> --- >>> >>> Iâve looked at a few other jobs (I noticed this for Pharo Launcher) and they seem the same. I think the jobs arenât configured properly? - As normally (at least in other languages like Java), the intent is that the console output reflects what was on the console when the job was run. I have a hunch that something is overwriting these files before they are archived away. >>> >>> As we donât seem to have other details of what went into a build job (which is another issue - I would expect the changes page for a build to also show this info in a better format). >>> >>> Do you think this could be fixed? >>> >>> tim >>> >>> >>> >>> >>> -- >>> -- >>> Marcus Denker -- denker(a)acm.org >>> http://www.marcusdenker.de >> >

Sept. 2, 2014

Re: [Pharo-dev] Jenkins builds not properly preserving artifacts?

by Christophe Demarey

Le 2 sept. 2014 Ã 12:53, Marcus Denker a Ã©crit : > > On 02 Sep 2014, at 11:41, Tim Mackinnon <tim(a)testit.works> wrote: > >> Marcus - how do you navigate to that view from the Build #890 of PharoLauncher? When I click on the link you show - thats that output I first saw in the console from the list of builds for Pharo Launcher (which is what I was looking for) - and when I click on âBack To Projectâ it takes me to the 890 build results page - however if I was looking at build 889 - where on that page do I click to see that output? >> > It is not niceâ¦ > > <Untitled 3.png> > > But something is strange in the setup: it only runs on windows and does not show good names. > > The Pharo build looks better: > > https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-2.1-Validation-A-L/ > > No idea, needs to be configures somehowâ¦ Jenkins is not that âniceâ from the UI as it targets developers who get used to it somehow. The bad thing is that a matrix job is used instead of a standard job. Jenkins could manage that better but it would have been better to use the appropriate job. There is no reference to a windows build only.

Sept. 2, 2014

Rewrite rules doc?

by Yuriy Tymchuk

Hi guys. Is there any doc about rewrite rules besides https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSucces… ? Uko

Sept. 2, 2014

Re: [Pharo-dev] Jenkins builds not properly preserving artifacts?

by Marcus Denker

On 02 Sep 2014, at 11:41, Tim Mackinnon <tim(a)testit.works> wrote: > Marcus - how do you navigate to that view from the Build #890 of PharoLauncher? When I click on the link you show - thats that output I first saw in the console from the list of builds for Pharo Launcher (which is what I was looking for) - and when I click on âBack To Projectâ it takes me to the 890 build results page - however if I was looking at build 889 - where on that page do I click to see that output? > It is not niceâ¦ But something is strange in the setup: it only runs on windows and does not show good names. The Pharo build looks better: https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-2.1-Validation-A-L/ No idea, needs to be configures somehowâ¦ Jenkins is not that âniceâ from the UI as it targets developers who get used to it somehow. > I think if I understand that - this would give the information we would expect - and then we can either document this, or maybe put some artefact in every build (via a script) that lets people easily navigate to see what a build was composed off (as it seems that the info is there). > > Tim > > On that page, > On 2 Sep 2014, at 09:14, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> The job is a matrix build... the outer job just triggers the matrix builds (see the link "default",), the log is there: >> >> https://ci.inria.fr/pharo-contribution/job/PharoLauncher/890/PHARO=30,VERSI… >> >> >> On Tue, Sep 2, 2014 at 12:41 AM, Tim Mackinnon <tim(a)testit.works> wrote: >> Guys - Iâve noticed that when a build completed on the Inria infrastructure, for a short time the console output correctly shows all the artefacts that were used to create that build - e.g. the slices loaded etc. However after a short time - the output then reverts to something like below (which isnât as useful): >> >> Started by upstream project " [8mha:AAAAqh+LCAAAAAAAAP9b85aBtbiIQTGjNKU4P08vOT+vOD8â¦. >> originally caused by: >> [URLTrigger] A change within the response URL invocation (log) >> Building remotely on pharo-contribution-winxp in workspace C:\builds\workspace\PharoLauncher >> >> Deleting project workspaceâ¦ done >> --- >> >> Iâve looked at a few other jobs (I noticed this for Pharo Launcher) and they seem the same. I think the jobs arenât configured properly? - As normally (at least in other languages like Java), the intent is that the console output reflects what was on the console when the job was run. I have a hunch that something is overwriting these files before they are archived away. >> >> As we donât seem to have other details of what went into a build job (which is another issue - I would expect the changes page for a build to also show this info in a better format). >> >> Do you think this could be fixed? >> >> tim >> >> >> >> >> -- >> -- >> Marcus Denker -- denker(a)acm.org >> http://www.marcusdenker.de >

Sept. 2, 2014

Re: [Pharo-dev] pharo4 ci build queue now has download links on top

by stepharo

good move. On 1/9/14 17:23, Marcus Denker wrote: > Hi, > > I added download links on top of > > https://ci.inria.fr/pharo/ > > (they download from files.pharo.org) > > Marcus > >

Sept. 2, 2014