- Pharo-dev - lists.pharo.org

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=win/… 12 regressions found. CompilerTests.ClosureCompilerTest.testBlockNumbering CompilerTests.ClosureCompilerTest.testBlockNumberingForInjectInto CompilerTests.ClosureCompilerTest.testSourceRangeAccessForClosureBytecodeInjectInto CompilerTests.ClosureCompilerTest.testSourceRangeAccessForClosureLongFormBytecodeInjectInto CompilerTests.ClosureCompilerTest.testSourceRangeAccessForInjectInto CompilerTests.CompilerEvaluationTest.testEvaluationOfSelfSend CompilerTests.MethodHighlightingTests.testMethodHighlighting KernelTests.Methods.MethodContextTest.testSetUp NECompletion.Tests.NECInstVarTypeGuesserTest.testMessageSend NECompletion.Tests.NECInstVarTypeGuesserTest.testTypeSuggestingParameter Refactoring.Tests.Core.RBPushDownInstanceVariableTest.testPushDownInstanceVariable Refactoring.Tests.Core.RBPushDownInstanceVariableTest.testModelRemoveUnusedVariable

Aug. 28, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=mac/… 12 regressions found. CompilerTests.ClosureCompilerTest.testBlockNumbering CompilerTests.ClosureCompilerTest.testBlockNumberingForInjectInto CompilerTests.ClosureCompilerTest.testSourceRangeAccessForClosureBytecodeInjectInto CompilerTests.ClosureCompilerTest.testSourceRangeAccessForClosureLongFormBytecodeInjectInto CompilerTests.ClosureCompilerTest.testSourceRangeAccessForInjectInto CompilerTests.CompilerEvaluationTest.testEvaluationOfSelfSend CompilerTests.MethodHighlightingTests.testMethodHighlighting KernelTests.Methods.MethodContextTest.testSetUp NECompletion.Tests.NECInstVarTypeGuesserTest.testMessageSend NECompletion.Tests.NECInstVarTypeGuesserTest.testTypeSuggestingParameter Refactoring.Tests.Core.RBPushDownInstanceVariableTest.testPushDownInstanceVariable Refactoring.Tests.Core.RBPushDownInstanceVariableTest.testModelRemoveUnusedVariable

Aug. 28, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=linu… 12 regressions found. CompilerTests.ClosureCompilerTest.testBlockNumbering CompilerTests.ClosureCompilerTest.testBlockNumberingForInjectInto CompilerTests.ClosureCompilerTest.testSourceRangeAccessForClosureBytecodeInjectInto CompilerTests.ClosureCompilerTest.testSourceRangeAccessForClosureLongFormBytecodeInjectInto CompilerTests.ClosureCompilerTest.testSourceRangeAccessForInjectInto CompilerTests.CompilerEvaluationTest.testEvaluationOfSelfSend CompilerTests.MethodHighlightingTests.testMethodHighlighting KernelTests.Methods.MethodContextTest.testSetUp NECompletion.Tests.NECInstVarTypeGuesserTest.testMessageSend NECompletion.Tests.NECInstVarTypeGuesserTest.testTypeSuggestingParameter Refactoring.Tests.Core.RBPushDownInstanceVariableTest.testPushDownInstanceVariable Refactoring.Tests.Core.RBPushDownInstanceVariableTest.testModelRemoveUnusedVariable

Aug. 28, 2013

Re: [Pharo-dev] Recent VM for Pharo 2 on Ubuntu 8.04

by Sven Van Caekenberghe

On 28 Aug 2013, at 14:03, Igor Stasenko <siguctua(a)gmail.com> wrote: > There is another option (or call it workaround, if you like): > Just find a years old VM which works on your years old platform and be happy.. > (but don't expect , of course, that latest Pharo image will be compatible with it) Hmm, that is not really true: recent images have certain requirements (native boost, file/time primitives, â¦) - catch 22 > On 28 August 2013 13:29, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > On 28/08/13 11:58, Esteban Lorenzano wrote: > well... real solution is to compile your own VM. > > Really? Then why do you at all offer VMs to download if people are > requested to compile at their own? :-) What would you say if you would > have to compile JVM on every system you use just because the pre-built > binaries are compiled against most recent libs? This maybe works in > academia but not in real world. Sorry, I don't take it. > That's not 'a real solution', this is merely a workaround. > > > > we can offer support (but should be pretty straight forward, specially in linux systems). > > I disagree with the solution proposed in (2), the cost of maintaining such approach would be exponential. > > No, not really. There aren't many of those (at least, weren't in my case) and I found out that sometimes I could do better (faster) job :-) > > Alternatively, you can just compile on old-enough system and hope that it will work. > > If you have another solution to this particular problem, please > share. I would love to know it! > > Anyway, that's what I did and what helped in my case. That's all I'd > like to say. > > > Best, Jan > > > > Esteban > > On Aug 28, 2013, at 12:41 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > > Hi, > > we had similar problems. After a bit of a research, I concluded that > there are basically two options for this sort of GLIBC a problem: > > 1) Workaround: recompile the VM on the target system, i.e., on > Ubuntu 8.04 > > 2) Solution: find symbols that introduces that dependency and then > simply not use them in the VM code. This means that you may have > to provide your own implementation of certain C functions > (memset, stat, things like that) > > To do so, nm and objdump is your friend. > > If I were you, I would go for a workaround. > > Best, Jan > > > On 28/08/13 11:25, Sven Van Caekenberghe wrote: > Hi, > > I asked this question before > > http://forum.world.st/Pharo-dev-Latest-vm-on-Ubuntu-8-04-4-LTS-tt4689467.ht… > > and yes I know that Ubuntu 8.04 is old, but I am really stuck. > > I need to deploy a Pharo #20619 image and I need a VM that works on Ubuntu 8.04 _and_ that is not 'too old' (like Eliot's most recent CogVM where I am getting lots of NB errors as well). > > The problem seems to be the dependency on the glibc 2.11. > > Has anyone successfully solved this issue ? > > Thx, > > Sven > > > > > > > > > > > > -- > Best regards, > Igor Stasenko.

Aug. 28, 2013

[update 3.0] #30353

by Marcus Denker

Aug. 28, 2013

Re: [Pharo-dev] Recent VM for Pharo 2 on Ubuntu 8.04

by Jan Vrany

On 28/08/13 12:54, Esteban Lorenzano wrote: > for older systems, you are by your own. Is like that, yes. > > We cannot maintain all VM for all possible configurations. Nobody can do that, not even canonical, less us. Ubuntu 8.04 is just too old. > > Even JVM is not supported on Ubuntu 8.04: http://www.oracle.com/technetwork/java/javase/config-417990.html > (latest is 10.04... which we support, or intent to at least) > Also... we are not oracle, we have more limited resources. > > So , is not a workaround. Is the only reasonable solution: every software provider in earth supports a limited amount of system configurations, usually from some years ago, we provide at least the sources, instructions and support in the form of help/answering questions. > This is not the only instance of the problem. If I'm not much mistaken, same problem has been recently reported for Debian 7 (Laszlo Zsolt KIss, 08/08/13 10:43). As Andres pointed out (08/08/13 14:40), it's libc is 17 months old. The proposed "solution" was the same - recompile on target system. To make me clear, I have no problem if you say "Sorry, we don't support anything older than 12 months. Or 3 years. Or ...". I just don't think that asking people to recompile whenever there is glibc dependency problem is "real solution". I'm very sorry for starting this pointless discussion. > >> >>> we can offer support (but should be pretty straight forward, specially in linux systems). >>> >>> I disagree with the solution proposed in (2), the cost of maintaining such approach would be exponential. >> >> No, not really. There aren't many of those (at least, weren't in my case) and I found out that sometimes I could do better (faster) job :-) > > you are invited to provide your working version, it would be cool for everybody :) > Unfortunately, I've done it for a different VM :-) Best, Jan

Aug. 28, 2013

Re: [Pharo-dev] Recent VM for Pharo 2 on Ubuntu 8.04

by Igor Stasenko

There is another option (or call it workaround, if you like): Just find a years old VM which works on your years old platform and be happy.. (but don't expect , of course, that latest Pharo image will be compatible with it) On 28 August 2013 13:29, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > On 28/08/13 11:58, Esteban Lorenzano wrote: > >> well... real solution is to compile your own VM. >> > > Really? Then why do you at all offer VMs to download if people are > requested to compile at their own? :-) What would you say if you would > have to compile JVM on every system you use just because the pre-built > binaries are compiled against most recent libs? This maybe works in > academia but not in real world. Sorry, I don't take it. > That's not 'a real solution', this is merely a workaround. > > > > we can offer support (but should be pretty straight forward, specially in >> linux systems). >> >> I disagree with the solution proposed in (2), the cost of maintaining >> such approach would be exponential. >> > > No, not really. There aren't many of those (at least, weren't in my case) > and I found out that sometimes I could do better (faster) job :-) > > Alternatively, you can just compile on old-enough system and hope that it > will work. > > If you have another solution to this particular problem, please > share. I would love to know it! > > Anyway, that's what I did and what helped in my case. That's all I'd > like to say. > > > Best, Jan > > > >> Esteban >> >> On Aug 28, 2013, at 12:41 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: >> >> Hi, >>> >>> we had similar problems. After a bit of a research, I concluded that >>> there are basically two options for this sort of GLIBC a problem: >>> >>> 1) Workaround: recompile the VM on the target system, i.e., on >>> Ubuntu 8.04 >>> >>> 2) Solution: find symbols that introduces that dependency and then >>> simply not use them in the VM code. This means that you may have >>> to provide your own implementation of certain C functions >>> (memset, stat, things like that) >>> >>> To do so, nm and objdump is your friend. >>> >>> If I were you, I would go for a workaround. >>> >>> Best, Jan >>> >>> >>> On 28/08/13 11:25, Sven Van Caekenberghe wrote: >>> >>>> Hi, >>>> >>>> I asked this question before >>>> >>>> http://forum.world.st/Pharo-**dev-Latest-vm-on-Ubuntu-8-04-** >>>> 4-LTS-tt4689467.html<http://forum.world.st/Pharo-dev-Latest-vm-on-Ubuntu-8-04-4-LTS-tt4689467.ht…> >>>> >>>> and yes I know that Ubuntu 8.04 is old, but I am really stuck. >>>> >>>> I need to deploy a Pharo #20619 image and I need a VM that works on >>>> Ubuntu 8.04 _and_ that is not 'too old' (like Eliot's most recent CogVM >>>> where I am getting lots of NB errors as well). >>>> >>>> The problem seems to be the dependency on the glibc 2.11. >>>> >>>> Has anyone successfully solved this issue ? >>>> >>>> Thx, >>>> >>>> Sven >>>> >>>> >>> >>> >> >> >> > > -- Best regards, Igor Stasenko.

Aug. 28, 2013

Re: [Pharo-dev] Recent VM for Pharo 2 on Ubuntu 8.04

by Esteban Lorenzano

for older systems, you are by your own. Is like that, yes. We cannot maintain all VM for all possible configurations. Nobody can do that, not even canonical, less us. Ubuntu 8.04 is just too old. Even JVM is not supported on Ubuntu 8.04: http://www.oracle.com/technetwork/java/javase/config-417990.html (latest is 10.04... which we support, or intent to at least) Also... we are not oracle, we have more limited resources. So , is not a workaround. Is the only reasonable solution: every software provider in earth supports a limited amount of system configurations, usually from some years ago, we provide at least the sources, instructions and support in the form of help/answering questions. On Aug 28, 2013, at 1:29 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > On 28/08/13 11:58, Esteban Lorenzano wrote: >> well... real solution is to compile your own VM. > > Really? Then why do you at all offer VMs to download if people are > requested to compile at their own? :-) What would you say if you would > have to compile JVM on every system you use just because the pre-built > binaries are compiled against most recent libs? This maybe works in > academia but not in real world. Sorry, I don't take it. > That's not 'a real solution', this is merely a workaround. > > >> we can offer support (but should be pretty straight forward, specially in linux systems). >> >> I disagree with the solution proposed in (2), the cost of maintaining such approach would be exponential. > > No, not really. There aren't many of those (at least, weren't in my case) and I found out that sometimes I could do better (faster) job :-) you are invited to provide your working version, it would be cool for everybody :) > > Alternatively, you can just compile on old-enough system and hope that it will work. > > If you have another solution to this particular problem, please > share. I would love to know it! > > Anyway, that's what I did and what helped in my case. That's all I'd > like to say. > > > Best, Jan > >> >> Esteban >> >> On Aug 28, 2013, at 12:41 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: >> >>> Hi, >>> >>> we had similar problems. After a bit of a research, I concluded that >>> there are basically two options for this sort of GLIBC a problem: >>> >>> 1) Workaround: recompile the VM on the target system, i.e., on >>> Ubuntu 8.04 >>> >>> 2) Solution: find symbols that introduces that dependency and then >>> simply not use them in the VM code. This means that you may have >>> to provide your own implementation of certain C functions >>> (memset, stat, things like that) >>> >>> To do so, nm and objdump is your friend. >>> >>> If I were you, I would go for a workaround. >>> >>> Best, Jan >>> >>> >>> On 28/08/13 11:25, Sven Van Caekenberghe wrote: >>>> Hi, >>>> >>>> I asked this question before >>>> >>>> http://forum.world.st/Pharo-dev-Latest-vm-on-Ubuntu-8-04-4-LTS-tt4689467.ht… >>>> >>>> and yes I know that Ubuntu 8.04 is old, but I am really stuck. >>>> >>>> I need to deploy a Pharo #20619 image and I need a VM that works on Ubuntu 8.04 _and_ that is not 'too old' (like Eliot's most recent CogVM where I am getting lots of NB errors as well). >>>> >>>> The problem seems to be the dependency on the glibc 2.11. >>>> >>>> Has anyone successfully solved this issue ? >>>> >>>> Thx, >>>> >>>> Sven >>>> >>> >>> >> >> >> > >

Aug. 28, 2013

[update 3.0] #30352

by Marcus Denker

Aug. 28, 2013

Re: [Pharo-dev] Issue 3015: When a test is restarted in the debugger, #tearDown and #setUp and not send

by otto

Hi, I just ran into an unexpected result because of this change, using pharo 1.4. Not sure if this has changed in pharo 2 / 3. I was debugging a test method which failed an assertion inside a block in the test method. When I restarted in the debugger, the execution restarted the block (and not the test method). To my suprise, all the changes that the test method did was gone, and I discovered this code. I know that this may be useful to some people, but I think this is an ugly hack and should be taken out. Where ever I restart a method (whether in a test or not), I don't expect some resetting of the environment / state to the execution point where I'm going. Everybody should be aware that when restarting a method or a block in the debugger, you will have side effects up to the restart that you cannot simply revert. To restart a method (or a block!!) in a debugger is a goto. I know that. Here's an example of what failed: testSomething self doSomething. User someone whileLoggedInDo: [ self assert: false ] When the debugger pops up on the failed assert in the block, and I restart, execution jumps to the beginning of the block (as expected). The unexpected bit was when the test tearDown & setUp was run (of course without calling doSomething. What do you think? Cheers Otto -- View this message in context: http://forum.world.st/Issue-3015-When-a-test-is-restarted-in-the-debugger-t… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 28, 2013