December 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] genJumpLong: distance index 1043 is out of range -1024 to 1023

by ClÃ©ment Bera

Hi, This will be fixed by using the alternative bytecode set, likely in the next few weeks in Pharo 6 alpha/beta. Basically control flow messages (ifTrue:, to:do:, etc.) cannot have too many statements in their blocks (ifTrue: argument, to:do: second arguments, etc) or the compiler can't compile them due to bytecode set encoding limitation. The new bytecode set is encoded differently and allows such code to be compiled. As a temporary solution, you need to split your code in multiple methods to lower the number of statements inside blocks inside control flow messages. Sorry for the annoyance. We're working on integrating a solution and we believe that this will be integrated in Pharo 6 in the next few weeks. Regards, Clement On Wed, Dec 7, 2016 at 4:14 PM, Davide Varvello via Pharo-dev < pharo-dev(a)lists.pharo.org> wrote: > > > ---------- Forwarded message ---------- > From: Davide Varvello <varvello(a)yahoo.com> > To: pharo-dev(a)lists.pharo.org > Cc: > Date: Wed, 7 Dec 2016 07:14:35 -0800 (PST) > Subject: genJumpLong: distance index 1043 is out of range -1024 to 1023 > Hi, > > Sometimes (and also today) after formatting and saving a method, an Error > is > thrown. > Following a chunk of PharoDebug.log > > TIA > Davide > > > --------------------- > THERE_BE_DRAGONS_HERE > Error: genJumpLong: distance index 1043 is out of range -1024 to 1023 > 7 December 2016 4:21:53.0426 pm > > VM: Mac OS - intel - 1096 - CoInterpreter > VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: > 16138eb3-2390-40f5-a6c8-15f0494936f8 Sep 30 2016 > StackToRegisterMappingCogit VMMaker.oscog-HolgerHansPeterFreyther.1880 > uuid: > 16138eb3-2390-40f5-a6c8-15f0494936f8 Sep 30 2016 > https://github.com/pharo-project/pharo-vm.git Commit: > 06744effac0f0aa3b4b32e17636448f9d51d6707 Date: 2016-09-30 08:40:43 +0200 > By: > GitHub <noreply(a)github.com> Jenkins build #603 > > Image: Pharo5.0 [Latest update: #50763] > > OpalEncoderForV3PlusClosures(Object)>>error: > Receiver: an OpalEncoderForV3PlusClosures > Arguments and temporary variables: > aString: 'genJumpLong: distance index 1043 is out > of range -1024 to 1023' > Receiver's instance variables: > stream: an IRBytecodeGenerator > position: nil > rootNode: nil > blockExtentsToLocals: nil > > > OpalEncoderForV3PlusClosures(OpalBytecodeEncoder)>> > outOfRangeError:index:range:to: > Receiver: an OpalEncoderForV3PlusClosures > Arguments and temporary variables: > string: 'distance' > index: 1043 > rangeStart: -1024 > rangeEnd: 1023 > Receiver's instance variables: > stream: an IRBytecodeGenerator > position: nil > rootNode: nil > blockExtentsToLocals: nil > > > OpalEncoderForV3PlusClosures(OpalEncoderForV3)>>genJumpLong: > Receiver: an OpalEncoderForV3PlusClosures > Arguments and temporary variables: > distance: 1043 > Receiver's instance variables: > stream: an IRBytecodeGenerator > position: nil > rootNode: nil > blockExtentsToLocals: nil > > > OpalEncoderForV3PlusClosures(OpalEncoderForV3)>>genJump: > Receiver: an OpalEncoderForV3PlusClosures > Arguments and temporary variables: > distance: 1043 > Receiver's instance variables: > stream: an IRBytecodeGenerator > position: nil > rootNode: nil > blockExtentsToLocals: nil > > > > -- > View this message in context: http://forum.world.st/ > genJumpLong-distance-index-1043-is-out-of-range-1024-to- > 1023-tp4926103.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > >

Dec. 7, 2016

Re: [Pharo-dev] genJumpLong: distance index 1043 is out of range -1024 to 1023

by Marcus Denker

Hello, The current bytecode limited the size of jumps. This means that you will get this error if your mehthods are so complex that they require a jump too large. Solution: refactor to simplify. We should improve the error message to explain that. (this will not happen anymore when the new bytecode set gets adopted). > On 7 Dec 2016, at 12:14, Davide Varvello via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > > From: Davide Varvello <varvello(a)yahoo.com> > Subject: genJumpLong: distance index 1043 is out of range -1024 to 1023 > Date: 7 December 2016 at 12:14:35 GMT-3 > To: pharo-dev(a)lists.pharo.org > > > Hi, > > Sometimes (and also today) after formatting and saving a method, an Error is > thrown. > Following a chunk of PharoDebug.log > > TIA > Davide > > > --------------------- > THERE_BE_DRAGONS_HERE > Error: genJumpLong: distance index 1043 is out of range -1024 to 1023 > 7 December 2016 4:21:53.0426 pm > > VM: Mac OS - intel - 1096 - CoInterpreter > VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: > 16138eb3-2390-40f5-a6c8-15f0494936f8 Sep 30 2016 > StackToRegisterMappingCogit VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: > 16138eb3-2390-40f5-a6c8-15f0494936f8 Sep 30 2016 > https://github.com/pharo-project/pharo-vm.git Commit: > 06744effac0f0aa3b4b32e17636448f9d51d6707 Date: 2016-09-30 08:40:43 +0200 By: > GitHub <noreply(a)github.com> Jenkins build #603 > > Image: Pharo5.0 [Latest update: #50763] > > OpalEncoderForV3PlusClosures(Object)>>error: > Receiver: an OpalEncoderForV3PlusClosures > Arguments and temporary variables: > aString: 'genJumpLong: distance index 1043 is out of range -1024 to 1023' > Receiver's instance variables: > stream: an IRBytecodeGenerator > position: nil > rootNode: nil > blockExtentsToLocals: nil > > > OpalEncoderForV3PlusClosures(OpalBytecodeEncoder)>>outOfRangeError:index:range:to: > Receiver: an OpalEncoderForV3PlusClosures > Arguments and temporary variables: > string: 'distance' > index: 1043 > rangeStart: -1024 > rangeEnd: 1023 > Receiver's instance variables: > stream: an IRBytecodeGenerator > position: nil > rootNode: nil > blockExtentsToLocals: nil > > > OpalEncoderForV3PlusClosures(OpalEncoderForV3)>>genJumpLong: > Receiver: an OpalEncoderForV3PlusClosures > Arguments and temporary variables: > distance: 1043 > Receiver's instance variables: > stream: an IRBytecodeGenerator > position: nil > rootNode: nil > blockExtentsToLocals: nil > > > OpalEncoderForV3PlusClosures(OpalEncoderForV3)>>genJump: > Receiver: an OpalEncoderForV3PlusClosures > Arguments and temporary variables: > distance: 1043 > Receiver's instance variables: > stream: an IRBytecodeGenerator > position: nil > rootNode: nil > blockExtentsToLocals: nil > > > > -- > View this message in context: http://forum.world.st/genJumpLong-distance-index-1043-is-out-of-range-1024-… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > > >

Dec. 7, 2016

Re: [Pharo-dev] Generate accessors refactoring

by John Brant

> On Dec 7, 2016, at 3:44 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-12-06 19:29 GMT+01:00 John Brant <brant(a)refactoryworkers.com>: > > We could make it configurable. "Manually" accessors will be generated in simplified mode and related refactorings will use intelligent mode > > My personal preference would be to ask the user what to do when performing the accessor refactoring. If the class hierarchy already has a method with the name of the variable, we can look at that method and determine what to do. In the case of #name, we could see that it is defined in a superclass and ask if it is ok to override the method (likely a good choice, but not always so it is good to confirm with the user). If the class directly defines the method, and that method has a return that returns the variable, then we can ask if they want to use that method as the âaccessorâ even though it does some other stuff (and potential returns a different value). Finally, if some subclass defines the method, then we can ask if they want to create that method even though some subclass is overriding it. Of course, we could have any combination of all three too. If they want a different method, then we should ask what to name the method instead of appending a number to the name. > > Ok. You prefer tons of questions to user just to perform stupid accessors generation. And, please, don't say that it is rare cases. It is quite common which nicely shown here 18880. > I wonder do you have real experience when it protected you from destroying system? We only talk about simple accessors refactoring. Yes, I would prefer a question to doing something wrong and breaking my code. Part of the problem appears to be what is defined as an "accessorâ. Accessors as defined for refactoring are simple get/set accessors (the set version can return or not return the set value â depending on usage). Using this definition of accessor we can prove things about the code. However, when you extend the âaccessorâ definition then it gets much tougher to prove anything. Which of these would you consider valid setter methods for foo? foo: anInteger (anInteger between: 1 and: 100) ifTrue: [foo := anInteger] foo: anInteger (anInteger between: 1 and: 100) ifTrue: [foo := anInteger] ifFalse: [self error: âInvalid valueâ] foo: anInteger (anInteger between: 1 and: 100) ifTrue: [foo := anInteger] ifFalse: [bar := anInteger] foo: anInteger foo := anInteger. self changed foo: anInteger self aboutToChange: #foo. foo := anInteger. self changed: #foo foo: anInteger self change: #foo to: anInteger foo: anInteger âdo nothingâ foo: anInteger bar := anInteger bar: anInteger foo := anInteger As for whether things are ârareâ or not, that would depend on the usage and the person performing the refactoring. If you are in the habit of creating some accessor like methods and then doing a create accessors refactoring, then you will get this behavior frequently. However, if you are defining the class and then immediately creating the accessors, then it will be much less frequent. As for my âreal experienceâ, I wrote the accessor refactoring over 22 years ago. Since then, Iâve had several times that it has saved me from overriding a method that I didnât want to be overridden. As for saving me from destroying the system, it most likely has, but not in the way you probably expect. When I would test the refactorings, I would purposely try to destroy the system by doing dangerous things. If the system crashed, I would fix the refactorings, or add an explanation that the refactoring didnât/couldnât check for that behavior. Testing in this way gave us confidence when giving demos. We could allow people to yell out refactorings that they wanted to see performed and we were fairly confident that everything would keep running. Over the years, we renamed Object to Thing, True/False to False/True, #+ to #p:, extracted/inlined bunches of code in String and OrderedCollection, etc. Only once in all of the demos did we destroy the system. We renamed a method that was being used by the process scheduler. We donât try to fix running code with the new names so when the original method was removed, the process scheduler threw an error and crashed the image. We could have had the rename method refactoring handle this case also, but that would have required some non-portable code. John Brant

Dec. 7, 2016

genJumpLong: distance index 1043 is out of range -1024 to 1023

by Davide Varvello

Hi, Sometimes (and also today) after formatting and saving a method, an Error is thrown. Following a chunk of PharoDebug.log TIA Davide --------------------- THERE_BE_DRAGONS_HERE Error: genJumpLong: distance index 1043 is out of range -1024 to 1023 7 December 2016 4:21:53.0426 pm VM: Mac OS - intel - 1096 - CoInterpreter VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 16138eb3-2390-40f5-a6c8-15f0494936f8 Sep 30 2016 StackToRegisterMappingCogit VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 16138eb3-2390-40f5-a6c8-15f0494936f8 Sep 30 2016 https://github.com/pharo-project/pharo-vm.git Commit: 06744effac0f0aa3b4b32e17636448f9d51d6707 Date: 2016-09-30 08:40:43 +0200 By: GitHub <noreply(a)github.com> Jenkins build #603 Image: Pharo5.0 [Latest update: #50763] OpalEncoderForV3PlusClosures(Object)>>error: Receiver: an OpalEncoderForV3PlusClosures Arguments and temporary variables: aString: 'genJumpLong: distance index 1043 is out of range -1024 to 1023' Receiver's instance variables: stream: an IRBytecodeGenerator position: nil rootNode: nil blockExtentsToLocals: nil OpalEncoderForV3PlusClosures(OpalBytecodeEncoder)>>outOfRangeError:index:range:to: Receiver: an OpalEncoderForV3PlusClosures Arguments and temporary variables: string: 'distance' index: 1043 rangeStart: -1024 rangeEnd: 1023 Receiver's instance variables: stream: an IRBytecodeGenerator position: nil rootNode: nil blockExtentsToLocals: nil OpalEncoderForV3PlusClosures(OpalEncoderForV3)>>genJumpLong: Receiver: an OpalEncoderForV3PlusClosures Arguments and temporary variables: distance: 1043 Receiver's instance variables: stream: an IRBytecodeGenerator position: nil rootNode: nil blockExtentsToLocals: nil OpalEncoderForV3PlusClosures(OpalEncoderForV3)>>genJump: Receiver: an OpalEncoderForV3PlusClosures Arguments and temporary variables: distance: 1043 Receiver's instance variables: stream: an IRBytecodeGenerator position: nil rootNode: nil blockExtentsToLocals: nil -- View this message in context: http://forum.world.st/genJumpLong-distance-index-1043-is-out-of-range-1024-… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 7, 2016

Re: [Pharo-dev] Fogbugz admin - please add Pharo 7 milestone

by Marcus Denker

Hi, I added the new Milestone. (the dates for start and end are just made upâ¦ they might change) > On 7 Dec 2016, at 02:15, Ben Coman <btc(a)openinworld.com> wrote: > > Just taking a browse through open tickets for Pharo 6, and maybe some > can be bumped to Pharo 7 (rather than just "Later"). Could we have a > Fogbugz milestone for it? > > cheers -ben >

Dec. 7, 2016

Re: [Pharo-dev] Generate accessors refactoring

by Nicolai Hess

2016-12-07 10:44 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2016-12-06 19:29 GMT+01:00 John Brant <brant(a)refactoryworkers.com>: > >> > We could make it configurable. "Manually" accessors will be generated >> in simplified mode and related refactorings will use intelligent mode >> >> My personal preference would be to ask the user what to do when >> performing the accessor refactoring. If the class hierarchy already has a >> method with the name of the variable, we can look at that method and >> determine what to do. In the case of #name, we could see that it is defined >> in a superclass and ask if it is ok to override the method (likely a good >> choice, but not always so it is good to confirm with the user). If the >> class directly defines the method, and that method has a return that >> returns the variable, then we can ask if they want to use that method as >> the âaccessorâ even though it does some other stuff (and potential returns >> a different value). Finally, if some subclass defines the method, then we >> can ask if they want to create that method even though some subclass is >> overriding it. Of course, we could have any combination of all three too. >> If they want a different method, then we should ask what to name the method >> instead of appending a number to the name. > > > Ok. You prefer tons of questions to user just to perform stupid accessors > generation. And, please, don't say that it is rare cases. It is quite > common which nicely shown here 18880 > <https://pharo.fogbugz.com/f/cases/18880/Autogenerating-accessors-should-be-…> > . > I wonder do you have *real* experience when it protected you from > destroying system? We only talk about simple accessors refactoring. > Possible solution in inbox for case 18880. Needs a test case. As far as I can see, this change does not conflict with application of abstract-variable-refactoring, but needs some testing (exising RB-Tests are green).

Dec. 7, 2016

[pharo-project/pharo-core]

by GitHub

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

Dec. 7, 2016

[pharo-project/pharo-core] 44e997: 60319

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 44e9977b19d5e712cadefd4a3fcdfbf034f5cf9f https://github.com/pharo-project/pharo-core/commit/44e9977b19d5e712cadefd4a… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-12-07 (Wed, 07 Dec 2016) Changed paths: R Glamour-Morphic-Brick.package/extension/RubScrolledTextMorph/instance/cursor.st R Glamour-Morphic-Brick.package/extension/RubScrolledTextMorph/instance/font_.st R Glamour-Morphic-Brick.package/extension/RubScrolledTextMorph/instance/margins_.st M Kernel.package/Delay.class/class/settings/delaySchedulerClass_.st A Kernel.package/ManifestKernel.class/class/code-critics/ruleRBBadMessageRuleV1FalsePositive.st A Morphic-Widgets-Tabs.package/TabBarMorph.class/instance/initialization/addMenuButton.st A Morphic-Widgets-Tabs.package/TabBarMorph.class/instance/initialization/useSortedTabsBy_.st R Morphic-Widgets-Tabs.package/TabBarMorph.class/instance/initialize/addMenuButton.st A Morphic-Widgets-Tabs.package/TabManagerMorph.class/instance/initialization/minExtent.st A Morphic-Widgets-Tabs.package/TabManagerMorph.class/instance/initialization/registerBarActions.st A Morphic-Widgets-Tabs.package/TabManagerMorph.class/instance/initialization/registerShortcuts.st A Morphic-Widgets-Tabs.package/TabManagerMorph.class/instance/initialization/useSortedTabsBy_.st R Morphic-Widgets-Tabs.package/TabManagerMorph.class/instance/initialize/minExtent.st R Morphic-Widgets-Tabs.package/TabManagerMorph.class/instance/initialize/registerBarActions.st R Morphic-Widgets-Tabs.package/TabManagerMorph.class/instance/initialize/registerShortcuts.st M Morphic-Widgets-Tabs.package/TabMorph.class/instance/protocol/close.st A Morphic-Widgets-Tabs.package/TabMorph.class/instance/protocol/okToClose.st A Rubric.package/RubScrolledTextMorph.class/instance/accessing text area/cursor.st A Rubric.package/RubScrolledTextMorph.class/instance/accessing text area/font_.st A Rubric.package/RubScrolledTextMorph.class/instance/accessing text area/margins_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60318.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60319.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60318.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60319.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60319 19412 SpecDebugger cannot work without Glamour https://pharo.fogbugz.com/f/cases/19412 19428 Silently ignore loading DelayScheduler setting when its the same as existing https://pharo.fogbugz.com/f/cases/19428 19426 TabsManagerMorph improvements https://pharo.fogbugz.com/f/cases/19426 http://files.pharo.org/image/60/60319.zip

Dec. 7, 2016

Re: [Pharo-dev] Generate accessors refactoring

by Denis Kudriashov

2016-12-06 19:29 GMT+01:00 John Brant <brant(a)refactoryworkers.com>: > > We could make it configurable. "Manually" accessors will be generated in > simplified mode and related refactorings will use intelligent mode > > My personal preference would be to ask the user what to do when performing > the accessor refactoring. If the class hierarchy already has a method with > the name of the variable, we can look at that method and determine what to > do. In the case of #name, we could see that it is defined in a superclass > and ask if it is ok to override the method (likely a good choice, but not > always so it is good to confirm with the user). If the class directly > defines the method, and that method has a return that returns the variable, > then we can ask if they want to use that method as the âaccessorâ even > though it does some other stuff (and potential returns a different value). > Finally, if some subclass defines the method, then we can ask if they want > to create that method even though some subclass is overriding it. Of > course, we could have any combination of all three too. If they want a > different method, then we should ask what to name the method instead of > appending a number to the name. Ok. You prefer tons of questions to user just to perform stupid accessors generation. And, please, don't say that it is rare cases. It is quite common which nicely shown here 18880 <https://pharo.fogbugz.com/f/cases/18880/Autogenerating-accessors-should-be-…> . I wonder do you have *real* experience when it protected you from destroying system? We only talk about simple accessors refactoring.

Dec. 7, 2016

Re: [Pharo-dev] Fogbugz admin - please add Pharo 7 milestone

by stepharong

we will :) On Wed, 07 Dec 2016 06:15:09 +0100, Ben Coman <btc(a)openinworld.com> wrote: > Just taking a browse through open tickets for Pharo 6, and maybe some > can be bumped to Pharo 7 (rather than just "Later"). Could we have a > Fogbugz milestone for it? > > cheers -ben > -- Using Opera's mail client: http://www.opera.com/mail/

Dec. 7, 2016