- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo Project Catalog Should look at Pharo 3

by stepharo

Yes I should change that. I started to change the code to handle multiple repos but I thought that it was a mistake. Now I propose to students to build a real catalog based on ston-based meta data :) but some smart guys should select this great topic :) On 2/9/14 09:47, Sven Van Caekenberghe wrote: > Hi, > > It seems the Pharo Project Catalog CI job looks at Configurations in MetaRepoForPharo2. Would it not be better if it (also) looked at MetaRepoForPharo3/main ? > > Sven >

Sept. 2, 2014

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

by Tim Mackinnon

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? 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

[pharo-project/pharo-core]

by GitHub

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

Sept. 2, 2014

[pharo-project/pharo-core] d45fa4: 40196

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: d45fa418c5b78c474497721b97328f43706c7e4b https://github.com/pharo-project/pharo-core/commit/d45fa418c5b78c474497721b… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-09-02 (Tue, 02 Sep 2014) Changed paths: A OpalCompiler-Core.package/extension/TApplyingOnClassSide/instance/compiler.st A OpalCompiler-Core.package/extension/TApplyingOnClassSide/instance/compilerClass.st A OpalCompiler-Core.package/extension/TClass/instance/classSideCompiler.st A OpalCompiler-Core.package/extension/TClass/instance/classSideCompilerClass.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script196.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40196.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/class/accessing/availableRepositories.st A Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/class/defaults/defaultAvailableRepositories.st M Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/definition.st A Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/instance/actions/addRepository.st M Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/instance/menu/configurationListMenu_.st M Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/instance/private accessing/availableRepositories.st Log Message: ----------- 40196 13941 [FEATURE]: Configuration Browser: Switch to Any Repository https://pharo.fogbugz.com/f/cases/13941 13938 Opal, custom compilers and class side methods https://pharo.fogbugz.com/f/cases/13938 http://files.pharo.org/image/40/40196.zip

Sept. 2, 2014

Re: [Pharo-dev] Pharo Project Catalog Should look at Pharo 3

by Guillermo Polito

Maybe we should have two ci jobs... On Tue, Sep 2, 2014 at 9:47 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > It seems the Pharo Project Catalog CI job looks at Configurations in > MetaRepoForPharo2. Would it not be better if it (also) looked at > MetaRepoForPharo3/main ? > > Sven >

Sept. 2, 2014

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

by Marcus Denker

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 <https://ci.inria.fr/pharo-contribution/job/PharoLauncher/884/triggerCauseAc…>) > Building remotely on pharo-contribution-winxp <https://ci.inria.fr/pharo-contribution/computer/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

Pharo Project Catalog Should look at Pharo 3

by Sven Van Caekenberghe

Hi, It seems the Pharo Project Catalog CI job looks at Configurations in MetaRepoForPharo2. Would it not be better if it (also) looked at MetaRepoForPharo3/main ? Sven

Sept. 2, 2014

Re: [Pharo-dev] [Article] Reddit.st - In 10 Cool Pharo Classes

by Thierry Goubier

Cool! Thanks. Thierry 2014-09-01 23:18 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Hi, > > I published another introduction/tutorial article > > Reddit.st - In 10 Cool Pharo Classes > > Implementing a Reddit style web application in Pharo using Seaside, Glorp > and PostgreSQL > > > https://medium.com/@svenvc/reddit-st-in-10-cool-pharo-classes-1b5327ca0740 > > The focus is not so much on the smaller size or the higher developer > productivity in Pharo, but more on the fact that we can cover so much > ground using such powerful frameworks, as well as the natural development > flow from model over tests and persistence to web GUI. This is a more > intermediate level article that assumes basic knowledge about Pharo > (language and IDE). > > https://ci.inria.fr/pharo-contribution/job/Reddit/ > > http://www.smalltalkhub.com/#!/~SvenVanCaekenberghe/Reddit > > Enjoy! > > Sven > > PS: This article is actually an update of an article that I wrote in 2010 > and that became unavailable/outdated. > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org >

Sept. 2, 2014

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

by Max Leske

On 02.09.2014, at 00:41, 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 > â Not entirely sure but I think thatâs the fingerprint of the specific build that triggered the build youâre looking at. Fingerprints allow builds to reference other builds explicitly and to use artifacts from those builds (if configured correctly). That being said, I agree that the output doesnât help a human reader much... > > 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). That would require either - to write a dedicated log from within the image (which could probably be done with a dedicated package that you could load) or - saving all artifacts (like packages, configurations etc.) in the workspace (taks up a huge amount of space). Iâm not sure that thereâs a simple general solution at this timeâ¦ Cheers, Max > > Do you think this could be fixed? > > tim >

Sept. 2, 2014

Re: [Pharo-dev] Startup Error: SyntaxErrorNotification: Cannot store into

by Alain Rastoul

Le 02/09/2014 06:50, Tudor Girba a Ã©crit : > Moose is not supported yet for Pharo 4. We are still in the process of > releasing it for Pharo 3 and we will move afterwards. If you want to > play with it, it is more advisable to play in Pharo 3. > > Doru Thank you Doru, That's what I thought and that makes sense, however the error is still relevant to the new compiler, I thought it would help Uko. I registered to the moose mailing list but have problems with my email address since few days, don't know wtf is going on. Regards Alain

Sept. 2, 2014