Packages March 2017

packages@lists.squeakfoundation.org

1 participants
168 discussions

The Trunk: Compression-nice.52.mcz
by commits＠source.squeak.org 31 Mar '17

31 Mar '17

Nicolas Cellier uploaded a new version of Compression to project The Trunk: http://source.squeak.org/trunk/Compression-nice.52.mcz ==================== Summary ==================== Name: Compression-nice.52 Author: nice Time: 1 April 2017, 12:30:20.191934 am UUID: 470505e6-d35d-450a-9804-29b904c5853d Ancestors: Compression-ul.51 Correct a bug that can cause ZlibPlugin to read past the zipCollection boundary in DeflateBlock. If the plugin is disabled, there will be a 'subscript is out of bounds: 65537' in DeflateStream fallback code. ByteString(Object)>>error: ByteString(Object)>>errorSubscriptBounds: ByteString(Object)>>at: ByteString>>at: ByteString>>byteAt: GZipWriteStream(DeflateStream)>>updateHashAt: GZipWriteStream(DeflateStream)>>insertStringAt: GZipWriteStream(DeflateStream)>>deflateBlock:chainLength:goodMatch: GZipWriteStream(ZipWriteStream)>>deflateBlock:chainLength:goodMatch: GZipWriteStream(DeflateStream)>>deflateBlock GZipWriteStream(DeflateStream)>>next:putAll:startingAt: GZipWriteStream(DeflateStream)>>nextPutAll: ByteString(String)>>zipped This bug is triggered by some input data, for example if you extract the snapshot.bin file from the zip archive the archive http://source.squeak.org/VMMaker/VMMaker.oscog-nice.794.mcz We need MinMatch bytes to insert the string following the best match. (confirmed by comment near the end of a C version http://git.savannah.gnu.org/cgit/gzip.git/tree/deflate.c) Since we pass lastIndex-1 to the primitive, and that the longest match can be up to MaxMatch, we are going to read the zipCollection up to: lastIndex - 1 + MaxMatch - 1 + MinMatch - 1 (0 based) Thus we must have: lastIndex - 1 + MaxMatch - 1 + MinMatch - 1 < writeLimit We have MinMatch = 3, thus the simplification lastIndex + MaxMatch < writeLimit Thus the requirement: lastIndex + MaxMatch + 1 <= writeLimit =============== Diff against Compression-ul.51 =============== Item was changed: ----- Method: DeflateStream>>deflateBlock (in category 'deflating') ----- deflateBlock "Deflate the current contents of the stream" | flushNeeded lastIndex | (blockStart == nil) ifTrue:[ "One time initialization for the first block" 1 to: MinMatch-1 do:[:i| self updateHashAt: i]. blockStart := 0]. [blockPosition < position] whileTrue:[ + (position + MaxMatch + 1 > writeLimit) + ifTrue:[lastIndex := writeLimit - MaxMatch - 1] - (position + MaxMatch > writeLimit) - ifTrue:[lastIndex := writeLimit - MaxMatch] ifFalse:[lastIndex := position]. flushNeeded := self deflateBlock: lastIndex-1 chainLength: self hashChainLength goodMatch: self goodMatchLength. flushNeeded ifTrue:[ self flushBlock. blockStart := blockPosition]. "Make room for more data" self moveContentsToFront]. !

1 0

The Trunk: Kernel-eem.1081.mcz
by commits＠source.squeak.org 31 Mar '17

31 Mar '17

Eliot Miranda uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-eem.1081.mcz ==================== Summary ==================== Name: Kernel-eem.1081 Author: eem Time: 31 March 2017, 9:31:25.428558 am UUID: ef0a2820-8b5e-4e17-847f-6a802a426afd Ancestors: Kernel-eem.1080 Move MethodContext's binding to Undeclared. =============== Diff against Kernel-eem.1080 =============== Item was added: + (PackageInfo named: 'Kernel') postscript: '"below, add code to be run after the loading of this package" + (Smalltalk globals includesKey: #MethodContext) ifTrue: + [Undeclared declare: #MethodContext from: Smalltalk globals]'!

1 0

The Trunk: KernelTests-eem.327.mcz
by commits＠source.squeak.org 31 Mar '17

31 Mar '17

Eliot Miranda uploaded a new version of KernelTests to project The Trunk: http://source.squeak.org/trunk/KernelTests-eem.327.mcz ==================== Summary ==================== Name: KernelTests-eem.327 Author: eem Time: 31 March 2017, 9:02:18.123091 am UUID: dfec8010-9c25-4ac3-8557-4470e3291ca5 Ancestors: KernelTests-eem.326 Another MethodContext => Context change. =============== Diff against KernelTests-eem.326 =============== Item was changed: ----- Method: MethodContextTest>>testReturn (in category 'tests') ----- testReturn "Why am I overriding setUp? Because sender must be thisContext, i.e, testReturn, not setUp." + aMethodContext := Context sender: thisContext receiver: aReceiver method: aCompiledMethod arguments: #(). + self assert: (aMethodContext return: 5) = 5! - aMethodContext := MethodContext sender: thisContext receiver: aReceiver method: aCompiledMethod arguments: #(). - self assert: (aMethodContext return: 5) = 5.!

1 0

The Trunk: Tools-eem.754.mcz
by commits＠source.squeak.org 31 Mar '17

31 Mar '17

Eliot Miranda uploaded a new version of Tools to project The Trunk: http://source.squeak.org/trunk/Tools-eem.754.mcz ==================== Summary ==================== Name: Tools-eem.754 Author: eem Time: 30 March 2017, 6:07:58.127843 pm UUID: 961c220b-163f-4034-92c6-2ce4faec8d06 Ancestors: Tools-eem.753 Replace mention of MethodContext with Context in class comments as appropriate. =============== Diff against Tools-eem.753 =============== Item was changed: Inspector subclass: #ContextVariablesInspector instanceVariableNames: 'fieldList' classVariableNames: '' poolDictionaries: '' category: 'Tools-Debugger'! + !ContextVariablesInspector commentStamp: 'eem 3/30/2017 17:32' prior: 0! + I represent a query path into the internal representation of a Context. Typically this is a context at a point in the query path of a Debugger. As a StringHolder, the string I represent is the value of the currently selected variable of the observed temporary variable of the context.! - !ContextVariablesInspector commentStamp: '<historical>' prior: 0! - I represent a query path into the internal representation of a ContextPart. Typically this is a context at a point in the query path of a Debugger. As a StringHolder, the string I represent is the value of the currently selected variable of the observed temporary variable of the context.! Item was changed: FileList subclass: #PluggableFileList instanceVariableNames: 'accepted fileFilterBlock canAcceptBlock validateBlock newFiles prompt resultBlock' classVariableNames: '' poolDictionaries: '' category: 'Tools-FileList'! + !PluggableFileList commentStamp: 'eem 3/30/2017 17:30' prior: 0! - !PluggableFileList commentStamp: '<historical>' prior: 0! I am a model for a modal dialog akin to "Standard File Services" on various modern GUI operating systems. My protocol includes some methods to maintain upward compatibility with StandardFileMenu, which I hope to replace. Sample doIts: "StandardFileDialog getFolder"-- ask user to select folder, answer corresponding FileDirectory "StandardFileDialog getFile" -- ask user to select file, answer corresponding FileStream "StandardFileDialog putFile" -- ask user to create new file, answer FileStream In addition to the instance variables inhereted from FileList, of which I am a subclass, I am pluggable via the following instance variables: prompt <String> Display a prompt between the buttons. + resultBlock <BlockClosure> - resultBlock <BlockContext> Passed a file directory and a file name, answer the result to be answered by the dialog. + canAcceptBlock <BlockClosure> - canAcceptBlock <BlockContext> Answer whether the accept button should be "active" + fileFilterBlock <BlockClosure> - fileFilterBlock <BlockContext> Passed a file directory entry, answer whether the entry should be added to the list. The list can be further filtered (but not expanded) by the user through the pattern. + validateBlock <BlockClosure> - validateBlock <BlockContent> Passed a file directory entry, a file name and a collection of newly created files, answer whether the dialog selection is valid. validateBlock is checked after the user has pressed accept, for example to ask if the user really meant to delete a file. newFiles <OrderedCollection> newFiles is an OrderedCollection of fileNames of files added by the user to the current directory since the user last entered same!

1 0

The Trunk: ST80-eem.226.mcz
by commits＠source.squeak.org 31 Mar '17

31 Mar '17

Eliot Miranda uploaded a new version of ST80 to project The Trunk: http://source.squeak.org/trunk/ST80-eem.226.mcz ==================== Summary ==================== Name: ST80-eem.226 Author: eem Time: 30 March 2017, 6:06:51.771911 pm UUID: ababcf44-ca33-4ee1-854d-f2bbf4707f6f Ancestors: ST80-eem.225 Replace mention of MethodContext with Context in class comments as appropriate. =============== Diff against ST80-eem.225 =============== Item was changed: TestCase subclass: #ST80MenusTest instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'ST80-Menus-Tests'! + !ST80MenusTest commentStamp: 'eem 3/30/2017 17:33' prior: 0! - !ST80MenusTest commentStamp: 'tlk 5/2/2006 22:41' prior: 0! I am an SUnit Test of PopUpMenu and FillInTheBlank. The original motivation for my creation was the regression of functionality associated with allowing the non-interactive testing of these menus. My fixtures are: None NOTES ABOUT AUTOMATING USER INPUTS (See MethodContextTest also for a discussion of this functionality.) When executing non-interactive programs you will inevitably run into programs that require user input during their execution and these sort of problems shoot the whole non-interactiveness of your enclosing program. This is particularly true in doing Sunit tests. + PopUpMenu and FillInTheBlankMorph were modified to first signal a ProvideAnswerNotification and if someone handles that (e.g. the enclosing block) then the user interaction will be avoided and a answer provided by an array will be used instead. PopUpMenu and FillInTheBlankMorph take advantage of BlockClosure helper methods have been made available and tests of these helpers are provided in this class to demonstrate that it can intercept requests for user interaction. Of course, - PopUpMenu and FillInTheBlankMorph were modified to first signal a ProvideAnswerNotification and if someone handles that (e.g. the enclosing block) then the user interaction will be avoided and a answer provided by an array will be used instead. PopUpMenu and FillInTheBlankMorph take advantage of BlockContext helper methods have been made available and tests of these helpers are provided in this class to demonstrate that it can intercept requests for user interaction. Of course, The basic syntax looks like: [self confirm: 'Install spyware?'] valueSupplyingAnswer: #('Install spyware?' false) There a few variants on this theme making it easy to provide a literal list of answers for the block so that you can handle a bunch of questions in a block with appropriate answers. Additionally, it is possible to suppress Object>>inform: modal dialog boxes as these get in the way of automating anything. After applying this changeset you should be able to tryout the following code snippets to see the variants on this theme that are available. Examples: So you don't need any introduction here -- this one works like usual. [self inform: 'hello'. #done] value. Now let's suppress all inform: messages. [self inform: 'hello'; inform: 'there'. #done] valueSuppressingAllMessages. Here we can just suppress a single inform: message. [self inform: 'hi'; inform: 'there'. #done] valueSuppressingMessages: #('there') Here you see how you can suppress a list of messages. [self inform: 'hi'; inform: 'there'; inform: 'bill'. #done] valueSuppressingMessages: #('hi' 'there') Enough about inform:, let's look at confirm:. As you see this one works as expected. [self confirm: 'You like Squeak?'] value Let's supply answers to one of the questions -- check out the return value. [{self confirm: 'You like Smalltalk?'. self confirm: 'You like Squeak?'}] valueSupplyingAnswer: #('You like Smalltalk?' true) Here we supply answers using only substrings of the questions (for simplicity). [{self confirm: 'You like Squeak?'. self confirm: 'You like MVC?'}] valueSupplyingAnswers: #( ('Squeak' true) ('MVC' false) ) This time let's answer all questions exactly the same way. [{self confirm: 'You like Squeak?'. self confirm: 'You like Morphic?'}] valueSupplyingAnswer: true And, of course, we can answer FillInTheBlank questions in the same manner. [FillInTheBlank request: 'What day is it?'] valueSupplyingAnswer: 'the first day of the rest of your life' We can also return whatever the initialAnswer of the FillInTheBlank was by using the #default answer. [FillInTheBlank request: 'What day is it?' initialAnswer: DateAndTime now dayOfWeekName] valueSupplyingAnswer: #default Finally, you can also do regex matches on any of the question text (or inform text) (should you have VB-Regex enhancements in your image). [FillInTheBlank request: 'What day is it?'] valueSupplyingAnswers: { {'What day.*\?'. DateAndTime now dayOfWeekName} }!

1 0

The Trunk: KernelTests-eem.326.mcz
by commits＠source.squeak.org 31 Mar '17

31 Mar '17

Eliot Miranda uploaded a new version of KernelTests to project The Trunk: http://source.squeak.org/trunk/KernelTests-eem.326.mcz ==================== Summary ==================== Name: KernelTests-eem.326 Author: eem Time: 30 March 2017, 6:06:00.734042 pm UUID: ec9113f8-c80a-4ce3-beac-2bf1da602763 Ancestors: KernelTests-eem.325 Replace mention of MethodContext with Context in class comments as appropriate. =============== Diff against KernelTests-eem.325 =============== Item was changed: TestCase subclass: #BlockClosureTest instanceVariableNames: 'aBlockClosure homeOfABlockClosure' classVariableNames: '' poolDictionaries: '' category: 'KernelTests-Methods'! + !BlockClosureTest commentStamp: 'eem 3/30/2017 17:45' prior: 0! - !BlockClosureTest commentStamp: 'eem 3/23/2017 18:07' prior: 0! I am an SUnit Test of BlockClosure and some of Context's simulation machinery'. See also MethodContextTest. My fixtures are: aBlockClosure - just some trivial block, i.e., [100@100 corner: 200@200]. homeOfABlockClosure - the home context of the block NOTES ABOUT AUTOMATING USER INPUTS When executing non-interactive programs you will inevitably run into programs (like SqueakMap or Monticello installation packages -- and other programs, to be fair) that require user input during their execution and these sort of problems shoot the whole non-interactiveness of your enclosing program. BlockClosure helper methods have been made available and tests of these helpers are provided in this class to demonstrate that it can intercept PopUpMenu and FillInTheBlankMorph requests for user interaction. Of course, PopUpMenu and FillInTheBlankMorph were modified to first signal a ProvideAnswerNotification and if someone handles that (e.g. the enclosing block) then the user interaction will be circumvented and the provided answer of the enclosing block will be used. The basic syntax looks like: [self confirm: 'Install spyware?'] valueSupplyingAnswer: #('Install spyware?' false) There a few variants on this theme making it easy to provide a literal list of answers for the block so that you can handle a bunch of questions in a block with appropriate answers. Additionally, it is possible to suppress Object>>inform: modal dialog boxes as these get in the way of automating anything. After applying this changeset you should be able to tryout the following code snippets to see the variants on this theme that are available. Examples: So you don't need any introduction here -- this one works like usual. [self inform: 'hello'. #done] value. Now let's suppress all inform: messages. [self inform: 'hello'; inform: 'there'. #done] valueSuppressingAllMessages. Here we can just suppress a single inform: message. [self inform: 'hi'; inform: 'there'. #done] valueSuppressingMessages: #('there') Here you see how you can suppress a list of messages. [self inform: 'hi'; inform: 'there'; inform: 'bill'. #done] valueSuppressingMessages: #('hi' 'there') Enough about inform:, let's look at confirm:. As you see this one works as expected. [self confirm: 'You like Squeak?'] value Let's supply answers to one of the questions -- check out the return value. [{self confirm: 'You like Smalltalk?'. self confirm: 'You like Squeak?'}] valueSupplyingAnswer: #('You like Smalltalk?' true) Here we supply answers using only substrings of the questions (for simplicity). [{self confirm: 'You like Squeak?'. self confirm: 'You like MVC?'}] valueSupplyingAnswers: #( ('Squeak' true) ('MVC' false) ) This time let's answer all questions exactly the same way. [{self confirm: 'You like Squeak?'. self confirm: 'You like Morphic?'}] valueSupplyingAnswer: true And, of course, we can answer FillInTheBlank questions in the same manner. [FillInTheBlank request: 'What day is it?'] valueSupplyingAnswer: 'the first day of the rest of your life' We can also return whatever the initialAnswer of the FillInTheBlank was by using the #default answer. [FillInTheBlank request: 'What day is it?' initialAnswer: DateAndTime now dayOfWeekName] valueSupplyingAnswer: #default Finally, you can also do regex matches on any of the question text (or inform text) (should you have VB-Regex enhancements in your image). [FillInTheBlank request: 'What day is it?'] valueSupplyingAnswers: { {'What day.*\?'. DateAndTime now dayOfWeekName} } + [Comment taken from BlockClosureTest last written by jrp 10/17/2004 12:22]! - [Comment taken from BlockContextTest last written by jrp 10/17/2004 12:22]! Item was changed: TestCase subclass: #MethodContextTest instanceVariableNames: 'aCompiledMethod aReceiver aMethodContext aSender' classVariableNames: '' poolDictionaries: '' category: 'KernelTests-Methods'! + !MethodContextTest commentStamp: 'eem 3/30/2017 17:42' prior: 0! + I am an SUnit Test of Context. See also BlockClosureTest. + See pages 430-437 of A. Goldberg and D. Robson's Smalltalk-80 The Language (aka the purple book), which deal with Contexts. My fixtures are from their example. To see how blocks are implemented in this version of Squeak see http://www.mirandabanda.org/cogblog/2008/06/07/closures-part-i/ and http://www.mirandabanda.org/cogblog/2008/07/22/closures-part-ii-the-bytecod…. (The Squeak V3 byte codes are not quite the same as Smalltalk-80, and the SistaV1 byetcodes are quite different.) - !MethodContextTest commentStamp: 'tlk 5/31/2004 16:07' prior: 0! - I am an SUnit Test of MethodContext and its super type, ContextPart. See also BlockContextTest. - See pages 430-437 of A. Goldberg and D. Robson's Smalltalk-80 The Language (aka the purple book), which deal with Contexts. My fixtures are from their example. (The Squeak byte codes are not quite the same as Smalltalk-80.) My fixtures are: aReceiver - just some arbitrary object, "Rectangle origin: 100@100 corner: 200@200" aSender - just some arbitrary object, thisContext aCompiledMethod - just some arbitrary method, "Rectangle rightCenter". aMethodContext - just some arbitray context ... !

1 0

The Trunk: Kernel-eem.1080.mcz
by commits＠source.squeak.org 31 Mar '17

31 Mar '17

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} - ].!

1 0

The Trunk: Compiler-eem.336.mcz
by commits＠source.squeak.org 31 Mar '17

31 Mar '17

Eliot Miranda uploaded a new version of Compiler to project The Trunk: http://source.squeak.org/trunk/Compiler-eem.336.mcz ==================== Summary ==================== Name: Compiler-eem.336 Author: eem Time: 30 March 2017, 6:03:14.217388 pm UUID: bcc6a515-1159-462a-9ab9-89faeeadfadc Ancestors: Compiler-eem.335 Replace mention of MethodContext with Context in class comments as appropriate. =============== Diff against Compiler-eem.335 =============== Item was changed: Object subclass: #CompilationCue instanceVariableNames: 'source context receiver class environment requestor' classVariableNames: '' poolDictionaries: '' category: 'Compiler-Kernel'! + !CompilationCue commentStamp: 'eem 3/30/2017 17:32' prior: 0! - !CompilationCue commentStamp: 'nice 9/20/2013 02:07' prior: 0! A CompilationCue is a helper class holding enough context for evaluating/compiling Smalltalk code. That is mainly the source code, and the source code editor to interact with if the Compiler is used interactively. But that is also any additional information necessary to resolve variable names. When compiling a method, the Compiler typically need to know the target class in which to install the method. When evaluating an expression, the Compiler also needs a receiver (for accessing the value of its instance variables), its class (for resolving instance/class variable names), and optionnally a context of execution when debugging a method (for accessing values of temporaries and parameters). Instance Variables + class: <Behavior> + context: <Context | nil> + environment: <Environment | nil> - class: <Behavior> - context: <ContextPart | nil> - environment: <Environment | nil> receiver: <Object> requestor: <TextEditor | nil> + source: <Stream> - source: <Stream> class - the target class in which to install the compiled method; this enables to resolve the instance variable names, class variable names and shared pool variable names. When evaluating, this should be the receiver class context - the context introspected when evaluating the code: this is typically for accessing parameters and temporary variables when debugging environment - the environment in which to resolve global variable names receiver - the receiver into which to evaluate the code: this is typically for accessing instance variables in an inspector requestor - typically the text editor containing the source code being compiled/evaluated. This enables the Compiler to interact in case of syntax error. source - a ReadStream on the source code to be compiled !

1 0

The Trunk: Collections-eem.743.mcz
by commits＠source.squeak.org 31 Mar '17

31 Mar '17

Eliot Miranda uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-eem.743.mcz ==================== Summary ==================== Name: Collections-eem.743 Author: eem Time: 30 March 2017, 6:02:18.123591 pm UUID: c8c62336-051e-4025-82d1-7dc2bebe4b6e Ancestors: Collections-ul.742 Replace mention of MethodContext with Context in class comments as appropriate. =============== Diff against Collections-ul.742 =============== Item was changed: Stream subclass: #Generator instanceVariableNames: 'block next continue home' classVariableNames: '' poolDictionaries: '' category: 'Collections-Streams'! + !Generator commentStamp: 'eem 3/30/2017 17:31' prior: 0! - !Generator commentStamp: 'ar 2/10/2010 20:51' prior: 0! A Generator transforms callback interfaces into stream interfaces. When a producer algorithm provide results as callbacks (blocks) and a consumer algorithm expects streamable input, a Generator transforms one into the other, for example: | generator | generator := Generator on: [:g| Integer primesUpTo: 100 do:[:prime| g yield: prime]]. [generator atEnd] whileFalse:[Transcript show: generator next]. Instance Variables + block: <BlockClosure> The block associated with the generator. + continue: <Context> The continuation to return to. + home: <Context> The home (root) context of the activated block + next: <Object> The next object to return from the Generator.! - block: <BlockClosure> The block associated with the generator. - continue: <MethodContext> The continuation to return to. - home: <MethodContext> The home (root) context of the activated block - next: <Object> The next object to return from the Generator. - ! Item was changed: Dictionary subclass: #PluggableDictionary instanceVariableNames: 'hashBlock equalBlock' classVariableNames: '' poolDictionaries: '' category: 'Collections-Unordered'! + !PluggableDictionary commentStamp: 'eem 3/30/2017 17:44' prior: 0! - !PluggableDictionary commentStamp: '<historical>' prior: 0! Class PluggableDictionary allows the redefinition of hashing and equality by clients. This is in particular useful if the clients know about specific properties of the objects stored in the dictionary. See the class comment of PluggableSet for an example. Instance variables: + hashBlock <BlockClosure> A one argument block used for hashing the elements. + equalBlock <BlockClosure> A two argument block used for comparing the elements. - hashBlock <BlockContext> A one argument block used for hashing the elements. - equalBlock <BlockContext> A two argument block used for comparing the elements. ! Item was changed: Set subclass: #PluggableSet instanceVariableNames: 'hashBlock equalBlock' classVariableNames: '' poolDictionaries: '' category: 'Collections-Unordered'! + !PluggableSet commentStamp: 'eem 3/30/2017 17:59' prior: 0! - !PluggableSet commentStamp: 'nice 3/25/2010 23:02' prior: 0! PluggableSets allow the redefinition of hashing and equality by clients. This is in particular useful if the clients know about specific properties of the objects stored in the set which in turn can heavily improve the performance of sets and dictionaries. Instance variables: + hashBlock <BlockClosure> A one argument block used for hashing the elements. + equalBlock <BlockClosure> A two argument block used for comparing the elements. - hashBlock <BlockContext> A one argument block used for hashing the elements. - equalBlock <BlockContext> A two argument block used for comparing the elements. + Example: Adding 1000000 integer points in the range (0@0) to: (100@100) to a set. - Example: Adding 1000 integer points in the range (0@0) to: (100@100) to a set. + ( | n rnd set max points | + set := Set new: (n := 1000000). - | rnd set max pt | - set := Set new: 1000. rnd := Random new. max := 100. + points := (1 to: n) collect: [:ign| (rnd next @ rnd next * max) truncated]. + Smalltalk garbageCollectMost. "to reduce variability in the run-to-run times" + [1 to: 1000000 do: [:i| set add: (points at: i)]] + timeToRun + ) - Time millisecondsToRun:[ - 1 to: 1000 do:[:i| - pt := (rnd next * max) truncated @ (rnd next * max) truncated. - set add: pt. - ]. - ]. The above is way slow since the default hashing function of points leads to an awful lot of collisions in the set. And now the same, with a somewhat different hash function: + ( | n rnd set max points | + set := PluggableSet new: (n := 1000000). + set hashBlock: [:item| (item x bitShift: 10) + item y]. - | rnd set max pt | - set := PluggableSet new: 1000. - set hashBlock:[:item| (item x bitShift: 16) + item y]. rnd := Random new. max := 100. + points := (1 to: n) collect: [:ign| (rnd next @ rnd next * max) truncated]. + Smalltalk garbageCollectMost. "to reduce variability in the run-to-run times" + [1 to: 1000000 do: [:i| set add: (points at: i)]] + timeToRun + )! - Time millisecondsToRun:[ - 1 to: 1000 do:[:i| - pt := (rnd next * max) truncated @ (rnd next * max) truncated. - set add: pt. - ]. - ]. - ! Item was changed: OrderedCollection subclass: #SortedCollection instanceVariableNames: 'sortBlock' classVariableNames: '' poolDictionaries: '' category: 'Collections-Sequenceable'! + !SortedCollection commentStamp: 'eem 3/30/2017 17:33' prior: 0! + I represent a collection of objects ordered by some property of the objects themselves. The ordering is specified in a two argument BlockClosure. The default sorting function is a <= comparison on elements.! - !SortedCollection commentStamp: 'dtl 9/6/2009 16:02' prior: 0! - I represent a collection of objects ordered by some property of the objects themselves. The ordering is specified in a BlockContext. The default sorting function is a <= comparison on elements.!

1 0

The Trunk: Tools-eem.753.mcz
by commits＠source.squeak.org 31 Mar '17

31 Mar '17

Eliot Miranda uploaded a new version of Tools to project The Trunk: http://source.squeak.org/trunk/Tools-eem.753.mcz ==================== Summary ==================== Name: Tools-eem.753 Author: eem Time: 30 March 2017, 5:24:31.941311 pm UUID: 55e72d95-e5b4-4bcb-801b-167d4786b8f6 Ancestors: Tools-eem.752 Replace mention of BlockContext with BlockClosure in comments as appropriate. =============== Diff against Tools-eem.752 =============== Item was changed: ----- Method: Context>>errorReportOn: (in category '*Tools-debugger access') ----- errorReportOn: strm "Write a detailed error report on the stack (above me) on a stream. For both the error file, and emailing a bug report. Suppress any errors while getting printStrings. Limit the length." | cnt aContext startPos | strm print: Date today; space; print: Time now; cr. strm cr. strm nextPutAll: 'VM: '; nextPutAll: Smalltalk platformName asString; nextPutAll: ' - '; nextPutAll: Smalltalk asString; cr. strm nextPutAll: 'Image: '; nextPutAll: SystemVersion current version asString; nextPutAll: ' ['; nextPutAll: Smalltalk lastUpdateString asString; nextPutAll: ']'; cr. strm cr. SecurityManager default printStateOn: strm. + "Note: The following is an open-coded version of Context>>stackOfSize: since this method may be called during a low space condition and we might run out of space for allocating the full stack." - "Note: The following is an open-coded version of ContextPart>>stackOfSize: since this method may be called during a low space condition and we might run out of space for allocating the full stack." cnt := 0. startPos := strm position. aContext := self. [aContext notNil and: [(cnt := cnt + 1) < 20]] whileTrue: [aContext printDetails: strm. "variable values" strm cr. aContext := aContext sender]. strm cr; nextPutAll: '--- The full stack ---'; cr. aContext := self. cnt := 0. [aContext == nil] whileFalse: [cnt := cnt + 1. cnt = 20 ifTrue: [strm nextPutAll: ' - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -'; cr]. strm print: aContext; cr. "just class>>selector" "exit early if too long..." strm position > (startPos+ self class maxLengthForASingleDebugLogReport) ifTrue: [strm nextPutAll: '...etc...'. ^ self]. cnt > self class maxStackDepthForASingleDebugLogReport ifTrue: [strm nextPutAll: '-- and more not shown --'. ^ self]. + aContext := aContext sender] - aContext := aContext sender]. !

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Packages March 2017