Squeak-dev March 2017

squeak-dev@lists.squeakfoundation.org

50 participants
281 discussions

More cruft
by Eliot Miranda 31 Mar '17

31 Mar '17

Hi All, another dubious piece of code is this: SmallInteger>>instVarAt: i "Small integer has to be specially handled." i = 1 ifTrue: [^self]. self error: 'argument too big for small integer instVarAt:' Either this is important and should be replicated in Character and SmallFloat64 (the other two immediate classes) or it should be discarded. It's ancient (pre version stamps). I vote to nuke it. Opinions? _,,,^..^,,,_ best, Eliot

4 4

ExternalDropHandler chooseServiceFrom: -- cancel button is missing; (FileServices: dropping a TrueType file)
by H. Hirzel 31 Mar '17

31 Mar '17

Hello This is a follow up message on the thread http://forum.world.st/Dropping-a-morph-gives-me-a-funny-menu-td4939787.html Dropping a ttf file gives the dialog box attached below. I probably do not want to edit a TrueType font file but rather prefer to have a 'cancel' button instead. -- Hannes Details ====== The method used is #chooseServiceFrom: [1] ExternalDropHandler chooseServiceFrom: chooseServiceFrom: aCollection "private - choose a service from aCollection asking the user if needed" ^aCollection size = 1 ifTrue: [aCollection anyOne] ifFalse:[UIManager default chooseFrom: (aCollection collect:[:each| each label]) values: aCollection title: 'You dropped a file. Please choose a service:' translated withCRs]. aCollection contains a list of FileServices classes. These are classes which implement #fileReaderServicesForFile:suffix: [2]. BTW there are only a few ExternalDropHandler instances. Most cases are handled by a file service "external" to the "ExternalDropHandler". References ---------------- [1] http://wiki.squeak.org/squeak/4283 ExternalDropHandler [2] http://wiki.squeak.org/squeak/1005 List of classes which provide file reader services

2 2

Squeak 6 kernel changes, ContextPart+MethodContext -> Context
by Eliot Miranda 31 Mar '17

31 Mar '17

Hi All, another change planned for Squeak 6 is eliminating ContextPart & MethodContext in favor of Context. In reviewing the (very few) changes necessary I came across the following: MethodContext>>printString "Answer an emphasized string in case of a breakpoint method" ^(self method notNil and: [self method hasBreakpoint]) ifTrue:[(super printString , ' [break]') asText allBold] ifFalse:[super printString] Seriously? I don't object to modifying [Method]Conext>>printOn: to include [break] but having printString answer a text seems completely broken to me, and overriding printString is a hack; printOn: being the operative method for producing self-descriptions. Should we nuke it and add [break] to printOn:? Or...? _,,,^..^,,,_ best, Eliot

5 9

RunSingleApp relaunch without file
by Ron Teitelbaum 31 Mar '17

31 Mar '17

Hi All, Hopefully a quick question. If I set RunSingleApp to 1 and I launch with a registered file that file will be delivered to the running instance. We have that working now. I'm registering a URI protocol to launch with parameters and that works fine. Is there any way to get the parameters into the running instance when launched through a URI or do I need to run from a file to have that work? In other words, if I launch using squeak:run=test&program=foo, or something like that and squeak is already running and RunSingleApp is set to 1 are the parameters sent to the running VM? The URI handler essentially calls squeak.exe run=test&program=foo. The object is to have a link that sends the parameters from a browser to launch a client squeak instance or modify a running squeak instance (through the URI handler). If not I suppose I could create a handler which creates a file and launches using that instead. Thanks! Ron Teitelbaum

2 2

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

← Newer
1
2
3
4
5
6
7
...
29
Older →

Jump to page: