Squeak-dev January 2017

squeak-dev@lists.squeakfoundation.org

34 participants
77 discussions

Primitive archeaology (was: VM Maker: VMMaker-dtl.391.mcz)
by David T. Lewis 06 Jan '17

06 Jan '17

Moving this from vm-dev to squeak-dev because the interest (and knowledge) probably resides here. The SqueakJS VM can support older images back to Squeak 1.13, and the logic for doing this is now being back-ported into the old interpreter VM. Mainly this involves identifying the old primitive calls that were referenced as numbered primitives in the old images, and then installing them into a table of numbered primitives whenever the VM runs an old image. This all works fine, but just to tie up some loose ends I want to ask about a fow ancient primitives that were used in the earliest Squeak images. There are five sound primitives that I am not sure about, as mentioned in a recent update on vm-dev: On Fri, Jan 06, 2017 at 12:35:29AM +0000, commits(a)source.squeak.org wrote: > > Old image support: Rescue five sound primitive assignments for updatePrimitiveTable for primitives that should be loaded from SouondGenerationPlugin, not from SoundPlugin. > > The following ancient primitives are still not loadable into the primitiive table for old image support: > > #primWaveTableSoundmixSampleCountintostartingAtpan > #primFMSoundmixSampleCountintostartingAtpan > #primPluckedSoundmixSampleCountintostartingAtpan > #primSampledSoundmixSampleCountintostartingAtpan > #oldprimSampledSoundmixSampleCountintostartingAtleftVolrightVol I think that these primitives were originally implemented in hand-written code that was (circa Squeak 1.13) stored in the image in method InterpreterSupportCode class>>macSoundFile, and later (circa Squeak 1.31) as InterpreterSupportCode class>>squeakOldSoundPrimsFile. Later, as numbered primitives were replaced by named primitives and loadable VM plugins, the original InterpreterSupportCode class was abandoned, and the various sound primitives were reimplemented in Smalltalk ("slang"). The old sound primitives (with 'pan' in the names, and input parameters for left/right panning) were abandoned as no longer relevant. Questions: - Is the above more or less right? - Am I right in thinking that the five primitives above are of minor historical interest, and there would be no point in providing an implemention in current VMs? Thanks, Dave

1 0

Backward image and VM compatibility
by Chris Cunnington 05 Jan '17

05 Jan '17

>> run images back to Squeak 1.13 Nice. Chris

1 0

Sierra and All-In-One fail (was Ma Client Server & Squeak launch issues)
by Chris Cunnington 04 Jan '17

04 Jan '17

> The all-in-one? I just downloaded it and it did launch (MacOS 10.10.5) > -- might be something on your end? It works for you, because you are not using Sierra (MacOS 10.12.2). Chris

1 0

Tales from the Crypt^H^H^H^H^HSimulator
by Eliot Miranda 03 Jan '17

03 Jan '17

Hi All, in working on the compactor in the simulator I'm observing some loooong pauses due to some, um, interesting image code. For example... -16r31A8 IdentityDictionary>scanFor: 16r7333E8: a(n) IdentityDictionary -16r3184 IdentityDictionary(Dictionary)>at:ifAbsent: 16r7333E8: a(n) IdentityDictionary -16r3160 MorphExtension>valueOfProperty: 16r4341A0: a(n) MorphExtension -16r3140 PasteUpMorph(Morph)>valueOfProperty: 16r898788: a(n) PasteUpMorph -16r3120 PasteUpMorph(Morph)>eventBubbleFilters 16r898788: a(n) PasteUpMorph -16r30F4 PasteUpMorph(Morph)>sendFilterEventBubble:for: 16r898788: a(n) PasteUpMorph -16r30CC PasteUpMorph(Morph)>handleEvent: 16r898788: a(n) PasteUpMorph -16r30A0 [] in MorphicEventDispatcher>doBubblingForFocusEvent:with: 16r2638F8: a(n) MorphicEventDispatcher -16r3080 PasteUpMorph(Morph)>withAllOwnersDo: 16r898788: a(n) PasteUpMorph -16r3060 FillInTheBlankMorph(Morph)>allOwnersDo: 16r9A498: a(n) FillInTheBlankMorph -16r3038 MorphicEventDispatcher>doBubblingForFocusEvent:with: 16r2638F8: a(n) MorphicEventDispatcher -16r3010 MorphicEventDispatcher>dispatchFocusEventFully:with: 16r2638F8: a(n) MorphicEventDispatcher -16r2B38 FillInTheBlankMorph(DialogWindow)>processFocusEvent:using: 16r9A498: a(n) FillInTheBlankMorph -16r2B14 FillInTheBlankMorph(Morph)>processFocusEvent: 16r9A498: a(n) FillInTheBlankMorph -16r2AE8 [] in HandMorph>sendFocusEvent:to:clear: 16rC85548: a(n) HandMorph -16r2AC4 BlockClosure>ensure: 16r263860: a(n) BlockClosure -16r2AA0 MouseEvent(MorphicEvent)>becomeActiveDuring: 16r2634C0: a(n) MouseEvent -16r2A74 [] in HandMorph>sendFocusEvent:to:clear: 16rC85548: a(n) HandMorph -16r2A50 BlockClosure>ensure: 16r263768: a(n) BlockClosure -16r2A2C HandMorph>becomeActiveDuring: 16rC85548: a(n) HandMorph -16r2A00 [] in HandMorph>sendFocusEvent:to:clear: 16rC85548: a(n) HandMorph -16r29DC BlockClosure>ensure: 16r263670: a(n) BlockClosure -16r29B8 PasteUpMorph>becomeActiveDuring: 16r898788: a(n) PasteUpMorph -16r2990 HandMorph>sendFocusEvent:to:clear: 16rC85548: a(n) HandMorph -16r2960 HandMorph>sendEvent:focus:clear: 16rC85548: a(n) HandMorph -16r2938 HandMorph>sendMouseEvent: 16rC85548: a(n) HandMorph -16r2914 HandMorph>handleEvent: 16rC85548: a(n) HandMorph -16r28E8 MouseOverHandler>processMouseOver: 16r2D08BC8: a(n) MouseOverHandler -16r28B8 HandMorph>processEvents 16rC85548: a(n) HandMorph -16r2898 [] in WorldState>doOneCycleNowFor: 16r126DFF8: a(n) WorldState -16r2870 Array(SequenceableCollection)>do: 16r434190: a(n) Array -16r2850 WorldState>handsDo: 16r126DFF8: a(n) WorldState -16r282C WorldState>doOneCycleNowFor: 16r126DFF8: a(n) WorldState -16r280C WorldState>doOneCycleFor: 16r126DFF8: a(n) WorldState -16r2330 WorldState>doOneSubCycleFor: 16r126DFF8: a(n) WorldState -16r2310 PasteUpMorph>doOneSubCycle 16r898788: a(n) PasteUpMorph -16r22E8 [] in FillInTheBlankMorph(DialogWindow)>getUserResponse 16r9A498: a(n) FillInTheBlankMorph -16r22C8 UndefinedObject(Object)>in: 16r41A280: a(n) UndefinedObject -16r22A0 [] in FillInTheBlankMorph(DialogWindow)>getUserResponse 16r9A498: a(n) FillInTheBlankMorph -16r2280 UndefinedObject(Object)>in: 16r41A280: a(n) UndefinedObject -16r2254 FillInTheBlankMorph(DialogWindow)>getUserResponse 16r9A498: a(n) FillInTheBlankMorph -16r2234 FillInTheBlankMorph class>request:initialAnswer:centerAt:inWorld:onCancelReturn:acceptOnCR:answerExtent: 16r12232B8: a(n) FillInTheBlankMorph class -16r21FC FillInTheBlankMorph class>request:initialAnswer:centerAt:inWorld:onCancelReturn:acceptOnCR: 16r12232B8: a(n) FillInTheBlankMorph class -16r21C8 FillInTheBlankMorph class>request:initialAnswer:centerAt:inWorld:onCancelReturn: 16r12232B8: a(n) FillInTheBlankMorph class -16r2198 FillInTheBlankMorph class>request:initialAnswer:centerAt:inWorld: 16r12232B8: a(n) FillInTheBlankMorph class -16r216C FillInTheBlankMorph class>request:initialAnswer:centerAt: 16r12232B8: a(n) FillInTheBlankMorph class -16r2144 FillInTheBlankMorph class>request:initialAnswer: 16r12232B8: a(n) FillInTheBlankMorph class -16r2120 MorphicUIManager>request:initialAnswer: 16r821990: a(n) MorphicUIManager -16r20F8 SmalltalkImage>getFileNameFromUserSuggesting: 16r79FC80: a(n) SmalltalkImage -16r20D8 SmalltalkImage>getFileNameFromUser 16r79FC80: a(n) SmalltalkImage -16r20B8 SmalltalkImage>saveAs 16r79FC80: a(n) SmalltalkImage -16r209C TheWorldMainDockingBar>saveImageAs 16r739530: a(n) TheWorldMainDockingBar -16r2078 [] in MenuItemMorph>invokeWithEvent: 16r16E7B60: a(n) MenuItemMorph -16r2054 BlockClosure>ensure: 16r9DC50: a(n) BlockClosure -16r2030 CursorWithMask(Cursor)>showWhile: 16r70B1C0: a(n) CursorWithMask -16r200C MenuItemMorph>invokeWithEvent: 16r16E7B60: a(n) MenuItemMorph scavenging(676)...scavenging(677)...scavenging(678)...scavenging(679)...scavenging(680)...scavenging(681)...scavenging(682)... and so on. It seems that doBubblingForFocusEvent:with hides a /lot/ of computation. I wonder if the system might be more responsive if this were to receive some attention. _,,,^..^,,,_ best, Eliot

1 1

I was surprised
by Bob Arning 03 Jan '17

03 Jan '17

This has been this way for aeons, but it surprised me: false | 'hello' ==> 'hello' Does anything actually depend on this being this way?

4 6

The Trunk: WebClient-Tests-jr.49.mcz
by commits＠source.squeak.org 03 Jan '17

03 Jan '17

Tobias Pape uploaded a new version of WebClient-Tests to project The Trunk: http://source.squeak.org/trunk/WebClient-Tests-jr.49.mcz ==================== Summary ==================== Name: WebClient-Tests-jr.49 Author: jr Time: 3 January 2017, 2:02:24.562318 pm UUID: 69152681-25b5-e84a-9c59-c68167eaff09 Ancestors: WebClient-Tests-topa.48 add test for chunk stream reading =============== Diff against WebClient-Tests-topa.48 =============== Item was added: + ----- Method: WebClientServerTest>>testChunkedLoopbackWithStream (in category 'tests - chunked') ----- + testChunkedLoopbackWithStream + "Test HTTP loopback streaming using chunked transfer-encoding" + + | queue response stream | + queue := SharedQueue new. + server addService: '/recv' action:[:req | + + "The /recv service establishes the write-end for the server. + In a real environment we would access protect the request + and also pass a token to be used to link the incoming /send + request from the client." + + req sendResponse: 200 chunked:[:writeEnd| + | chunk | + "There is no reason to wait for the client to send a request, + the protocol is entirely freestyle. Send something just because + we can" + writeEnd nextChunkPut: 'Initial response'. + "And from here on echo any incoming data" + [chunk := queue next. + chunk == nil] whileFalse:[writeEnd nextChunkPut: chunk]. + "And some final data" + writeEnd nextChunkPut: 'Final response'. + ]. + ] methods: #('GET'). "only allow GET requests" + + server addService: '/send' action:[:req | + + "The /send service establishes the read-end for the server. + Simply read the chunks as they come in and stick them in + our loopback queue to send them back to the client." + + | chunk | + [chunk := req nextChunk. + chunk == nil] whileFalse:[queue nextPut: chunk]. + queue nextPut: nil. "end conversation" + req send200Response: 'ok'. + ] methods: #('POST'). "only allow POST requests" + + "Establish the server response stream" + response := WebClient new httpGet: self localHostUrl, '/recv'. + self assert: response code = 200. + self assert: (response headerAt: 'Transfer-Encoding') = 'chunked'. + stream := response contentStream. + self assert: (stream next: 'Initial response' size) equals: 'Initial response'. + + "Establish the client request stream" + WebClient + httpPostChunked: self localHostUrl, '/send' + content:[:request| + "We've set up both ends, try our loopback server" + request nextChunkPut: 'Hello World'. + self assert: (stream next: 'Hello World' size) equals: 'Hello World'. + request nextChunkPut: 'The answer is 42'. + self assert: (stream next: 'The answer is 42' size) equals: 'The answer is 42'. + ] type: nil. + + self assert: (stream next: 'Final response' size) equals: 'Final response'. + !

1 0

The Trunk: WebClient-Core-jr.104.mcz
by commits＠source.squeak.org 03 Jan '17

03 Jan '17

Tobias Pape uploaded a new version of WebClient-Core to project The Trunk: http://source.squeak.org/trunk/WebClient-Core-jr.104.mcz ==================== Summary ==================== Name: WebClient-Core-jr.104 Author: jr Time: 3 January 2017, 2:00:53.087318 pm UUID: d1ea9e44-934e-db44-9617-a57b408678fe Ancestors: WebClient-Core-ul.103 fix: bogus chunked stream data if a later chunk is smaller than a previous one also do not fetch the next chunk until its contents is requested =============== Diff against WebClient-Core-ul.103 =============== Item was changed: ----- Method: WebChunkedStream>>next: (in category 'accessing') ----- next: anInteger "Answer the next anInteger elements of my collection. overriden for simplicity" + [(position + anInteger > readLimit) and:[chunkSize ~= 0]] - [(position + anInteger >= readLimit) and:[chunkSize ~= 0]] whileTrue:[self nextChunk]. ^super next: anInteger ! Item was changed: ----- Method: WebChunkedStream>>nextChunk (in category 'accessing') ----- nextChunk "Answer the next chunk from a message using chunked transfer encoding." | chunk | chunkSize = 0 ifTrue:[^'']. "read last chunk" chunkSize := Integer readFrom: (sourceStream upToAll: String crlf) asString base: 16. chunkSize = 0 ifFalse:[chunk := sourceStream next: chunkSize]. sourceStream skip: 2. "CrLf" (chunkSize + readLimit - position) <= collection size ifTrue:[ collection replaceFrom: 1 to: (readLimit-position) with: collection startingAt: position+1. readLimit := readLimit - position. position := 0. collection replaceFrom: readLimit+1 to: readLimit + chunkSize with: chunk startingAt: 1. readLimit := readLimit + chunkSize. ] ifFalse:[ + position < readLimit + ifTrue: [collection := (collection copyFrom: position + 1 to: readLimit), chunk] + ifFalse: [collection := chunk]. + position := 0. + readLimit := collection size. - collection := collection, chunk. - readLimit := readLimit + chunkSize. ]. ^chunk !

1 0