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

Re: [Pharo-project] [update 3.0] #30042

by Camillo Bruni

:D On 2013-04-16, at 16:22, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 16 April 2013 15:32, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> 30042 >> ----- >> >> 10028 Integrate Opal >> https://pharo.fogbugz.com/f/cases/10028 >> >> (remove destructive tests) >> > > YESSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > > > > > -- > Best regards, > Igor Stasenko. >

April 16, 2013

Re: [Pharo-project] [update 3.0] #30042

by Igor Stasenko

On 16 April 2013 15:32, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > 30042 > ----- > > 10028 Integrate Opal > https://pharo.fogbugz.com/f/cases/10028 > > (remove destructive tests) > YESSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -- Best regards, Igor Stasenko.

April 16, 2013

Re: [Pharo-project] Understanding Athens

by Igor Stasenko

On 16 April 2013 15:52, Tristan Bourgois <tristan.bourgois(a)gmail.com> wrote: > > > > 2013/4/16 kilon <thekilon(a)yahoo.co.uk> >> >> Thats awesome but I cant open my pharo image anymore , I dont mind >> starting >> from a new image and reinstalling everything >> but I was wondering if there is a way to recover all that or am I screwed >> ? >> :) >> > I already have this problem > I open it with CogVM without native boost and kill the morph which use > Athens and save the image. > Reopen it with your Native Boost VM and it's ok! > (I'm not sure that's the best solution but it's work :) > Best solution is to check the session before attempting to access invalid resources :) > Tristan >> >> >> -- >> View this message in context: >> http://forum.world.st/Understanding-Athens-tp4681820p4681909.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > -- Best regards, Igor Stasenko.

April 16, 2013

Re: [Pharo-project] [regression reporter]regression occurred

by Esteban Lorenzano

it is already fixed :) On Apr 16, 2013, at 4:09 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > These was because Destructive regression tests were loaded in the image. Should be fixed soon. > > > 2013/4/16 Goubier Thierry <thierry.goubier(a)cea.fr> > Le 16/04/2013 14:11, Marcus Denker a Ã©crit : > > > On Apr 16, 2013, at 2:08 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > oops... those are a lot of regressions :) > > This should not happen: This means that somehow Opal is taken as the compiler. > (The tests are not compatible between the two, we are going through them one by > one, either porting or fixingâ¦ but it takes while). > > If they fail this mean that the wrong compiler is used when running the tests. > > Who was asking if it wasn't a good idea to use Opal by default ? > > Markus, look, plenty of failed tests to help you progress :) > > Thierry > > > > On Apr 16, 2013, at 2:06 PM, no-reply(a)ci.inria.fr wrote: > > https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=li… > > 71 regressions found. > CompilerTests.ClosureCompilerTest.testBlockDoitDecompilation > CompilerTests.ClosureCompilerTest.testDecompiledDoitMethodTempNames > CompilerTests.ClosureCompilerTest.testSourceRangeAccessForClosureBytecodeInjectInto > CompilerTests.ClosureCompilerTest.testSourceRangeAccessForClosureLongFormBytecodeInjectInto > CompilerTests.ClosureCompilerTest.testSourceRangeAccessForInjectInto > CompilerTests.CompilerExceptionsTest.testAmbiguousSelector > CompilerTests.CompilerExceptionsTest.testUndeclaredVariable > CompilerTests.CompilerExceptionsTest.testUndefinedVariable > CompilerTests.CompilerExceptionsTest.testUnknownSelector > CompilerTests.CompilerExceptionsTest.testUnusedVariable > CompilerTests.CompilerNotifyingTest.testATempShadowingAnotherTemp > CompilerTests.CompilerNotifyingTest.testAlltogether > CompilerTests.CompilerNotifyingTest.testAssignmentOfSelf > CompilerTests.CompilerNotifyingTest.testCascadeInASuperSend > CompilerTests.CompilerNotifyingTest.testDigitTooLargeForARadix > CompilerTests.CompilerNotifyingTest.testEmptyCaseStatement > CompilerTests.CompilerNotifyingTest.testExpectedExpressionInBraceArray > CompilerTests.CompilerNotifyingTest.testExtraneousStatementAfterAReturnInABlock > CompilerTests.CompilerNotifyingTest.testInvalidRadix > CompilerTests.CompilerNotifyingTest.testLiteralCharacterMissing > ... > > > > > > > > > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > > > > > -- > ClÃ©ment BÃ©ra > Mate Virtual Machine Engineer > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq

April 16, 2013

Re: [Pharo-project] Understanding Athens

by Igor Stasenko

On 16 April 2013 15:47, kilon <thekilon(a)yahoo.co.uk> wrote: > Thats awesome but I cant open my pharo image anymore , I dont mind starting > from a new image and reinstalling everything > but I was wondering if there is a way to recover all that or am I screwed ? > :) > You have a talent at screwing things up :) But your feedback is invaluable, which helping to spot details , which obvious to me but not for a newcomer. Yeah, concerning screwed image: in such cases i usually run it with VM which does not includes NativeBoost, then it fails with error.. and you can close morphs/debugger save image and can continue work with Cog VM.. it is , of course not always works, because it depends how badly things screwed up. :) > > > -- > View this message in context: http://forum.world.st/Understanding-Athens-tp4681820p4681909.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

April 16, 2013

Re: [Pharo-project] Metacello configuration conventions

by Stephan Eggermont

Frank wrote: >I'd argue that since you're declaring that a certain set of versions >of packages work together, you should _always_ use explicit versions. >The "optimistic" strategy leaves you vulnerable to third parties >making seemingly innocuous changes that break your code. (I've been >bitten by this, by making such an apparently innocuous change.) Thank you. That's a clear vulnerability of the optimistic strategy. That sounds nice, but also means getting a change rate that is the sum of that of all your dependencies. It is also not very nice when you are depending on things that have known bugs you know will be fixed soon. What does it mean that a certain set of versions work together? Implicit seems the assumption that #Pharo2x is #stable, and we don't talk about the vm version or even worse the non-smalltalk dependencies. I don't see Metacello descriptions specifying all loaded packages. Stephan

April 16, 2013

Re: [Pharo-project] [regression reporter]regression occurred

by ClÃ©ment Bera

These was because Destructive regression tests were loaded in the image. Should be fixed soon. 2013/4/16 Goubier Thierry <thierry.goubier(a)cea.fr> > Le 16/04/2013 14:11, Marcus Denker a Ã©crit : > > >> On Apr 16, 2013, at 2:08 PM, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> >> oops... those are a lot of regressions :) >>> >> >> This should not happen: This means that somehow Opal is taken as the >> compiler. >> (The tests are not compatible between the two, we are going through them >> one by >> one, either porting or fixingâ¦ but it takes while). >> >> If they fail this mean that the wrong compiler is used when running the >> tests. >> > > Who was asking if it wasn't a good idea to use Opal by default ? > > Markus, look, plenty of failed tests to help you progress :) > > Thierry > > > >>> On Apr 16, 2013, at 2:06 PM, no-reply(a)ci.inria.fr wrote: >>> >>> https://ci.inria.fr/pharo/job/**Pharo-3.0-Update-Step-2-** >>>> Validation/./label=linux/58/<https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=li…> >>>> >>>> 71 regressions found. >>>> CompilerTests.**ClosureCompilerTest.**testBlockDoitDecompilation >>>> CompilerTests.**ClosureCompilerTest.**testDecompiledDoitMethodTempNa** >>>> mes >>>> CompilerTests.**ClosureCompilerTest.**testSourceRangeAccessForClosur** >>>> eBytecodeInjectInto >>>> CompilerTests.**ClosureCompilerTest.**testSourceRangeAccessForClosur** >>>> eLongFormBytecodeInjectInto >>>> CompilerTests.**ClosureCompilerTest.**testSourceRangeAccessForInject** >>>> Into >>>> CompilerTests.**CompilerExceptionsTest.**testAmbiguousSelector >>>> CompilerTests.**CompilerExceptionsTest.**testUndeclaredVariable >>>> CompilerTests.**CompilerExceptionsTest.**testUndefinedVariable >>>> CompilerTests.**CompilerExceptionsTest.**testUnknownSelector >>>> CompilerTests.**CompilerExceptionsTest.**testUnusedVariable >>>> CompilerTests.**CompilerNotifyingTest.**testATempShadowingAnotherTemp >>>> CompilerTests.**CompilerNotifyingTest.**testAlltogether >>>> CompilerTests.**CompilerNotifyingTest.**testAssignmentOfSelf >>>> CompilerTests.**CompilerNotifyingTest.**testCascadeInASuperSend >>>> CompilerTests.**CompilerNotifyingTest.**testDigitTooLargeForARadix >>>> CompilerTests.**CompilerNotifyingTest.**testEmptyCaseStatement >>>> CompilerTests.**CompilerNotifyingTest.**testExpectedExpressionInBraceA* >>>> *rray >>>> CompilerTests.**CompilerNotifyingTest.**testExtraneousStatementAfterAR* >>>> *eturnInABlock >>>> CompilerTests.**CompilerNotifyingTest.**testInvalidRadix >>>> CompilerTests.**CompilerNotifyingTest.**testLiteralCharacterMissing >>>> ... >>>> >>>> >>> >>> >> >> >> >> > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > > -- ClÃ©ment BÃ©ra Mate Virtual Machine Engineer BÃ¢timent B 40, avenue Halley 59650 *Villeneuve d'Ascq*

April 16, 2013

Re: [Pharo-project] Understanding Athens

by Esteban Lorenzano

start it with a stackvm, then close the offending window and save, then restart with a regular vm :) Esteban On Apr 16, 2013, at 3:47 PM, kilon <thekilon(a)yahoo.co.uk> wrote: > Thats awesome but I cant open my pharo image anymore , I dont mind starting > from a new image and reinstalling everything > but I was wondering if there is a way to recover all that or am I screwed ? > :) > > > > -- > View this message in context: http://forum.world.st/Understanding-Athens-tp4681820p4681909.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

April 16, 2013

Re: [Pharo-project] Understanding Athens

by Tristan Bourgois

2013/4/16 kilon <thekilon(a)yahoo.co.uk> > Thats awesome but I cant open my pharo image anymore , I dont mind starting > from a new image and reinstalling everything > but I was wondering if there is a way to recover all that or am I screwed ? > :) > > I already have this problem I open it with CogVM without native boost and kill the morph which use Athens and save the image. Reopen it with your Native Boost VM and it's ok! (I'm not sure that's the best solution but it's work :) Tristan > > -- > View this message in context: > http://forum.world.st/Understanding-Athens-tp4681820p4681909.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

April 16, 2013

Re: [Pharo-project] [regression reporter]regression occurred

by Camillo Bruni

aaah I love to see a response to that :P my vicious plan to spam the pharo list when there are new tests failing seems to work :) On 2013-04-16, at 14:11, Marcus Denker <marcus.denker(a)inria.fr> wrote: > On Apr 16, 2013, at 2:08 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> oops... those are a lot of regressions :) > > This should not happen: This means that somehow Opal is taken as the compiler. > (The tests are not compatible between the two, we are going through them one by > one, either porting or fixingâ¦ but it takes while). > > If they fail this mean that the wrong compiler is used when running the tests. > >> >> On Apr 16, 2013, at 2:06 PM, no-reply(a)ci.inria.fr wrote: >> >>> https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=li… >>> >>> 71 regressions found. >>> CompilerTests.ClosureCompilerTest.testBlockDoitDecompilation >>> CompilerTests.ClosureCompilerTest.testDecompiledDoitMethodTempNames >>> CompilerTests.ClosureCompilerTest.testSourceRangeAccessForClosureBytecodeInjectInto >>> CompilerTests.ClosureCompilerTest.testSourceRangeAccessForClosureLongFormBytecodeInjectInto >>> CompilerTests.ClosureCompilerTest.testSourceRangeAccessForInjectInto >>> CompilerTests.CompilerExceptionsTest.testAmbiguousSelector >>> CompilerTests.CompilerExceptionsTest.testUndeclaredVariable >>> CompilerTests.CompilerExceptionsTest.testUndefinedVariable >>> CompilerTests.CompilerExceptionsTest.testUnknownSelector >>> CompilerTests.CompilerExceptionsTest.testUnusedVariable >>> CompilerTests.CompilerNotifyingTest.testATempShadowingAnotherTemp >>> CompilerTests.CompilerNotifyingTest.testAlltogether >>> CompilerTests.CompilerNotifyingTest.testAssignmentOfSelf >>> CompilerTests.CompilerNotifyingTest.testCascadeInASuperSend >>> CompilerTests.CompilerNotifyingTest.testDigitTooLargeForARadix >>> CompilerTests.CompilerNotifyingTest.testEmptyCaseStatement >>> CompilerTests.CompilerNotifyingTest.testExpectedExpressionInBraceArray >>> CompilerTests.CompilerNotifyingTest.testExtraneousStatementAfterAReturnInABlock >>> CompilerTests.CompilerNotifyingTest.testInvalidRadix >>> CompilerTests.CompilerNotifyingTest.testLiteralCharacterMissing >>> ...

April 16, 2013