Squeak-dev February 2018

squeak-dev@lists.squeakfoundation.org

51 participants
149 discussions

Re: [squeak-dev] Survey: what do you do with Squeak, what do you *want* to do?
by Edwin Ancaer 28 Feb '18

28 Feb '18

Ben, Thanks for pointing me to that tutorial. I just finished the first section, and I skimmed over the complete document. It seems to give a good impression on how development with Squeak can be done. In the coming days, I will certainly be doing the other sections. There is some hope left for me after all...👍 Op 26 feb. 2018 22:11 schreef "Ben Coman" <btc(a)openinworld.com>: > > > On 23 February 2018 at 13:16, Edwin Ancaer <eancaer(a)gmail.com> wrote: > >> >> >> What do you use Squeak for? >> >> >> Unfortunately, I mostly just follow the list. My experience is limited >> to elementary experiments: just defining some classes, and using them in a >> workspace, using the transcript to inspect the results. >> >> If you don't use Squeak, why not? >> >> >> I just don't seem to get it. I think I master the building blocks, I get >> what is in the SBE book, but somehow, I don't see how to tie the pieces >> together into something that looks like a regular application. >> > > Hi Edwin, > > You might like Stephan Wessels "LaserGame" tutorial. Its is a great > end-to-end tutorial for developing a regular application. > http://squeak.preeminent.org/tut2007/html/index.html > > I'd suggest you do it in Squeak 3.9 to closely match the version the > tutorial was done in... > http://files.squeak.org/3.9/ > > cheers -ben > > > >> >> If you used Squeak in the past and don't now, what pulled you away? >> >> >> To be honest, it's more a mystery what keeps pulling me towards Squeak, >> given my poor results until now. >> >> >> What does Squeak lack that you think might make you use it for 'regular' >> development? >> >> >> I am not in a position to answer this question. >> >> What things are too hard or annoying to do? >> >> >> Everything is hard, but not annoying. I probably need to get more general >> knowledge of the 'Object Oriented' paradigm, and some UI design skills. A >> 30+ year career in mainframe development left me a very procedural guy, and >> a UI for me has 30 lines with 132 colums each. >> >> What would you like to be able to use Squeak for? >> >> >> What got me interested was reading about Squeaknos, turtles all the way >> down, at one of those moments I was struggling once more with a linux >> upgrade that destroyed the GNUstep installation I had managed to install. >> Now I see this is miles beyond my reach, but that was the spark. >> >> Currently, I'm trying to build an intelligent doorbell, with Squeak and a >> Raspberry Pi that was laying around here. Now if only it would just ring >> outside the simulation. >> Did I mention my knowledge of electronics is far below average..... >> >> >> >> I don't know if this is of much use to you, but since you asked.... >> >> >> tim >> -- >> tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim >> C for sinking, java for drinking, Smalltalk for thinking >> >> >> >> >> >> >> >> > > > >

1 0

Text cursor, text selection drag/drop, and drag-transfer morph
by Marcel Taeumel 27 Feb '18

27 Feb '18

Hi, there. :-) In the last two days, I had fun with text selections. You can now drag a selection and drop it somewhere in a(nother) text morph --- if you enable the preference "Draggable Text Selections". As usual, hold [SHIFT] for copy, otherwise it will move. I also changed TransferMorph to make use of UI themes. You might have to rebuilt your themes via "UserInterfaceTheme cleanUp: true" to see the change. That's all for this year. :-) Merry Christmas everybody! Best, Marcel P.S.: Please forgive my strange mail application to prefix this list with "Hanh Ho Si via". I am still in the process of figuring out how to control it.

6 6

The Trunk: Kernel-eem.1155.mcz
by commits＠source.squeak.org 27 Feb '18

27 Feb '18

Eliot Miranda uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-eem.1155.mcz ==================== Summary ==================== Name: Kernel-eem.1155 Author: eem Time: 27 February 2018, 12:52:46.556955 pm UUID: 0041924e-8077-4c30-8456-45ce511eb376 Ancestors: Kernel-eem.1154 Improve class comments for CompiledCode, CompiledMethod, and CompiledBlock. =============== Diff against Kernel-eem.1154 =============== Item was changed: CompiledCode variableByteSubclass: #CompiledBlock instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Kernel-Methods'! + !CompiledBlock commentStamp: 'eem 2/27/2018 12:27' prior: 0! + CompiledBlock instances are blocks suitable for interpretation by the virtual machine. They are a specialization of CompiledCode. This requires both bytecode set and compiler support. The V3 bytecode (EncoderForV3PlusClosures) does not provide support for CompiledBlock. The SistaV1 set does (EncoderForSistaV1). - !CompiledBlock commentStamp: 'eem 3/22/2017 12:10' prior: 0! - CompiledBlock instances are blocks suitable for interpretation by the virtual machine. They are a specialization oif CompiledCode. This requires both bytecode set and compiler support. The V3 bytecode (EncoderForV3PlusClosures) does not provide support for CompiledBlock. The SistaV1 set does (EncoderForSistaV1). The last literal in a CompiledBlock is reserved for a reference to its enclosing CompiledBlock or CompiledMethod. Super sends in CompiledBlocks must use the directed super send bytecode. By convention the penultimate literal of a method is either its selector or an instance of AdditionalMethodState. AdditionalMethodState may be used to add instance variables to a method, albeit ones held in the method's AdditionalMethodState. Subclasses of CompiledBlock that want to add state should subclass AdditionalMethodState to add the state they want, and implement methodPropertiesClass on the class side of the CompiledBlock subclass to answer the specialized subclass of AdditionalMethodState. Enterprising programmers are encouraged to try and implement this support automatically through suitable modifications to the compiler and class builder.! Item was changed: ByteArray variableByteSubclass: #CompiledCode instanceVariableNames: '' classVariableNames: 'LargeFrame PreferredBytecodeSetEncoderClass PrimaryBytecodeSetEncoderClass SecondaryBytecodeSetEncoderClass SmallFrame' poolDictionaries: '' category: 'Kernel-Methods'! + !CompiledCode commentStamp: 'eem 2/27/2018 12:23' prior: 0! + CompiledCode instances are methods suitable for execution by the virtual machine. Instances of CompiledCode and its subclasses are the only objects in the system that have both indexable pointer fields and indexable 8-bit integer fields. The pointer fields are used for literals and metadata, and the bytes are used for bytecodes and a variety of encoded informaton such as source code, source code position, etc. The first part of a CompiledCode object is pointers, the second part is bytes. CompiledCode inherits from ByteArray to avoid duplicating some of ByteArray's methods, not because a CompiledCode is-a ByteArray. - !CompiledCode commentStamp: 'eem 3/23/2017 14:33' prior: 0! - CompiledCode instances are methods suitable for execution by the virtual machine. Instances of CompiledCode and its subclasses are the only objects in the system that have both indexable pointer fields and indexable 8-bit integer fields. The first part of a CompiledCode object is pointers, the second part is bytes. CompiledCode inherits from ByteArray to avoid duplicating some of ByteArray's methods, not because a CompiledCode is-a ByteArray. Instance variables: *indexed* (no named inst vars) Class variables: SmallFrame - the number of stack slots in a small frame Context LargeFrame - the number of stack slots in a large frame Context PrimaryBytecodeSetEncoderClass - the encoder class that defines the primary instruction set SecondaryBytecodeSetEncoderClass - the encoder class that defines the secondary instruction set The current format of a CompiledCode object is as follows: header (4 or 8 bytes, SmallInteger) literals (4 or 8 bytes each, Object, see "The last literal..." below) bytecodes (variable, bytes) trailer (variable, bytes) The header is a SmallInteger (which in the 32-bit system has 31 bits, and in the 64-bit system, 61 bits) in the following format: (index 0) 15 bits: number of literals (#numLiterals) (index 15) 1 bit: jit without counters - reserved for methods that have been optimized by Sista (index 16) 1 bit: has primitive (index 17) 1 bit: whether a large frame size is needed (#frameSize => either SmallFrame or LargeFrame) (index 18) 6 bits: number of temporary variables (#numTemps) (index 24) 4 bits: number of arguments to the method (#numArgs) (index 28) 2 bits: reserved for an access modifier (00-unused, 01-private, 10-protected, 11-public), although accessors for bit 29 exist (see #flag). sign bit: 1 bit: selects the instruction set, >= 0 Primary, < 0 Secondary (#signFlag) If the method has a primitive then the first bytecode of the method must be a callPrimitive: bytecode that encodes the primitive index. This bytecode can encode a primitive index from 0 to 65535. The trailer is an encoding of an instance of CompiledMethodTrailer. It is typically used to encode the index into the source files array of the method's source, but may be used to encode other values, e.g. tempNames, source as a string, etc. See the class CompiledMethodTrailer. While there are disadvantages to this "flat" representation (it is impossible to add named instance variables to CompiledCode or its subclasses, but it is possible indirectly; see AdditionalMethodState) it is effective for interpreters. It means that both bytecodes and literals can be fetched directly from a single method object, and that only one object, the method, must be saved and restored on activation and return. A more natural representation, in which there are searate instance variables for the bytecode, and (conveniently) the literals, requires either much more work on activation and return setting up references to the literals and bytecodes, or slower access to bytecodes and literals, indirecting on each access. The last literal of a CompiledCode object is reserved for special use by the kernel and/or the virtual machine. In CompiledMethod instances it must either be the methodClassAssociation, used to implement super sends, or nil, if the method is anonymous. In CompiledBlock it is to be used for a reference to the enclosing method or block object. + By convention, the penultimate literal is reserved for special use by the kernel. In CompiledMethod instances it must either be the method selector, or an instance of AdditionalMethodState which holds the selector and any pragmas or properties in the method. In CompiledBlock it is reserved for use for an AdditionalMethodState. - By convention, the penultimate literal is reserved for special use by the kernel. CompiledMethod instances it must either be the method selector, or an instance of AdditionalMethodState which holds the selector and any pragmas or properties in the method. In CompiledBlock it is reserved for use for an AdditionalMethodState. Note that super sends in CompiledBlock instances do not use a methodClass association, but expect a directed supersend bytecode, in which the method class (the subclass of the class in which to start the lookup) is a literal. Logically when we switch to a bytecode set that supports the directed super send bytecode, and discard the old super send bytecodes, we can use the last literal to store the selector or the enclosing method/block or an AdditionalMethodState, and the AdditionalMethodState can hold the selector and/or the enclosing method/block.! Item was changed: CompiledCode variableByteSubclass: #CompiledMethod instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Kernel-Methods'! + !CompiledMethod commentStamp: 'eem 2/27/2018 12:48' prior: 0! + CompiledMethod instances are methods suitable for interpretation by the virtual machine. They are a specialization of CompiledCode. They represent methods, and may also, depending on the bytecode set, include nested blocks. Bytecode sets that support non-nested blocks use CompiledBlock instances to implement nested block methods, that are separate from their enclosing method. Bytecode sets that do not support non-nested blocks require the literals and bytecodes for a block to occur within the literals and bytecodes of a single CompiledMethod. For example, the inject:into: method in the EncoderForV3PlusClosures bytecode set is as follows - !CompiledMethod commentStamp: 'eem 3/22/2017 13:17' prior: 0! - CompiledMethod instances are methods suitable for interpretation by the virtual machine. They are a specialization of CompiledCode. They represent methods, and may also, depending on the bytecode set, include nested blocks. Bytecode sets that support non-nested blocks with use CompiledBlock instances to implement nested block methods, that are separate from their enclosing method. This requires compiler support. + Collection>>#inject:into: + header ((primitive: 0) (numArgs: 2) (numTemps: 3) (numLiterals: 3) (frameSize: 16) (bytecodeSet: V3PlusClosures)) + literal1 #value:value: + literal2 #inject:into: + literal3 #Collection=>Collection + 33 <8A 01> push: (Array new: 1) + 35 <6A> popIntoTemp: 2 + 36 <10> pushTemp: 0 + 37 <8E 00 02> popIntoTemp: 0 inVectorAt: 2 + 40 <70> self + 41 <11> pushTemp: 1 + 42 <12> pushTemp: 2 + 43 <8F 21 00 0A> closureNumCopied: 2 numArgs: 1 bytes 47 to 56 + 47 <11> pushTemp: 1 + 48 <8C 00 02> pushTemp: 0 inVectorAt: 2 + 51 <10> pushTemp: 0 + 52 <F0> send: value:value: + 53 <8D 00 02> storeIntoTemp: 0 inVectorAt: 2 + 56 <7D> blockReturn + 57 <CB> send: do: + 58 <87> pop + 59 <8C 00 02> pushTemp: 0 inVectorAt: 2 + 62 <7C> returnTop + + whereas using the encoderForSistaV1 bytecode set it is + + Collection>>#inject:into: + header ((primitive: 0) (numArgs: 2) (numTemps: 3) (numLiterals: 3) (frameSize: 16) (bytecodeSet: #SistaV1)) + literal1 ([] in Collection>>#inject:into: "a CompiledBlock(3755867)") + literal2 #inject:into: + literal3 #Collection=>Collection + 33 <E7 01> push: (Array new: 1) + 35 <D2> popIntoTemp: 2 + 36 <40> pushTemp: 0 + 37 <FD 00 02> popIntoTemp: 0 inVectorAt: 2 + 40 <4C> self + 41 <41> pushTemp: 1 + 42 <42> pushTemp: 2 + 43 <F9 00 02> closureNumCopied: 2 numArgs: 1 + 46 <7B> send: do: + 47 <D8> pop + 48 <FB 00 02> pushTemp: 0 inVectorAt: 2 + 51 <5C> returnTop + + [] in Collection>>#inject:into: "a CompiledBlock(3755867)" + header ((block #full) (numArgs: 1) (numTemps: 3) (numLiterals: 3) (frameSize: 16) (bytecodeSet: #SistaV1)) + literal1 #value:value: + literal2 nil + literal3 (Collection>>#inject:into: "a CompiledMethod(736427)") + 33 <41> pushTemp: 1 + 34 <FB 00 02> pushTemp: 0 inVectorAt: 2 + 37 <40> pushTemp: 0 + 38 <A0> send: value:value: + 39 <FC 00 02> storeIntoTemp: 0 inVectorAt: 2 + 42 <5E> blockReturn + The last literal in a CompiledMethod must be its methodClassAssociation, a binding whose value is the class the method is installed in. The methodClassAssociation is used to implement super sends. If a method contains no super send then its methodClassAssociation may be nil (as would be the case for example of methods providing a pool of inst var accessors). By convention the penultimate literal of a method is either its selector or an instance of AdditionalMethodState. AdditionalMethodState holds the method's selector and any pragmas and properties of the method. AdditionalMethodState may also be used to add instance variables to a method, albeit ones held in the method's AdditionalMethodState. Subclasses of CompiledMethod that want to add state should subclass AdditionalMethodState to add the state they want, and implement methodPropertiesClass on the class side of the CompiledMethod subclass to answer the specialized subclass of AdditionalMethodState. Enterprising programmers are encouraged to try and implement this support automatically through suitable modifications to the compiler and class builder.!

1 0

PostgresV3 SchemaMirror browseChanges Upload All vs Download All . Which way is which?
by gettimothy 27 Feb '18

27 Feb '18

Hi all. While writing the PostgresV3 help, I am following Balázs Kósi-2 example here: http://forum.world.st/Status-of-PostgresV3-td4780110.html In the section on SchemaMirror To create a schema mirror, subclass PG3SchemaMirror and implement its pool and schema class side methods. YourSchemaMirror class >> pool ^YourConnectionPool default YourSchemaMirror class >> schema ^’schema_name’ Schema mirrors mirror the functions in your database and provide an interface to call them. There is a little tool to inspect the differences between the methods of the schema mirror and the functions in the database, which can be invoked by: YourSchemaMirror browseChanges You can up and download functions via this interface. In earlier times we would write the database functions in pgAdmin3 and download them into the image. Nowadays we use the smalltalk browser to write the plpgsql code. You can set the autocommit behavior with: YourSchemaMirror commitOnAccept: true I have this beautiful tool that lists all the functions in my schema and it has buttons "Download All" and "Upload All" etc. My question are "Which way is Up" and "Which way is Down"? What I want to accomplish is this direction [My database] ---->[Squeak] I am guessing that I want to Upload, BUT for documentation purposes I want to be clear. Also, I don't want to have to re-import the functions. thx

2 6

The Trunk: SystemChangeNotification-Tests-fn.27.mcz
by commits＠source.squeak.org 26 Feb '18

26 Feb '18

Fabio Niephaus uploaded a new version of SystemChangeNotification-Tests to project The Trunk: http://source.squeak.org/trunk/SystemChangeNotification-Tests-fn.27.mcz ==================== Summary ==================== Name: SystemChangeNotification-Tests-fn.27 Author: fn Time: 26 February 2018, 2:06:31.146356 pm UUID: e7f994ba-43f9-4288-8a7f-cbab1f93d380 Ancestors: SystemChangeNotification-Tests-pre.26 Rename SystemChangeErrorHandling to SystemChangeErrorHandlingTest. SystemChangeErrorHandlingTest was there before, but empty. I'm assuming something went wrong when someone wanted to rename the class. === text below is ignored === Ancestors: SystemChangeNotification-Tests-pre.26 SystemChangeNotification-Tests-pre.26: Fixes a test case for the system change notifications. D SystemChangeErrorHandling D SystemChangeErrorHandling>>handleEventWithError: D SystemChangeErrorHandling>>handleEventWithHalt: D SystemChangeErrorHandling>>setUp D SystemChangeErrorHandling>>storeEvent1: D SystemChangeErrorHandling>>storeEvent2: D SystemChangeErrorHandling>>storeEvent3: D SystemChangeErrorHandling>>tearDown D SystemChangeErrorHandling>>testErrorOperation D SystemChangeErrorHandling>>testHaltOperation D SystemChangeErrorHandling>>testUnhandledEventOperation M SystemChangeErrorHandlingTest A SystemChangeErrorHandlingTest>>handleEventWithError: A SystemChangeErrorHandlingTest>>handleEventWithHalt: A SystemChangeErrorHandlingTest>>setUp A SystemChangeErrorHandlingTest>>storeEvent1: A SystemChangeErrorHandlingTest>>storeEvent2: A SystemChangeErrorHandlingTest>>storeEvent3: A SystemChangeErrorHandlingTest>>tearDown A SystemChangeErrorHandlingTest>>testErrorOperation A SystemChangeErrorHandlingTest>>testHaltOperation A SystemChangeErrorHandlingTest>>testUnhandledEventOperation =============== Diff against SystemChangeNotification-Tests-pre.26 =============== Item was removed: - SystemChangeTestRoot subclass: #SystemChangeErrorHandling - instanceVariableNames: 'capturedEvents' - classVariableNames: '' - poolDictionaries: '' - category: 'SystemChangeNotification-Tests'! - - !SystemChangeErrorHandling commentStamp: 'bp 12/4/2009 10:37' prior: 0! - This class tests the error handing of the notification mechanism to ensure that one client that receives a system change cannot lock up the complete system.! Item was removed: - ----- Method: SystemChangeErrorHandling>>handleEventWithError: (in category 'Event Notifications') ----- - handleEventWithError: event - - self error: 'Example of event handling code that throws an error.'! Item was removed: - ----- Method: SystemChangeErrorHandling>>handleEventWithHalt: (in category 'Event Notifications') ----- - handleEventWithHalt: event - - self halt: 'Example of event handling code that contains a halt.'! Item was removed: - ----- Method: SystemChangeErrorHandling>>setUp (in category 'Running') ----- - setUp - - super setUp. - capturedEvents := OrderedCollection new! Item was removed: - ----- Method: SystemChangeErrorHandling>>storeEvent1: (in category 'Event Notifications') ----- - storeEvent1: anEvent - - capturedEvents add: anEvent! Item was removed: - ----- Method: SystemChangeErrorHandling>>storeEvent2: (in category 'Event Notifications') ----- - storeEvent2: anEvent - - capturedEvents add: anEvent! Item was removed: - ----- Method: SystemChangeErrorHandling>>storeEvent3: (in category 'Event Notifications') ----- - storeEvent3: anEvent - - capturedEvents add: anEvent! Item was removed: - ----- Method: SystemChangeErrorHandling>>tearDown (in category 'Running') ----- - tearDown - - capturedEvents := nil. - super tearDown! Item was removed: - ----- Method: SystemChangeErrorHandling>>testErrorOperation (in category 'Testing') ----- - testErrorOperation - - | notifier wasCaptured | - notifier := self systemChangeNotifier. - wasCaptured := false. - notifier notify: self ofSystemChangesOfItem: #class change: #Added using: #storeEvent1:. - notifier notify: self ofSystemChangesOfItem: #class change: #Added using: #storeEvent2:. - notifier notify: self ofSystemChangesOfItem: #class change: #Added using: #handleEventWithError:. - notifier notify: self ofSystemChangesOfItem: #class change: #Added using: #storeEvent3:. - [notifier classAdded: self class inCategory: #FooCat] on: Error do: [:exc | - wasCaptured := true. - self assert: (capturedEvents size = 3)]. - self assert: wasCaptured.! Item was removed: - ----- Method: SystemChangeErrorHandling>>testHaltOperation (in category 'Testing') ----- - testHaltOperation - - | notifier wasCaptured | - notifier := self systemChangeNotifier. - wasCaptured := false. - notifier notify: self ofAllSystemChangesUsing: #storeEvent1:. - notifier notify: self ofAllSystemChangesUsing: #storeEvent2:. - notifier notify: self ofAllSystemChangesUsing: #handleEventWithHalt:. - notifier notify: self ofAllSystemChangesUsing: #storeEvent3:. - [notifier classAdded: self class inCategory: #FooCat] on: Halt do: [:exc | - wasCaptured := true. - self assert: (capturedEvents size = 3)]. - self assert: wasCaptured.! Item was removed: - ----- Method: SystemChangeErrorHandling>>testUnhandledEventOperation (in category 'Testing') ----- - testUnhandledEventOperation - - | notifier wasCaptured | - notifier := self systemChangeNotifier. - wasCaptured := false. - notifier notify: self ofSystemChangesOfItem: #class change: #Added using: #storeEvent1:. - notifier notify: self ofSystemChangesOfItem: #class change: #Added using: #storeEvent2:. - notifier notify: self ofSystemChangesOfItem: #class change: #Added using: #zork:. - notifier notify: self ofSystemChangesOfItem: #class change: #Added using: #storeEvent3:. - [notifier classAdded: self class inCategory: #FooCat] on: MessageNotUnderstood do: [:exc | - wasCaptured := true. - self assert: (capturedEvents size = 3)]. - self assert: wasCaptured.! Item was changed: SystemChangeTestRoot subclass: #SystemChangeErrorHandlingTest instanceVariableNames: 'capturedEvents' classVariableNames: '' poolDictionaries: '' category: 'SystemChangeNotification-Tests'! + + !SystemChangeErrorHandlingTest commentStamp: 'bp 12/4/2009 10:37' prior: 0! + This class tests the error handing of the notification mechanism to ensure that one client that receives a system change cannot lock up the complete system.! Item was added: + ----- Method: SystemChangeErrorHandlingTest>>handleEventWithError: (in category 'Event Notifications') ----- + handleEventWithError: event + + self error: 'Example of event handling code that throws an error.'! Item was added: + ----- Method: SystemChangeErrorHandlingTest>>handleEventWithHalt: (in category 'Event Notifications') ----- + handleEventWithHalt: event + + self halt: 'Example of event handling code that contains a halt.'! Item was added: + ----- Method: SystemChangeErrorHandlingTest>>setUp (in category 'Running') ----- + setUp + + super setUp. + capturedEvents := OrderedCollection new! Item was added: + ----- Method: SystemChangeErrorHandlingTest>>storeEvent1: (in category 'Event Notifications') ----- + storeEvent1: anEvent + + capturedEvents add: anEvent! Item was added: + ----- Method: SystemChangeErrorHandlingTest>>storeEvent2: (in category 'Event Notifications') ----- + storeEvent2: anEvent + + capturedEvents add: anEvent! Item was added: + ----- Method: SystemChangeErrorHandlingTest>>storeEvent3: (in category 'Event Notifications') ----- + storeEvent3: anEvent + + capturedEvents add: anEvent! Item was added: + ----- Method: SystemChangeErrorHandlingTest>>tearDown (in category 'Running') ----- + tearDown + + capturedEvents := nil. + super tearDown! Item was added: + ----- Method: SystemChangeErrorHandlingTest>>testErrorOperation (in category 'Testing') ----- + testErrorOperation + + | notifier wasCaptured | + notifier := self systemChangeNotifier. + wasCaptured := false. + notifier notify: self ofSystemChangesOfItem: #class change: #Added using: #storeEvent1:. + notifier notify: self ofSystemChangesOfItem: #class change: #Added using: #storeEvent2:. + notifier notify: self ofSystemChangesOfItem: #class change: #Added using: #handleEventWithError:. + notifier notify: self ofSystemChangesOfItem: #class change: #Added using: #storeEvent3:. + [notifier classAdded: self class inCategory: #FooCat] on: Error do: [:exc | + wasCaptured := true. + self assert: (capturedEvents size = 3)]. + self assert: wasCaptured.! Item was added: + ----- Method: SystemChangeErrorHandlingTest>>testHaltOperation (in category 'Testing') ----- + testHaltOperation + + | notifier wasCaptured | + notifier := self systemChangeNotifier. + wasCaptured := false. + notifier notify: self ofAllSystemChangesUsing: #storeEvent1:. + notifier notify: self ofAllSystemChangesUsing: #storeEvent2:. + notifier notify: self ofAllSystemChangesUsing: #handleEventWithHalt:. + notifier notify: self ofAllSystemChangesUsing: #storeEvent3:. + [notifier classAdded: self class inCategory: #FooCat] on: Halt do: [:exc | + wasCaptured := true. + self assert: (capturedEvents size = 3)]. + self assert: wasCaptured.! Item was added: + ----- Method: SystemChangeErrorHandlingTest>>testUnhandledEventOperation (in category 'Testing') ----- + testUnhandledEventOperation + + | notifier wasCaptured | + notifier := self systemChangeNotifier. + wasCaptured := false. + notifier notify: self ofSystemChangesOfItem: #class change: #Added using: #storeEvent1:. + notifier notify: self ofSystemChangesOfItem: #class change: #Added using: #storeEvent2:. + notifier notify: self ofSystemChangesOfItem: #class change: #Added using: #zork:. + notifier notify: self ofSystemChangesOfItem: #class change: #Added using: #storeEvent3:. + [notifier classAdded: self class inCategory: #FooCat] on: MessageNotUnderstood do: [:exc | + wasCaptured := true. + self assert: (capturedEvents size = 3)]. + self assert: wasCaptured.!

1 0

Onward! 2018 | Call for Papers
by Robert Hirschfeld 25 Feb '18

25 Feb '18

=========================================================== Call for Papers =========================================================== Onward! 2018 Co-located with SPLASH 2018 November 4 - 9, 2018, Boston, USA https://2018.onward-conference.org Onward! is a premier multidisciplinary conference focused on everything to do with programming and software: including processes, methods, languages, communities and applications. Onward! is more radical, more visionary and more open than other conferences to ideas that are well-argued but not yet proven. We welcome different ways of thinking about, approaching and reporting on programming language and software engineering research. Onward! has two tracks that accept submissions: Papers and Essays. ### Call for Onward! Essays Onward! Essays is looking for clear and compelling pieces of writing about topics important to the software community. An essay can be long or short. Anessay can be an exploration of the topic and its impact, or a story about the circumstances of its creation; it can present a personal view of what is, explore a terrain, or lead the reader in an act of discovery; it can be aphilosophical digression or a deep analysis. It can describe a personal journey, perhaps the one the author took to reach an understanding of the topic. The subject area—software, programming, and programming languages —should be interpreted broadly and can include the relationship of software to human endeavors, or its philosophical, sociological, psychological, historical, or anthropological underpinnings. Instructions for authors and further information at: https://2018.onward-conference.org/track/onward-2018-Onward-Essays ### Call for Onward! Papers Onward! Papers is looking for grand visions and new paradigms that could make a big difference in how we will one day build software. But it is not looking for research-as-usual papers—conferences like OOPSLA are the place for that. Those conferences require rigorous validation such as theorems or empirical experiments, which are necessary for scientific progress, but which typically preclude discussion of early-stage ideas. Onward! papers must also supply some degree of validation because mere speculation is not a good basis for progress. However, Onward! accepts less rigorous methods of validation such as compelling arguments, exploratory implementations, and substantial examples. The use of worked-out examples to support new ideas is strongly encouraged. Instructions for authors and further information at: https://2018.onward-conference.org/track/onward-2018-papers ### Important Dates for both Essays and Papers Submission deadline: 23 April 2018 Primary notification: 11 June 2018 Revisions deadline: 15 July 2018 Final notification: 30 July 2018 ### Program Chairs Richard P. Gabriel, Dream Songs, Inc. & HPI, USA (Essays Chair) Elisa Gonzalez Boix, Vrije Universiteit Brussel, Belgium (Papers Chair) ### Onward! 2018 Essays Program Committee Craig Anslow, Victoria University of Wellington, New Zealand Elisa Baniassad, University of British Columbia, Canada Siobhán Clarke, Trinity College Dublin, Ireland Charlotte Herzeel, imec, Belgium Graham Hutton, University of Nottingham, United Kingdom Jenny Quillien, Embodied Making Institute, United States Annette Vee, University of Pittsburgh, United States ### Onward! 2018 Papers Program Committee Craig Anslow, Victoria University of Wellington, New Zealand Daan Leijen, Microsoft Research, USA Dave Thomas, Kx Systems, Canada Friederich Steimann, Fernuniversität, Germany Gail Murphy, University of British Columbia, Canada Guido Salvaneschi, TU Darmstadt, Germany Heather Miller, Northeastern University, USA Jonathan Edwards, MIT, USA Nada Amin, University of Cambridge, UK Peng Wu, Huawei America Research Lab, USA Philipp Haller, KTH Royal Institute of Technology, Sweden Ralf Lammel, University of Koblenz-Landau, Germany Robert Hirschfeld, HPI, Germany Roberto Ierusalimschy, PUC-Rio, Brazil Sean McDirmid, Independent Shigeru Chiba, University of Tokyo, Japan Stefan Marr, University of Kent, UK Stephane Ducasse, INRIA, France Vincent St-Amour, Northeastern University, USA Wolfgang De Meuter, Vrije Universiteit Brussel, Belgium ========================================================== -- Robert Hirschfeld hirschfeld(a)acm.org www.hirschfeld.org

1 0

Interesting articles about Mobile Smalltalk on Android and iOS
by Bruce O'Neel 25 Feb '18

25 Feb '18

[http://simberon.blogspot.ch/2017/11/mobile-smalltalk.html?m=1](http://simbe… The TL;DR section is: I've wanted to be able to run Smalltalk on Android and iOS for many years. I finally decided to do something about it. I chose VisualWorks for my development environment. Unfortunately iOS doesn't support dynamic compilation so getting the regular VisualWorks VM to run on iOS is virtually impossible. I decided to skirt around the issue by writing my own VM. My VM is written in C. It interprets the same bytecodes as those generated by VisualWorks so I can use the VisualWorks compiler to compile all of the code for the mobile Smalltalk. Being a pure interpreter, I get around the problem of dynamic compilation on iOS. Apple is okay with an interpreter so long as all of the code it's interpreting is delivered with the product and not downloaded dynamically. cheers bruce

2 1

Election, do you know where your email goes?
by Ron Teitelbaum 25 Feb '18

25 Feb '18

Hi All, As a reminder the Squeak Oversight Election starts on Monday. If you received a ballot last year you are already set. If you would like to vote please send an email to voters(a)sueak.org If you are not sure about an email please let me know. You have until Monday to ensure you are ready to vote. Voting is one of the more important contributions you can make to your community. Please VOTE! All the best, Ron Teitelbaum

4 5

The Trunk: Kernel-ul.1153.mcz
by commits＠source.squeak.org 25 Feb '18

25 Feb '18

Levente Uzonyi uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-ul.1153.mcz ==================== Summary ==================== Name: Kernel-ul.1153 Author: ul Time: 25 February 2018, 1:02:44.121313 am UUID: 647960c4-9e41-4ad0-9190-9cac3a97f7ad Ancestors: Kernel-tonyg.1152 - When CroquetPlugin's primitiveGatherEntropy is available, use it to initialize the states array of Random instances. =============== Diff against Kernel-tonyg.1152 =============== Item was added: + ----- Method: Random class>>gatherEntropyInto: (in category 'entropy source') ----- + gatherEntropyInto: aByteArray + "Gather good random entropy from a system source and fill up aByteArray with it. Return true upon success, else false." + + <primitive: 'primitiveGatherEntropy' module: 'CroquetPlugin'> + ^false! Item was changed: ----- Method: Random>>seed: (in category 'initialization') ----- seed: anIntegerOrNil "Use the given integer as the seed, or generate one if it's nil." + (anIntegerOrNil isNil and: [ self seedWithRandomBytes ]) ifFalse: [ + | newSeed | + newSeed := anIntegerOrNil ifNil: [ + (Time utcMicrosecondClock bitShift: 28) bitXor: self hash hashMultiply ]. + (newSeed between: 0 and: 16rFFFFFFFF) ifFalse: [ + newSeed := self hashSeed: newSeed ]. + self initializeStatesWith: newSeed ]. + self generateStates! - | newSeed | - newSeed := anIntegerOrNil ifNil: - [(Time utcMicrosecondClock bitShift: 28) bitXor: self hash hashMultiply]. - (newSeed between: 0 and: 16rFFFFFFFF) ifFalse: - [newSeed := self hashSeed: newSeed]. - self - initializeStatesWith: newSeed; - generateStates! Item was added: + ----- Method: Random>>seedWithRandomBytes (in category 'private') ----- + seedWithRandomBytes + "Initialize the states array with random bytes from the VM. Return true on success, false on failure." + + | randomBytes | + randomBytes := ByteArray new: MTn * 4. + (self class gatherEntropyInto: randomBytes) ifFalse: [ + "Primitive not available" + ^false ]. + states := Array new: MTn. + 1 to: MTn do: [ :i | + states at: i put: ( + "The below code assumes that MTwordMask is 1 << 30 - 1. It avoids LargeInteger operations on 32-bit platforms. It's equivalent to: + (randomBytes unsignedLongAt: 1 bigEndian: true) bitAnd: MTwordMask" + ((randomBytes at: i * 4 - 3) bitAnd: 16r3F) * 256 + + (randomBytes at: i * 4 - 2) * 256 + + (randomBytes at: i * 4 - 1) * 256 + + (randomBytes at: i * 4)) ]. + ^true!

1 0

About customizing Squeak -> the title of the world menu?
by H. Hirzel 24 Feb '18

24 Feb '18

Hello a third issue today about customizing Squeak. The world menu has a title and this is given in Preferences desktopMenuTitle This is called in PasteUpMorph openWorldMenu However the source code in #desktopMenuTitle is from the year 2000 and it says desktopMenuTitle "Answer the title to be used for the 'meta menu'. For now, you can hard-code this, later someone should make this be a parameter the user can easily change. sw 9/6/2000" ^ 'World' "This is what it has always been" "^ 'Desktop' ^ 'Squeak' ^ 'Mike''s Control Panel'" How could a solution look like to make it possible for a user to easily change this parameter on a per project or per project type bases? Regards --Hannes

1 1

Jump to page: