Squeak-dev February 2024

squeak-dev@lists.squeakfoundation.org

32 participants
107 discussions

The Inbox: Graphics-nice.550.mcz
by commits＠source.squeak.org 08 Feb '24

08 Feb '24

Nicolas Cellier uploaded a new version of Graphics to project The Inbox: http://source.squeak.org/inbox/Graphics-nice.550.mcz ==================== Summary ==================== Name: Graphics-nice.550 Author: nice Time: 7 February 2024, 11:08:47.366987 pm UUID: 9a845f0a-b60c-a740-93f9-d705b5b9b840 Ancestors: Graphics-mt.549 Provide a new Form hack of arbitrary width for bulk transfer of bytes. This may be used for example for reversing the endianness of a DoubleWordArray. =============== Diff against Graphics-mt.549 =============== Item was added: + ----- Method: Form>>hackBits:width: (in category 'private') ----- + hackBits: bitThing width: anInteger + "This method provides an initialization so that BitBlt may be used, eg, to + copy ByteArrays and other non-pointer objects efficiently. + The resulting form looks anInteger wide, 8 bits deep, and height is adjusted to fit the bitThing size. + anInteger shall be a multiple of 4, because lines in a Form always fall on a Word boundary. + If not, some dead bytes will remain unaccessible to the BitBlt operations on each line. + That's also the case of trailing excess bytes" + width := anInteger. + depth := 8. + bitThing class isBits ifFalse: [self error: 'bitThing must be a non-pointer object']. + height := bitThing basicSize * bitThing bytesPerBasicElement // (width + 3 // 4 * 4). + bits := bitThing!

1 0

(no subject)
by Nicolas Cellier 08 Feb '24

08 Feb '24

Hi all, while answering https://stackoverflow.com/questions/77883145/how-to-define-a-variable-in-st… I remembered that Compiler evaluations are performed in the scope of nil. We thus have access to instance variables (none) of this UndefinedObjects but also to class variables of Object. Thus, evaluating 'DependentsFields inspect' from anywhere in the Squeak World (but maybe from a browser browsing ProtoObject) gives access to the dependents. It's been a long time since I did not do that, so to my surprise the DependentsFields are quite populated! I saw a lot of Morphs in there, InspectorField, but also some intriguing '...' When I click on '...' the system becomes unresponsive. An interrupt shows a rather long stream dedicated at printing the dependents of this object. I stopped the stream at position 375271474, hmm those VM are really getting to fast! The debugger shows a recursive attempt at storing a CompiledMethod in CompiledCode>>storeOn: '(InspectorField basicNew instVarAt: 1 put: 30; instVarAt: 2 put: ((FullBlockClosure basicNew: 1) instVarAt: 1 put: ((Context basicNew: 1) instVarAt: 1 put: nil; instVarAt: 2 put: nil; instVarAt: 3 put: 1; instVarAt: 4 put: ((CompiledMethod newMethod: 9 header: -1152921504589807613) at: 33 put: 64; at: 34 put: 249; at: 36 put: 1; at: 37 put: 92; literalAt: 1 put: ((CompiledBlock newMethod: 5 header: -1152921504589545471) at: 17 put: 64; at: 18 put: 65; at: 19 put: 112; at: 20 put: 94; literalAt: 1 put: ((CompiledMethod newMethod: 9 header: -1152921504589807613) at: 33 put: 64; at: 34 put: 249; at: 36 put: 1; at: 37 put: 92; literalAt: 1 put: ((CompiledBlock newMethod: 5 header: -1152921504589545471) at: 17 put: 64; at: 18 put: 65; at: 19 put: 112; at: 20 put: 94; literalAt: 1 put: ((CompiledMethod newMethod: 9 header: -1152921504589807613) at: 33 put: 64; at: 34 put: 249; at: 36 put: 1; at: 37 put: 92; literalAt: 1 put: ((CompiledBlock newMethod: 5 header: -1152921504589545471) ...' OK, so the first literal of the CompiledMethod is the FullBlockClosure in CollectionInspector>>#elementGetterAt: self == (CollectionInspector>>#elementGetterAt:) = false So it is not the current definition of the method, though the decompiledCode is similar elementGetterAt: t1 ^ [:t2 | t2 at: t1] The FullBlockClosure store the CompiledMethod in 1st literal, so we effectively have an infinite loop when invoking storeOn: But I cannot get the sender of storeOn: , the Full Stack button of the debugger cut the execution stack at CompiledBlock(CompiledCode)>>storeOn: Strange. If I inspect the local variable field thisContext in the debugger, it shows that the original sender was InspectorField(Object)>>storeString Hmm, if the debugger is in my way, that's not easy. | x | x := self. [x sender sender method == x method] whileTrue: [x := x sender sender]. x longStack inspect WriteStream>>store: InspectorField(Object)>>storeOn: [] in InspectorField(Object)>>storeString String class(SequenceableCollection class)>>new:streamContents: String class(SequenceableCollection class)>>streamContents: InspectorField(Object)>>storeString DictionaryInspector(Inspector)>>contentsForTruncationOf: [] in [] in DictionaryInspector(Inspector)>>streamOn:truncate:collectFields: InspectorField>>getValueFor: DictionaryInspector(Inspector)>>selection [] in DictionaryInspector(Inspector)>>getContents Time class>>microsecondsToRun: Time class>>millisecondsToRun: FullBlockClosure(BlockClosure)>>timeToRun DictionaryInspector(Inspector)>>getContents [] in DictionaryInspector(Inspector)>>updateContentsSafely FullBlockClosure(BlockClosure)>>on:do: FullBlockClosure(BlockClosure)>>ifError: DictionaryInspector(Inspector)>>updateContentsSafely DictionaryInspector(Inspector)>>selectionIndex: PluggableListMorphPlus(PluggableListMorph)>>changeModelSelection: PluggableListMorphPlus(PluggableListMorph)>>mouseUp: ...snip... I'm a bit lost, but it's worrying that contentsForTruncationOf: uses storeString, since storeString is not recursive structure friendly. The ellipsis was the filed #95 of the inspector, an InspectorField<#ellipsis> named '...' which has a valueGetter [closure] in [] in DictionaryInspector(Inspector)>>streamOn:truncate:collectFields: which points me to the outerContext CollectionInspector>>elementGetterAt: for the method (CollectionInspector>>#elementGetterAt: "a CompiledMethod(2960732)") but has no sender... Huh, could it be the source of debugger confusion? (the cut Full stack) These circonvolutions drive me nuts. I don't know if it's just this image, or how to purge the dependent fields, so I just report here. it may involve debugging and process termination problems, whatever, I don't know, so maybe someone can reproduce/explain...

1 1

Re: [squeak-smalltalk/squeak-object-memory] "Computation has been terminated" when terminating a process while resuming from an exception (Issue #112)
by Christoph Thiede 08 Feb '24

08 Feb '24

Ah, I see. The ensure context in `Context>>#runSimulated:contextAtEachStep:` incorrectly acts like `valueUninterruptably`, forcing a return from the home context even when the execution shall not continue. This was introduced to support situations like ```smalltalk [Context runSimulated: [2/0]] on: ZeroDivide do: [:ex | ex return: 1] ``` but when the execution is actually to abort, this behavior makes no sense. Hmm... maybe `ensure:` should have an `aborting` variable and cull it to aBlock? ;-) Or how else could we find out from within that specific ensure block that we must not try to proceed? -- Reply to this email directly or view it on GitHub: https://github.com/squeak-smalltalk/squeak-object-memory/issues/112#issueco… You are receiving this because you are subscribed to this thread. Message ID: <squeak-smalltalk/squeak-object-memory/issues/112/1933081333(a)github.com>

1 0

Making a Debian project package for squeak
by Tim Rowledge 07 Feb '24

07 Feb '24

We don't have a current debian package for Squeak; it would nice to get that solved. Some time ago philb was working away at this but we haven't heard from him in a while now, so I'd like to know if anyone might be interested in pushing forward with it. It's not simple but it would be good to have sorted and set up so it is as near self-maintaining as practical. Philb's last comment on progress was - "Work completed: 1) I have (or had... it worked as of late last year) working multi-arch packaging for i386/amd64/armhf/arm64. On x86, side-by-side installs of i386 and amd64 packages were confirmed working. (I don't recall if side-by-side ARM 32- and 64-bit versions were working yet or not) 2) Thanks to Dave's changes to the classic VM repo, all VM packages can co-exist. This should provide roughly the functionality of the all-in-one packaging in terms of being able to run the majority of images in use out there. 3) Given 1 & 2, the packages can be built and either manually installed or installed via a custom (Debian package) repo. Work remaining to be done: 1a) I was beginning work with Tobias and Marcel to make the (relatively minor, IIRC) changes needed to integrate the packaging work into the VM (github) repo. 1b) There was also a desire to include CI builds in the scope. I don't recall how much there is to do for this. 2) There are several (IIRC, 3) embedded libraries that need to be eliminated (i.e. switch to using the Debian package repo versions of the libraries) to comply with Debian packaging policies. This does not appear to be entirely straightforward as the Squeak library versions are rather ancient and there's at least one custom patch to work around an issue with a library. (based on my preliminary research on the JPEG library, this is probably the largest bit of work remaining) 3) Once 2 is done, work with the Debian maintainer to get the packages included in the Debian package repos. This will likely require some additional minor tweaks to make the maintainers happy. This process will require some diplomacy as the package maintainers don't have a deep understanding of why Squeak does things the way it does and wanted some things that aren't possible... but initial feedback was encouraging that getting them on board is feasible." tim -- tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim Oxymorons: Living dead

1 0

Re: [squeak-smalltalk/squeak-object-memory] "Computation has been terminated" when terminating a process while resuming from an exception (Issue #112)
by Christoph Thiede 07 Feb '24

07 Feb '24

@isCzech Thanks, willl take a look soon! In the meantime, here is just another example that triggers the same error: ```smalltalk block := [Context runSimulated: [6 * 7]]. ``` This one is actually of practical relevance for me, because in my scenario I am running a lot of sandboxed simulations in background processes ... I wonder whether we could think this together with the stepOver/runUntilErrorOrReturnFrom issue which shares the same vulnerability to irregular context switches ... Like, place a marker on the context stack/a safe bottom context while performing a temporary context switch and when we are terminating a process, check for such a marker, and if yes, continue execution regularly until the marker is no longer set? Or a bit stateless, use a pragma in known context switching methods such as #contextEnsure: (the old version) that instruct the unwinding logic to defer unwinding until that method has popped? Hm ... this is tricky ^^ -- Reply to this email directly or view it on GitHub: https://github.com/squeak-smalltalk/squeak-object-memory/issues/112#issueco… You are receiving this because you are subscribed to this thread. Message ID: <squeak-smalltalk/squeak-object-memory/issues/112/1932699985(a)github.com>

1 0

Re: [squeak-smalltalk/squeak-object-memory] Please ignore | Test 1 (Issue #114)
by Christoph Thiede 06 Feb '24

06 Feb '24

Hello test, `this` is a _world_? -- Reply to this email directly or view it on GitHub: https://github.com/squeak-smalltalk/squeak-object-memory/issues/114#issueco… You are receiving this because you commented. Message ID: <squeak-smalltalk/squeak-object-memory/issues/114/1930240900(a)github.com>

3 3

Re: mailing list problems
by Hal Eden 06 Feb '24

06 Feb '24

just a little more info related to my mail problems: i stopped receiving mail from squeak dev around the same time that colorado.edu mail was moved to 365 (around the end of 2022). in working with consulting customers, i have run into a lot of situations where microsoft tends to be very picky about accepting mail. i noticed that MX ToolBox says that squeak.org does not have a DMARC policy enabled—i know that MS might use that as a reason to not accept mail. hal > On Jan 31, 2024, at 1:56 PM, Hal Eden <haleden303(a)gmail.com> wrote: > to separate this out, in case anyone is looking into mail problems. > the email address i am not receiving mail from squeak-dev on: haleden(a)colorado.edu > > hal > >> On Jan 30, 2024, at 6:56 PM, lewis(a)mail.msen.com wrote: >> … mention of mail problems... >> Thanks for mentioning this. I guess it'’ a topic for a different discussion thread, but I also have had similar issues receiving mail from the Squeak lists, and I wonder if others are having issues but are not able to ask about it because (d'oh!) their list email is not working.

2 3

Re: [squeak-smalltalk/squeak-object-memory] Please ignore | Test 1 (Issue #114)
by Christoph Thiede 06 Feb '24

06 Feb '24

Please ignore this message (3) _as_ `well`. -- Reply to this email directly or view it on GitHub: https://github.com/squeak-smalltalk/squeak-object-memory/issues/114#issueco… You are receiving this because you are subscribed to this thread. Message ID: <squeak-smalltalk/squeak-object-memory/issues/114/1930225027(a)github.com>

1 0

[GitHub] Please verify your email address.
by GitHub 06 Feb '24

06 Feb '24

Almost done, @squeak-smalltalk-bot! To secure your GitHub account, we just need to verify your email address: squeak-dev(a)lists.squeakfoundation.org. Click the link below to verify your email address: https://github.com/users/squeak-smalltalk-bot/emails/305696150/confirm_veri… This will let you receive notifications and password resets from GitHub. You're receiving this email because you recently created a new GitHub account or added a new email address. If this wasn’t you, please ignore this email. --- Sent with <3 by GitHub. GitHub, Inc. 88 Colin P Kelly Jr Street San Francisco, CA 94107

1 0

Please ignore | Test (new GitHub bot, attempt 3)
by Christoph Thiede 06 Feb '24

06 Feb '24

This message should appear on squeak-dev and come from an account named GitHub-Bot. Later, this bot should automatically inform the list about new issues on bugs.squeak.org. I hope this works ...

1 0