- Pharo-dev - lists.pharo.org

Re: [Pharo-project] CI down?

by Sean P. DeNigris

marcus.denker wrote: > > I send a mail to INRIA support... > It's back up. Thanks. -- View this message in context: http://forum.world.st/CI-down-tp3770259p3771100.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 26, 2011

Re: [Pharo-project] Exceptions with Continuations

by Lukas Renggli

Why don't you just debug the test then? If you have to enable and rerun the test anyway, you can as well tell the test to open a debugger in case of a problem. Isn't this what "MyTest debug: #testMe" does? Lukas On Friday, 26 August 2011, Camillo Bruni <camillo.bruni(a)inria.fr> wrote: > > On 2011-08-26, at 16:28, Lukas Renggli wrote: > > Storing a continuation per failure/error potentially consumes a lot of memory. Memory leaks are also the reason why SUnit doesn't even remeber the exception (which only refer to one or two unwound stack frames). > > point taken. > > Furthermore continuations interfeer with the guarantees of tearDown methods in test-cases and test-resources. This opens a box full of worms: when do you run them, how often do you run them, how do you ensure a consistent state, â¦? > > right, but they might also help debugging annoying nondeterministic edge cases. so I will implement it with an optional setting in the TestRunner. When you find an annoying test that won't run consistently you can rerun it with the continuation being recorded. > > Lukas > > On Friday, 26 August 2011, Camillo Bruni <camillo.bruni(a)inria.fr> wrote: >> >> On 2011-08-26, at 16:02, Frank Shearar wrote: >> >>> On 26 August 2011 14:54, Camillo Bruni <camillo.bruni(a)inria.fr> wrote: >>>> It always bugged me that SUnit has to rerun the tests again when you want to debug them. So I made a little use-case where exceptions have an optional continuation, so you can resume/debug them later on. >>>> >>>> Here's a small example: >>>> >>>> |e| >>>> [ 0 / 0 ] >>>> on: Error >>>> do: [ :error| e := error freeze ]. >>>> e debug >>>> >>>> >>>> freeze simply creates a continuation (at the moment a full one, but that could be of course reduced to a partial one by the TestRunner). Now when you would click on the failing test result you would simply have to activate the corresponding error by sending #debug to it. >>>> >>>> This would have a major advantage for non-deterministic tests (which of course they should not be). Because in this case you're lost with the current SUnit since the debug stack will differ from the actual test-run which produced the error. >>>> >>>> >>>> Needed Changes: >>>> - Continuations (the one from Seaside will just do fine) >>>> - Exception >> #freeze saving the continuation >>>> - TestCase has to store the actual exception >>> >>> Hi Camillo, >>> >>> Indeed, partial continuations would make an excellent addition to >>> SUnit. Levente & I discussed doing do a short while back in >>> squeak-dev. Have you had a look at >>> http://www.squeaksource.com/Control.html by any chance? It implements >>> the shift/reset control operator, which is almost what Seaside uses. >>> >>> frank >> >> No I was unaware of that, having a look at it right now. >> >> thanks >> > > -- > Lukas Renggli > www.lukas-renggli.ch <http://www.lukas-renggli.ch/> > > -- Lukas Renggli www.lukas-renggli.ch

Aug. 26, 2011

Re: [Pharo-project] Exceptions with Continuations

by Camillo Bruni

On 2011-08-26, at 16:28, Lukas Renggli wrote: > Storing a continuation per failure/error potentially consumes a lot of memory. Memory leaks are also the reason why SUnit doesn't even remeber the exception (which only refer to one or two unwound stack frames). point taken. > Furthermore continuations interfeer with the guarantees of tearDown methods in test-cases and test-resources. This opens a box full of worms: when do you run them, how often do you run them, how do you ensure a consistent state, â¦? right, but they might also help debugging annoying nondeterministic edge cases. so I will implement it with an optional setting in the TestRunner. When you find an annoying test that won't run consistently you can rerun it with the continuation being recorded. > Lukas > > On Friday, 26 August 2011, Camillo Bruni <camillo.bruni(a)inria.fr> wrote: > > > > On 2011-08-26, at 16:02, Frank Shearar wrote: > > > >> On 26 August 2011 14:54, Camillo Bruni <camillo.bruni(a)inria.fr> wrote: > >>> It always bugged me that SUnit has to rerun the tests again when you want to debug them. So I made a little use-case where exceptions have an optional continuation, so you can resume/debug them later on. > >>> > >>> Here's a small example: > >>> > >>> |e| > >>> [ 0 / 0 ] > >>> on: Error > >>> do: [ :error| e := error freeze ]. > >>> e debug > >>> > >>> > >>> freeze simply creates a continuation (at the moment a full one, but that could be of course reduced to a partial one by the TestRunner). Now when you would click on the failing test result you would simply have to activate the corresponding error by sending #debug to it. > >>> > >>> This would have a major advantage for non-deterministic tests (which of course they should not be). Because in this case you're lost with the current SUnit since the debug stack will differ from the actual test-run which produced the error. > >>> > >>> > >>> Needed Changes: > >>> - Continuations (the one from Seaside will just do fine) > >>> - Exception >> #freeze saving the continuation > >>> - TestCase has to store the actual exception > >> > >> Hi Camillo, > >> > >> Indeed, partial continuations would make an excellent addition to > >> SUnit. Levente & I discussed doing do a short while back in > >> squeak-dev. Have you had a look at > >> http://www.squeaksource.com/Control.html by any chance? It implements > >> the shift/reset control operator, which is almost what Seaside uses. > >> > >> frank > > > > No I was unaware of that, having a look at it right now. > > > > thanks > > > > -- > Lukas Renggli > www.lukas-renggli.ch

Aug. 26, 2011

Re: [Pharo-project] Exceptions with Continuations

by Lukas Renggli

Storing a continuation per failure/error potentially consumes a lot of memory. Memory leaks are also the reason why SUnit doesn't even remeber the exception (which only refer to one or two unwound stack frames). Furthermore continuations interfeer with the guarantees of tearDown methods in test-cases and test-resources. This opens a box full of worms: when do you run them, how often do you run them, how do you ensure a consistent state, ...? Lukas On Friday, 26 August 2011, Camillo Bruni <camillo.bruni(a)inria.fr> wrote: > > On 2011-08-26, at 16:02, Frank Shearar wrote: > >> On 26 August 2011 14:54, Camillo Bruni <camillo.bruni(a)inria.fr> wrote: >>> It always bugged me that SUnit has to rerun the tests again when you want to debug them. So I made a little use-case where exceptions have an optional continuation, so you can resume/debug them later on. >>> >>> Here's a small example: >>> >>> |e| >>> [ 0 / 0 ] >>> on: Error >>> do: [ :error| e := error freeze ]. >>> e debug >>> >>> >>> freeze simply creates a continuation (at the moment a full one, but that could be of course reduced to a partial one by the TestRunner). Now when you would click on the failing test result you would simply have to activate the corresponding error by sending #debug to it. >>> >>> This would have a major advantage for non-deterministic tests (which of course they should not be). Because in this case you're lost with the current SUnit since the debug stack will differ from the actual test-run which produced the error. >>> >>> >>> Needed Changes: >>> - Continuations (the one from Seaside will just do fine) >>> - Exception >> #freeze saving the continuation >>> - TestCase has to store the actual exception >> >> Hi Camillo, >> >> Indeed, partial continuations would make an excellent addition to >> SUnit. Levente & I discussed doing do a short while back in >> squeak-dev. Have you had a look at >> http://www.squeaksource.com/Control.html by any chance? It implements >> the shift/reset control operator, which is almost what Seaside uses. >> >> frank > > No I was unaware of that, having a look at it right now. > > thanks > -- Lukas Renggli www.lukas-renggli.ch

Aug. 26, 2011

Re: [Pharo-project] Exceptions with Continuations

by Camillo Bruni

On 2011-08-26, at 16:02, Frank Shearar wrote: > On 26 August 2011 14:54, Camillo Bruni <camillo.bruni(a)inria.fr> wrote: >> It always bugged me that SUnit has to rerun the tests again when you want to debug them. So I made a little use-case where exceptions have an optional continuation, so you can resume/debug them later on. >> >> Here's a small example: >> >> |e| >> [ 0 / 0 ] >> on: Error >> do: [ :error| e := error freeze ]. >> e debug >> >> >> freeze simply creates a continuation (at the moment a full one, but that could be of course reduced to a partial one by the TestRunner). Now when you would click on the failing test result you would simply have to activate the corresponding error by sending #debug to it. >> >> This would have a major advantage for non-deterministic tests (which of course they should not be). Because in this case you're lost with the current SUnit since the debug stack will differ from the actual test-run which produced the error. >> >> >> Needed Changes: >> - Continuations (the one from Seaside will just do fine) >> - Exception >> #freeze saving the continuation >> - TestCase has to store the actual exception > > Hi Camillo, > > Indeed, partial continuations would make an excellent addition to > SUnit. Levente & I discussed doing do a short while back in > squeak-dev. Have you had a look at > http://www.squeaksource.com/Control.html by any chance? It implements > the shift/reset control operator, which is almost what Seaside uses. > > frank No I was unaware of that, having a look at it right now. thanks

Aug. 26, 2011

Re: [Pharo-project] Exceptions with Continuations

by Frank Shearar

On 26 August 2011 14:54, Camillo Bruni <camillo.bruni(a)inria.fr> wrote: > It always bugged me that SUnit has to rerun the tests again when you want to debug them. So I made a little use-case where exceptions have an optional continuation, so you can resume/debug them later on. > > Here's a small example: > > |e| > [ 0 / 0 ] > Â Â Â Â on: Error > Â Â Â Â do: [ :error| e := error freeze ]. > e debug > > > freeze simply creates a continuation (at the moment a full one, but that could be of course reduced to a partial one by the TestRunner). Now when you would click on the failing test result you would simply have to activate the corresponding error by sending #debug to it. > > This would have a major advantage for non-deterministic tests (which of course they should not be). Because in this case you're lost with the current SUnit since the debug stack will differ from the actual test-run which produced the error. > > > Needed Changes: > - Continuations (the one from Seaside will just do fine) > - Exception >> #freeze saving the continuation > - TestCase has to store the actual exception Hi Camillo, Indeed, partial continuations would make an excellent addition to SUnit. Levente & I discussed doing do a short while back in squeak-dev. Have you had a look at http://www.squeaksource.com/Control.html by any chance? It implements the shift/reset control operator, which is almost what Seaside uses. frank

Aug. 26, 2011

[Pharo-project] Exceptions with Continuations

by Camillo Bruni

It always bugged me that SUnit has to rerun the tests again when you want to debug them. So I made a little use-case where exceptions have an optional continuation, so you can resume/debug them later on. Here's a small example: |e| [ 0 / 0 ] on: Error do: [ :error| e := error freeze ]. e debug freeze simply creates a continuation (at the moment a full one, but that could be of course reduced to a partial one by the TestRunner). Now when you would click on the failing test result you would simply have to activate the corresponding error by sending #debug to it. This would have a major advantage for non-deterministic tests (which of course they should not be). Because in this case you're lost with the current SUnit since the debug stack will differ from the actual test-run which produced the error. Needed Changes: - Continuations (the one from Seaside will just do fine) - Exception >> #freeze saving the continuation - TestCase has to store the actual exception

Aug. 26, 2011

Re: [Pharo-project] jenkins cog - slow monticello on osx

by Igor Stasenko

On 26 August 2011 13:30, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Since a couple of weeks I am working with the Cog VM built on Jenkins: > https://ci.lille.inria.fr/pharo/view/Cog/job/Cog-Mac-Cocoa/ > > Here is a little feedback. It worked quite well, the only problem is that Monticello is really slow in the Moose image. This means that even opening the Monticello Browser takes several seconds. > > I thought that this might be induced by something in the Moose image, but if I try with the Elliot's VM (2489), it works blazingly fast. > Thanks for the information, Tudor. Apparently the difference between Eliot's VM and Cog-Mac-Cocoa that they are using different frameworks (Carbon vs Cocoa) and i don't know too much details about the difference there. John or Esteban may have better insights how to fix that. > Cheers, > Doru > > > -- > www.tudorgirba.com > > "The coherence of a trip is given by the clearness of the goal." > > > > > > -- Best regards, Igor Stasenko AKA sig.

Aug. 26, 2011

[Pharo-project] jenkins cog - slow monticello on osx

by Tudor Girba

Hi, Since a couple of weeks I am working with the Cog VM built on Jenkins: https://ci.lille.inria.fr/pharo/view/Cog/job/Cog-Mac-Cocoa/ Here is a little feedback. It worked quite well, the only problem is that Monticello is really slow in the Moose image. This means that even opening the Monticello Browser takes several seconds. I thought that this might be induced by something in the Moose image, but if I try with the Elliot's VM (2489), it works blazingly fast. Cheers, Doru -- www.tudorgirba.com "The coherence of a trip is given by the clearness of the goal."

Aug. 26, 2011

Re: [Pharo-project] Addition to "About Pharo" dialog

by GermÃ¡n Arduino

I take a look to SystemReporter, really interesting, it has a lot of information. It's based on ToolBuilder, if I not bad remember of this list, was removed from Pharo. Sorry with the question (I'm not a morphic guy) but exist some guide to convert/migrate/rewrite a UI from ToolBuilder to current UI tools on Pharo? Cheers. 2011/8/26 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > In Squeak alexander lazaverich did a SystemReporter. I wanted to have a look but got distracted. > It would be good to use it. > > Stef > > > On Aug 26, 2011, at 12:36 AM, GermÃ¡n Arduino wrote: > >> Hi Guys: >> >> Is just me that think that is useful to have the VM version at hand >> (may be in the "About Pharo" dialog)? >> >> In my case, using different computers, and having differents vm's is >> so useful and I added a little code to have this info in such Dialog. >> >> If may be of interest I cand send a slice. Let me know. >> >> Cheers. >> >> -- >> ================================================= >> GermÃ¡n S. Arduino Â <gsa @ arsol.net> Â Twitter: garduino >> Arduino Software & Web Hosting Â http://www.arduinosoftware.com >> PasswordsPro Â http://www.passwordspro.com >> ================================================= >> > > > -- ================================================= GermÃ¡n S. ArduinoÂ <gsa @ arsol.net>Â Â Twitter: garduino Arduino Software & Web HostingÂ Â http://www.arduinosoftware.com PasswordsProÂ http://www.passwordspro.com =================================================

Aug. 26, 2011