February 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] OneClick for 2.0 available again

by H. Hirzel

On 2/8/13, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > We have again a one-click for 2.0: > > https://ci.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/artifact/Pharo2… > > This right now uses the same VM that we use to run the tests on the build > server (NBCog from November). > (Later we need to use the latest verified build from the server > automatically) > > Marcus > thank you very much indeed, Marcus. --Hannes

Feb. 9, 2013

Re: [Pharo-project] OneClick for 2.0 available again

by Marcus Denker

On Feb 9, 2013, at 5:11 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Marcus Denker-4 wrote >> >> https://ci.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/artifact/Pharo2… > > What if we set up the files.pharo.org link for this, and just change it to > point to the static file server when it's ready. This way we won't have to > keep changing it, and Jenkins will get a rest soon... > > I tried to do this (it is configured to upload the file to gforge), but somehow Jenkins does not want to do it. Marcus

Feb. 9, 2013

Re: [Pharo-project] Soup works in 2.0

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote > I would consider > > Soup class>>fromUrl: urlObject > urlObject asUrl retrieveContents. This looks good, but if the user has a ZnUrl, it DNU #asUrl... otherwise, it will work for strings and Url objects. -- View this message in context: http://forum.world.st/Soup-works-in-2-0-tp4665907p4668801.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 9, 2013

Re: [Pharo-project] OneClick for 2.0 available again

by Sean P. DeNigris

Marcus Denker-4 wrote > > https://ci.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/artifact/Pharo2… What if we set up the files.pharo.org link for this, and just change it to point to the static file server when it's ready. This way we won't have to keep changing it, and Jenkins will get a rest soon... -- View this message in context: http://forum.world.st/OneClick-for-2-0-available-again-tp4668502p4668800.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 9, 2013

Re: [Pharo-project] New Issue Tracker

by Sean P. DeNigris

Benjamin Van Ryseghem-2 wrote > I think we can all say a big thank you :) Yes, thank you for this amazing gift :) -- View this message in context: http://forum.world.st/New-Issue-Tracker-tp4668700p4668799.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 9, 2013

Re: [Pharo-project] [update 2.0] #20529

by Sean P. DeNigris

Marcus Denker-4 wrote > Issue 7269: Code Critic automatically adds class without permission > http://code.google.com/p/pharo/issues/detail?id=7269 > > Issue 7238: LazyListMorph>>selectionFrameForRow: fails with a should not > happen from Rectangle>>intersect:ifNone: > http://code.google.com/p/pharo/issues/detail?id=7238 Two nasty ones, nice!! -- View this message in context: http://forum.world.st/update-2-0-20529-tp4668611p4668797.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 9, 2013

Re: [Pharo-project] New Issue Tracker

by Marcus Denker

On Fri, Feb 8, 2013 at 11:49 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > > Well, obviously Squeak is a rather smaller community, so that's hardly > surprising. > What is cause and what is effect? -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

Feb. 9, 2013

Re: [Pharo-project] New Issue Tracker

by Craig Latta

Hi-- Eliot writes: > That's not a valid comparison. In Squeak trunk bugs are getting > fixed at a much higher rate Marcus responds: > Are you sure? The list that Craig showed at Fosdem was rather short. Hey, I only showed the usual short list of highlights from the Squeak 4.4 welcome windows, and clearly identified it as such. -C -- Craig Latta www.netjam.org/resume +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

Feb. 9, 2013

Re: [Pharo-project] New Issue Tracker

by Eliot Miranda

Hi Ben, please include the squeak list in this discussion It's clearly relevant to the whole community. On Fri, Feb 8, 2013 at 4:12 PM, Benjamin < benjamin.vanryseghem.pharo(a)gmail.com> wrote: > > On Feb 9, 2013, at 1:06 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Fri, Feb 8, 2013 at 3:10 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > >> >> On Feb 9, 2013, at 12:01 AM, Frank Shearar <frank.shearar(a)gmail.com> >> wrote: >> >> > On 8 February 2013 22:51, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >> >> On Feb 8, 2013, at 11:49 PM, Frank Shearar <frank.shearar(a)gmail.com> >> wrote: >> >> >> >>> On 8 February 2013 22:41, Marcus Denker <marcus.denker(a)inria.fr> >> wrote: >> >>>> >> >>>> On Feb 8, 2013, at 11:34 PM, Camillo Bruni <camillobruni(a)gmail.com> >> wrote: >> >>>> >> >>>>>>> >> >>>>>> >> >>>>>> That's not a valid comparison. In Squeak trunk bugs are getting >> fixed at a >> >>>>>> much higher rate >> >>>> >> >>>> Are you sure? The list that Craig showed at Fosdem was rather short. >> >>> >> >>> Well, obviously Squeak is a rather smaller community, so that's hardly >> >>> surprising. >> >>> >> >>> Squeakers _do_ need to use bugs.squeak.org, but as I'm sure you know >> >>> from getting Pharo going, this is partly a matter of education. >> >>> >> >> >> >> It is a matter of someone doing it. >> > >> > ... and convincing people to do it is called education. Note my use of >> > the word "partly". Anyway, I'm not sure why you're getting stuck into >> > this. You sound annoyed. >> >> I will always be annoyed about that topicâ¦ ;-) >> > > Quite right too. The issue for me is that the bug trackers are not > well-enough integrated into my Squeak work flow. Montivcello is > beautifully integrated into the work flow and hence a joy to use. I'm not > proposing reinventing the wheel and writing a Squeak/Pharo bug tracker > (although we did that at ParcPlace/ObjectShare/Cincom and the results were > excellent). But at the same time I don't want to go to an external web > page to read bugs (althoguh I'm willing to) and I *definitely* don't want > to go there to update fixes. I want to update fixes from my Monticello > check-in and/or TestRunner. > > I wonder whether it is feasible to provide a skin to an existing, popular > bug tracker so that at least one can have the updating/closing side of the > work-flow brought much closer to Monticello check-in/TestRunner? > > Wouldn't the ideal work-flow be built around an interface between > TestRunner and a bug tracker? If we built such an interface wouldn't there > be much greater use? Imagine being able to have one-click (plus filling in > a description in a submit dialogue) bug creation from TestRunner? And e.g. > using pragmas or some-such, add the state and history, or simply the > pointer to the bug tracker page, embedded in the test case? Then one could > read, in-image, the state of the bug long after it was fixed, in the > context of the test that demonstrated the bug and its fix. > > > That's exactly why Camillo and I spent so much time implementing a Google > Issue Tracker API in Smalltalk :) > And why we are looking for an alternative solution providing a scriptable > API > So two questions. a) What are the candidates? b) how much effort do you think it would be, compared to the interface you've already built, implementing a bug tracker with a scriptable interface? It is essentially an evolveable DB schema plus some triggers to send emails, right? > Ben > > > > >> >> Marcus >> > > > > -- > best, > Eliot > > > -- best, Eliot

Feb. 9, 2013

Re: [Pharo-project] New Issue Tracker

by Benjamin

On Feb 9, 2013, at 1:06 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Fri, Feb 8, 2013 at 3:10 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Feb 9, 2013, at 12:01 AM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > > > On 8 February 2013 22:51, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> > >> On Feb 8, 2013, at 11:49 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > >> > >>> On 8 February 2013 22:41, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >>>> > >>>> On Feb 8, 2013, at 11:34 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >>>> > >>>>>>> > >>>>>> > >>>>>> That's not a valid comparison. In Squeak trunk bugs are getting fixed at a > >>>>>> much higher rate > >>>> > >>>> Are you sure? The list that Craig showed at Fosdem was rather short. > >>> > >>> Well, obviously Squeak is a rather smaller community, so that's hardly > >>> surprising. > >>> > >>> Squeakers _do_ need to use bugs.squeak.org, but as I'm sure you know > >>> from getting Pharo going, this is partly a matter of education. > >>> > >> > >> It is a matter of someone doing it. > > > > ... and convincing people to do it is called education. Note my use of > > the word "partly". Anyway, I'm not sure why you're getting stuck into > > this. You sound annoyed. > > I will always be annoyed about that topicâ¦ ;-) > > Quite right too. The issue for me is that the bug trackers are not well-enough integrated into my Squeak work flow. Montivcello is beautifully integrated into the work flow and hence a joy to use. I'm not proposing reinventing the wheel and writing a Squeak/Pharo bug tracker (although we did that at ParcPlace/ObjectShare/Cincom and the results were excellent). But at the same time I don't want to go to an external web page to read bugs (althoguh I'm willing to) and I *definitely* don't want to go there to update fixes. I want to update fixes from my Monticello check-in and/or TestRunner. > > I wonder whether it is feasible to provide a skin to an existing, popular bug tracker so that at least one can have the updating/closing side of the work-flow brought much closer to Monticello check-in/TestRunner? > > Wouldn't the ideal work-flow be built around an interface between TestRunner and a bug tracker? If we built such an interface wouldn't there be much greater use? Imagine being able to have one-click (plus filling in a description in a submit dialogue) bug creation from TestRunner? And e.g. using pragmas or some-such, add the state and history, or simply the pointer to the bug tracker page, embedded in the test case? Then one could read, in-image, the state of the bug long after it was fixed, in the context of the test that demonstrated the bug and its fix. That's exactly why Camillo and I spent so much time implementing a Google Issue Tracker API in Smalltalk :) And why we are looking for an alternative solution providing a scriptable API Ben > > > > Marcus > > > > -- > best, > Eliot

Feb. 9, 2013