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

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

by Esteban Lorenzano

On Aug 28, 2013, at 2:19 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > 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. in that moment answer was: compile it yourself until we provide a working version (which we now provide). Ubuntu 8 is another problem :( but do not get me wrong... is not that I do not would want to help... is just that I need to be realistic about what I can and what I don't :( > > 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

Notes for the August iteration

by StÃ©phane Ducasse

Hi guys we got a new meeting and here are the notes Stef

Aug. 28, 2013

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

by Norbert Hartl

Am 28.08.2013 um 14:19 schrieb Jan Vrany <jan.vrany(a)fit.cvut.cz>: > 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. > Indeed, I don't even understand what is your point. You are arguing that offering binaries for download is pointless if it does not support a wide range of systems. So is there even a way to compile a single binary for at least every version of a linux distro over the last couple of ears? I so then name it and there are guys who will be lucky incorporating your strategy. Arguing against the need of compilation is somewhat I cannot understand either. Of course every binary has to be compiled for every different system. The part that does make it work is the distro as a dependency tree of packages and versions. So Damien created this nice launchpad ppa archive that enables compiling the vm for a lot of ubuntus up to 10.04 which is over 3 years old. For everything else you are in bad luck. This community cannot deliver everything someone things is needed to be a mature system. We tried already to add the vm to the debian channels but it wasn't possible. And even then it would only be for debian. So to solve this particular problem you could go to [1], open a project for the pharo-vm and maintain easily the builds for a wide variety of linux systems. Problem solved, everyone is thankful. Complaining doesn't solve anything. Norbert [1] https://build.opensuse.org/ >> >>> >>>> 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

[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

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

by Sven Van Caekenberghe

On 28 Aug 2013, at 12:59, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > https://github.com/pharo-project/pharovm/blob/master/HOWTOBUILD > > and of course, you can ask as many questions as you want :) I will have to reconsider: too many tools are too old (git, cmake, who knows what else). Unless someone else has already done it and can give me an executable, I will have to find another solution and abandon that machine for pharo. > Esteban > > On Aug 28, 2013, at 12:56 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 28 Aug 2013, at 12:40, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >>> If you're in for DIY, you can "simply" compile the current VM under 8.04 and you should be fine. >> >> I've never done that, but it should be doable on Linux I guess. >> Where/how do I start ? >> >>> On 2013-08-28, at 12:25, Sven Van Caekenberghe <sven(a)stfx.eu> 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

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

by Jan Vrany

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

Aug. 28, 2013

Re: [Pharo-dev] a weak on:do:/when:do:

by Tudor Girba

That is what I knew, too. I asked because the mail seemed to suggest that it would work :). Doru On Wed, Aug 28, 2013 at 12:54 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > no, it is not. > that will keep the registry forever because it acts over a block (no > ephemerons, remember) > > Esteban > > On Aug 28, 2013, at 11:56 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Does this work? > > Doru > > > On Wed, Aug 28, 2013 at 11:54 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> whenListChanged: aBlock >> "Specify a block to value after the contents of the list has >> changed" >> >> "Basically when you set a new list of items" >> >> <api: #event> >> | block | >> block := [ :announcement :ann | >> aBlock >> cull: announcement newContents >> cull: announcement oldContents >> cull: announcement >> cull: ann ]. >> listAnnouncer weak >> when: ValueChanged >> do: block >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 28, 2013

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

by Camillo Bruni

On 2013-08-28, at 12:56, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 28 Aug 2013, at 12:40, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> If you're in for DIY, you can "simply" compile the current VM under 8.04 and you should be fine. > > I've never done that, but it should be doable on Linux I guess. > Where/how do I start ? You can check our VM builds https://ci.inria.fr/pharo/view/VM/job/PharoVM/configure basically you will have to run the bash script there an check that all the necessary libs are installed, for which you will find a script here: https://gitorious.org/pharo-build/pharo-build/source/9fe0d031d4b8d45d464c02… I hope that get's you started

Aug. 28, 2013

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

by Esteban Lorenzano

oops, the newImage.sh is most probably outdated :) On Aug 28, 2013, at 12:59 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > https://github.com/pharo-project/pharovm/blob/master/HOWTOBUILD > > and of course, you can ask as many questions as you want :) > > Esteban > > On Aug 28, 2013, at 12:56 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 28 Aug 2013, at 12:40, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >>> If you're in for DIY, you can "simply" compile the current VM under 8.04 and you should be fine. >> >> I've never done that, but it should be doable on Linux I guess. >> Where/how do I start ? >> >>> On 2013-08-28, at 12:25, Sven Van Caekenberghe <sven(a)stfx.eu> 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

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

by Esteban Lorenzano

https://github.com/pharo-project/pharovm/blob/master/HOWTOBUILD and of course, you can ask as many questions as you want :) Esteban On Aug 28, 2013, at 12:56 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 28 Aug 2013, at 12:40, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> If you're in for DIY, you can "simply" compile the current VM under 8.04 and you should be fine. > > I've never done that, but it should be doable on Linux I guess. > Where/how do I start ? > >> On 2013-08-28, at 12:25, Sven Van Caekenberghe <sven(a)stfx.eu> 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

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

by Sven Van Caekenberghe

On 28 Aug 2013, at 12:41, 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. Thanks for the suggestion. I was also thinking if it would be possible to somehow compile a new glibc in a local directory and use it. Was it easy to compile a pharo VM ? > 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

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

by Esteban Lorenzano

well... real solution is to compile your own VM. 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. 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

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

by Sven Van Caekenberghe

On 28 Aug 2013, at 12:40, Camillo Bruni <camillobruni(a)gmail.com> wrote: > If you're in for DIY, you can "simply" compile the current VM under 8.04 and you should be fine. I've never done that, but it should be doable on Linux I guess. Where/how do I start ? > On 2013-08-28, at 12:25, Sven Van Caekenberghe <sven(a)stfx.eu> 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

Re: [Pharo-dev] a weak on:do:/when:do:

by Esteban Lorenzano

no, it is not. that will keep the registry forever because it acts over a block (no ephemerons, remember) Esteban On Aug 28, 2013, at 11:56 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Does this work? > > Doru > > > On Wed, Aug 28, 2013 at 11:54 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > whenListChanged: aBlock > "Specify a block to value after the contents of the list has changed" > > "Basically when you set a new list of items" > > <api: #event> > | block | > block := [ :announcement :ann | > aBlock > cull: announcement newContents > cull: announcement oldContents > cull: announcement > cull: ann ]. > listAnnouncer weak > when: ValueChanged > do: block > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Aug. 28, 2013

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

by Jan Vrany

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

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

by Camillo Bruni

If you're in for DIY, you can "simply" compile the current VM under 8.04 and you should be fine. On 2013-08-28, at 12:25, Sven Van Caekenberghe <sven(a)stfx.eu> 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

Recent VM for Pharo 2 on Ubuntu 8.04

by Sven Van Caekenberghe

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

windows performance

by Camillo Bruni

I just discovered a strange anomaly with the windows build concerning the test performance: If you check the overall speed of the tests, windows is faster than our mac slave https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=mac/… https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=win/… EXCEPT for the trait tests (mac=32s, win=2m9s)! That's a factor 4! whereas otherwise the windows slave is ~20% faster. https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=mac/… https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=win/… I'll investigate during our minisprint today, any hints otherwhise?

Aug. 28, 2013

Re: [Pharo-dev] a weak on:do:/when:do:

by Tudor Girba

Does this work? Doru On Wed, Aug 28, 2013 at 11:54 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > whenListChanged: aBlock > "Specify a block to value after the contents of the list has > changed" > > "Basically when you set a new list of items" > > <api: #event> > | block | > block := [ :announcement :ann | > aBlock > cull: announcement newContents > cull: announcement oldContents > cull: announcement > cull: ann ]. > listAnnouncer weak > when: ValueChanged > do: block > > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 28, 2013

a weak on:do:/when:do:

by StÃ©phane Ducasse

whenListChanged: aBlock "Specify a block to value after the contents of the list has changed" "Basically when you set a new list of items" <api: #event> | block | block := [ :announcement :ann | aBlock cull: announcement newContents cull: announcement oldContents cull: announcement cull: ann ]. listAnnouncer weak when: ValueChanged do: block

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=win/… 5 regressions found. CollectionsTests.Weak.WeakIdentityKeyDictionaryTest.testClearing CollectionsTests.Weak.WeakIdentityKeyDictionaryTest.testNoNils CollectionsTests.Weak.WeakKeyDictionaryTest.testClearing CollectionsTests.Weak.WeakKeyToCollectionDictionaryTest.testClearing CollectionsTests.Weak.WeakKeyToCollectionDictionaryTest.testNoNils

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/… 6 regressions found. CollectionsTests.Weak.WeakIdentityKeyDictionaryTest.testClearing CollectionsTests.Weak.WeakIdentityKeyDictionaryTest.testNoNils CollectionsTests.Weak.WeakKeyDictionaryTest.testClearing CollectionsTests.Weak.WeakKeyToCollectionDictionaryTest.testClearing CollectionsTests.Weak.WeakKeyToCollectionDictionaryTest.testNoNils Zinc.Zodiac.ZnHTTPSTests.testWikimedia

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… 5 regressions found. CollectionsTests.Weak.WeakIdentityKeyDictionaryTest.testClearing CollectionsTests.Weak.WeakIdentityKeyDictionaryTest.testNoNils CollectionsTests.Weak.WeakKeyDictionaryTest.testClearing CollectionsTests.Weak.WeakKeyToCollectionDictionaryTest.testClearing CollectionsTests.Weak.WeakKeyToCollectionDictionaryTest.testNoNils

Aug. 28, 2013

[update 3.0] #30351

by Marcus Denker

30351 ----- 11473 Optimize Dictionary >> #valuesDo: https://pharo.fogbugz.com/f/cases/11473 11422 Support quantifiers in regular expressions https://pharo.fogbugz.com/f/cases/11422 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Regex-Tests-Core-MarcusDenker… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Regex-Core-MarcusDenker.28.di… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Unordered-MarcusD…

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=win/… 1 regressions found. Zinc.Tests.ZnClientTests.testGetGeoIP

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/… 1 regressions found. Zinc.Tests.ZnClientTests.testGetGeoIP

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… 1 regressions found. Zinc.Tests.ZnClientTests.testGetGeoIP

Aug. 28, 2013

[update 3.0] #30350

by Marcus Denker

30350 ----- 11477 RBRepeteadMethodsInTheSuperclassRule Minor Improvement https://pharo.fogbugz.com/f/cases/11477 11472 Optimize MCClassDefinitionTest https://pharo.fogbugz.com/f/cases/11472 11474 Optimize SHParserST80Test https://pharo.fogbugz.com/f/cases/11474 11479 Removing unused temps in source code is broken https://pharo.fogbugz.com/f/cases/11479 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tests-MarcusDenker.617.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/ShoutTests-MarcusDenker.19.di… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Critics-MarcusDen… http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Core-MarcusDenke… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Compiler-MarcusDenker.515.diff

Aug. 28, 2013

Re: [Pharo-dev] Compilation code in grease not compatible with Pharo 3.0

by Damien Cassou

thank you Marcus. Now, this does not work because #printCategoryChunk:on: does not exist anymore: aClass printCategoryChunk: aSymbol asString on: file priorMethod: (aClass compiledMethodAt: selector ifAbsent: [ nil ] On Tue, Aug 27, 2013 at 7:19 PM, Damien Cassou <damien.cassou(a)gmail.com>wrote: > Hi, > > how can I make the following code compile in Pharo 3.0? This is part of > Grease ( > https://ci.inria.fr/pharo-contribution/job/Grease/PHARO=30,VERSION=stable,V… > ): > > GRPharoPlatform>>compile: aString into: aClass classified: aSymbol > "The trick here is to be as silently a possible so that the package is > not marked dirty when running WAFileLibrary test. > This also makes running tests much faster." > | methodNode compiledMethod selector methodAndNode | > methodNode := aClass compilerClass new > compile: aString > in: aClass > notifying: nil > ifFail: [ GRError signal: 'syntax error' ]. > selector := methodNode selector. > methodAndNode := CompiledMethodWithNode > generateMethodFromNode: methodNode > trailer: aClass defaultMethodTrailer. > compiledMethod := methodAndNode method. > compiledMethod > putSource: aString > fromParseNode: methodAndNode node > inFile: 2 > withPreamble: [ :file | > aClass > printCategoryChunk: aSymbol asString > on: file priorMethod: (aClass compiledMethodAt: selector > ifAbsent: [ nil ]). > file cr ]. > aClass > addSelectorSilently: selector > withMethod: compiledMethod. > self doSilently: [ > aClass organization > classify: selector > under: aSymbol ] > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without losing > enthusiasm." > Winston Churchill > -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Aug. 28, 2013

Re: [Pharo-dev] Compilation code in grease not compatible with Pharo 3.0

by Marcus Denker

On Aug 27, 2013, at 9:12 PM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > thank you ClÃ©ment. That's what I came up with. Now, there is always the call to #putSource:fromParseNode:inFile:withPreamble: that is not implemented anymore: The parameter was remove : #putSource:inFile:withPreamble: > On Tue, Aug 27, 2013 at 7:53 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > putSource: aString > fromParseNode: methodNode > > > inFile: 2 > withPreamble: > > > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without losing enthusiasm." > Winston Churchill

Aug. 28, 2013

Re: [Pharo-dev] how can we get a more terse monkey?

by Erwan Douaille

The idea was to write an url on fogbugz. And the repository contains the report. I started to write a class doing it. Never test it due to "the bug" 2013/8/28 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > Beause it is not useful to fill up the bug tracker > > https://pharo.fogbugz.com/default.asp?7444 > > Stef > > -- Best regards, Douaille Erwan <douaille.erwan(a)gmail.com>

Aug. 28, 2013

how can we get a more terse monkey?

by StÃ©phane Ducasse

Beause it is not useful to fill up the bug tracker https://pharo.fogbugz.com/default.asp?7444 Stef

Aug. 28, 2013

Re: [Pharo-dev] Filing in chunks

by StÃ©phane Ducasse

On Aug 28, 2013, at 3:14 AM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > What is the "official" way to file in chunks in Pharo? > > I'm porting something from Dolphin to Pharo 2, with no purpose of having > compatibility between both (it is, I want to continue with it on Pharo). > > I've been manually "translating" the chunk from Dolphin into Pharo format, > but the problem is... I can't find a way to File In the file contents! you can simply drop the file on the world. > Using the File Explorer, there is a contextual menu in the contents pane of > the selected file "FileIn Selection (G)", but as soon as I select some > chunks or the whole contents to file In I get a MessageNotUnderstood of > #fileIn in ReadWriteStream (the selected contents). this is a bug can you open an issue if it is still there in Pharo30 > I couldn't find another menu for filing in in a Workspace (expected), > SystemBrowser (Nautilus) nor anywhere else. I'm doing it with 'myChanges.st' > asFileReference fileIn > > But I was expecting more user friendly, like a chunk browser. No there is no such tools. We are working on a new change browser and may be we will support importing cs but I doubt for now. > Any clues? > > Thanks! > > > > > -- > View this message in context: http://forum.world.st/Filing-in-chunks-tp4705341.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Aug. 28, 2013

Filing in chunks

by Esteban A. Maringolo

What is the "official" way to file in chunks in Pharo? I'm porting something from Dolphin to Pharo 2, with no purpose of having compatibility between both (it is, I want to continue with it on Pharo). I've been manually "translating" the chunk from Dolphin into Pharo format, but the problem is... I can't find a way to File In the file contents! Using the File Explorer, there is a contextual menu in the contents pane of the selected file "FileIn Selection (G)", but as soon as I select some chunks or the whole contents to file In I get a MessageNotUnderstood of #fileIn in ReadWriteStream (the selected contents). I couldn't find another menu for filing in in a Workspace (expected), SystemBrowser (Nautilus) nor anywhere else. I'm doing it with 'myChanges.st' asFileReference fileIn But I was expecting more user friendly, like a chunk browser. Any clues? Thanks! -- View this message in context: http://forum.world.st/Filing-in-chunks-tp4705341.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 28, 2013

[update 3.0] #30349

by StÃ©phane Ducasse

30349 ----- - issue 11316 Add when:send:to: and deprecate on:do: Added more comments and when:do:for: as suggested by Henrik. https://pharo.fogbugz.com/default.asp?11316 - issue 11466 Speed up Refactoring-Tests-Core. Thanks Camillo Bruni. https://pharo.fogbugz.com/default.asp?11466 - issue 5331 MorphThreeModel>>#setPageSize: https://pharo.fogbugz.com/default.asp?5331 - issue 11469 2 small sorting fixes needed https://pharo.fogbugz.com/default.asp?11469 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Tests-Core-Stepha… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-StephaneDucasse.… http://smalltalkhub.com/mc/Pharo/Pharo30/main/CollectionsTests-StephaneDuca… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Strings-StephaneD… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Sequenceable-Step… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Announcements-Core-StephaneDu…

Aug. 27, 2013

Re: [Pharo-dev] Debugger recursion

by Mariano Martinez Peck

If you take a look to Ghost proxies, in the proxy handler I have a dictionary in which users can define exceptions. That means, that the proxy handler will do something different than the expected action (like forwarding the message to another object). By default, I added some helper methods that add some of these exceptions. One of these, where a list of method to proper debug/inspect proxies. And the nice thing of being a dictionary is that you can enable/disable them even on the fly. Cheers, On Tue, Aug 27, 2013 at 5:09 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 24 August 2013 14:18, jan.struz <public+pharo(a)struz.cz> wrote: > >> StÃ©phane Ducasse wrote >> > On Aug 23, 2013, at 7:13 PM, jan.struz < >> >> > public+pharo@ >> >> > > wrote: >> > >> >> Proxy implementation >> > >> > did you have a look at Ghost because mariano spent nearly a year on it. >> > >> > I do not really know what are the messages supposed to be supported by >> > ProtoObject to be debugged >> > May be it is not in the contract of ProtoObject and as such it produces >> > normally an infinite loop. >> > >> > Stef >> >> ok, so the rule is: never subclass ProtoObject to make Debugger crazy.. >> I will definitely look at Ghost, it has already been on my todo list.. >> >> i would say: > - if you subclass from ProtoObject then you are on your own.. don't expect > any standard tools to work anymore (including debugger, of course). > > And no, there is no 'fix' for that.. except from merging ProtoObject with > Object, > which kills the purpose of having ProtoObject class. > > thanks >> >> >> >> >> >> ----- >> Save The World! >> -- >> View this message in context: >> http://forum.world.st/Debugger-recursion-tp4704703p4704864.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> > > > -- > Best regards, > Igor Stasenko. > -- Mariano http://marianopeck.wordpress.com

Aug. 27, 2013

Re: [Pharo-dev] Debugger recursion

by Igor Stasenko

On 24 August 2013 14:18, jan.struz <public+pharo(a)struz.cz> wrote: > StÃ©phane Ducasse wrote > > On Aug 23, 2013, at 7:13 PM, jan.struz < > > > public+pharo@ > > > > wrote: > > > >> Proxy implementation > > > > did you have a look at Ghost because mariano spent nearly a year on it. > > > > I do not really know what are the messages supposed to be supported by > > ProtoObject to be debugged > > May be it is not in the contract of ProtoObject and as such it produces > > normally an infinite loop. > > > > Stef > > ok, so the rule is: never subclass ProtoObject to make Debugger crazy.. > I will definitely look at Ghost, it has already been on my todo list.. > > i would say: - if you subclass from ProtoObject then you are on your own.. don't expect any standard tools to work anymore (including debugger, of course). And no, there is no 'fix' for that.. except from merging ProtoObject with Object, which kills the purpose of having ProtoObject class. thanks > > > > > > ----- > Save The World! > -- > View this message in context: > http://forum.world.st/Debugger-recursion-tp4704703p4704864.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- Best regards, Igor Stasenko.

Aug. 27, 2013

fixing the Browser settings

by StÃ©phane Ducasse

Hi guys I need a good soul that can fix the opening of the setting browser. The TreeMorph got certainly touched and now it garbages a lot. Stef

Aug. 27, 2013

[update 3.0] #30348

by StÃ©phane Ducasse

Aug. 27, 2013

Re: [Pharo-dev] Compilation code in grease not compatible with Pharo 3.0

by Damien Cassou

thank you ClÃ©ment. That's what I came up with. Now, there is always the call to #putSource:fromParseNode:inFile:withPreamble: that is not implemented anymore: On Tue, Aug 27, 2013 at 7:53 PM, ClÃ©ment Bera <bera.clement(a)gmail.com>wrote: > putSource: aString > fromParseNode: methodNode > > inFile: 2 > withPreamble: > -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Aug. 27, 2013

Re: [Pharo-dev] Compilation code in grease not compatible with Pharo 3.0

by ClÃ©ment Bera

I didn't check (I'm not on my laptop) but I would say the problem is that CompiledMethodWithNode does not exist any more. Something like that would fix it: GRPharoPlatform>>compile: aString into: aClass classified: aSymbol "The trick here is to be as silently a possible so that the package is not marked dirty when running WAFileLibrary test. This also makes running tests much faster." | methodNode compiledMethod selector methodAndNode | methodNode := aClass compilerClass new source: aString; class: aClass; failBlock: [ GRError signal: 'syntax error' ]; translate. compiledMethod := methodNode generate: aClass defaultMethodTrailer. selector := methodNode selector. compiledMethod putSource: aString fromParseNode: methodNode inFile: 2 withPreamble: [ :file | aClass printCategoryChunk: aSymbol asString on: file priorMethod: (aClass compiledMethodAt: selector ifAbsent: [ nil ]). file cr ]. aClass addSelectorSilently: selector withMethod: compiledMethod. self doSilently: [ aClass organization classify: selector under: aSymbol ] 2013/8/27 Damien Cassou <damien.cassou(a)gmail.com> > Hi, > > how can I make the following code compile in Pharo 3.0? This is part of > Grease ( > https://ci.inria.fr/pharo-contribution/job/Grease/PHARO=30,VERSION=stable,V… > ): > > GRPharoPlatform>>compile: aString into: aClass classified: aSymbol > "The trick here is to be as silently a possible so that the package is > not marked dirty when running WAFileLibrary test. > This also makes running tests much faster." > | methodNode compiledMethod selector methodAndNode | > methodNode := aClass compilerClass new > compile: aString > in: aClass > notifying: nil > ifFail: [ GRError signal: 'syntax error' ]. > selector := methodNode selector. > methodAndNode := CompiledMethodWithNode > generateMethodFromNode: methodNode > trailer: aClass defaultMethodTrailer. > compiledMethod := methodAndNode method. > compiledMethod > putSource: aString > fromParseNode: methodAndNode node > inFile: 2 > withPreamble: [ :file | > aClass > printCategoryChunk: aSymbol asString > on: file priorMethod: (aClass compiledMethodAt: selector > ifAbsent: [ nil ]). > file cr ]. > aClass > addSelectorSilently: selector > withMethod: compiledMethod. > self doSilently: [ > aClass organization > classify: selector > under: aSymbol ] > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without losing > enthusiasm." > Winston Churchill >

Aug. 27, 2013