- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Generate accessors refactoring

by stepharong

> 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, I would love to try these three ;) #+ 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. This is a cool example. Pablo is working on updating instances during a refactoring and we should try. We could have had the > rename method refactoring handle this case also, but that would have > required some non-portable code. > > > John Brant -- Using Opera's mail client: http://www.opera.com/mail/

Dec. 7, 2016

Drastically improving the messageNotUnderstood title

by stepharong

Hi guys As I exposed newbies to our wonderfull debugger I think that we should change MessageNotUnderstood: Class>>#message into an instance of Class did not understand message To me this simple change would have a HUGE impact on making the debugger first contact a lot more friendly. Any taker? I'm off with a company today. Stef --

Dec. 7, 2016

Drastically improving the messageNotUnderstood title

by stepharong

Hi guys As I exposed newbies to our wonderfull debugger I think that we should change MessageNotUnderstood: Class>>#message into an instance of Class did not understand message To me this simple change would have a HUGE impact on making the debugger first contact a lot more friendly. Any taker? I'm off with a company today. Stef --

Dec. 7, 2016

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

by Eliot Miranda

On Wed, Dec 7, 2016 at 11:26 AM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > On Wed, 2016-12-07 at 11:10 -0800, Eliot Miranda wrote: > > > > > > On Wed, Dec 7, 2016 at 9:52 AM, Marcus Denker <marcus.denker(a)inria.fr > > > wrote: > > > 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). > > > > > > > Forgive me being pedantic, but it will simply be much less likely. > > The limit is raised to +/- 32k bytes, but one can still construct > > methods that will hit these limits. > > What prevents you to generate what - if I remember correctly - > was called jump island? i.e, generate jump to another jump. > This was/is used a lot on PA-RISCs (I might we wrong, I have > not seen an alive PA-RISC machine for ages now) > NaÃ¯vely nothing. But the island must be jumped around. The JIT does assume well-formed control graphics (stacks balanced, no jumps into the middle of basic blocks) so its possible that a jump island could break the VM. I *think* it'll be OK in the RegisterAllocatingCogit because it has stronger merge logic would would allow it to adjust the stack correctly when encountering the island after an unconditional branch around it. One tricky thing about islands is that inserting one can cause another branch to exceed its limits and hence require an island. So it introduces a loop in the backend until a fixed point is reached. IMO, the new byte code, and avoiding very long methods, is preferable to implementing islands :-) > Jan > > > > > > > On 7 Dec 2016, at 12:14, Davide Varvello via Pharo-dev <pharo-dev > > > > @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)>>outOfRangeErro > > > > r: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-d > > > > istance-index-1043-is-out-of-range-1024-to-1023-tp4926103.html > > > > Sent from the Pharo Smalltalk Developers mailing list archive at > > > > Nabble.com. > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > _,,,^..^,,,_ > > best, Eliot > > -- _,,,^..^,,,_ best, Eliot

Dec. 7, 2016

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

by Jan Vrany

On Wed, 2016-12-07 at 11:10 -0800, Eliot Miranda wrote: > > > On Wed, Dec 7, 2016 at 9:52 AM, Marcus Denker <marcus.denker(a)inria.fr > > wrote: > > 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). > > > > Forgive me being pedantic, but it will simply be much less likely.Â > The limit is raised to +/- 32k bytes, but one can still construct > methods that will hit these limits. What prevents you to generate what - if I remember correctly -Â was called jump island? i.e, generate jump to another jump.Â This was/is used a lot on PA-RISCs (I might we wrong, I have not seen an alive PA-RISC machine for ages now) Jan > > > > On 7 Dec 2016, at 12:14, Davide Varvello via Pharo-dev <pharo-dev > > > @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)>>outOfRangeErro > > > r: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-d > > > istance-index-1043-is-out-of-range-1024-to-1023-tp4926103.html > > > Sent from the Pharo Smalltalk Developers mailing list archive at > > > Nabble.com. > > > > > > > > > > > > > > > > > --Â > _,,,^..^,,,_ > best,Â Eliot

Dec. 7, 2016

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

by Eliot Miranda

On Wed, Dec 7, 2016 at 9:52 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 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). > Forgive me being pedantic, but it will simply be much less likely. The limit is raised to +/- 32k bytes, but one can still construct methods that will hit these limits. 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-to- > 1023-tp4926103.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > > -- _,,,^..^,,,_ best, Eliot

Dec. 7, 2016

Re: [Pharo-dev] Generate accessors refactoring

by Eliot Miranda

On Wed, Dec 7, 2016 at 9:00 AM, John Brant <brant(a)refactoryworkers.com> wrote: > > 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 > Amen. If it ain't broke, don't fix it. It should go without saying that if it ain't broke, don't break it. Changing the accessor refactoring is breaking things. _,,,^..^,,,_ best, Eliot

Dec. 7, 2016

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