Eliot Miranda uploaded a new version of Tools to project The Trunk:
http://source.squeak.org/trunk/Tools-eem.702.mcz
==================== Summary ====================
Name: Tools-eem.702
Author: eem
Time: 13 May 2016, 12:50:20.522711 pm
UUID: 6e329560-7a10-4edf-ba1c-eb2ac424ceab
Ancestors: Tools-bf.701
See Kernel-eem.1023. CompiledMethod>>pcPreviousTo: is used in places other thna the debugger, so it has to be in kernel.
=============== Diff against Tools-bf.701 ===============
Item was removed:
- ----- Method: CompiledMethod>>pcPreviousTo: (in category '*Tools-Debugger-support') -----
- pcPreviousTo: thePC
- "Answer the pc of the bytecode before the bytecode at thePC."
- | pc prevPc byte encoderClass |
- self flag: 'belongs in DebuggerMethodMap?'.
- thePC > self endPC ifTrue: [^self endPC].
- pc := self initialPC.
- encoderClass := self encoderClass.
- [pc < thePC] whileTrue:
- [byte := self at: (prevPc := pc).
- [pc := pc + (encoderClass bytecodeSize: byte).
- encoderClass isExtension: byte] whileTrue:
- [byte := self at: pc]].
- ^prevPc!
Eliot Miranda uploaded a new version of Kernel to project The Trunk:
http://source.squeak.org/trunk/Kernel-eem.1023.mcz
==================== Summary ====================
Name: Kernel-eem.1023
Author: eem
Time: 13 May 2016, 12:47:58.825645 pm
UUID: dbe31b16-e7d4-4342-a314-a2faedcc6ce3
Ancestors: Kernel-eem.1022
CompiledMethod>>pcPreviousTo: is used in places other thna the debugger, so it has to be in kernel. Some time it may be replaceable with the new BytecodeEncoder class>>#pcPreviousTo:in:for:, but for now put it in the right package.
=============== Diff against Kernel-eem.1022 ===============
Item was added:
+ ----- Method: CompiledMethod>>pcPreviousTo: (in category 'scanning') -----
+ pcPreviousTo: thePC
+ "Answer the pc of the bytecode before the bytecode at thePC."
+ | pc prevPc byte encoderClass |
+ thePC > self endPC ifTrue: [^self endPC].
+ pc := self initialPC.
+ encoderClass := self encoderClass.
+ [pc < thePC] whileTrue:
+ [byte := self at: (prevPc := pc).
+ [pc := pc + (encoderClass bytecodeSize: byte).
+ encoderClass isExtension: byte] whileTrue:
+ [byte := self at: pc]].
+ ^prevPc!
Eliot Miranda uploaded a new version of Kernel to project The Trunk:
http://source.squeak.org/trunk/Kernel-eem.1022.mcz
==================== Summary ====================
Name: Kernel-eem.1022
Author: eem
Time: 13 May 2016, 12:42:06.679822 pm
UUID: a39b0f45-dcca-4780-aec1-1466aaadd607
Ancestors: Kernel-bf.1021
Revise the fix in Kernel-bf.1019 (Debugger: step over temp vector initializer when entering method). Use the new bytecode scanning mahcinery from Compiler-eem.322 to implement willReallyStore and use it in stepToSendOrReturn to filter-out stores of indirect temp vectors.
=============== Diff against Kernel-bf.1021 ===============
Item was changed:
----- Method: ContextPart>>stepToSendOrReturn (in category 'system simulation') -----
stepToSendOrReturn
"Simulate the execution of bytecodes until either sending a message or
returning a value to the receiver (that is, until switching contexts)."
| ctxt |
+ [self willReallySend or: [self willReturn or: [self willReallyStore]]] whileFalse:
- [self willReallySend or: [self willReturn or: [self willStore]]] whileFalse:
[ctxt := self step.
ctxt == self ifFalse:
[self halt.
"Caused by mustBeBoolean handling"
^ctxt]]!
Item was added:
+ ----- Method: InstructionStream>>willReallyStore (in category 'testing') -----
+ willReallyStore
+ "Answer whether the bytecode at pc is a store or store-pop into an explicit variable.
+ This eliminates stores into indirect temp vectors, which implement mutable closed-over
+ variables in the the closure implementation, and hence stores into temp vectors are not real stores."
+ | method |
+ method := self method.
+ ^method encoderClass isNonSyntheticStoreAt: pc in: method for: self!
Item was removed:
- ----- Method: MethodContext>>stepToSendOrReturn (in category 'system simulation') -----
- stepToSendOrReturn
- ((method at: pc) == 16r8A "push new array" and: [pc = method initialPC]) ifTrue: [
- (method at: pc+2) = 16r68 ifFalse: [self error: 'assumed pop into temp0 bytecode'].
- "init temp vector first"
- self step; step].
- ^super stepToSendOrReturn!
Eliot Miranda uploaded a new version of Compiler to project The Trunk:
http://source.squeak.org/trunk/Compiler-eem.322.mcz
==================== Summary ====================
Name: Compiler-eem.322
Author: eem
Time: 13 May 2016, 12:36:54.992126 pm
UUID: b7bb5d79-1a2e-4a45-a6cc-dd0a8cf438bb
Ancestors: Compiler-nice.321
Add bytecode scanning machinery to identify "synthetic" stores, i.e. the stores of indirect temp vectors at the start of methods containing closures.
Add a "high-quality" pcPreviousTo:in:for: that answers nil for the first pcs of blocks, and answers the block creation bytecode's pc for the pc following an embedded block, and use it to disambiguate bytecode sequences that look like pushNewArray of an empty array..
Add isTempStoreAt:in: & pcFollowingBlockAt:in: to support the above.
=============== Diff against Compiler-nice.321 ===============
Item was added:
+ ----- Method: BytecodeEncoder class>>createClosureCode (in category 'bytecode decoding') -----
+ createClosureCode
+ "Answer the create closure bytecode, if it exists in the encoder's byetcode set, or nil if not."
+ ^nil!
Item was added:
+ ----- Method: BytecodeEncoder class>>isNonSyntheticStoreAt:in:for: (in category 'instruction stream support') -----
+ isNonSyntheticStoreAt: pc in: method for: anInstructionStream
+ "Answer whether the bytecode at pc is a store or store-pop into an explicit variable.
+ This eliminates stores into indirect temp vectors, which implement mutable closed-over
+ variables in the the closure implementation, and hence stores into temp vectors are not real stores."
+
+ ^(self isStoreAt: pc in: method)
+ and: [(self isSyntheticStoreAt: pc in: method for: anInstructionStream) not]!
Item was added:
+ ----- Method: BytecodeEncoder class>>isSyntheticStoreAt:in:for: (in category 'instruction stream support') -----
+ isSyntheticStoreAt: pc in: method for: anInstructionStream
+ "Answer whether the bytecode at pc is a store or store-pop of an indirect temp vector,
+ which implement mutable closed-over variables in the the closure implementation.
+ Stores into temp vectors are not real stores."
+
+ self subclassResponsibility!
Item was added:
+ ----- Method: BytecodeEncoder class>>pcFollowingBlockAt:in: (in category 'bytecode decoding') -----
+ pcFollowingBlockAt: pc in: method
+ "Assuming the pc is that of a block creation bytecode, answer the pc immediately following the block,
+ i.e. the next pc after the block creation."
+ self subclassResponsibility!
Item was added:
+ ----- Method: BytecodeEncoder class>>pcPreviousTo:in:for: (in category 'bytecode decoding') -----
+ pcPreviousTo: thePC in: method for: anInstructionStreamOrContext
+ "Answer the pc of the bytecode before the bytecode at thePC.
+ Unlike CompiledMethod>>pcPreviousTo:, this version answers nil for
+ the first bytecode of an embedded block, and answers the pc of the
+ block creation bytecode for a bytecode following an embedded block."
+ | pc nextPc prevPc byte createClosureCode |
+ thePC > method endPC ifTrue:
+ [^method endPC].
+ pc := method initialPC.
+ "We could save time by scanning from the block creation bytecode of an embedded block,
+ using the following, but it saves less time than it loses in additional tests."
+ "(anInstructionStreamOrContext isContext
+ and: [anInstructionStreamOrContext isClosureContext
+ and: [(nextPc := anInstructionStreamOrContext startpc) > pc]]) ifTrue:
+ [pc := self pcOfBlockCreationBytecodeForBlockStartingAt: nextPc in: method]."
+ createClosureCode := self createClosureCode.
+ [pc < thePC] whileTrue:
+ [byte := method at: (prevPc := pc).
+ [pc := createClosureCode == byte
+ ifTrue:
+ [nextPc := self pcFollowingBlockAt: pc in: method.
+ nextPc = thePC ifTrue: "first bytecode following block"
+ [^prevPc].
+ nextPc > thePC
+ ifTrue:
+ [pc + (self bytecodeSize: byte) = thePC ifTrue: "first bytecode of block"
+ [^nil].
+ pc + (self bytecodeSize: byte)]
+ ifFalse: [nextPc]]
+ ifFalse: [pc + (self bytecodeSize: byte)].
+ self isExtension: byte] whileTrue:
+ [byte := method at: pc]].
+ ^prevPc
+
+ "Here's code to measure the effect of short-cutting scanning for blocks by starting at the startpc.
+ It measures how much time is used to scan for the pcs from the last block to the end of all mwetods containing blocks. Uncomment out the short-cut above to compare time with the optimization and time without. I see approximately 290ms for all such methods with the optimization and 292 ms without, so given that this slows down the substantial majority of methods without blocks, we KISS."
+ "| candidates |
+ candidates := Dictionary new.
+ self systemNavigation allSelect:
+ [:m| | ebc |
+ (m isQuick or: [(ebc := m embeddedBlockClosures) isEmpty]) ifFalse:
+ [candidates at: m put: { ebc last.
+ Array streamContents:
+ [:s| | is |
+ (is:= InstructionStream on: m)
+ pc: ebc last startpc;
+ scanFor:
+ [:b|
+ s nextPut: is pc.
+ false]] }].
+ false].
+ (1 to: 10) collect:
+ [:ign|
+ { [candidates keysAndValuesDo:
+ [:m :tuple|
+ [:ebc :pcs| | c |
+ c := ebc outerContext.
+ pcs do:
+ [:pc| m encoderClass pcPreviousTo: pc in: m for: c]] valueWithArguments: tuple]] timeToRun.
+ [candidates keysAndValuesDo:
+ [:m :tuple|
+ [:ebc :pcs| | c |
+ c := ebc outerContext.
+ pcs do:
+ [:pc| m encoderClass pcPreviousTo: pc in: m for: nil]] valueWithArguments: tuple]] timeToRun. }]"!
Item was added:
+ ----- Method: BytecodeEncoder class>>pushNewArrayCode (in category 'bytecode decoding') -----
+ pushNewArrayCode
+ "Answer the pushNewArray bytecode, if it exists in the encoder's byetcode set, or nil if not."
+ ^nil!
Item was added:
+ ----- Method: EncoderForV3 class>>isSyntheticStoreAt:in:for: (in category 'instruction stream support') -----
+ isSyntheticStoreAt: pc in: method for: anInstructionStream
+ "Answer whether the bytecode at pc is a store or store-pop of an indirect temp vector,
+ which implement mutable closed-over variables in the the closure implementation.
+ Stores into temp vectors are not real stores."
+
+ ^false!
Item was added:
+ ----- Method: EncoderForV3 class>>isTempStoreAt:in: (in category 'instruction stream support') -----
+ isTempStoreAt: pc in: method
+ "Answer whether the bytecode at pc is a store or store-pop into a temporary variable.
+ 104-111 01101iii Pop and Store Temporary Location #iii
+ 129 10000001 jjkkkkkk Store (Receiver Variable, Temporary Location, Illegal, Literal Variable) [jj] #kkkkkk
+ 130 10000010 jjkkkkkk Pop and Store (Receiver Variable, Temporary Location, Illegal, Literal Variable) [jj] #kkkkkk"
+
+ | byte |
+ byte := method at: pc.
+ ^byte >= 104
+ and: [byte <= 111
+ or: [byte <= 130 and: [byte >= 129 and: [(method at: pc + 1) >> 6 = 1]]]]!
Item was added:
+ ----- Method: EncoderForV3PlusClosures class>>createClosureCode (in category 'bytecode decoding') -----
+ createClosureCode
+ "Answer the create closure bytecode, if it exists in the encoder's byetcode set, or nil if not."
+ ^143!
Item was added:
+ ----- Method: EncoderForV3PlusClosures class>>isSyntheticStoreAt:in:for: (in category 'instruction stream support') -----
+ isSyntheticStoreAt: pc in: method for: anInstructionStream
+ "Answer whether the bytecode at pc is a store or store-pop of an indirect temp vector,
+ which implement mutable closed-over variables in the the closure implementation.
+ Stores into temp vectors are not real stores. N.B. pcPreviousTo:in:for: is slow, so filter
+ out any preceding bytecodes other than what looks like a pushNewArrayCode. But the
+ pcPreviousTo:in:for: is still necessary, since the presence of a pcPreviousTo:in:for: in the
+ right place is potentially ambiguous, possibly part of a different bytecode seqence."
+
+ ^(self isTempStoreAt: pc in: method)
+ and: [pc - 2 >= method initialPC
+ and: [(method at: pc - 2) = self pushNewArrayCode
+ and: [(method at: pc - 1) <= 127
+ and: [pc - 2 = (self pcPreviousTo: pc in: method for: anInstructionStream)]]]]!
Item was added:
+ ----- Method: EncoderForV3PlusClosures class>>pcFollowingBlockAt:in: (in category 'bytecode decoding') -----
+ pcFollowingBlockAt: pc in: method
+ "Assuming the pc is that of a block creation bytecode, answer the pc immediately following the block,
+ i.e. the next pc after the block creation."
+ self assert: (method at: pc) = self createClosureCode.
+ ^(method at: pc + 2) * 256 + (method at: pc + 3) + pc + 4!
Item was added:
+ ----- Method: EncoderForV3PlusClosures class>>pushNewArrayCode (in category 'bytecode decoding') -----
+ pushNewArrayCode
+ "138 10001010 jkkkkkkk Push (Array new: kkkkkkk) (j = 0)
+ or Pop kkkkkkk elements into: (Array new: kkkkkkk) (j = 1)"
+ ^138!
Marcel Taeumel uploaded a new version of Collections to project The Trunk:
http://source.squeak.org/trunk/Collections-mt.693.mcz
==================== Summary ====================
Name: Collections-mt.693
Author: mt
Time: 13 May 2016, 9:37:08.465429 pm
UUID: 68109039-441c-e344-a65b-e5b114d57cfa
Ancestors: Collections-mt.692
Extend the TranscriptStream's model protocol to support "Window Active On First Click" preference. Usually, only subclasses of Model behave accordingly. Other "models" have to mimick the protocol.
=============== Diff against Collections-mt.692 ===============
Item was added:
+ ----- Method: TranscriptStream>>windowActiveOnFirstClick (in category 'model protocol') -----
+ windowActiveOnFirstClick
+
+ ^ Model windowActiveOnFirstClick!
Marcel Taeumel uploaded a new version of ReleaseBuilder to project The Trunk:
http://source.squeak.org/trunk/ReleaseBuilder-mt.133.mcz
==================== Summary ====================
Name: ReleaseBuilder-mt.133
Author: mt
Time: 13 May 2016, 5:50:05.366492 pm
UUID: 446f4aae-bbcc-f744-8997-ddeed31e8ebd
Ancestors: ReleaseBuilder-mt.132
Condense changes.
Note that we may want to have more control about the contents in the changes file for the release process. Right now, it is based on the local changes only. We could, for example, fetch all updates since the last release and rewrite the changes file. This would yield a consistent output and the versions browser would be more fun to use in a new release.
=============== Diff against ReleaseBuilder-mt.132 ===============
Item was changed:
----- Method: ReleaseBuilder class>>prepareSourceCode (in category 'preparing') -----
prepareSourceCode
"Update code. Remove foreign packages."
MCMcmUpdater defaultUpdateURL: self buildRepository description.
MCMcmUpdater updateMissingPackages: true.
MCMcmUpdater enableUpdatesForAllPackages.
MCMcmUpdater default doUpdate: false. "non-interactive".
self
unloadForeignPackages;
checkForDirtyPackages;
loadWellKnownPackages.
+ Compiler recompileAll.
+ Smalltalk condenseChanges.!
- Compiler recompileAll.!
Marcel Taeumel uploaded a new version of Morphic to project The Trunk:
http://source.squeak.org/trunk/Morphic-mt.1147.mcz
==================== Summary ====================
Name: Morphic-mt.1147
Author: mt
Time: 13 May 2016, 3:11:29.319874 pm
UUID: 95a039a1-366d-1e4e-9ed6-eb5e4970c82d
Ancestors: Morphic-mt.1146
Remove the lockOffset variable. Let's hope that all open tools survive this...
=============== Diff against Morphic-mt.1146 ===============
Item was changed:
MorphicModel subclass: #ScrollPane
+ instanceVariableNames: 'scrollBar scroller retractableScrollBar scrollBarOnLeft getMenuSelector getMenuTitleSelector hasFocus hScrollBar hScrollBarPolicy vScrollBarPolicy scrollBarThickness'
- instanceVariableNames: 'scrollBar scroller retractableScrollBar scrollBarOnLeft getMenuSelector getMenuTitleSelector hasFocus hScrollBar lockOffset hScrollBarPolicy vScrollBarPolicy scrollBarThickness'
classVariableNames: 'UseRetractableScrollBars'
poolDictionaries: ''
category: 'Morphic-Windows'!
!ScrollPane commentStamp: 'mk 8/9/2005 10:34' prior: 0!
The scroller (a transform) of a scrollPane is driven by the scrollBar. The scroll values vary from 0.0, meaning zero offset to 1.0 meaning sufficient offset such that the bottom of the scrollable material appears 3/4 of the way down the pane. The total distance to achieve this range is called the totalScrollRange.
Basic clue about utilization of the ScrollPane class is given in:
ScrollPane example1.
ScrollPane example2.!
Marcel Taeumel uploaded a new version of Morphic to project The Trunk:
http://source.squeak.org/trunk/Morphic-mt.1146.mcz
==================== Summary ====================
Name: Morphic-mt.1146
Author: mt
Time: 13 May 2016, 3:02:50.901874 pm
UUID: f43bc24f-46a0-244f-ab6a-7a6959af9326
Ancestors: Morphic-mt.1145
Forgot to restore the "== true" pattern here. Be more robust against strange models...
=============== Diff against Morphic-mt.1145 ===============
Item was changed:
----- Method: PluggableTextMorph>>accept (in category 'menu commands') -----
accept
"Inform the model of text to be accepted, and return true if OK."
| priorSelection priorScrollerOffset |
(self canDiscardEdits and: [(self hasProperty: #alwaysAccept) not])
ifTrue: [^ self flash].
self hasEditingConflicts ifTrue: [
(self confirm: 'Caution!! This method may have been\changed elsewhere since you started\editing it here. Accept anyway?' withCRs translated) ifFalse: [^ self flash]].
priorSelection := self selectionInterval copy.
priorScrollerOffset := scroller offset copy.
+ self acceptTextInModel == true
- self acceptTextInModel
ifFalse: [^ self "something went wrong"].
self setText: self getText.
self hasUnacceptedEdits: false.
(model dependents
detect: [:dep | (dep isKindOf: PluggableTextMorph) and: [dep getTextSelector == #annotation]]
ifNone: [nil])
ifNotNil: [:aPane | model changed: #annotation].
"Update the model's internal caches. Note that this is specific to CodeHolder and the stepping it uses for updating. We have to trigger this here manually to avoid that the next step message destroys our selection and scrolling offset."
(model respondsTo: #updateCodePaneIfNeeded)
ifTrue: [model updateCodePaneIfNeeded].
"Restore prior selection:"
scroller offset: priorScrollerOffset.
selectionInterval := priorSelection.
self selectFrom: priorSelection first to: priorSelection last.!