Actually, I think that when single-line-stepping with Richo's new Scriptor debugger feature, if an object's pen is down and a line of script is executed that moves the object, a pen trail *should* be put down, even if "batchPenTrails" is in effect. A semantic argument for this choice can be made, given the definition of "batchPenTrails", but my preference is based just on common sense and least surprise.
(And anyone with experience with debugging any live system knows that the when you single-step at leisure through something that normally is happening in a flash, you're running the code in a different context and you're going to encounter differences...).
If doing turtle-graphics of the sort in Karl's example, one probably does not want "batchPenTrails" to be turned on in the first place.
-- Scott
On Feb 3, 2012, at 11:31 PM, commits@source.squeak.org wrote:
Ricardo Moran uploaded a new version of Etoys to project Etoys: http://source.squeak.org/etoys/Etoys-Richo.100.mcz
==================== Summary ====================
Name: Etoys-Richo.100 Author: Richo Time: 3 February 2012, 8:30:10 pm UUID: f95a393c-27a3-e541-a345-4fd66b47cd8f Ancestors: Etoys-kfr.99
- Fixed step button behavior when #batchPenTrails option is on.
=============== Diff against Etoys-kfr.99 ===============
Item was changed: Object subclass: #EtoysDebugger
- instanceVariableNames: 'scriptEditor next timesToRepeat highlighter startingPosition'
- instanceVariableNames: 'scriptEditor next timesToRepeat highlighter' classVariableNames: '' poolDictionaries: '' category: 'Etoys-Debugger'!
Item was changed:
- ----- Method: EtoysDebugger>>delete (in category 'initialization') -----
- ----- Method: EtoysDebugger>>delete (in category 'as yet unclassified') -----
delete highlighter ifNotNil: [:h | h delete]!
Item was changed: ----- Method: EtoysDebugger>>evaluateNextTile (in category 'evaluating') ----- evaluateNextTile
- [next = (scriptEditor tiles at: 1 ifAbsent: [nil])
ifTrue: ["We are about to evaluate the first tile"
self updateStartingPosition].
- self trailMorph batchPenTrails
ifTrue: [self evaluateNextTileWithBatchPenTrails]
ifFalse: [next evaluateOn: self]]
- [next evaluateOn: self] on: Error do: [:err || newNext | newNext := scriptEditor tiles at: 1 ifAbsent: [^ self]. newNext = next ifTrue: [err pass] ifFalse: [next := newNext].
self evaluateNextTile]
- !
self evaluateNextTile]!
Item was added:
- ----- Method: EtoysDebugger>>evaluateNextTileWithBatchPenTrails (in category 'evaluating') -----
- evaluateNextTileWithBatchPenTrails
- | penDown |
- penDown := self scriptedPlayer getPenDown.
- self scriptedPlayer setPenDown: false.
- [next evaluateOn: self]
ensure: [self scriptedPlayer setPenDown: penDown].
- (penDown and: [next = (scriptEditor tiles at: 1 ifAbsent: [nil])])
ifTrue: [| trailMorph tfm |
"We've just evaluated the last tile, we should draw pen trail"
trailMorph := self trailMorph.
tfm := self scriptedPlayer costume owner transformFrom: trailMorph.
trailMorph
drawPenTrailFor: self scriptedPlayer costume
from: (tfm localPointToGlobal: startingPosition)
to: (tfm localPointToGlobal: self scriptedPlayerPosition)]!
Item was changed: ----- Method: EtoysDebugger>>initializeWith: (in category 'initialization') ----- initializeWith: aScriptEditorMorph scriptEditor := aScriptEditorMorph. next := scriptEditor tiles at: 1 ifAbsent: nil.
- self updateStartingPosition;
initialize!
- self initialize!
Item was added:
- ----- Method: EtoysDebugger>>scriptedPlayer (in category 'accessing') -----
- scriptedPlayer
- ^ scriptEditor playerScripted!
Item was added:
- ----- Method: EtoysDebugger>>scriptedPlayerPosition (in category 'accessing') -----
- scriptedPlayerPosition
- ^ self scriptedPlayer costume
ifNil: [0@0]
ifNotNil: [:m | m referencePosition]!
Item was added:
- ----- Method: EtoysDebugger>>trailMorph (in category 'accessing') -----
- trailMorph
- ^ self scriptedPlayer costume ifNil: [World] ifNotNil: [:m | m trailMorph]!
Item was added:
- ----- Method: EtoysDebugger>>updateStartingPosition (in category 'initialization') -----
- updateStartingPosition
- startingPosition := self scriptedPlayerPosition!
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
Well, I would've thought that the end result of executing a script should be the same whether you step trough it or not. However, I think the batch pen trails issue is most of the times irrelevant and it overly complicates the code. So, I agree with you, but I would like to hear Karl's opinion on this.
Cheers, Richo
On Mon, Feb 6, 2012 at 9:21 PM, Scott Wallace scott.wallace@squeakland.orgwrote:
Actually, I think that when single-line-stepping with Richo's new Scriptor debugger feature, if an object's pen is down and a line of script is executed that moves the object, a pen trail *should* be put down, even if "batchPenTrails" is in effect. A semantic argument for this choice can be made, given the definition of "batchPenTrails", but my preference is based just on common sense and least surprise.
(And anyone with experience with debugging any live system knows that the when you single-step at leisure through something that normally is happening in a flash, you're running the code in a different context and you're going to encounter differences...).
If doing turtle-graphics of the sort in Karl's example, one probably does not want "batchPenTrails" to be turned on in the first place.
-- Scott
On Feb 3, 2012, at 11:31 PM, commits@source.squeak.org wrote:
Ricardo Moran uploaded a new version of Etoys to project Etoys: http://source.squeak.org/etoys/Etoys-Richo.100.mcz
==================== Summary ====================
Name: Etoys-Richo.100 Author: Richo Time: 3 February 2012, 8:30:10 pm UUID: f95a393c-27a3-e541-a345-4fd66b47cd8f Ancestors: Etoys-kfr.99
- Fixed step button behavior when #batchPenTrails option is on.
=============== Diff against Etoys-kfr.99 ===============
Item was changed: Object subclass: #EtoysDebugger
instanceVariableNames: 'scriptEditor next timesToRepeat
highlighter startingPosition'
instanceVariableNames: 'scriptEditor next timesToRepeat
highlighter'
classVariableNames: '' poolDictionaries: '' category: 'Etoys-Debugger'!
Item was changed:
- ----- Method: EtoysDebugger>>delete (in category 'initialization')
- ----- Method: EtoysDebugger>>delete (in category 'as yet
unclassified') -----
delete highlighter ifNotNil: [:h | h delete]!
Item was changed: ----- Method: EtoysDebugger>>evaluateNextTile (in category
'evaluating') -----
evaluateNextTile
[next = (scriptEditor tiles at: 1 ifAbsent: [nil])
ifTrue: ["We are about to evaluate the first tile"
self updateStartingPosition].
self trailMorph batchPenTrails
ifTrue: [self evaluateNextTileWithBatchPenTrails]
ifFalse: [next evaluateOn: self]]
[next evaluateOn: self] on: Error do: [:err || newNext | newNext := scriptEditor tiles at: 1 ifAbsent: [^
self].
newNext = next ifTrue: [err pass] ifFalse: [next := newNext].
self evaluateNextTile]
- !
self evaluateNextTile]!
Item was added:
- ----- Method: EtoysDebugger>>evaluateNextTileWithBatchPenTrails (in
category 'evaluating') -----
- evaluateNextTileWithBatchPenTrails
| penDown |
penDown := self scriptedPlayer getPenDown.
self scriptedPlayer setPenDown: false.
[next evaluateOn: self]
ensure: [self scriptedPlayer setPenDown: penDown].
(penDown and: [next = (scriptEditor tiles at: 1 ifAbsent: [nil])])
ifTrue: [| trailMorph tfm |
"We've just evaluated the last tile, we should
draw pen trail"
trailMorph := self trailMorph.
tfm := self scriptedPlayer costume owner
transformFrom: trailMorph.
trailMorph
drawPenTrailFor: self scriptedPlayer
costume
from: (tfm localPointToGlobal:
startingPosition)
to: (tfm localPointToGlobal: self
scriptedPlayerPosition)]!
Item was changed: ----- Method: EtoysDebugger>>initializeWith: (in category
'initialization') -----
initializeWith: aScriptEditorMorph scriptEditor := aScriptEditorMorph. next := scriptEditor tiles at: 1 ifAbsent: nil.
self updateStartingPosition;
initialize!
self initialize!
Item was added:
- ----- Method: EtoysDebugger>>scriptedPlayer (in category 'accessing')
- scriptedPlayer
^ scriptEditor playerScripted!
Item was added:
- ----- Method: EtoysDebugger>>scriptedPlayerPosition (in category
'accessing') -----
- scriptedPlayerPosition
^ self scriptedPlayer costume
ifNil: [0@0]
ifNotNil: [:m | m referencePosition]!
Item was added:
- ----- Method: EtoysDebugger>>trailMorph (in category 'accessing') -----
- trailMorph
^ self scriptedPlayer costume ifNil: [World] ifNotNil: [:m | m
trailMorph]!
Item was added:
- ----- Method: EtoysDebugger>>updateStartingPosition (in category
'initialization') -----
- updateStartingPosition
startingPosition := self scriptedPlayerPosition!
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
On Tue, Feb 7, 2012 at 1:21 AM, Scott Wallace scott.wallace@squeakland.org wrote:
Actually, I think that when single-line-stepping with Richo's new Scriptor debugger feature, if an object's pen is down and a line of script is executed that moves the object, a pen trail *should* be put down, even if "batchPenTrails" is in effect. A semantic argument for this choice can be made, given the definition of "batchPenTrails", but my preference is based just on common sense and least surprise.
I'm not sure what is the least surprise: that the program behaves differently when single stepping or if its batching over like when it ticking. I find both sides of the argument have it's points.
But maybe we should ask why do we have batchPenTrials visible in etoyFriendly mode in the first place? Because it's a very frustrating issue to encounter if its accidentally turned on.
(And anyone with experience with debugging any live system knows that the when you single-step at leisure through something that normally is happening in a flash, you're running the code in a different context and you're going to encounter differences...).
If doing turtle-graphics of the sort in Karl's example, one probably does not want "batchPenTrails" to be turned on in the first place.
True. What is the use case for batching pen trials ?
Karl
-- Scott
On Feb 3, 2012, at 11:31 PM, commits@source.squeak.org wrote:
Ricardo Moran uploaded a new version of Etoys to project Etoys: http://source.squeak.org/etoys/Etoys-Richo.100.mcz
==================== Summary ====================
Name: Etoys-Richo.100 Author: Richo Time: 3 February 2012, 8:30:10 pm UUID: f95a393c-27a3-e541-a345-4fd66b47cd8f Ancestors: Etoys-kfr.99
- Fixed step button behavior when #batchPenTrails option is on.
=============== Diff against Etoys-kfr.99 ===============
Item was changed: Object subclass: #EtoysDebugger
- instanceVariableNames: 'scriptEditor next timesToRepeat highlighter startingPosition'
- instanceVariableNames: 'scriptEditor next timesToRepeat highlighter'
classVariableNames: '' poolDictionaries: '' category: 'Etoys-Debugger'!
Item was changed:
- ----- Method: EtoysDebugger>>delete (in category 'initialization') -----
- ----- Method: EtoysDebugger>>delete (in category 'as yet unclassified') -----
delete highlighter ifNotNil: [:h | h delete]!
Item was changed: ----- Method: EtoysDebugger>>evaluateNextTile (in category 'evaluating') ----- evaluateNextTile
- [next = (scriptEditor tiles at: 1 ifAbsent: [nil])
- ifTrue: ["We are about to evaluate the first tile"
- self updateStartingPosition].
- self trailMorph batchPenTrails
- ifTrue: [self evaluateNextTileWithBatchPenTrails]
- ifFalse: [next evaluateOn: self]]
- [next evaluateOn: self]
on: Error do: [:err || newNext | newNext := scriptEditor tiles at: 1 ifAbsent: [^ self]. newNext = next ifTrue: [err pass] ifFalse: [next := newNext].
- self evaluateNextTile]
- !
- self evaluateNextTile]!
Item was added:
- ----- Method: EtoysDebugger>>evaluateNextTileWithBatchPenTrails (in category 'evaluating') -----
- evaluateNextTileWithBatchPenTrails
- | penDown |
- penDown := self scriptedPlayer getPenDown.
- self scriptedPlayer setPenDown: false.
- [next evaluateOn: self]
- ensure: [self scriptedPlayer setPenDown: penDown].
- (penDown and: [next = (scriptEditor tiles at: 1 ifAbsent: [nil])])
- ifTrue: [| trailMorph tfm |
- "We've just evaluated the last tile, we should draw pen trail"
- trailMorph := self trailMorph.
- tfm := self scriptedPlayer costume owner transformFrom: trailMorph.
- trailMorph
- drawPenTrailFor: self scriptedPlayer costume
- from: (tfm localPointToGlobal: startingPosition)
- to: (tfm localPointToGlobal: self scriptedPlayerPosition)]!
Item was changed: ----- Method: EtoysDebugger>>initializeWith: (in category 'initialization') ----- initializeWith: aScriptEditorMorph scriptEditor := aScriptEditorMorph. next := scriptEditor tiles at: 1 ifAbsent: nil.
- self updateStartingPosition;
- initialize!
- self initialize!
Item was added:
- ----- Method: EtoysDebugger>>scriptedPlayer (in category 'accessing') -----
- scriptedPlayer
- ^ scriptEditor playerScripted!
Item was added:
- ----- Method: EtoysDebugger>>scriptedPlayerPosition (in category 'accessing') -----
- scriptedPlayerPosition
- ^ self scriptedPlayer costume
- ifNil: [0@0]
- ifNotNil: [:m | m referencePosition]!
Item was added:
- ----- Method: EtoysDebugger>>trailMorph (in category 'accessing') -----
- trailMorph
- ^ self scriptedPlayer costume ifNil: [World] ifNotNil: [:m | m trailMorph]!
Item was added:
- ----- Method: EtoysDebugger>>updateStartingPosition (in category 'initialization') -----
- updateStartingPosition
- startingPosition := self scriptedPlayerPosition!
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
What is the use case for batching pen trials ?
Here's the earliest mention I find of it in my email archive -- from an email from Dan Ingalls, May 25 2000:
Beginning with the balloon help for that preference (it's in the 'scripting' category; you have to open a new preferences panel after filing in the file in order to see it)...
"batchPenTrails: Ignores the detailed movement of pens between display updates. Thus multiple line segments drawn within a script may not be seen individually."
This feature allows you to write scripts such as joe's x := joe's x + vx. joe's y := joe's y + vy. and see a smooth resulting line instead of an x-y stairstep.
The downside is that if you happen to write joe forward: 50. joe turn: 45. joe forward: 50. joe turn: 45. and run that script, you will neither see 45-degree angles nor sides of length 50. What it draws is the square formed by the lines from the beginning to the end of the script (ie a square inscribed inside the octagon that you might expect).
Hi, today I encounter two bugs with the step over button and the #batchPenTrails mechanism. One was an etoys bug (fixed) and the other is easy to fix, but I fear this #batchPenTrails issue has complicated the code with very few benefits, so I now vote for taking it back.
Cheers, Richo
On Mon, Feb 13, 2012 at 5:45 PM, Scott Wallace <scott.wallace@squeakland.org
wrote:
What is the use case for batching pen trials ?
Here's the earliest mention I find of it in my email archive -- from an email from Dan Ingalls, May 25 2000:
Beginning with the balloon help for that preference (it's in the
'scripting' category; you have to open a new preferences panel after filing in the file in order to see it)...
"batchPenTrails: Ignores the detailed movement of pens between display updates. Thus multiple line segments drawn within a script may not be seen individually."
This feature allows you to write scripts such as joe's x := joe's x + vx. joe's y := joe's y + vy. and see a smooth resulting line instead of an x-y stairstep.
The downside is that if you happen to write joe forward: 50. joe turn: 45. joe forward: 50. joe turn: 45. and run that script, you will neither see 45-degree angles nor sides of
length 50. What it draws is the square formed by the lines from the beginning to the end of the script (ie a square inscribed inside the octagon that you might expect). _______________________________________________ etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
etoys-dev@lists.squeakfoundation.org