January 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] bugs with blocks

by ClÃ©ment Bera

I remembered this situation was true in a bug report. Seemingly it is when you do context sourceNode on a dead context. 2014/1/27 Nicolai Hess <nicolaihess(a)web.de> > 2014-01-27 Camille Teruel <camille.teruel(a)gmail.com> > > >> On 27 janv. 2014, at 10:44, Camille Teruel <camille.teruel(a)gmail.com> >> wrote: >> >> >> On 27 janv. 2014, at 09:28, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> >> Hello, >> >> I don't think this line was there by mistake. In some cases, the activePC >> with this code is lower than the startpc and then the debugger shows an >> error 'no ast node found at this pc' and cannot properly highlight the >> current executed code because the pc is outside the method bytecode. >> >> >> Ok, thanks ClÃ©ment. >> So shouldn't it be: activePC <= self *home* startpc ifTrue: [ activePC >> := pc ] since self may be the context of a block? >> >> >> We looked at the issue with ClÃ©ment and we agreed on adding #home. >> Fix in inbox. >> Nicolai what do you think? >> >> >> I remember adding this line as a hack to fix a bug report.... But I don't >> remember any more... >> >> Here's an extract from my blog post, at that time the method had not this >> line, and we added it due to a bug report: >> >> *in a debugger, the context on the top of the stack does not highlight >> the same way other contexts does. In fact, the top context highlights the >> instruction in source code that *will* be executed in the next step. On the >> contrary, all the other contexts highlights the instruction in source code >> that *has been* executed previously. That means that you need to take care >> about that in the mapping to highlight the correct range.* >> >> *Right now we had to keep the old mapping API so there is a method >> named rangeForPC:contextIsActiveContext: that has a boolean as second >> argument. With this boolean you know if you need to look for the range of >> the current pc (first argument) of the previous pc of the first argument. >> On the old mapping, they needed the exact pc for their pc to abstract pc >> mapping. So they needed a method previousPCFor: to handle the case of >> multiple byte code instructions. But we donât care, as the pc will be used >> in the scan of instructionForPC:, so we just need to do pc â 1.* >> >> >> >> >> >> >> >> >> >> *The result is : >> DebuggerMethodMapOpal>>#rangeForPC: aPC contextIsActiveContext:contextIsActive >> "return the debug highlight for aPC"| pc |pc := contextIsActive ifTrue: >> [aPC] ifFalse: [aPC - 1].^ (methodNode sourceNodeForPC: pc) >> debugHighlightRangeRBMethodNode>>#sourceNodeForPC: anInteger ^ (self ir >> instructionForPC: anInteger) sourceNode* >> >> >> >> >> *IRMethod>>#instructionForPC: aPC 0 to: -3 by: -1 do: [ : off |(self >> firstInstructionMatching: [:ir | ir bytecodeOffset = (aPC - off) ]) >> ifNotNil: [:it |^it]] * >> >> >> 2014/1/27 Camille Teruel <camille.teruel(a)gmail.com> >> >>> >>> On 27 janv. 2014, at 08:44, Marcus Denker <marcus.denker(a)inria.fr> >>> wrote: >>> >>> >>> On 26 Jan 2014, at 10:08, Camille Teruel <camille.teruel(a)gmail.com> >>> wrote: >>> >>> [ [ ] ] >>> prints: >>> [ ] >>> instead of: >>> [ [ ] ] >>> >>> and >>> [ :arg | [ arg ] ] >>> prints: >>> DoIt >>> ^ [ :arg | [ arg ] ] yourself >>> instead of: >>> [ :arg | [ arg ] ] >>> >>> >>> Apparently it's the print that is not correct because of problem in >>> #sourceNode. >>> Any clue? Marcus? ClÃ©ment? >>> >>> >>> Other than âthe devil is in the detailsâ (this is all far too complex >>> for my taste, implementation wiseâ¦) >>> >>> Can you add an issue? My problem is that i have no time right now to >>> even think about itâ¦ >>> >>> >>> My problem is that I found a fix with try-and-fail without really >>> understanding the code. >>> I just found that problematic examples were passing through that >>> condition whereas non problematic examples were not. >>> I looked at the versions and though that you may have left this line by >>> error. >>> I removed it and so far, it *seems* to work. So the fix is there but I >>> have no clue if it's correct or not. >>> Here it the case: >>> https://pharo.fogbugz.com/f/cases/12732/sourceNode-broken >>> >>> >>> Marcus >>> >>> >>> >> >> >> > I am lost :) > > It looks right, I did some tests and it works. > > But I fail to see, > in what situation would this be true: > > activePC <= self home startpc > > > >

Jan. 27, 2014

500 timesRepeat: [ Workspace open ]

by HernÃ¡n Morales Durand

See this one: https://pharo.fogbugz.com/f/cases/12626/Too-many-open-windows-make-Pharo-un… What is the maximum of task bars tasks would you like to allow? To me more than 50 looks like recursion... Cheers, HernÃ¡n

Jan. 27, 2014

Re: [Pharo-dev] bugs with blocks

by Camille Teruel

On 27 janv. 2014, at 14:32, Nicolai Hess <nicolaihess(a)web.de> wrote: > 2014-01-27 Camille Teruel <camille.teruel(a)gmail.com> > > On 27 janv. 2014, at 10:44, Camille Teruel <camille.teruel(a)gmail.com> wrote: > >> >> On 27 janv. 2014, at 09:28, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> >>> Hello, >>> >>> I don't think this line was there by mistake. In some cases, the activePC with this code is lower than the startpc and then the debugger shows an error 'no ast node found at this pc' and cannot properly highlight the current executed code because the pc is outside the method bytecode. >> >> Ok, thanks ClÃ©ment. >> So shouldn't it be: activePC <= self home startpc ifTrue: [ activePC := pc ] since self may be the context of a block? > > We looked at the issue with ClÃ©ment and we agreed on adding #home. > Fix in inbox. > Nicolai what do you think? > >> >>> I remember adding this line as a hack to fix a bug report.... But I don't remember any more... >>> >>> Here's an extract from my blog post, at that time the method had not this line, and we added it due to a bug report: >>> >>> in a debugger, the context on the top of the stack does not highlight the same way other contexts does. In fact, the top context highlights the instruction in source code that *will* be executed in the next step. On the contrary, all the other contexts highlights the instruction in source code that *has been* executed previously. That means that you need to take care about that in the mapping to highlight the correct range. >>> >>> Right now we had to keep the old mapping API so there is a method named rangeForPC:contextIsActiveContext: that has a boolean as second argument. With this boolean you know if you need to look for the range of the current pc (first argument) of the previous pc of the first argument. On the old mapping, they needed the exact pc for their pc to abstract pc mapping. So they needed a method previousPCFor: to handle the case of multiple byte code instructions. But we donât care, as the pc will be used in the scan of instructionForPC:, so we just need to do pc â 1. >>> >>> The result is : >>> >>> DebuggerMethodMapOpal>>#rangeForPC: aPC contextIsActiveContext:contextIsActive >>> "return the debug highlight for aPC" >>> | pc | >>> pc := contextIsActive ifTrue: [aPC] ifFalse: [aPC - 1]. >>> ^ (methodNode sourceNodeForPC: pc) debugHighlightRange >>> RBMethodNode>>#sourceNodeForPC: anInteger >>> ^ (self ir instructionForPC: anInteger) sourceNode >>> >>> IRMethod>>#instructionForPC: aPC >>> 0 to: -3 by: -1 do: [ : off | >>> (self firstInstructionMatching: [:ir | ir bytecodeOffset = (aPC - off) ]) ifNotNil: [:it |^it]] >>> >>> >>> >>> 2014/1/27 Camille Teruel <camille.teruel(a)gmail.com> >>> >>> On 27 janv. 2014, at 08:44, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>>> >>>> On 26 Jan 2014, at 10:08, Camille Teruel <camille.teruel(a)gmail.com> wrote: >>>> >>>>> [ [ ] ] >>>>> prints: >>>>> [ ] >>>>> instead of: >>>>> [ [ ] ] >>>>> >>>>> and >>>>> [ :arg | [ arg ] ] >>>>> prints: >>>>> DoIt >>>>> ^ [ :arg | [ arg ] ] yourself >>>>> instead of: >>>>> [ :arg | [ arg ] ] >>>>> >>>>> >>>>> Apparently it's the print that is not correct because of problem in #sourceNode. >>>>> Any clue? Marcus? ClÃ©ment? >>>> >>>> Other than âthe devil is in the detailsâ (this is all far too complex for my taste, implementation wiseâ¦) >>>> >>>> Can you add an issue? My problem is that i have no time right now to even think about itâ¦ >>> >>> My problem is that I found a fix with try-and-fail without really understanding the code. >>> I just found that problematic examples were passing through that condition whereas non problematic examples were not. >>> I looked at the versions and though that you may have left this line by error. >>> I removed it and so far, it *seems* to work. So the fix is there but I have no clue if it's correct or not. >>> Here it the case: https://pharo.fogbugz.com/f/cases/12732/sourceNode-broken >>> >>>> >>>> Marcus >>> >>> >> > > > I am lost :) > > It looks right, I did some tests and it works. > > But I fail to see, > in what situation would this be true: > activePC <= self home startpc So do I :)

Jan. 27, 2014

Re: [Pharo-dev] [ci server][3.0] #cleanUpForRelease done on server again

by Marcus Denker

On 27 Jan 2014, at 14:49, Norbert Hartl <norbert(a)hartl.name> wrote: > Very cool, > > it would be very good if the ImageCleaner would enable me to manage what needs to be cleaned. At the moment it is all or nothing. My use case is that I like SUnit to stay in the image. Iâm not only writing module tests while developing but also runtime test cases that monitor the health of the image. It would be wonderful having an easy way to take control of that process. Just an idea for those who have a enough time and no current project to deal with :) > yesâ¦ itâs a very ad hoc thing. #cleanUpForProduction needs more work anyway, as lots of packages are dirty after. One of the things that should be changed is to *not* unload SUnit. The time when that was useful is overâ¦ people like to run tests in deployment more than conserve memory. But in general, this is all very very hackish anyway and what we need it a Pharo that is bootstrapped from a descriptionâ¦ Marcus

Jan. 27, 2014

Re: [Pharo-dev] Source city

by Diego Lont

Hi all, I am afraid I have to report I still failed to load code city. The problem is within code city, as Roassal 3d loads just fine. So we are going to use that instead of code city. Cheers, Diego On Jan 27, 2014, at 2:24 PM, Diego Lont wrote: > And of course I forgot to checkâ¦ new chance for a fixed configuration > > <ConfigurationOfSourceCity-DiegoLont.5.mcz> > On Jan 27, 2014, at 2:20 PM, Diego Lont wrote: > >> Hi all, >> >> I wanted to try out source city in Moose 5.0. The current pharo version there is Pharo3.0 (Latest update: #30714), so note before loading you need to install the slice that belongs to issue 12488. So somewhere regressions occurred. >> >> But after installing this slice, you still have to fix the configuration. I attached a fixed configuration, as I am not allowed to put it in the right spot. If someone could upload this, I would be much obliged. >> >> Cheers, >> Diego >> <ConfigurationOfSourceCity-DiegoLont.4.mcz> >

Jan. 27, 2014

Re: [Pharo-dev] [ci server][3.0] #cleanUpForRelease done on server again

by Norbert Hartl

Very cool, it would be very good if the ImageCleaner would enable me to manage what needs to be cleaned. At the moment it is all or nothing. My use case is that I like SUnit to stay in the image. Iâm not only writing module tests while developing but also runtime test cases that monitor the health of the image. It would be wonderful having an easy way to take control of that process. Just an idea for those who have a enough time and no current project to deal with :) Norbert Am 27.01.2014 um 13:28 schrieb Marcus Denker <marcus.denker(a)inria.fr>: > Hi, > > The job > > https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-1-Tracker/ > > now does a #cleanUpForRelease using ImageCleaner. This used to be done on update, > but that is not good as when people load updates they do not want the side effects of > a release clean (mostly, deleting all change set information). > > So I added command line support for ImageCleaner last week and now that it is in the image, > I added this line to the build script: > > ./pharo Pharo.image clean ârelease > > This will be used with the next update (#724) > > The command might be interesting for others, here is the description from the class > comment: > > > Usage: clean [ --release ] > --release do #cleanUpForRelease > --production do #cleanUpForProduction > > Documentation: > This allows to run the ImageCleaner from the commandLine. > With no special option it runs Smalltalk cleanUp: true. > > Usage: > pharo Pharo.image clean > pharo Pharo.image clean --release

Jan. 27, 2014

Re: [Pharo-dev] bugs with blocks

by Nicolai Hess

2014-01-27 Camille Teruel <camille.teruel(a)gmail.com> > > On 27 janv. 2014, at 10:44, Camille Teruel <camille.teruel(a)gmail.com> > wrote: > > > On 27 janv. 2014, at 09:28, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Hello, > > I don't think this line was there by mistake. In some cases, the activePC > with this code is lower than the startpc and then the debugger shows an > error 'no ast node found at this pc' and cannot properly highlight the > current executed code because the pc is outside the method bytecode. > > > Ok, thanks ClÃ©ment. > So shouldn't it be: activePC <= self *home* startpc ifTrue: [ activePC := > pc ] since self may be the context of a block? > > > We looked at the issue with ClÃ©ment and we agreed on adding #home. > Fix in inbox. > Nicolai what do you think? > > > I remember adding this line as a hack to fix a bug report.... But I don't > remember any more... > > Here's an extract from my blog post, at that time the method had not this > line, and we added it due to a bug report: > > *in a debugger, the context on the top of the stack does not highlight the > same way other contexts does. In fact, the top context highlights the > instruction in source code that *will* be executed in the next step. On the > contrary, all the other contexts highlights the instruction in source code > that *has been* executed previously. That means that you need to take care > about that in the mapping to highlight the correct range.* > > *Right now we had to keep the old mapping API so there is a method > named rangeForPC:contextIsActiveContext: that has a boolean as second > argument. With this boolean you know if you need to look for the range of > the current pc (first argument) of the previous pc of the first argument. > On the old mapping, they needed the exact pc for their pc to abstract pc > mapping. So they needed a method previousPCFor: to handle the case of > multiple byte code instructions. But we donât care, as the pc will be used > in the scan of instructionForPC:, so we just need to do pc â 1.* > > > > > > > > > > *The result is : > DebuggerMethodMapOpal>>#rangeForPC: aPC contextIsActiveContext:contextIsActive > "return the debug highlight for aPC"| pc |pc := contextIsActive ifTrue: > [aPC] ifFalse: [aPC - 1].^ (methodNode sourceNodeForPC: pc) > debugHighlightRangeRBMethodNode>>#sourceNodeForPC: anInteger ^ (self ir > instructionForPC: anInteger) sourceNode* > > > > > *IRMethod>>#instructionForPC: aPC 0 to: -3 by: -1 do: [ : off |(self > firstInstructionMatching: [:ir | ir bytecodeOffset = (aPC - off) ]) > ifNotNil: [:it |^it]] * > > > 2014/1/27 Camille Teruel <camille.teruel(a)gmail.com> > >> >> On 27 janv. 2014, at 08:44, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >> On 26 Jan 2014, at 10:08, Camille Teruel <camille.teruel(a)gmail.com> >> wrote: >> >> [ [ ] ] >> prints: >> [ ] >> instead of: >> [ [ ] ] >> >> and >> [ :arg | [ arg ] ] >> prints: >> DoIt >> ^ [ :arg | [ arg ] ] yourself >> instead of: >> [ :arg | [ arg ] ] >> >> >> Apparently it's the print that is not correct because of problem in >> #sourceNode. >> Any clue? Marcus? ClÃ©ment? >> >> >> Other than âthe devil is in the detailsâ (this is all far too complex for >> my taste, implementation wiseâ¦) >> >> Can you add an issue? My problem is that i have no time right now to even >> think about itâ¦ >> >> >> My problem is that I found a fix with try-and-fail without really >> understanding the code. >> I just found that problematic examples were passing through that >> condition whereas non problematic examples were not. >> I looked at the versions and though that you may have left this line by >> error. >> I removed it and so far, it *seems* to work. So the fix is there but I >> have no clue if it's correct or not. >> Here it the case: >> https://pharo.fogbugz.com/f/cases/12732/sourceNode-broken >> >> >> Marcus >> >> >> > > > I am lost :) It looks right, I did some tests and it works. But I fail to see, in what situation would this be true: activePC <= self home startpc

Jan. 27, 2014

Re: [Pharo-dev] iPad version does not work ?

by Esteban Lorenzano

1.4 and 2.0 worked out of the boxâ¦ and after my latest integration, 3.0 should work too. I will take a look as soon as I have half and hour to spare. Esteban On 27 Jan 2014, at 14:27, jannik laval <jannik.laval(a)gmail.com> wrote: > Hi list, > > Does anyone try to load Pharoon iPad ? > In the past, the version 1.4 worked with XCode 4.4. > > I just tried to recompile it with the new XCode (5.0.2). > The VM seems to work, but the pharo 1.4 image freezes. > > Any idea ? > > -- > ~~Jannik Laval~~ > Ãcole des Mines de Douai > Enseignant-chercheur > http://www.jannik-laval.eu > http://car.mines-douai.fr/ >

Jan. 27, 2014

[pharo-project/pharo-core] b7d95c: 30724

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: b7d95ce191a422e69ad6b04c34a97c0349b57386 https://github.com/pharo-project/pharo-core/commit/b7d95ce191a422e69ad6b04c… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-01-27 (Mon, 27 Jan 2014) Changed paths: A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script377.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30724.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M StartupPreferences.package/StartupPreferencesHandler.class/instance/actions/lookInGeneralPreferencesFolder.st M StartupPreferences.package/StartupPreferencesHandler.class/instance/actions/lookInPreferencesVersionFolder.st M StartupPreferences.package/StartupPreferencesLoader.class/class/private/preferencesGeneralFolder.st M StartupPreferences.package/StartupPreferencesLoader.class/class/private/preferencesVersionFolder.st R System-Platforms.package/NixEnvironment.class/README.md R System-Platforms.package/NixEnvironment.class/definition.st R System-Platforms.package/NixEnvironment.class/instance/accessing/environ.st R System-Platforms.package/NixEnvironment.class/instance/enumeration/keysAndValuesDo_.st R System-Platforms.package/NixEnvironment.class/instance/private/environAt_.st R System-Platforms.package/NixEnvironment.class/instance/private/setEnv_value_.st A System-Platforms.package/OSEnvironment.class/class/accessing/environmentFor_.st A System-Platforms.package/OSEnvironment.class/class/testing/isAvailable.st A System-Platforms.package/OSEnvironment.class/class/testing/isDefaultFor_.st M System-Platforms.package/OSPlatform.class/class/class initialization/shutDown_.st M System-Platforms.package/OSPlatform.class/class/class initialization/startUp_.st A System-Platforms.package/OSPlatform.class/class/private/determineActivePlatform.st R System-Platforms.package/OSPlatform.class/class/private/determineActivePlatformStartingAt_.st M System-Platforms.package/OSPlatform.class/instance/accessing/environment.st A System-Platforms.package/OSPlatform.class/instance/private/createEnvironment.st A System-Platforms.package/PlatformIndependentEnvironment.class/README.md A System-Platforms.package/PlatformIndependentEnvironment.class/class/testing/isAvailable.st A System-Platforms.package/PlatformIndependentEnvironment.class/class/testing/isDefaultFor_.st A System-Platforms.package/PlatformIndependentEnvironment.class/definition.st A System-Platforms.package/PlatformIndependentEnvironment.class/instance/enumeration/keysAndValuesDo_.st A System-Platforms.package/PlatformIndependentEnvironment.class/instance/private/getEnv_.st A System-Platforms.package/PlatformIndependentEnvironment.class/instance/private/setEnv_value_.st A System-Platforms.package/PlatformIndependentEnvironment.class/instance/private/unsetEnv_.st A System-Platforms.package/UnixEnvironment.class/README.md A System-Platforms.package/UnixEnvironment.class/class/testing/isDefaultFor_.st A System-Platforms.package/UnixEnvironment.class/definition.st A System-Platforms.package/UnixEnvironment.class/instance/accessing/environ.st A System-Platforms.package/UnixEnvironment.class/instance/enumeration/keysAndValuesDo_.st A System-Platforms.package/UnixEnvironment.class/instance/private/environAt_.st A System-Platforms.package/UnixEnvironment.class/instance/private/setEnv_value_.st A System-Platforms.package/Win32Environment.class/class/testing/isDefaultFor_.st A Tests.package/OSEnvironmentTest.class/instance/tests/testEnvironmentFor.st Log Message: ----------- 30724 12716 pharo initialization fails when there is no NativeBoost present https://pharo.fogbugz.com/f/cases/12716 http://files.pharo.org/image/30/30724.zip

Jan. 27, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30724 Home: https://github.com/pharo-project/pharo-core

Jan. 27, 2014