[Pharo-project] [[ false ] whileFalse: [ ]] in workspace
Hi! I was surprised by trying to evaluate the following expression in a workspace: [[ false ] whileFalse: [ ]] and getting an error SubscriptOutOfBounds: 1... The strange thing is that compiling that expression inside a block works, but not in the workspace... Any idea? Guille
if you have time try to figure out in which pharo version the bug appeared... (I should write a tool for that :P) => do a binary search over pharo versions http://pharo.gforge.inria.fr/ci/image/20/ On 2012-11-29, at 11:04, Guillermo Polito <guillermopolito@gmail.com> wrote:
Hi!
I was surprised by trying to evaluate the following expression in a workspace:
[[ false ] whileFalse: [ ]]
and getting an error SubscriptOutOfBounds: 1...
The strange thing is that compiling that expression inside a block works, but not in the workspace...
Any idea? Guille
On Thu, Nov 29, 2012 at 3:30 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
if you have time try to figure out in which pharo version the bug appeared... (I should write a tool for that :P)
=> do a binary search over pharo versions http://pharo.gforge.inria.fr/ci/image/20/
Like a git bissect ? :-) http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://doesnotunderstand.org/
On Thu, Nov 29, 2012 at 5:26 PM, Serge Stinckwich < serge.stinckwich@gmail.com> wrote:
On Thu, Nov 29, 2012 at 3:30 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
if you have time try to figure out in which pharo version the bug appeared... (I should write a tool for that :P)
=> do a binary search over pharo versions http://pharo.gforge.inria.fr/ci/image/20/
Like a git bissect ? :-)
http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html
Cami, the wiki police says you should store this as a student project ;)
-- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://doesnotunderstand.org/
-- Mariano http://marianopeck.wordpress.com
On 2012-11-29, at 13:37, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Thu, Nov 29, 2012 at 5:26 PM, Serge Stinckwich < serge.stinckwich@gmail.com> wrote:
On Thu, Nov 29, 2012 at 3:30 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
if you have time try to figure out in which pharo version the bug appeared... (I should write a tool for that :P)
=> do a binary search over pharo versions http://pharo.gforge.inria.fr/ci/image/20/
Like a git bissect ? :-)
http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html
Cami, the wiki police says you should store this as a student project ;)
you know there is a reason I started to export pharo to git (it's broken right now I know)... so I can just use bisect :P on the pharo git repos: https://github.com/PharoProject/pharo-core but yeah, students project sounds like a good idea, I'll think about it.
2012/11/29 Camillo Bruni <camillobruni@gmail.com>:
if you have time try to figure out in which pharo version the bug appeared... (I should write a tool for that :P)
=> do a binary search over pharo versions http://pharo.gforge.inria.fr/ci/image/20/
Ok, I'll look into it...
Done :-) It happens between 20042 (works) and 20047 (error). 2012/11/29 Camillo Bruni <camillobruni@gmail.com>:
if you have time try to figure out in which pharo version the bug appeared... (I should write a tool for that :P)
=> do a binary search over pharo versions http://pharo.gforge.inria.fr/ci/image/20/
On 2012-11-29, at 11:04, Guillermo Polito <guillermopolito@gmail.com> wrote:
Hi!
I was surprised by trying to evaluate the following expression in a workspace:
[[ false ] whileFalse: [ ]]
and getting an error SubscriptOutOfBounds: 1...
The strange thing is that compiling that expression inside a block works, but not in the workspace...
Any idea? Guille
On 2012-11-29, at 14:27, Sebastian Nozzi <sebnozzi@gmail.com> wrote:
Done :-) It happens between 20042 (works) and 20047 (error).
perfect! can you open a bug report with this information? :)
2012/11/29 Camillo Bruni <camillobruni@gmail.com>:
if you have time try to figure out in which pharo version the bug appeared... (I should write a tool for that :P)
=> do a binary search over pharo versions http://pharo.gforge.inria.fr/ci/image/20/
On 2012-11-29, at 11:04, Guillermo Polito <guillermopolito@gmail.com> wrote:
Hi!
I was surprised by trying to evaluate the following expression in a workspace:
[[ false ] whileFalse: [ ]]
and getting an error SubscriptOutOfBounds: 1...
The strange thing is that compiling that expression inside a block works, but not in the workspace...
Any idea? Guille
Sebastian I can tell you that what you did is **useful** because we are all working like mad and such kind of help is really welcome. Stef On Dec 1, 2012, at 3:24 PM, Sebastian Nozzi wrote:
It's the #7076.
2012/11/29 Camillo Bruni <camillobruni@gmail.com>:
perfect! can you open a bug report with this information? :)
Ok, I've found the cause :).
From update 20043:
Issue 5744: Clean up Temp Embedding 2): DoIts http://code.google.com/p/pharo/issues/detail?id=5744 - Doits are now compiled with source embedded - embedding sources for doits pretty prints from AST as doits are compiled specially (with a return added) CompiledMethod: - remove blockExtendsToTempsMap: Not needed anymore, all calls go the MethodNode - remove #copyWitTempsFromMethodNode: All senders use #copyWithSource - remove #holdsTempNames. Temp name embedding not needed - add isDoit - schematicTempNamesString always returns the schematic string representation of all temps - tempNames forwards to methodNode - remove tempNamesString. Concatenate yourself if you need that. Debugger>>selectedMessage asks the selectedContext directly for the source. No need for the methodMap. DebuggerMethodMap - no special handling of methods that encode temps. Just as for methodNode always. MethodNode - generateWithSource. embedd pretty printed code in case of doit - remove generateWithTempNames In general: rewrite code to use #generateWithSource On Sat, Dec 1, 2012 at 6:24 PM, Stéphane Ducasse <stephane.ducasse@inria.fr>wrote:
Sebastian
I can tell you that what you did is **useful** because we are all working like mad and such kind of help is really welcome.
Stef
On Dec 1, 2012, at 3:24 PM, Sebastian Nozzi wrote:
It's the #7076.
2012/11/29 Camillo Bruni <camillobruni@gmail.com>:
perfect! can you open a bug report with this information? :)
Hi! I've hacked a fix, but I don't know if it is correct... can somebody check it so I make a Slice? Guille On Sun, Dec 2, 2012 at 8:56 PM, Guillermo Polito <guillermopolito@gmail.com>wrote:
Ok, I've found the cause :).
From update 20043:
Issue 5744: Clean up Temp Embedding 2): DoIts http://code.google.com/p/pharo/issues/detail?id=5744
- Doits are now compiled with source embedded - embedding sources for doits pretty prints from AST as doits are compiled specially (with a return added)
CompiledMethod:
- remove blockExtendsToTempsMap: Not needed anymore, all calls go the MethodNode - remove #copyWitTempsFromMethodNode: All senders use #copyWithSource - remove #holdsTempNames. Temp name embedding not needed - add isDoit - schematicTempNamesString always returns the schematic string representation of all temps - tempNames forwards to methodNode - remove tempNamesString. Concatenate yourself if you need that.
Debugger>>selectedMessage asks the selectedContext directly for the source. No need for the methodMap.
DebuggerMethodMap
- no special handling of methods that encode temps. Just as for methodNode always.
MethodNode
- generateWithSource. embedd pretty printed code in case of doit - remove generateWithTempNames
In general: rewrite code to use #generateWithSource
On Sat, Dec 1, 2012 at 6:24 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
Sebastian
I can tell you that what you did is **useful** because we are all working like mad and such kind of help is really welcome.
Stef
On Dec 1, 2012, at 3:24 PM, Sebastian Nozzi wrote:
It's the #7076.
2012/11/29 Camillo Bruni <camillobruni@gmail.com>:
perfect! can you open a bug report with this information? :)
can you just put in in the issue tracker? I have no time right now⦠but mails are such bad TODO trackers⦠On Dec 2, 2012, at 10:42 PM, Guillermo Polito <guillermopolito@gmail.com> wrote:
Hi!
I've hacked a fix, but I don't know if it is correct... can somebody check it so I make a Slice?
Guille
On Sun, Dec 2, 2012 at 8:56 PM, Guillermo Polito <guillermopolito@gmail.com> wrote: Ok, I've found the cause :).
From update 20043:
Issue 5744: Clean up Temp Embedding 2): DoIts http://code.google.com/p/pharo/issues/detail?id=5744
- Doits are now compiled with source embedded - embedding sources for doits pretty prints from AST as doits are compiled specially (with a return added)
CompiledMethod:
- remove blockExtendsToTempsMap: Not needed anymore, all calls go the MethodNode - remove #copyWitTempsFromMethodNode: All senders use #copyWithSource - remove #holdsTempNames. Temp name embedding not needed - add isDoit - schematicTempNamesString always returns the schematic string representation of all temps - tempNames forwards to methodNode - remove tempNamesString. Concatenate yourself if you need that.
Debugger>>selectedMessage asks the selectedContext directly for the source. No need for the methodMap.
DebuggerMethodMap
- no special handling of methods that encode temps. Just as for methodNode always.
MethodNode
- generateWithSource. embedd pretty printed code in case of doit - remove generateWithTempNames
In general: rewrite code to use #generateWithSource
On Sat, Dec 1, 2012 at 6:24 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: Sebastian
I can tell you that what you did is **useful** because we are all working like mad and such kind of help is really welcome.
Stef
On Dec 1, 2012, at 3:24 PM, Sebastian Nozzi wrote:
It's the #7076.
2012/11/29 Camillo Bruni <camillobruni@gmail.com>:
perfect! can you open a bug report with this information? :)
<MessageNode.GuillermoPolito.cs>
Done :) On Tue, Dec 4, 2012 at 8:46 AM, Marcus Denker <marcus.denker@inria.fr>wrote:
can you just put in in the issue tracker? I have no time right now⦠but mails are such bad TODO trackersâ¦
On Dec 2, 2012, at 10:42 PM, Guillermo Polito <guillermopolito@gmail.com> wrote:
Hi!
I've hacked a fix, but I don't know if it is correct... can somebody check it so I make a Slice?
Guille
On Sun, Dec 2, 2012 at 8:56 PM, Guillermo Polito < guillermopolito@gmail.com> wrote:
Ok, I've found the cause :).
From update 20043:
Issue 5744: Clean up Temp Embedding 2): DoIts http://code.google.com/p/pharo/issues/detail?id=5744
- Doits are now compiled with source embedded - embedding sources for doits pretty prints from AST as doits are compiled specially (with a return added)
CompiledMethod:
- remove blockExtendsToTempsMap: Not needed anymore, all calls go the MethodNode - remove #copyWitTempsFromMethodNode: All senders use #copyWithSource - remove #holdsTempNames. Temp name embedding not needed - add isDoit - schematicTempNamesString always returns the schematic string representation of all temps - tempNames forwards to methodNode - remove tempNamesString. Concatenate yourself if you need that.
Debugger>>selectedMessage asks the selectedContext directly for the source. No need for the methodMap.
DebuggerMethodMap
- no special handling of methods that encode temps. Just as for methodNode always.
MethodNode
- generateWithSource. embedd pretty printed code in case of doit - remove generateWithTempNames
In general: rewrite code to use #generateWithSource
On Sat, Dec 1, 2012 at 6:24 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
Sebastian
I can tell you that what you did is **useful** because we are all working like mad and such kind of help is really welcome.
Stef
On Dec 1, 2012, at 3:24 PM, Sebastian Nozzi wrote:
It's the #7076.
2012/11/29 Camillo Bruni <camillobruni@gmail.com>:
perfect! can you open a bug report with this information? :)
<MessageNode.GuillermoPolito.cs>
On Sat, Dec 1, 2012 at 6:24 PM, Stéphane Ducasse <stephane.ducasse@inria.fr>wrote:
Sebastian
I can tell you that what you did is **useful** because we are all working like mad and such kind of help is really welcome.
+9999
Stef
On Dec 1, 2012, at 3:24 PM, Sebastian Nozzi wrote:
It's the #7076.
2012/11/29 Camillo Bruni <camillobruni@gmail.com>:
perfect! can you open a bug report with this information? :)
-- Mariano http://marianopeck.wordpress.com
excellent! Thanks for your help. On Nov 29, 2012, at 6:27 PM, Sebastian Nozzi wrote:
Done :-) It happens between 20042 (works) and 20047 (error).
2012/11/29 Camillo Bruni <camillobruni@gmail.com>:
if you have time try to figure out in which pharo version the bug appeared... (I should write a tool for that :P)
=> do a binary search over pharo versions http://pharo.gforge.inria.fr/ci/image/20/
On 2012-11-29, at 11:04, Guillermo Polito <guillermopolito@gmail.com> wrote:
Hi!
I was surprised by trying to evaluate the following expression in a workspace:
[[ false ] whileFalse: [ ]]
and getting an error SubscriptOutOfBounds: 1...
The strange thing is that compiling that expression inside a block works, but not in the workspace...
Any idea? Guille
participants (7)
-
Camillo Bruni -
Guillermo Polito -
Marcus Denker -
Mariano Martinez Peck -
Sebastian Nozzi -
Serge Stinckwich -
Stéphane Ducasse