The Trunk: Kernel-eem.1080.mcz

Eliot Miranda uploaded a new version of Kernel to project The Trunk:
http://source.squeak.org/trunk/Kernel-eem.1080.mcz

==================== Summary ====================

Name: Kernel-eem.1080
Author: eem
Time: 30 March 2017, 6:04:09.745358 pm
UUID: b3cbc78a-e6de-4624-ae85-181a64e89c05
Ancestors: Kernel-eem.1079

Replace mention of MethodContext with Context in class comments as appropriate.

=============== Diff against Kernel-eem.1079 ===============

Item was changed:
  InstructionStream variableSubclass: #Context
  instanceVariableNames: 'stackp method closureOrNil receiver'
  classVariableNames: 'MaxLengthForASingleDebugLogReport MaxStackDepthForASingleDebugLogReport PrimitiveFailToken QuickStep ValueIndex'
  poolDictionaries: ''
  category: 'Kernel-Methods'!
 
+ !Context commentStamp: 'eem 3/30/2017 17:27' prior: 0!
- !Context commentStamp: '<historical>' prior: 0!
  My instances hold all the dynamic state associated with the execution of either a method activation resulting from a message send or a block activation resulting from a block evaluation.  In addition to their inherited state, this includes the receiver (self), the closure for a BlockClosure activation (which is nil for a method activation), a CompiledMethod, and space in the variable part of the context for arguments and temporary variables.
 
+ Contexts, though normal in their variable size, are actually only used in two sizes, small and large, which are determined by the temporary space required by the method being executed.
- MethodContexts, though normal in their variable size, are actually only used in two sizes, small and large, which are determined by the temporary space required by the method being executed.
 
+ Contexts must only be created using the method newForMethod:.  Note that it is impossible to determine the real object size of a Context except by asking for the frameSize of its method.  Any fields above the stack pointer (stackp) are truly invisible -- even (and especially!!) to the garbage collector.  Any store into stackp other than by the primitive method stackp: is potentially fatal.!
- MethodContexts must only be created using the method newForMethod:.  Note that it is impossible to determine the real object size of a MethodContext except by asking for the frameSize of its method.  Any fields above the stack pointer (stackp) are truly invisible -- even (and especially!!) to the garbage collector.  Any store into stackp other than by the primitive method stackp: is potentially fatal.!

Item was changed:
  Object subclass: #Exception
  instanceVariableNames: 'messageText tag signalContext handlerContext outerContext'
  classVariableNames: ''
  poolDictionaries: ''
  category: 'Kernel-Exceptions-Kernel'!
 
+ !Exception commentStamp: 'eem 3/30/2017 17:49' prior: 0!
- !Exception commentStamp: '<historical>' prior: 0!
  This is the main class used to implement the exception handling system (EHS).  It plays two distinct roles:  that of the exception, and that of the exception handler.  More specifically, it implements the bulk of the protocols laid out in the ANSI specification - those protocol names are reflected in the message categories.
 
  Exception is an abstract class.  Instances should neither be created nor trapped.  In most cases, subclasses should inherit from Error or Notification rather than directly from Exception.
 
+ In implementing this EHS, The Fourth Estate Inc. incorporated some ideas and code from Craig Latta's EHS.  His insights were crucial in allowing us to implement BlockClosure>>valueUninterruptably (and by extension, #ensure: and #ifCurtailed:), and we imported the following methods with little or no modification:
- In implementing this EHS, The Fourth Estate Inc. incorporated some ideas and code from Craig Latta's EHS.  His insights were crucial in allowing us to implement BlockContext>>valueUninterruptably (and by extension, #ensure: and #ifCurtailed:), and we imported the following methods with little or no modification:
 
+ Context>>terminateTo:
+ Context>>terminate
+ Context>>receiver:
+ Context>>answer:
- ContextPart>>terminateTo:
- ContextPart>>terminate
- MethodContext>>receiver:
- MethodContext>>answer:
 
  Thanks, Craig!!!

Item was changed:
  InstructionClient subclass: #InstVarRefLocator
  instanceVariableNames: 'bingo'
  classVariableNames: ''
  poolDictionaries: ''
  category: 'Kernel-Methods'!
 
+ !InstVarRefLocator commentStamp: 'eem 3/30/2017 17:43' prior: 0!
- !InstVarRefLocator commentStamp: 'md 4/8/2003 12:50' prior: 0!
  My job is to scan bytecodes for instance variable references.
 
+ BlockClosure allInstances collect: [ :x |
+ {x. x method hasInstVarRef}
+ ]!
- BlockContext allInstances collect: [ :x |
- {x. x hasInstVarRef}
- ].!