Vm-dev June 2021

vm-dev@lists.squeakfoundation.org

14 participants
74 discussions

[OpenSmalltalk/opensmalltalk-vm] Allow choosing an image via zenity when no arguments are provided (#408)
by Leon Matthes 05 Jun '23

05 Jun '23

You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/408 -- Commit Summary -- * Add file chooser dialog to squeak.sh.in * Add file chooser dialog to bin.squeak.sh.in -- File Changes -- M platforms/unix/config/bin.squeak.sh.in (13) M platforms/unix/config/squeak.sh.in (13) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/408.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/408.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/408

4 8

[OpenSmalltalk/opensmalltalk-vm] Patch callback thunkEntry to not optimize (#353)
by Guille Polito 13 Apr '22

13 Apr '22

O2 and O1 compilation produce a segmentation fault due to stack corruption (when debugging we saw some extra pushes from the stack) on callbacks return. This happens on windows 32, when compiling with mingw gcc 7.4.0. The issue can be reproduced easily by running the Alien qsort example in latest vms in both Pharo and Squeak. This PR proposes to patch just the thunkEntry function. Not optimizing just that function solves the issue in our environment, though maybe there is a more fine-grained solution. We should still investigate what is the particular optimization that causes the problem. You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/353 -- Commit Summary -- * Patch callback thunkEntry to not optimize, failing in win32 using gcc 7.4.0 -- File Changes -- M platforms/Cross/plugins/IA32ABI/ia32abicc.c (2) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/353.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/353.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/353

4 4

[OpenSmalltalk/opensmalltalk-vm] Proposal for new BitBlt rules (#505)
by Juan Vuletich 26 Feb '22

26 Feb '22

In addition to the existing alpha blending rules (24 and 34), I propose 3 new additional rules. Check https://en.wikipedia.org/wiki/Alpha_compositing Existing rule 34 is a correct implementation of Alpha Blending for scaled forms, i.e. if premultiplied alpha is used. But rule 24 is a correct implementation of non-scaled forms, only for the case where destination is opaque (i.e. it's alpha is 1.0 in every pixel). If destination includes translucency (or it is completely transparent), the result is not correct. In order to fix it, the RGB of each pixel need to be divided by the pixel alpha. The proposed blendUnscaled is the basic (for non-scaled forms) alpha blending described in Wikipedia. Note that users knowing that destination background is opaque might call the faster rule 24 instead. The other two additional proposed rules are for converting to and from premultiplied alpha. EXISTING blend 24 alphaBlend resultAlpha = srcAlpha + destAlpha*(1-srcAlpha) resultRGB = srcAlpha*source + (1-srcAlpha)*dest EXISTING blendAlphaScaled 34 alphaBlendScaled resultRGBA = source + (1-srcAlpha)*dest NEW PROPOSED multiplyRGBByAlpha Non premultiplied alpha -> premultiplied alpha. Only uses destination. Alpha unmodified. For each RGB component, resultRGB = dest*destAlpha NEW PROPOSED divideRGBByAlpha Premultiplied alpha -> non premultiplied alpha. Only uses destination. Alpha unmodified. For each RGB component, resultRGB = dest/destAlpha NEW PROPOSED blendUnscaled Equivalent to blend, and then divideRGBByAlpha resultAlpha = srcAlpha + destAlpha*(1-srcAlpha) resultRGB = (srcAlpha*source + (1-srcAlpha)*dest) / resultAlpha This would allow handling of scaled (premultiplied-alpha) forms, and blending of regular forms including translucency, without the need to call slower smalltalk code to fix the results. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/505

7 12

[OpenSmalltalk/opensmalltalk-vm] primitiveTranslateStringWithTable modifies symbols in place, it should be reserved for non-literal strings only (#561)
by fmateoc 21 Feb '22

21 Feb '22

After making sure a string was not interned, ( "Symbol findInterned: 'test123'" returned nil ), I did | s | s := #TEST123. s translateToLowercase. s -> (Symbol findInterned: s) and the resulting s is a Symbol and it is not interned. To make sure that the primitive is invoked (and not its fallback code), put a halt in ByteString class >> #translate:from:to:table: -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/561

2 2

[OpenSmalltalk/opensmalltalk-vm] Cannot build unix sources (missing file: bld/plugins.int) (#507)
by Christoph Thiede 21 Dec '21

21 Dec '21

I am trying to build the unix sources for this project, exactly following the `HowToBuildFromSources` manual (the easy way). But unfortunately, when running `make` I get an error that `bld/plugins.int` is missing: ``` $ make [ -d bld ] || mkdir bld [ -f bld/Makefile ] || ( cd bld; ../config/configure; ) checking for gcc... gcc # ... (75 lines skipped) checking whether to build static libraries... no /workspace/opensmalltalk-vm/src /workspace/opensmalltalk-vm/src/plugins checking sanity of generated src directory... bad missing file: /workspace/opensmalltalk-vm/platforms/unix/bld/plugins.int make: *** [Makefile:5: all] Error 1 ``` See yourself: [![Open in Gitpod](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#snapshot/9bc102f3-ba84-437f-a226-a8851782c41b) Is it me or is the documentation of the build process not up to date? Looking forward to your help! -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/507

7 12

[OpenSmalltalk/opensmalltalk-vm] UnixProcess forkSqueak broken since October (#548)
by David T Lewis 21 Dec '21

21 Dec '21

UnixProcess class>>forkSqueak is no longer working. The forked child process VM crashes with segmentation fault. Testing with VMs from bintray shows that version 5.0-202009300634 works, and any version 5.0-202010192227 or later fails. Stack dump sometimes (but not always) shows failure in aioPoll() for example: */usr/local/bin/../lib/squeak/5.0-202101160259/squeak(aioPoll+0x12e)[0x4bc0fe] I am not able to catch the failure in gdb because it happens in the child process. My initial guess is that it may be related to the epoll enhancements added in this time frame, because forking the VM requires initializing things like this in the new child VM process. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/548

4 9

[OpenSmalltalk/opensmalltalk-vm] primitiveSSLCreate fails sporadically on Windows (#554)
by Christoph Thiede 28 Oct '21

28 Oct '21

Hi all, I think this is not a new issue, but I am experiencing it with increasing frequency on my Win 10 machine: When instantiating SqueakSSL, primitiveCreate fails. I don't see an error in the console so I cannot tell more details about the error. Sometimes restarting my image helps, but right now, it does not. Other images running with the same VM (202010232046) can still access the internet via SSL. Maybe it plays a role that the affected image puts the plugin much more under stress by always holding at least one open connection to a server. Is this a known problem? Are there any workarounds? Looking forward to a fix, Christoph -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/554

5 27

[OpenSmalltalk/opensmalltalk-vm] ThreadedFFIPlugin throws FFIErrorCoercionFailed when passing 64-bit indexable objects to 64-bit pointer arguments (#569)
by Stephan Lutz 11 Sep '21

11 Sep '21

Given the external function defined by the following Squeak method: ```smalltalk myFunc: aFloat64Array <apicall: void 'myFunc' (double*)> ^ self externalCallFailed ``` When passing an instance of `Float64Array` to this method, the FFI plugin throws error code 6 (`Could not coerce arguments`). The same can be reproduced in similar scenarios for other 64-bit indexable objects like `DoubleWordArray` and `SignedDoubleWordArray` (which ultimately share the same class format anyway). There were no issues when doing the same using 32-bit indexable objects. --- As far as I can tell the issue seems to stem from `ThreadedFFIPlugin >> ffiAtomicArgByReference:Class:in:` which ends with the following code: ```smalltalk (atomicType <= FFITypeDoubleFloat) ifTrue: [((interpreterProxy isWords: oop) or: [oopClass = interpreterProxy classByteArray]) ifTrue: [^self ffiPushPointer: (interpreterProxy firstIndexableField: oop) in: calloutState]. (oopClass = interpreterProxy classExternalAddress) ifTrue: [^self ffiPushPointer: (self longAt: oop + interpreterProxy baseHeaderSize) in: calloutState]. isAlien ifTrue: [^self ffiPushPointer: (self pointerForOop: (self startOfData: oop)) in: calloutState]]. ^FFIErrorCoercionFailed ``` While the second line checks 32-bit indexable via `isWords:` and byte arrays, it seems to be missing a test for `isLong64s:`. --- Just in case it's relevant for some reason: ``` Squeak latest update: #20467 Image format 68021 (64 bit) Preferred bytecode set: SistaV1 ``` ``` Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.2940] Unix built on Jun 9 2021 14:12:17 Compiler: Clang 10.0.0 platform sources revision VM: 202102090434 Date: Mon Feb 8 20:34:38 2021 CommitHash: 9f1b4644e Plugins: 202102090434 CoInterpreter VMMaker.oscog-eem.2940 uuid: 29171f50-756f-4560-8488-ced65f2d4841 Jun 9 2021 StackToRegisterMappingCogit VMMaker.oscog-eem.2940 uuid: 29171f50-756f-4560-8488-ced65f2d4841 Jun 9 2021 ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/569

2 4

[OpenSmalltalk/opensmalltalk-vm] Context >> #printOn: is weird (#536)
by Marcel Taeumel 13 Aug '21

13 Aug '21

VM: win32x86.cog.spur (202011160746, VMMaker.oscog-eem.2887) OS: Windows 10 SQ: Squeak6.0alpha #20077 I suppose that `Context >> #objectClass:` (primitive 111) answers `Context` from time to time. I cannot really debug it, though. Sometimes `Context >> #printOn:` does the right thing. ![grafik](https://user-images.githubusercontent.com/5765308/99515452-459d5b00-298d-11eb-93f3-a617c099a95a.png) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/536

1 2

[OpenSmalltalk/opensmalltalk-vm] Failing linux build due to error directive in config.h (#560)
by Nicolas Cellier 13 Aug '21

13 Aug '21

The linux builds are failing for a while after some re-arrangement of header order. It happens that config.h cannot work after linux features.h, so the former should be included before the later. An #error directive checks and protect against this case. One possible workaround could be to move #include "config.h" ahead in a few files... -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/560

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev June 2021