From notifications at github.com Mon Feb 1 02:34:17 2021 From: notifications at github.com (David T Lewis) Date: Sun, 31 Jan 2021 18:34:17 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] UnixProcess forkSqueak broken since October (#548) In-Reply-To: References: Message-ID: Update - The actual forkSqueak is working fine, but we get failures associated with aio handling for the socket connection to the X11 server. The child closes the socket and calls aioDisable for the socket fd to unregister it. When using epoll rather than generic aio event handling, this apparently affects the Linux kernel epoll registration for the socket fd (I am not sure if I understand this correctly, but this appears to be the case). The result seems to be failures in either the child or parent VM process, or both. The problem goes away if I #ifdef the call to aioDisable() in the forgetXDisplay() function. I am not sure if this is a proper fix or just a workaround kludge, but it does work. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/548#issuecomment-770523083 -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at github.com Mon Feb 1 04:38:59 2021 From: noreply at github.com (David T Lewis) Date: Sun, 31 Jan 2021 20:38:59 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] cc3dd1: In forgetXDisplay() do not call aioDisable() for t... Message-ID: Branch: refs/heads/dtl/aio-forksqueak Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: cc3dd188b692270c268dffad44a8a6268ec1ae47 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/cc3dd188b692270c268dffad44a8a6268ec1ae47 Author: David T. Lewis Date: 2021-01-31 (Sun, 31 Jan 2021) Changed paths: M platforms/unix/vm-display-X11/sqUnixX11.c Log Message: ----------- In forgetXDisplay() do not call aioDisable() for the socket connection to the X11 server if Linux epoll event handling is being used, because forgetXDisplay() is typically called after a fork(). With epoll event handling the shared fd reference affects both parent and child badly. From notifications at github.com Mon Feb 1 04:41:32 2021 From: notifications at github.com (David T Lewis) Date: Sun, 31 Jan 2021 20:41:32 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] In forgetXDisplay() do not call aioDisable() for the socket connection (#550) Message-ID: to the X11 server if Linux epoll event handling is being used, because forgetXDisplay() is typically called after a fork(). With epoll event handling the shared fd reference affects both parent and child badly. You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/550 -- Commit Summary -- * In forgetXDisplay() do not call aioDisable() for the socket connection -- File Changes -- M platforms/unix/vm-display-X11/sqUnixX11.c (2) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/550.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/550.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/550 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Feb 1 04:45:44 2021 From: notifications at github.com (David T Lewis) Date: Sun, 31 Jan 2021 20:45:44 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] UnixProcess forkSqueak broken since October (#548) In-Reply-To: References: Message-ID: The workaround (fix?) for forkSqueak is in pull request #550 -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/548#issuecomment-770559995 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Feb 1 08:33:19 2021 From: notifications at github.com (Nicolas Cellier) Date: Mon, 01 Feb 2021 00:33:19 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] In forgetXDisplay() do not call aioDisable() for the socket connection (#550) In-Reply-To: References: Message-ID: IMO, not a good fix. The fact the the epoll structure is shared between parent and childs (forked) process is a problem not only for the X11 socket connection, but for ALL the polled fd. We shall close the epoll fd and re-create it in the forked vm. Probably, we should use a close-on-exec flag for epoll `epoll_create1(EPOLL_CLOEXEC )`, so as to protect from accidental sharing, unless someone foresee a good scenario for sharing epoll fd (I fail to see one). -- 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/550#issuecomment-770674150 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Feb 1 08:35:20 2021 From: notifications at github.com (Tobias Pape) Date: Mon, 01 Feb 2021 00:35:20 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] In forgetXDisplay() do not call aioDisable() for the socket connection (#550) In-Reply-To: References: Message-ID: Isn't there a way to duplicate fd's on fork, so that the child can close them at will without harm? (haven't done fork/exec in a while, tho) -- 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/550#issuecomment-770675459 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Feb 1 08:51:58 2021 From: notifications at github.com (Nicolas Cellier) Date: Mon, 01 Feb 2021 00:51:58 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] In forgetXDisplay() do not call aioDisable() for the socket connection (#550) In-Reply-To: References: Message-ID: > > > Isn't there a way to duplicate fd's on fork, so that the child can close them at will without harm? > (haven't done fork/exec in a while, tho) No, from what I understand, the file-descriptors are duped anyway (they are in the process space), but the file descriptions are shared (in the kernel space). The duped fd point to shared objects... See https://copyconstruct.medium.com/the-method-to-epolls-madness-d9d2d6378642 -- 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/550#issuecomment-770686787 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Feb 1 09:03:00 2021 From: notifications at github.com (Tobias Pape) Date: Mon, 01 Feb 2021 01:03:00 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] In forgetXDisplay() do not call aioDisable() for the socket connection (#550) In-Reply-To: References: Message-ID: Regarding `EPOLL_CLOEXEC`, does it really help when we do not actually `exec`? -- 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/550#issuecomment-770694817 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Feb 1 09:53:20 2021 From: notifications at github.com (Nicolas Cellier) Date: Mon, 01 Feb 2021 01:53:20 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] In forgetXDisplay() do not call aioDisable() for the socket connection (#550) In-Reply-To: References: Message-ID: Ouch, you're right, close-on-exec does close on exec as the name tells... Why the hell did I think that it would work at fork time? Just because it would fit our needs? Sort of wishful thinking... -- 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/550#issuecomment-770727997 -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at github.com Tue Feb 2 19:01:46 2021 From: noreply at github.com (Eliot Miranda) Date: Tue, 02 Feb 2021 11:01:46 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] 739ad1: ALlow the defaylt stack size to be overridden in t... Message-ID: Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 739ad1ebada2035c3cc6f1dc7b1a178bd52a7125 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/739ad1ebada2035c3cc6f1dc7b1a178bd52a7125 Author: Eliot Miranda Date: 2021-02-02 (Tue, 02 Feb 2021) Changed paths: M build.win64x64/common/Makefile.msvc.tools Log Message: ----------- ALlow the defaylt stack size to be overridden in the MSVC 64-bit window builds. From noreply at github.com Wed Feb 3 00:57:03 2021 From: noreply at github.com (Eliot Miranda) Date: Tue, 02 Feb 2021 16:57:03 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] 4d8cc8: CameraPlugin robustness on macOS. If the frame bu... Message-ID: Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 4d8cc8d71eb254f3eb687a4486819c13ac04d0ba https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/4d8cc8d71eb254f3eb687a4486819c13ac04d0ba Author: Eliot Miranda Date: 2021-02-02 (Tue, 02 Feb 2021) Changed paths: M platforms/iOS/plugins/CameraPlugin/AVFoundationVideoGrabber.m Log Message: ----------- CameraPlugin robustness on macOS. If the frame buffer isn't big enough (eg because another app has changed the camera) then free and remalloc the frame buffer if it is too small. Get rid of the firstTime flag and just use the frame buffer (pixels) as the flag. Commit: e113cc5f0577f8f89f5be1d7524f0d0448b53845 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/e113cc5f0577f8f89f5be1d7524f0d0448b53845 Author: Eliot Miranda Date: 2021-02-02 (Tue, 02 Feb 2021) Changed paths: M build.win64x64/common/Makefile.msvc.tools Log Message: ----------- Merge branch 'Cog' of https://github.com/OpenSmalltalk/opensmalltalk-vm into Cog Compare: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/739ad1ebada2...e113cc5f0577 From noreply at github.com Wed Feb 3 17:58:08 2021 From: noreply at github.com (Eliot Miranda) Date: Wed, 03 Feb 2021 09:58:08 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] 38e53d: Win32 SoundPlugin: don't get confused by VOICEIN d... Message-ID: Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 38e53d9c32e7119481db069c3294fedc714107c9 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/38e53d9c32e7119481db069c3294fedc714107c9 Author: Eliot Miranda Date: 2021-02-03 (Wed, 03 Feb 2021) Changed paths: M platforms/win32/plugins/SoundPlugin/sqWin32Sound.c Log Message: ----------- Win32 SoundPlugin: don't get confused by VOICEIN devices. For accessing mixers treat VOICEIN devuces as WAVEIN devices. The old code was blind-sided and ended up treating them as output devices. [ci skip] Commit: 3694a6756a4d77d4bc7c0d94f068713167ba0311 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/3694a6756a4d77d4bc7c0d94f068713167ba0311 Author: Eliot Miranda Date: 2021-02-03 (Wed, 03 Feb 2021) Changed paths: M platforms/iOS/plugins/CameraPlugin/AVFoundationVideoGrabber.m Log Message: ----------- Merge branch 'Cog' of https://github.com/OpenSmalltalk/opensmalltalk-vm into Cog Compare: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/e113cc5f0577...3694a6756a4d From lists at fniephaus.com Wed Feb 3 21:07:13 2021 From: lists at fniephaus.com (Fabio Niephaus) Date: Wed, 3 Feb 2021 22:07:13 +0100 Subject: [Vm-dev] Bintray is shutting down In-Reply-To: <20210125221550.GA13374@shell.msen.com> References: <20210121061112.1.AB56D1309B11C812@mailer.bintray.com> <20210125221550.GA13374@shell.msen.com> Message-ID: Hi all, Looks like we need to find a new way to host bleeding edge builds. Bintray will be shut down on May 1st, 2021: https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/ Fabio On Mon, 25 Jan 2021 at 11:15 pm, David T. Lewis wrote: > > On Mon, Jan 25, 2021 at 11:37:56AM +0100, Nicolas Cellier wrote: > > > > Bah, too many successful builds these days ;) > > > > And thank you very much for that "problem" :-) > > Dave > > > > > Le lun. 25 janv. 2021 ?? 10:57, Fabio Niephaus a > ??crit : > > > > > > > > > Here's an update from Bintray support: > > > > > > Hi Fabio, > > > > > > Thank you for reaching out to JFrog Support. With regards to your > > > query on getting rate-limited, We have unblocked your Bintray account > > > opensmalltalk and increased the storage quota to 13GB. Your current > > > storage is 10.28 GB/13 GB (80)%. However in future in order to avoid > > > this issue, we strongly recommend you to clear the unused files to > > > save the storage. > > > > > > Please let us know if everything is working as expected after > > > unblocking the account. > > > > > > Best regards, > > > JFrog Support > > > > > > On Fri, Jan 22, 2021 at 5:04 PM Fabio Niephaus > wrote: > > > > > > > > Hi all, > > > > > > > > Looks like our Bintray account has been rate-limited again, possibly > > > > due to too many builds that pushed binaries to Bintray without > > > > deleting older ones. This possibly can cause CI builds to fail (if > > > > they fail to deploy to Bintray). I'm afraid I don't have much time to > > > > look into this, but I will monitor and forward the communication with > > > > Bintray support. > > > > > > > > Best, > > > > Fabio > > > > > > > > ---------- Forwarded message --------- > > > > From: Bintray > > > > Date: Thu, Jan 21, 2021 at 7:11 AM > > > > Subject: Bintray account for OpenSmalltalk has been rate-limited > > > > To: > > > > > > > > > > > > Hi OpenSmalltalk, > > > > > > > > Your Bintray account is currently rate-limited due to overuse. > > > > > > > > Customer Support should contact you at the earliest to remove the > > > > limits from your account. You may also contact them directly at > > > > support at jfrog.com. > > > > > > > > Regards, > > > > The Bintray Team > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leves at caesar.elte.hu Wed Feb 3 22:42:35 2021 From: leves at caesar.elte.hu (Levente Uzonyi) Date: Wed, 3 Feb 2021 23:42:35 +0100 (CET) Subject: [Vm-dev] Bintray is shutting down In-Reply-To: References: <20210121061112.1.AB56D1309B11C812@mailer.bintray.com> <20210125221550.GA13374@shell.msen.com> Message-ID: Why not use files.squeak.org? Levente From commits at source.squeak.org Thu Feb 4 03:57:01 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Thu, 4 Feb 2021 03:57:01 0000 Subject: [Vm-dev] VM Maker: VMMaker.oscog-eem.2942.mcz Message-ID: Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.2942.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.2942 Author: eem Time: 3 February 2021, 7:56:52.6547 pm UUID: 31e90656-0f99-4fae-8633-6b761b62bc6f Ancestors: VMMaker.oscog-eem.2941 Add TerfVM-specific support to the SondPlugin for retrieving a sound device's UID. Use stackEphemeralStringValue: for marshalling devuce names. Remove an obsolete method. =============== Diff against VMMaker.oscog-eem.2941 =============== Item was added: + ----- Method: SoundPlugin>>primitiveGetSoundPlayerDeviceUID (in category 'primitives') ----- + primitiveGetSoundPlayerDeviceUID + "arguments: name(type, stack offset) + deviceNumber(Integer, 0)" + "answers a string or nil" + + + | deviceNumber | + + "Parse arguments" + interpreterProxy methodArgumentCount = 1 ifFalse: + [^interpreterProxy primitiveFailFor: PrimErrBadNumArgs]. + + deviceNumber := interpreterProxy positive32BitValueOf: (interpreterProxy stackValue: 0). + interpreterProxy failed ifTrue: + [^interpreterProxy primitiveFailFor: PrimErrBadArgument]. + + self methodReturnStringOrNil: (self getSoundPlayerDeviceUID: deviceNumber - 1)! Item was added: + ----- Method: SoundPlugin>>primitiveGetSoundRecorderDeviceUID (in category 'primitives') ----- + primitiveGetSoundRecorderDeviceUID + "arguments: name(type, stack offset) + deviceNumber(Integer, 0)" + "answers a string or nil" + + + | deviceNumber | + + "Parse arguments" + interpreterProxy methodArgumentCount = 1 ifFalse: + [^interpreterProxy primitiveFailFor: PrimErrBadNumArgs]. + + deviceNumber := interpreterProxy positive32BitValueOf: (interpreterProxy stackValue: 0). + interpreterProxy failed ifTrue: + [^interpreterProxy primitiveFailFor: PrimErrBadArgument]. + + self methodReturnStringOrNil: (self getSoundRecorderDeviceUID: deviceNumber - 1)! Item was changed: ----- Method: SoundPlugin>>primitiveSetDefaultSoundPlayer (in category 'primitives') ----- primitiveSetDefaultSoundPlayer "Tell the operating system to use the specified device name as the output device for sound." "arg at top of stack is the String" + | deviceName | - | deviceName obj srcPtr sz | - - - self cCode: [] inSmalltalk: [deviceName := ByteString new: 257]. "Parse arguments" interpreterProxy methodArgumentCount = 1 ifFalse: [^interpreterProxy primitiveFailFor: PrimErrBadNumArgs]. + deviceName := interpreterProxy stackEphemeralStringValue: 0. - ((interpreterProxy isBytes: (obj := interpreterProxy stackValue: 0)) - and: [(sz := interpreterProxy byteSizeOf: obj) <= 256]) ifFalse: - [^interpreterProxy primitiveFailFor: PrimErrBadArgument]. - - srcPtr := self cCoerce: (interpreterProxy firstIndexableField: obj) to: #'char *'. - self strncpy: deviceName _: srcPtr _: sz. - deviceName at: sz put: 0. - self setDefaultSoundPlayer: deviceName. - interpreterProxy failed ifFalse: + [self setDefaultSoundPlayer: deviceName. + interpreterProxy failed ifFalse: + [interpreterProxy methodReturnReceiver]]! - [interpreterProxy methodReturnReceiver]! Item was changed: ----- Method: SoundPlugin>>primitiveSetDefaultSoundRecorder (in category 'primitives') ----- primitiveSetDefaultSoundRecorder "Tell the operating system to use the specified device name as the input device for sound." "arg at top of stack is the String" + | deviceName | - | deviceName obj srcPtr sz | - - - self cCode: [] inSmalltalk: [deviceName := ByteString new: 257]. "Parse arguments" interpreterProxy methodArgumentCount = 1 ifFalse: [^interpreterProxy primitiveFailFor: PrimErrBadNumArgs]. + deviceName := interpreterProxy stackEphemeralStringValue: 0. - ((interpreterProxy isBytes: (obj := interpreterProxy stackValue: 0)) - and: [(sz := interpreterProxy byteSizeOf: obj) <= 256]) ifFalse: - [^interpreterProxy primitiveFailFor: PrimErrBadArgument]. - - srcPtr := self cCoerce: (interpreterProxy firstIndexableField: obj) to: #'char *'. - self strncpy: deviceName _: srcPtr _: sz. - deviceName at: sz put: 0. - self setDefaultSoundRecorder: deviceName. - interpreterProxy failed ifFalse: + [self setDefaultSoundRecorder: deviceName. + interpreterProxy failed ifFalse: + [interpreterProxy methodReturnReceiver]]! - [interpreterProxy methodReturnReceiver]! Item was removed: - ----- Method: SoundPlugin>>sampleSizeOf: (in category 'support') ----- - sampleSizeOf: buf - "Answer the number of 16-bit sound samples in buf, a pointer to the first indexable field of a sound buffer." - - ^(interpreterProxy byteSizeOf: buf cPtrAsOop) / (self sizeof: #short)! From noreply at github.com Thu Feb 4 03:59:49 2021 From: noreply at github.com (Eliot Miranda) Date: Wed, 03 Feb 2021 19:59:49 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] dfefae: CogVM source as per VMMaker.oscog-eem.2942 Message-ID: Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: dfefae1b8aa4709b90c1cfa93c26f7a3a29ce8cd https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/dfefae1b8aa4709b90c1cfa93c26f7a3a29ce8cd Author: Eliot Miranda Date: 2021-02-03 (Wed, 03 Feb 2021) Changed paths: M platforms/Cross/plugins/SoundPlugin/SoundPlugin.h M platforms/iOS/plugins/SoundPlugin/sqSqueakSoundCoreAudio.h M platforms/iOS/plugins/SoundPlugin/sqSqueakSoundCoreAudio.m M platforms/iOS/plugins/SoundPlugin/sqSqueakSoundCoreAudioAPI.m M platforms/unix/plugins/SoundPlugin/sqUnixSound.c M src/plugins/SoundPlugin/SoundPlugin.c Log Message: ----------- CogVM source as per VMMaker.oscog-eem.2942 Add TerfVM-specific support to the SoundPlugin for retrieving a sound device's UID. Use stackEphemeralStringValue: for marshalling device names. Implement the support for macOS. [ci skip] From noreply at github.com Thu Feb 4 04:56:13 2021 From: noreply at github.com (Eliot Miranda) Date: Wed, 03 Feb 2021 20:56:13 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] 894d6c: Add the win32 TerfVM-specific SoundPlugin device U... Message-ID: Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 894d6cbb2a17af9f5dc5b0505d76a657d9f9e83f https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/894d6cbb2a17af9f5dc5b0505d76a657d9f9e83f Author: Eliot Miranda Date: 2021-02-03 (Wed, 03 Feb 2021) Changed paths: M platforms/win32/plugins/SoundPlugin/sqWin32Sound.c Log Message: ----------- Add the win32 TerfVM-specific SoundPlugin device UID support. [ci skip] From marcel.taeumel at hpi.de Thu Feb 4 07:46:53 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Thu, 4 Feb 2021 08:46:53 +0100 Subject: [Vm-dev] Bintray is shutting down In-Reply-To: References: <20210121061112.1.AB56D1309B11C812@mailer.bintray.com> <20210125221550.GA13374@shell.msen.com> Message-ID: > Why not use files.squeak.org? +1 Best, Marcel Am 03.02.2021 23:42:48 schrieb Levente Uzonyi : Why not use files.squeak.org? Levente -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Feb 4 07:59:07 2021 From: notifications at github.com (Tobias Pape) Date: Wed, 03 Feb 2021 23:59:07 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] CogVM source as per VMMaker.oscog-eem.2942 (dfefae1) In-Reply-To: References: Message-ID: Just curious, why was that moved? -- 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/commit/dfefae1b8aa4709b90c1cfa93c26f7a3a29ce8cd#commitcomment-46732787 -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at github.com Thu Feb 4 16:34:38 2021 From: noreply at github.com (Eliot Miranda) Date: Thu, 04 Feb 2021 08:34:38 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] a50d3f: For te sake of readability apply to sqWin32Time.c the Message-ID: Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: a50d3f8dd67d409aaa36e5d417c06e1adc6f62f9 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/a50d3f8dd67d409aaa36e5d417c06e1adc6f62f9 Author: Eliot Miranda Date: 2021-02-04 (Thu, 04 Feb 2021) Changed paths: M platforms/win32/vm/sqWin32Heartbeat.c M platforms/win32/vm/sqWin32Time.c Log Message: ----------- For te sake of readability apply to sqWin32Time.c the GetSystemTimePreciseAsFileTime fix for clock resolution that is in platforms/win32/vm/sqWin32Heartbeat.c. [ci skip] From eliot.miranda at gmail.com Thu Feb 4 16:48:26 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Thu, 4 Feb 2021 08:48:26 -0800 Subject: [Vm-dev] Off topic 6802 Message-ID: <32FC5843-D303-4B3A-9D60-4746764FACD0@gmail.com> https://www.goldmine-elec-products.com/prodinfo.asp?number=G25499 _,,,^..^,,,_ (phone) -------------- next part -------------- An HTML attachment was scrubbed... URL: From eliot.miranda at gmail.com Thu Feb 4 16:54:07 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Thu, 4 Feb 2021 08:54:07 -0800 Subject: [Vm-dev] Bintray is shutting down In-Reply-To: References: Message-ID: <9186DAD7-B306-400D-B217-495772B145F0@gmail.com> > On Feb 3, 2021, at 2:42 PM, Levente Uzonyi wrote: > > Why not use files.squeak.org? Also +1. I’d love to see two builds, the latest known good build that has passed all tests, and the latest build that compiled but might be broken. I don’t see too much utility in saving literally hundreds of builds given they we can use git bisect to hunt for regressions. That should keep the storage requirements in check, right? We do of course still need to retain release VMs. > > > Levente > From boris at shingarov.com Thu Feb 4 19:16:55 2021 From: boris at shingarov.com (Boris Shingarov) Date: Thu, 4 Feb 2021 14:16:55 -0500 Subject: [Vm-dev] Off topic 6802 In-Reply-To: <32FC5843-D303-4B3A-9D60-4746764FACD0@gmail.com> References: <32FC5843-D303-4B3A-9D60-4746764FACD0@gmail.com> Message-ID: What a remarkable coincidence in timing!  I just got this today as a birthday present: http://shingarov.com/cm601 The CM601 was a Bulgarian bootleg of the 6800: Ivan Marangozov of the IME-BAN reverse-engineered the Motorola masks. On 2/4/21 11:48 AM, Eliot Miranda wrote: > > > https://www.goldmine-elec-products.com/prodinfo.asp?number=G25499 > > > _,,,^..^,,,_ (phone) -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Fri Feb 5 08:11:10 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Fri, 5 Feb 2021 09:11:10 +0100 Subject: [Vm-dev] Bintray is shutting down In-Reply-To: <9186DAD7-B306-400D-B217-495772B145F0@gmail.com> References: <9186DAD7-B306-400D-B217-495772B145F0@gmail.com> Message-ID: > I don’t see too much utility in saving literally hundreds of builds given they we can use git bisect to hunt for regressions. That should keep the storage requirements in check, right? Hmm... we need some mechanism to pin a version that we want to test as a release candidate. Best, Marcel Am 04.02.2021 17:54:19 schrieb Eliot Miranda : > On Feb 3, 2021, at 2:42 PM, Levente Uzonyi wrote: > > Why not use files.squeak.org? Also +1. I’d love to see two builds, the latest known good build that has passed all tests, and the latest build that compiled but might be broken. I don’t see too much utility in saving literally hundreds of builds given they we can use git bisect to hunt for regressions. That should keep the storage requirements in check, right? We do of course still need to retain release VMs. > > > Levente > -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Sun Feb 7 00:10:04 2021 From: notifications at github.com (=?UTF-8?B?SmFyb3NsYXYgxaBrYXJ2YWRh?=) Date: Sat, 06 Feb 2021 16:10:04 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] Please allow building with the system libraries (#551) Message-ID: I was trying to package opensmalltalk-vm to Fedora, but it's not possible at the moment, because it seems it tries to download and compile libraries, e.g. SDL2 and others from the third-party dir. Could you please add option or auto-detection for building with the system libraries? -- 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/551 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Sun Feb 7 08:00:51 2021 From: notifications at github.com (Tobias Pape) Date: Sun, 07 Feb 2021 00:00:51 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] Please allow building with the system libraries (#551) In-Reply-To: References: Message-ID: Hi @yarda, could you tell us which of the many configuration you tried to build? The squeak.* ones should not try to use the third-party stuff. -- 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/551#issuecomment-774630616 -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at github.com Sun Feb 7 17:21:23 2021 From: noreply at github.com (David T Lewis) Date: Sun, 07 Feb 2021 09:21:23 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] 754980: Rearrange forgetXDisplay to disable aio before fd ... Message-ID: Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 75498075b2bd030794f54c5303d00626fe33b195 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/75498075b2bd030794f54c5303d00626fe33b195 Author: David T. Lewis Date: 2021-02-07 (Sun, 07 Feb 2021) Changed paths: M platforms/unix/vm-display-X11/sqUnixX11.c Log Message: ----------- Rearrange forgetXDisplay to disable aio before fd close. Required for epoll event handling, we should not close the descriptor before unregistering it. Commit: b6616b21d263ecaa334d458bf3a9579fcb88c635 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/b6616b21d263ecaa334d458bf3a9579fcb88c635 Author: David T. Lewis Date: 2021-02-07 (Sun, 07 Feb 2021) Changed paths: M platforms/unix/vm/aio.c Log Message: ----------- Handle epoll event delivery errors without VM segfault. Under certain error conditions epoll may deliver event notification to the wrong process, with empty event data provided by the kernel. If this happens, handle the condition with a message to stderr and proceed without segfault. Error messages will look like this: aioPoll in process 9055 no readHandler in epollEventData undefined handler called (fd 0, flags 2) Compare: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/a50d3f8dd67d...b6616b21d263 From notifications at github.com Sun Feb 7 17:29:18 2021 From: notifications at github.com (David T Lewis) Date: Sun, 07 Feb 2021 09:29:18 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] In forgetXDisplay() do not call aioDisable() for the socket connection (#550) In-Reply-To: References: Message-ID: I made a couple of commits to the Cog branch that provide error messages on stderr rather than segfault the VM. This shows clearly that after a fork, the X11 event notification for the child process is being delivered to both the child VM and the parent VM, and also that the kernel is supplying empty event data to the parent when this happens. -- 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/550#issuecomment-774714133 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Sun Feb 7 17:34:23 2021 From: notifications at github.com (David T Lewis) Date: Sun, 07 Feb 2021 09:34:23 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] In forgetXDisplay() do not call aioDisable() for the socket connection (#550) In-Reply-To: References: Message-ID: I suspect that for epoll, the rule should be never unregister the fd if you are also going to close the fd. This would be different from non-epoll event event handling, so possibly there would be a need for e.g. aioDisableAndClose(fd) in addition to the existing aioDisable(fd). Or maybe is it sufficient to just reopen the aiofd after a fork as suggested above. -- 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/550#issuecomment-774715140 -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at github.com Mon Feb 8 02:19:56 2021 From: noreply at github.com (David T Lewis) Date: Sun, 07 Feb 2021 18:19:56 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] 057b0c: Silence an overly helpful compiler warning Message-ID: Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 057b0c2d67b23a364452b2075b1aa47f486824d9 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/057b0c2d67b23a364452b2075b1aa47f486824d9 Author: David T. Lewis Date: 2021-02-07 (Sun, 07 Feb 2021) Changed paths: M platforms/unix/vm/aio.c Log Message: ----------- Silence an overly helpful compiler warning From notifications at github.com Mon Feb 8 03:06:54 2021 From: notifications at github.com (smalltalking) Date: Sun, 07 Feb 2021 19:06:54 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] Handle epoll event delivery errors without VM segfault. (b6616b2) In-Reply-To: References: Message-ID: AIO_R should be AIO_W here. -- 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/commit/b6616b21d263ecaa334d458bf3a9579fcb88c635#commitcomment-46864203 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Feb 8 03:07:10 2021 From: notifications at github.com (smalltalking) Date: Sun, 07 Feb 2021 19:07:10 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] Handle epoll event delivery errors without VM segfault. (b6616b2) In-Reply-To: References: Message-ID: And AIO_X here. -- 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/commit/b6616b21d263ecaa334d458bf3a9579fcb88c635#commitcomment-46864211 -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at github.com Mon Feb 8 04:18:05 2021 From: noreply at github.com (David T Lewis) Date: Sun, 07 Feb 2021 20:18:05 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] f376ff: Fix epoll event delivery error messages cut and pa... Message-ID: Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: f376ffbc0b6d62047b7effb7f29d405fbd7e4611 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/f376ffbc0b6d62047b7effb7f29d405fbd7e4611 Author: David T. Lewis Date: 2021-02-07 (Sun, 07 Feb 2021) Changed paths: M platforms/unix/vm/aio.c Log Message: ----------- Fix epoll event delivery error messages cut and paste error From notifications at github.com Mon Feb 8 04:20:53 2021 From: notifications at github.com (David T Lewis) Date: Sun, 07 Feb 2021 20:20:53 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] Handle epoll event delivery errors without VM segfault. (b6616b2) In-Reply-To: References: Message-ID: Oops sorry about that. Just pushed the fix. Thank you for reviewing. -- 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/commit/b6616b21d263ecaa334d458bf3a9579fcb88c635#commitcomment-46865614 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Feb 8 07:42:33 2021 From: notifications at github.com (Tobias Pape) Date: Sun, 07 Feb 2021 23:42:33 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] Please allow building with the system libraries (#551) In-Reply-To: References: Message-ID: Also, could you share the spec file? -- 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/551#issuecomment-774941921 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Feb 8 15:52:27 2021 From: notifications at github.com (Nicolas Cellier) Date: Mon, 08 Feb 2021 07:52:27 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] Handle epoll event delivery errors without VM segfault. (b6616b2) In-Reply-To: References: Message-ID: Also note that `if(a=b)` will generate a warning on modern compiler because often a miss write of `a==b`. The modern convention is to write `if( (a=b) )` to express the intention to assign and shut up the warning. -- 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/commit/b6616b21d263ecaa334d458bf3a9579fcb88c635#commitcomment-46886891 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Feb 8 16:00:31 2021 From: notifications at github.com (David T Lewis) Date: Mon, 08 Feb 2021 08:00:31 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] Handle epoll event delivery errors without VM segfault. (b6616b2) In-Reply-To: References: Message-ID: Fixed in the next update, thanks -- 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/commit/b6616b21d263ecaa334d458bf3a9579fcb88c635#commitcomment-46887098 -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at github.com Mon Feb 8 20:18:04 2021 From: noreply at github.com (David T Lewis) Date: Mon, 08 Feb 2021 12:18:04 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] 066a43: For epoll aio, close and reopen the epoll fd in fo... Message-ID: Branch: refs/heads/dtl/epoll-forksqueak Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 066a43128584d55964f4a6ace4b2c878cf96087e https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/066a43128584d55964f4a6ace4b2c878cf96087e Author: David T. Lewis Date: 2021-02-08 (Mon, 08 Feb 2021) Changed paths: M platforms/unix/vm/aio.c Log Message: ----------- For epoll aio, close and reopen the epoll fd in forked child process Factor the epoll initiation out of aioInit into new epollInit function and invoke it via pthread_atfork in the child process after a fork. Prevents misdelivery of events from the common kernel epoll structures. From notifications at github.com Mon Feb 8 20:20:54 2021 From: notifications at github.com (David T Lewis) Date: Mon, 08 Feb 2021 12:20:54 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] In forgetXDisplay() do not call aioDisable() for the socket connection (#550) In-Reply-To: References: Message-ID: Closed #550. -- 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/550#event-4305552752 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Feb 8 20:23:44 2021 From: notifications at github.com (David T Lewis) Date: Mon, 08 Feb 2021 12:23:44 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] In forgetXDisplay() do not call aioDisable() for the socket connection (#550) In-Reply-To: References: Message-ID: Closing the PR because the solution is not sufficient. I will open a different PR to close and reopen the epoll fd based on the suggestions above and in issue #548. -- 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/550#issuecomment-775424691 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Feb 8 20:24:59 2021 From: notifications at github.com (David T Lewis) Date: Mon, 08 Feb 2021 12:24:59 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] For epoll aio, close and reopen the epoll fd in forked child process (#552) Message-ID: Factor the epoll initiation out of aioInit into new epollInit function and invoke it via pthread_atfork in the child process after a fork. Prevents misdelivery of events from the common kernel epoll structures. You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/552 -- Commit Summary -- * For epoll aio, close and reopen the epoll fd in forked child process -- File Changes -- M platforms/unix/vm/aio.c (23) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/552.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/552.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/552 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Feb 8 21:04:48 2021 From: notifications at github.com (David T Lewis) Date: Mon, 08 Feb 2021 13:04:48 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] UnixProcess forkSqueak broken since October (#548) In-Reply-To: References: Message-ID: I opened a different PR to address the issue as recommended above: For epoll aio, close and reopen the epoll fd in forked child process #552 -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/548#issuecomment-775460732 -------------- next part -------------- An HTML attachment was scrubbed... URL: From commits at source.squeak.org Tue Feb 9 04:27:53 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Tue, 9 Feb 2021 04:27:53 0000 Subject: [Vm-dev] VM Maker: VMMaker.oscog-eem.2943.mcz Message-ID: Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.2943.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.2943 Author: eem Time: 8 February 2021, 8:27:45.60406 pm UUID: e003897d-8105-40a7-bffe-2e8f14f31b5b Ancestors: VMMaker.oscog-eem.2942 Resolve the conflict between sqAssert.h's attempt to export warning and error to external plugins with the crude redefinition of the EXPORT macro on generating plugins. So so by moving the redefinition of EXPORT after a plugin's include files. =============== Diff against VMMaker.oscog-eem.2942 =============== Item was changed: ----- Method: VMPluginCodeGenerator>>emitCHeaderOn: (in category 'C code generator') ----- emitCHeaderOn: aStream "Write a C file header onto the given stream, adding include files and some basic definitions." | standardHeaders | aStream nextPutAll: (self fileHeaderVersionStampForSourceClass: pluginClass); cr; cr. "config.h should always go first because config.h properly defines flags. One of those is _GNU_SOURCE, as explained in https://www.gnu.org/software/autoconf/manual/autoconf.html#Posix-Variants, where the Autoconf macro AC_USE_SYSTEM_EXTENSIONS makes sure this is defined." standardHeaders := #('"config.h"' '' '"sqMathShim.h"' '' '' '' ''). self emitHeaderFiles: standardHeaders on: aStream. headerFiles := headerFiles copyWithoutAll: standardHeaders. "Additional header files; include C library ones first." self emitHeaderFiles: (headerFiles select: [:hdr| hdr includes: $<]) on: aStream. + aStream cr; nextPutAll: '/* Do not include the entire sq.h file but just those parts needed. */ - aStream cr; nextPutAll: '/* Default EXPORT macro that does nothing (see comment in sq.h): */ - #define EXPORT(returnType) returnType - - /* Do not include the entire sq.h file but just those parts needed. */ #include "sqConfig.h" /* Configuration options */ #include "sqVirtualMachine.h" /* The virtual machine proxy definition */ + #include "sqPlatformSpecific.h" /* Platform specific definitions */'; cr; cr. - #include "sqPlatformSpecific.h" /* Platform specific definitions */ + self addHeaderFile: '"sqMemoryAccess.h"'. + "Additional header files; include squeak VM ones last" + self emitHeaderFiles: (headerFiles reject: [:hdr| hdr includes: $<]) on: aStream. + aStream cr; nextPutAll: '/* Default EXPORT macro that does nothing (see comment in sq.h): */ + #define EXPORT(returnType) returnType + #define true 1 #define false 0 #define null 0 /* using ''null'' because nil is predefined in Think C */ #ifdef SQUEAK_BUILTIN_PLUGIN # undef EXPORT # define EXPORT(returnType) static returnType # define INT_EXT "(i)" #else # define INT_EXT "(e)" + #endif'; cr. - #endif'; cr; cr. - self addHeaderFile: '"sqMemoryAccess.h"'. - "Additional header files; include squeak VM ones last" - self emitHeaderFiles: (headerFiles reject: [:hdr| hdr includes: $<]) on: aStream. self maybePutPreambleFor: pluginClass on: aStream. aStream cr! From noreply at github.com Tue Feb 9 04:35:03 2021 From: noreply at github.com (Eliot Miranda) Date: Mon, 08 Feb 2021 20:35:03 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] dbe76b: CogVM source as per VMMaker.oscog-eem.2943 Message-ID: Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: dbe76be273c374a63a25e1079486a6ef2aabcfba https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/dbe76be273c374a63a25e1079486a6ef2aabcfba Author: Eliot Miranda Date: 2021-02-08 (Mon, 08 Feb 2021) Changed paths: M src/plugins/ADPCMCodecPlugin/ADPCMCodecPlugin.c M src/plugins/AioPlugin/AioPlugin.c M src/plugins/AsynchFilePlugin/AsynchFilePlugin.c M src/plugins/B2DPlugin/B2DPlugin.c M src/plugins/B3DAcceleratorPlugin/B3DAcceleratorPlugin.c M src/plugins/BMPReadWriterPlugin/BMPReadWriterPlugin.c M src/plugins/BitBltPlugin/BitBltPlugin.c M src/plugins/BochsIA32Plugin/BochsIA32Plugin.c M src/plugins/BochsX64Plugin/BochsX64Plugin.c M src/plugins/CameraPlugin/CameraPlugin.c M src/plugins/ClipboardExtendedPlugin/ClipboardExtendedPlugin.c M src/plugins/CroquetPlugin/CroquetPlugin.c M src/plugins/DESPlugin/DESPlugin.c M src/plugins/DSAPrims/DSAPrims.c M src/plugins/DropPlugin/DropPlugin.c M src/plugins/FFTPlugin/FFTPlugin.c M src/plugins/FileAttributesPlugin/FileAttributesPlugin.c M src/plugins/FileCopyPlugin/FileCopyPlugin.c M src/plugins/FilePlugin/FilePlugin.c M src/plugins/Float64ArrayPlugin/Float64ArrayPlugin.c M src/plugins/FloatArrayPlugin/FloatArrayPlugin.c M src/plugins/FloatMathPlugin/FloatMathPlugin.c M src/plugins/GdbARMPlugin/GdbARMPlugin.c M src/plugins/GdbARMv8Plugin/GdbARMv8Plugin.c M src/plugins/GeniePlugin/GeniePlugin.c M src/plugins/HostWindowPlugin/HostWindowPlugin.c M src/plugins/IA32ABI/IA32ABI.c M src/plugins/ImmX11Plugin/ImmX11Plugin.c M src/plugins/InternetConfigPlugin/InternetConfigPlugin.c M src/plugins/JPEGReadWriter2Plugin/JPEGReadWriter2Plugin.c M src/plugins/JPEGReaderPlugin/JPEGReaderPlugin.c M src/plugins/JoystickTabletPlugin/JoystickTabletPlugin.c M src/plugins/Klatt/Klatt.c M src/plugins/LargeIntegers/LargeIntegers.c M src/plugins/LocalePlugin/LocalePlugin.c M src/plugins/MD5Plugin/MD5Plugin.c M src/plugins/MIDIPlugin/MIDIPlugin.c M src/plugins/MacMenubarPlugin/MacMenubarPlugin.c M src/plugins/Matrix2x3Plugin/Matrix2x3Plugin.c M src/plugins/MiscPrimitivePlugin/MiscPrimitivePlugin.c M src/plugins/Mpeg3Plugin/Mpeg3Plugin.c M src/plugins/QuicktimePlugin/QuicktimePlugin.c M src/plugins/RePlugin/RePlugin.c M src/plugins/SHA2Plugin/SHA2Plugin.c M src/plugins/ScratchPlugin/ScratchPlugin.c M src/plugins/SecurityPlugin/SecurityPlugin.c M src/plugins/SerialPlugin/SerialPlugin.c M src/plugins/SocketPlugin/SocketPlugin.c M src/plugins/SoundCodecPrims/SoundCodecPrims.c M src/plugins/SoundGenerationPlugin/SoundGenerationPlugin.c M src/plugins/SoundPlugin/SoundPlugin.c M src/plugins/Squeak3D/Squeak3D.c M src/plugins/SqueakFFIPrims/ARM32FFIPlugin.c M src/plugins/SqueakFFIPrims/ARM64FFIPlugin.c M src/plugins/SqueakFFIPrims/IA32FFIPlugin.c M src/plugins/SqueakFFIPrims/X64SysVFFIPlugin.c M src/plugins/SqueakFFIPrims/X64Win64FFIPlugin.c M src/plugins/SqueakSSL/SqueakSSL.c M src/plugins/StarSqueakPlugin/StarSqueakPlugin.c M src/plugins/UUIDPlugin/UUIDPlugin.c M src/plugins/UnicodePlugin/UnicodePlugin.c M src/plugins/UnixOSProcessPlugin/UnixOSProcessPlugin.c M src/plugins/VMProfileLinuxSupportPlugin/VMProfileLinuxSupportPlugin.c M src/plugins/VMProfileMacSupportPlugin/VMProfileMacSupportPlugin.c M src/plugins/WeDoPlugin/WeDoPlugin.c M src/plugins/Win32OSProcessPlugin/Win32OSProcessPlugin.c M src/plugins/XDisplayControlPlugin/XDisplayControlPlugin.c M src/plugins/ZipPlugin/ZipPlugin.c Log Message: ----------- CogVM source as per VMMaker.oscog-eem.2943 Resolve the conflict between sqAssert.h's attempt to export warning and error to external plugins with the crude redefinition of the EXPORT macro on generating plugins. So so by moving the redefinition of EXPORT after a plugin's include files. The issue here is Windows' requirement to use declspec(dll_import) & declspec(dll_import) for sharing between exe and dll. Commit: 9f1b4644e7396e473bd9bb4cf67f8a9d5a4e11d6 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/9f1b4644e7396e473bd9bb4cf67f8a9d5a4e11d6 Author: Eliot Miranda Date: 2021-02-08 (Mon, 08 Feb 2021) Changed paths: M platforms/unix/vm/aio.c Log Message: ----------- Merge branch 'Cog' of https://github.com/OpenSmalltalk/opensmalltalk-vm into Cog Compare: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/f376ffbc0b6d...9f1b4644e739 From noreply at github.com Tue Feb 9 05:02:10 2021 From: noreply at github.com (Eliot Miranda) Date: Mon, 08 Feb 2021 21:02:10 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] aafcb7: Changes to sq.h and sqAssert.h to accompany commit Message-ID: Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: aafcb78371c7e576073a8dbf2f1f32667568e05e https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/aafcb78371c7e576073a8dbf2f1f32667568e05e Author: Eliot Miranda Date: 2021-02-08 (Mon, 08 Feb 2021) Changed paths: M platforms/Cross/vm/sq.h M platforms/Cross/vm/sqAssert.h M platforms/win32/vm/sqWin32Heartbeat.c Log Message: ----------- Changes to sq.h and sqAssert.h to accompany commit dbe76be273c374a63a25e1079486a6ef2aabcfba Author: Eliot Miranda Date: Mon Feb 8 20:32:56 2021 -0800 CogVM source as per VMMaker.oscog-eem.2943 Resolve the conflict between sqAssert.h's attempt to export warning and error to external plugins with the crude redefinition of the EXPORT macro on generating plugins. So so by moving the redefinition of EXPORT after a plugin's include files. The issue here is Windows' requirement to use declspec(dll_import) & declspec(dll_import) for sharing between exe and dll. To allow the VM to export warning and error to external plugins, warning and error must be correctly declared using the EXPORT macro. Hence these macros cannot be redefined until after the interpreters and any definitions in sqPlatformSpecific.h have been seen and applied. Further, so that sqPlatformSpecific.h *can* define EXPORT et al sq.h must include it before it attempts to provide default definitions of EXPORT et al and sq.h should never replace EXPORT et al if they have been defined. Further still, sqPlatformSpecific.h *cannot* be included before stdio if it is to "conveniently" define fseeko & ftello to the various 64-bit versions certain platforms require. Thankyou for understanding. The idea of sqCOnfig.h is perhaps in conflict with these changes. However, in my opinion it is much more important that we be able to build a complete VM on all platforms, including the ability to use asserts in external plugins, than it is for a convenient sqConfig.h to be usable. As previously discussed, C includes are white box and cannot reliably be prefixed with sqConfig.h unless we maintain each platform's sqConfig.h to apply to every possible version of a platform's include files, an obvious impossibility. I ask anyone wishing to alter the system here to please contact me and discuss before making changes. It is extraordinarily expensive and frustrating to have to make changes of this kind to make sure that a signfiicantly more complex VM such as Terf's builds correctly. From no-reply at appveyor.com Tue Feb 9 08:22:30 2021 From: no-reply at appveyor.com (AppVeyor) Date: Tue, 09 Feb 2021 08:22:30 +0000 Subject: [Vm-dev] Build failed: opensmalltalk-vm 1.0.2401 Message-ID: <20210209082230.1.24C446D8928A33EF@appveyor.com> An HTML attachment was scrubbed... URL: From commits at source.squeak.org Tue Feb 9 17:01:36 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Tue, 9 Feb 2021 17:01:36 0000 Subject: [Vm-dev] VM Maker: VMMaker.oscog-eem.2944.mcz Message-ID: Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.2944.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.2944 Author: eem Time: 9 February 2021, 9:01:28.421478 am UUID: 242b00d2-2d09-4363-8f25-cedcd6ee2187 Ancestors: VMMaker.oscog-eem.2943 Continuing on from VMMaker.oscog-eem.2943 we have no business overriding the default EXPORT definitoon for external plugins. We define EXPORT to map to static for internal plugins only. =============== Diff against VMMaker.oscog-eem.2943 =============== Item was changed: ----- Method: VMPluginCodeGenerator>>emitCHeaderOn: (in category 'C code generator') ----- emitCHeaderOn: aStream "Write a C file header onto the given stream, adding include files and some basic definitions." | standardHeaders | + aStream nextPutAll: (self fileHeaderVersionStampForSourceClass: pluginClass); cr. - aStream nextPutAll: (self fileHeaderVersionStampForSourceClass: pluginClass); cr; cr. "config.h should always go first because config.h properly defines flags. One of those is _GNU_SOURCE, as explained in https://www.gnu.org/software/autoconf/manual/autoconf.html#Posix-Variants, where the Autoconf macro AC_USE_SYSTEM_EXTENSIONS makes sure this is defined." standardHeaders := #('"config.h"' '' '"sqMathShim.h"' '' '' '' ''). self emitHeaderFiles: standardHeaders on: aStream. headerFiles := headerFiles copyWithoutAll: standardHeaders. "Additional header files; include C library ones first." self emitHeaderFiles: (headerFiles select: [:hdr| hdr includes: $<]) on: aStream. aStream cr; nextPutAll: '/* Do not include the entire sq.h file but just those parts needed. */ #include "sqConfig.h" /* Configuration options */ #include "sqVirtualMachine.h" /* The virtual machine proxy definition */ #include "sqPlatformSpecific.h" /* Platform specific definitions */'; cr; cr. self addHeaderFile: '"sqMemoryAccess.h"'. "Additional header files; include squeak VM ones last" self emitHeaderFiles: (headerFiles reject: [:hdr| hdr includes: $<]) on: aStream. + aStream cr; nextPutAll: '#define true 1 - aStream cr; nextPutAll: '/* Default EXPORT macro that does nothing (see comment in sq.h): */ - #define EXPORT(returnType) returnType - - #define true 1 #define false 0 #define null 0 /* using ''null'' because nil is predefined in Think C */ #ifdef SQUEAK_BUILTIN_PLUGIN # undef EXPORT # define EXPORT(returnType) static returnType # define INT_EXT "(i)" #else # define INT_EXT "(e)" #endif'; cr. self maybePutPreambleFor: pluginClass on: aStream. aStream cr! From noreply at github.com Tue Feb 9 17:14:00 2021 From: noreply at github.com (Eliot Miranda) Date: Tue, 09 Feb 2021 09:14:00 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] 3125f1: CogVM source as per VMMaker.oscog-eem.2944 Message-ID: Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 3125f103b1efcde6e6bdc8e3275447ca5f1aad5e https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/3125f103b1efcde6e6bdc8e3275447ca5f1aad5e Author: Eliot Miranda Date: 2021-02-09 (Tue, 09 Feb 2021) Changed paths: M src/plugins/ADPCMCodecPlugin/ADPCMCodecPlugin.c M src/plugins/AioPlugin/AioPlugin.c M src/plugins/AsynchFilePlugin/AsynchFilePlugin.c M src/plugins/B2DPlugin/B2DPlugin.c M src/plugins/B3DAcceleratorPlugin/B3DAcceleratorPlugin.c M src/plugins/BMPReadWriterPlugin/BMPReadWriterPlugin.c M src/plugins/BitBltPlugin/BitBltPlugin.c M src/plugins/BochsIA32Plugin/BochsIA32Plugin.c M src/plugins/BochsX64Plugin/BochsX64Plugin.c M src/plugins/CameraPlugin/CameraPlugin.c M src/plugins/ClipboardExtendedPlugin/ClipboardExtendedPlugin.c M src/plugins/CroquetPlugin/CroquetPlugin.c M src/plugins/DESPlugin/DESPlugin.c M src/plugins/DSAPrims/DSAPrims.c M src/plugins/DropPlugin/DropPlugin.c M src/plugins/FFTPlugin/FFTPlugin.c M src/plugins/FileAttributesPlugin/FileAttributesPlugin.c M src/plugins/FileCopyPlugin/FileCopyPlugin.c M src/plugins/FilePlugin/FilePlugin.c M src/plugins/Float64ArrayPlugin/Float64ArrayPlugin.c M src/plugins/FloatArrayPlugin/FloatArrayPlugin.c M src/plugins/FloatMathPlugin/FloatMathPlugin.c M src/plugins/GdbARMPlugin/GdbARMPlugin.c M src/plugins/GdbARMv8Plugin/GdbARMv8Plugin.c M src/plugins/GeniePlugin/GeniePlugin.c M src/plugins/HostWindowPlugin/HostWindowPlugin.c M src/plugins/IA32ABI/IA32ABI.c M src/plugins/ImmX11Plugin/ImmX11Plugin.c M src/plugins/InternetConfigPlugin/InternetConfigPlugin.c M src/plugins/JPEGReadWriter2Plugin/JPEGReadWriter2Plugin.c M src/plugins/JPEGReaderPlugin/JPEGReaderPlugin.c M src/plugins/JoystickTabletPlugin/JoystickTabletPlugin.c M src/plugins/Klatt/Klatt.c M src/plugins/LargeIntegers/LargeIntegers.c M src/plugins/LocalePlugin/LocalePlugin.c M src/plugins/MD5Plugin/MD5Plugin.c M src/plugins/MIDIPlugin/MIDIPlugin.c M src/plugins/MacMenubarPlugin/MacMenubarPlugin.c M src/plugins/Matrix2x3Plugin/Matrix2x3Plugin.c M src/plugins/MiscPrimitivePlugin/MiscPrimitivePlugin.c M src/plugins/Mpeg3Plugin/Mpeg3Plugin.c M src/plugins/QuicktimePlugin/QuicktimePlugin.c M src/plugins/RePlugin/RePlugin.c M src/plugins/SHA2Plugin/SHA2Plugin.c M src/plugins/ScratchPlugin/ScratchPlugin.c M src/plugins/SecurityPlugin/SecurityPlugin.c M src/plugins/SerialPlugin/SerialPlugin.c M src/plugins/SocketPlugin/SocketPlugin.c M src/plugins/SoundCodecPrims/SoundCodecPrims.c M src/plugins/SoundGenerationPlugin/SoundGenerationPlugin.c M src/plugins/SoundPlugin/SoundPlugin.c M src/plugins/Squeak3D/Squeak3D.c M src/plugins/SqueakFFIPrims/ARM32FFIPlugin.c M src/plugins/SqueakFFIPrims/ARM64FFIPlugin.c M src/plugins/SqueakFFIPrims/IA32FFIPlugin.c M src/plugins/SqueakFFIPrims/SqueakFFIPrims.c M src/plugins/SqueakFFIPrims/X64SysVFFIPlugin.c M src/plugins/SqueakFFIPrims/X64Win64FFIPlugin.c M src/plugins/SqueakSSL/SqueakSSL.c M src/plugins/StarSqueakPlugin/StarSqueakPlugin.c M src/plugins/UUIDPlugin/UUIDPlugin.c M src/plugins/UnicodePlugin/UnicodePlugin.c M src/plugins/UnixOSProcessPlugin/UnixOSProcessPlugin.c M src/plugins/VMProfileLinuxSupportPlugin/VMProfileLinuxSupportPlugin.c M src/plugins/VMProfileMacSupportPlugin/VMProfileMacSupportPlugin.c M src/plugins/WeDoPlugin/WeDoPlugin.c M src/plugins/Win32OSProcessPlugin/Win32OSProcessPlugin.c M src/plugins/XDisplayControlPlugin/XDisplayControlPlugin.c M src/plugins/ZipPlugin/ZipPlugin.c Log Message: ----------- CogVM source as per VMMaker.oscog-eem.2944 Continuing on from VMMaker.oscog-eem.2943 we have no business overriding the default EXPORT definition for external plugins (which is essential on Windows). We define EXPORT to map to static for internal plugins only. Commit: 2076dcd279e4458d3681f9e43846b594e7dcc3e9 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/2076dcd279e4458d3681f9e43846b594e7dcc3e9 Author: Eliot Miranda Date: 2021-02-09 (Tue, 09 Feb 2021) Changed paths: M platforms/Cross/vm/sq.h M platforms/Cross/vm/sqAssert.h M platforms/win32/vm/sqWin32Heartbeat.c Log Message: ----------- Merge branch 'Cog' of https://github.com/OpenSmalltalk/opensmalltalk-vm into Cog Compare: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/aafcb78371c7...2076dcd279e4 From noreply at github.com Tue Feb 9 17:16:24 2021 From: noreply at github.com (Eliot Miranda) Date: Tue, 09 Feb 2021 09:16:24 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] 5e9e49: Add left/right button definitions for 3d gaming mi... Message-ID: Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 5e9e498227a5f1fac387d94f76be54469c0fcf2f https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/5e9e498227a5f1fac387d94f76be54469c0fcf2f Author: Eliot Miranda Date: 2021-02-09 (Tue, 09 Feb 2021) Changed paths: M platforms/Cross/vm/sq.h Log Message: ----------- Add left/right button definitions for 3d gaming mice. [ci skip] From no-reply at appveyor.com Tue Feb 9 17:34:40 2021 From: no-reply at appveyor.com (AppVeyor) Date: Tue, 09 Feb 2021 17:34:40 +0000 Subject: [Vm-dev] Build failed: opensmalltalk-vm 1.0.2402 Message-ID: <20210209173440.1.83D982A0B9373E97@appveyor.com> An HTML attachment was scrubbed... URL: From noreply at github.com Wed Feb 10 01:59:53 2021 From: noreply at github.com (Eliot Miranda) Date: Tue, 09 Feb 2021 17:59:53 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] 11a079: Add a variable (deviceChangeCount) to the Windows ... Message-ID: Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 11a07925dd8acf106488a255fa15fe933364d5ff https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/11a07925dd8acf106488a255fa15fe933364d5ff Author: Eliot Miranda Date: 2021-02-09 (Tue, 09 Feb 2021) Changed paths: M platforms/win32/vm/sqWin32.h M platforms/win32/vm/sqWin32Window.c Log Message: ----------- Add a variable (deviceChangeCount) to the Windows VM to track WM_DEVICECHANGE messages so that plugins such as the SoundPlugin can update their device lists as and when required, rather than on every access. Make sure the variable is correctly exported to external plugins. [ci skip] (cuz I'm not ready to release the new SoundPlugin). From eliot.miranda at gmail.com Wed Feb 10 18:20:26 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Wed, 10 Feb 2021 10:20:26 -0800 Subject: [Vm-dev] quick request for a volunteer to implement device add/remove callbacks and processing Message-ID: Hi All, I just added a variable to the Windows VM that tracks device additions and removals via receiving WM_DEVICECHANGE messages. On Windows this allows plugins such as the SoundPlugin and CameraPlugin enumerating the available devices on every API call/primitive invocation rather than only when devices change. This facility is also needed on Mac and would be great to have on unix. It turn out that on Mac it is also straight=forward to achieve. See https://stackoverflow.com/questions/9918429/how-to-know-when-a-hid-usb-bluetooth-device-is-connected-in-cocoa, especially Vivek Gani's answer (2 upvotes). It also turns out that much of the necessary support code already exists in the Mac JoystickPlugin. See platforms/iOS//plugins/JoystickTabletPlugin/HID*. I wonder if any one has free time to do the work for the Mac to use IOHIDManagerRegisterDeviceMatchingCallback & IOHIDManagerRegisterDeviceRemovalCallback to provide a simple counter in the core Mac VM which is incremented whenever a device changes, just like the Windows implementation. If not, no biggie I'll get to this eventually. And if any unix and/or linux experts know how various unices and especially linux approach this issue please respond here. I've no idea if unix/linux provide a good API here. _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at github.com Thu Feb 11 00:30:21 2021 From: noreply at github.com (David T Lewis) Date: Wed, 10 Feb 2021 16:30:21 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] 8996e9: Rearrange disconnectXDisplay and forgetXDisplay to... Message-ID: Branch: refs/heads/dtl/epoll-forksqueak Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 8996e9691f97e9f8b4f0c3460737ba484a7527db https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/8996e9691f97e9f8b4f0c3460737ba484a7527db Author: David T. Lewis Date: 2021-02-10 (Wed, 10 Feb 2021) Changed paths: M platforms/unix/vm-display-X11/sqUnixX11.c Log Message: ----------- Rearrange disconnectXDisplay and forgetXDisplay to give clean shutdown with epoll event handling. Fixes a spurious console error message on image exit. From notifications at github.com Thu Feb 11 00:30:22 2021 From: notifications at github.com (David T Lewis) Date: Wed, 10 Feb 2021 16:30:22 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] For epoll aio, close and reopen the epoll fd in forked child process (#552) In-Reply-To: References: Message-ID: @dtlewis290 pushed 1 commit. 8996e9691f97e9f8b4f0c3460737ba484a7527db Rearrange disconnectXDisplay and forgetXDisplay to give clean shutdown -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/552/files/066a43128584d55964f4a6ace4b2c878cf96087e..8996e9691f97e9f8b4f0c3460737ba484a7527db -------------- next part -------------- An HTML attachment was scrubbed... URL: From no-reply at appveyor.com Thu Feb 11 01:39:09 2021 From: no-reply at appveyor.com (AppVeyor) Date: Thu, 11 Feb 2021 01:39:09 +0000 Subject: [Vm-dev] Build failed: opensmalltalk-vm 1.0.2403 Message-ID: <20210211013909.1.C6C7BD5836997010@appveyor.com> An HTML attachment was scrubbed... URL: From no-reply at appveyor.com Thu Feb 11 02:04:42 2021 From: no-reply at appveyor.com (AppVeyor) Date: Thu, 11 Feb 2021 02:04:42 +0000 Subject: [Vm-dev] Build failed: opensmalltalk-vm 1.0.2404 Message-ID: <20210211020442.1.D3BA9D91C54753AF@appveyor.com> An HTML attachment was scrubbed... URL: From lewis at mail.msen.com Thu Feb 11 04:38:42 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Wed, 10 Feb 2021 23:38:42 -0500 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] aafcb7: Changes to sq.h and sqAssert.h to accompany commit In-Reply-To: References: Message-ID: <20210211043842.GA86301@shell.msen.com> On Mon, Feb 08, 2021 at 09:02:10PM -0800, Eliot Miranda wrote: > > I ask anyone wishing to alter the system here to please contact me and discuss > before making changes. It is extraordinarily expensive and frustrating to have > to make changes of this kind to make sure that a signfiicantly more complex VM > such as Terf's builds correctly. > > Hi Eliot, Just a heads up in case it is not showing in the automated buids. I am getting build failures, apparently related to these changes. The last working version for me is 9f1b4644e7396e473bd9bb4cf67f8a9d5a4e11d6 I am working on Ubuntu 16.04 LTS and currently building from opensmalltalk-vm/build.linux64x64/squeak.stack.spur/build.debug With the latest Cog branch the LOG shows: In file included from /home/lewis/squeak/git/opensmalltalk-vm/platforms/Cross/vm/sqVirtualMachine.c:8: /home/lewis/squeak/git/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:24:14: error: expected function body after function declarator EXPORT(void) error(const char *); ^ /home/lewis/squeak/git/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:25:14: error: expected function body after function declarator EXPORT(void) warning(const char *); ^ /home/lewis/squeak/git/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:26:14: error: expected function body after function declarator EXPORT(void) warningat(const char *,int); Dave From eliot.miranda at gmail.com Thu Feb 11 05:12:43 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Wed, 10 Feb 2021 21:12:43 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] aafcb7: Changes to sq.h and sqAssert.h to accompany commit In-Reply-To: <20210211043842.GA86301@shell.msen.com> References: <20210211043842.GA86301@shell.msen.com> Message-ID: Hi David, On Wed, Feb 10, 2021 at 8:38 PM David T. Lewis wrote: > > On Mon, Feb 08, 2021 at 09:02:10PM -0800, Eliot Miranda wrote: > > > > I ask anyone wishing to alter the system here to please contact me and > discuss > > before making changes. It is extraordinarily expensive and frustrating > to have > > to make changes of this kind to make sure that a signfiicantly more > complex VM > > such as Terf's builds correctly. > > > > > > Hi Eliot, > > Just a heads up in case it is not showing in the automated buids. I > am getting build failures, apparently related to these changes. The > last working version for me is 9f1b4644e7396e473bd9bb4cf67f8a9d5a4e11d6 > Thanks for the heads up. Looking at it now. The cogit files don't include sq.h so they don't pick up sq.h's default definition of EXPORT et al. I'm testing what happens if I move the def to sqMemoryAccess.h (so far so good on linux, but have to test on Windows & Mac). Putting them in sqMemoryAccess.h clearly shows an issue with the cogitFOO.c files, which include sqMemoryAccess.h *before* sqPlatformSpecific.h. That can't work, so if I do decide to move EXPORT et al to sqMemoryAccess.h I'll have to change the header file declarations of the cogit files to get sqPlatformSpecific.h before sqMemoryAccess.h. This is such a mess :-(. > I am working on Ubuntu 16.04 LTS and currently building from > opensmalltalk-vm/build.linux64x64/squeak.stack.spur/build.debug > > With the latest Cog branch the LOG shows: > > In file included from > /home/lewis/squeak/git/opensmalltalk-vm/platforms/Cross/vm/sqVirtualMachine.c:8: > /home/lewis/squeak/git/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:24:14: > error: expected function body after function declarator > EXPORT(void) error(const char *); > ^ > /home/lewis/squeak/git/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:25:14: > error: expected function body after function declarator > EXPORT(void) warning(const char *); > ^ > /home/lewis/squeak/git/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:26:14: > error: expected function body after function declarator > EXPORT(void) warningat(const char *,int); > > Dave > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at github.com Thu Feb 11 05:46:32 2021 From: noreply at github.com (Eliot Miranda) Date: Wed, 10 Feb 2021 21:46:32 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] 6d74c4: Revisions to core include files to get EXPORT defi... Message-ID: Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 6d74c4b652c7780110fe327f97e98aaef5242fbc https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/6d74c4b652c7780110fe327f97e98aaef5242fbc Author: Eliot Miranda Date: 2021-02-10 (Wed, 10 Feb 2021) Changed paths: M build.linux32ARMv6/newspeak.cog.spur/build.assert/mvm M build.linux32ARMv6/newspeak.cog.spur/build.debug/mvm M build.linux32ARMv6/newspeak.cog.spur/build/mvm M build.linux32ARMv6/newspeak.stack.spur/build.assert/mvm M build.linux32ARMv6/newspeak.stack.spur/build.debug/mvm M build.linux32ARMv6/newspeak.stack.spur/build/mvm M build.linux32ARMv6/pharo.cog.spur/build.assert/mvm M build.linux32ARMv6/pharo.cog.spur/build.debug/mvm M build.linux32ARMv6/squeak.cog.spur/build.assert/mvm M build.linux32ARMv6/squeak.cog.spur/build.debug/mvm M build.linux32ARMv6/squeak.cog.spur/build/mvm M build.linux32ARMv6/squeak.stack.spur/build.assert/mvm M build.linux32ARMv6/squeak.stack.spur/build.debug/mvm M build.linux32ARMv6/squeak.stack.spur/build/mvm M build.linux32ARMv6/squeak.stack.v3/build.assert/mvm M build.linux32ARMv6/squeak.stack.v3/build.debug/mvm M build.linux32ARMv6/squeak.stack.v3/build/mvm M platforms/Cross/vm/sq.h M platforms/Cross/vm/sqAssert.h M platforms/Cross/vm/sqMemoryAccess.h M platforms/Cross/vm/sqVirtualMachine.c M platforms/Cross/vm/sqVirtualMachine.h Log Message: ----------- Revisions to core include files to get EXPORT defined correctly at the relevant points. Essentially move the default EXPORT definitions from sq.h to sqMemoryAccess.h. Include fbdev support in build.linux32ARMv6 builds and add -m32 to their CFLAGS to attempt to get the 32-bit VMs to be compilable on 64-bit ARM. [ci skip] cuz new cogit files will arrive soon. From commits at source.squeak.org Thu Feb 11 05:53:46 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Thu, 11 Feb 2021 05:53:46 0000 Subject: [Vm-dev] VM Maker: VMMaker.oscog-eem.2945.mcz Message-ID: Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.2945.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.2945 Author: eem Time: 10 February 2021, 9:53:36.233073 pm UUID: 5eae7a41-7349-4d77-87cc-fba72c5d8fd1 Ancestors: VMMaker.oscog-eem.2944 If sqMemoryAccess.h is to define EXPORT et al then sqPlatformSpecific.h, which provides platform-specific overrides, must precede it. This affects the cogit files. =============== Diff against VMMaker.oscog-eem.2944 =============== Item was changed: ----- Method: Cogit class>>declareCVarsIn: (in category 'translation') ----- declareCVarsIn: aCCodeGenerator | backEnd | backEnd := CogCompilerClass basicNew. #( 'coInterpreter' 'objectMemory' 'methodZone' 'objectRepresentation' 'cogBlockMethodSurrogateClass' 'cogMethodSurrogateClass' 'nsSendCacheSurrogateClass' 'threadManager' 'processor' 'lastNInstructions' 'simulatedAddresses' 'simulatedTrampolines' 'simulatedVariableGetters' 'simulatedVariableSetters' 'processorFrameValid' 'printRegisters' 'printInstructions' 'clickConfirm' 'singleStep') do: [:simulationVariableNotNeededForRealVM| aCCodeGenerator removeVariable: simulationVariableNotNeededForRealVM]. NewspeakVM ifFalse: [#( 'selfSendTrampolines' 'dynamicSuperSendTrampolines' 'implicitReceiverSendTrampolines' 'outerSendTrampolines' 'ceEnclosingObjectTrampoline' 'numIRCs' 'indexOfIRC' 'theIRCs') do: [:variableNotNeededInNormalVM| aCCodeGenerator removeVariable: variableNotNeededInNormalVM]]. aCCodeGenerator removeConstant: #COGMTVM. "this should be defined at compile time" "N.B. We *do not* include sq.h; it pulls in conflicting definitions now that sqVirtualMachine.h declares cointerp's functions, and declares some of them inaccurately for histrical reasons. We pull in CoInterpreter's api via cointerp.h which is accurate." aCCodeGenerator addHeaderFile:''; "for e.g. offsetof" addHeaderFile:''; addHeaderFile:''; addHeaderFile:''; addHeaderFile:'"sqConfig.h"'; - addHeaderFile:'"sqMemoryAccess.h"'; addHeaderFile:'"sqPlatformSpecific.h"'; "e.g. solaris overrides things for sqCogStackAlignment.h" + addHeaderFile:'"sqMemoryAccess.h"'; addHeaderFile:'"sqCogStackAlignment.h"'; addHeaderFile:'"dispdbg.h"'; "must precede cointerp.h & cogit.h otherwise NoDbgRegParms gets screwed up" addHeaderFile:'"cogmethod.h"'. NewspeakVM ifTrue: [aCCodeGenerator addHeaderFile:'"nssendcache.h"']. aCCodeGenerator addHeaderFile:'#if COGMTVM'; addHeaderFile:'"cointerpmt.h"'; addHeaderFile:'#else'; addHeaderFile:'"cointerp.h"'; addHeaderFile:'#endif'; addHeaderFile:'"cogit.h"'. aCCodeGenerator var: #ceGetFP declareC: 'usqIntptr_t (*ceGetFP)(void)'; var: #ceGetSP declareC: 'usqIntptr_t (*ceGetSP)(void)'; var: #ceCaptureCStackPointers declareC: 'void (*ceCaptureCStackPointers)(void)'; var: #ceInvokeInterpret declareC: 'void (*ceInvokeInterpret)(void)'; var: #ceEnterCogCodePopReceiverReg declareC: 'void (*ceEnterCogCodePopReceiverReg)(void)'; var: #realCEEnterCogCodePopReceiverReg declareC: 'void (*realCEEnterCogCodePopReceiverReg)(void)'; var: #ceCallCogCodePopReceiverReg declareC: 'void (*ceCallCogCodePopReceiverReg)(void)'; var: #realCECallCogCodePopReceiverReg declareC: 'void (*realCECallCogCodePopReceiverReg)(void)'; var: #ceCallCogCodePopReceiverAndClassRegs declareC: 'void (*ceCallCogCodePopReceiverAndClassRegs)(void)'; var: #realCECallCogCodePopReceiverAndClassRegs declareC: 'void (*realCECallCogCodePopReceiverAndClassRegs)(void)'; var: #postCompileHook declareC: 'void (*postCompileHook)(CogMethod *)'; var: #openPICList declareC: 'CogMethod *openPICList = 0'; var: #maxMethodBefore type: #'CogBlockMethod *'; var: 'enumeratingCogMethod' type: #'CogMethod *'. aCCodeGenerator var: #ceTryLockVMOwner declareC: '#if COGMTVM\usqIntptr_t (*ceTryLockVMOwner)(usqIntptr_t)\#endif'. backEnd numICacheFlushOpcodes > 0 ifTrue: [aCCodeGenerator var: #ceFlushICache declareC: 'static void (*ceFlushICache)(usqIntptr_t from, usqIntptr_t to)']. aCCodeGenerator var: #ceFlushDCache declareC: '#if DUAL_MAPPED_CODE_ZONE\static void (*ceFlushDCache)(usqIntptr_t from, usqIntptr_t to)\#endif'; var: #codeToDataDelta declareC: '#if DUAL_MAPPED_CODE_ZONE\static sqInt codeToDataDelta\#else\# define codeToDataDelta 0\#endif'. aCCodeGenerator declareVar: 'aMethodLabel' type: #'AbstractInstruction'; "Has to come lexicographically before backEnd & methodLabel" var: #backEnd declareC: 'AbstractInstruction * const backEnd = &aMethodLabel'; var: #methodLabel declareC: 'AbstractInstruction * const methodLabel = &aMethodLabel'. self declareC: #(abstractOpcodes stackCheckLabel blockEntryLabel blockEntryNoContextSwitch stackOverflowCall sendMiss entry noCheckEntry selfSendEntry dynSuperEntry fullBlockNoContextSwitchEntry fullBlockEntry picMNUAbort picInterpretAbort endCPICCase0 endCPICCase1 cPICEndOfCodeLabel) as: #'AbstractInstruction *' in: aCCodeGenerator. aCCodeGenerator declareVar: #cPICPrototype type: #'CogMethod *'; declareVar: #blockStarts type: #'BlockStart *'; declareVar: #fixups type: #'BytecodeFixup *'; declareVar: #methodZoneBase type: #usqInt. aCCodeGenerator var: #ordinarySendTrampolines declareC: 'sqInt ordinarySendTrampolines[NumSendTrampolines]'; var: #superSendTrampolines declareC: 'sqInt superSendTrampolines[NumSendTrampolines]'. BytecodeSetHasDirectedSuperSend ifTrue: [aCCodeGenerator var: #directedSuperSendTrampolines declareC: 'sqInt directedSuperSendTrampolines[NumSendTrampolines]'; var: #directedSuperBindingSendTrampolines declareC: 'sqInt directedSuperBindingSendTrampolines[NumSendTrampolines]']. NewspeakVM ifTrue: [aCCodeGenerator var: #selfSendTrampolines declareC: 'sqInt selfSendTrampolines[NumSendTrampolines]'; var: #dynamicSuperSendTrampolines declareC: 'sqInt dynamicSuperSendTrampolines[NumSendTrampolines]'; var: #implicitReceiverSendTrampolines declareC: 'sqInt implicitReceiverSendTrampolines[NumSendTrampolines]'; var: #outerSendTrampolines declareC: 'sqInt outerSendTrampolines[NumSendTrampolines]']. aCCodeGenerator addConstantForBinding: self bindingForNumTrampolines; var: #trampolineAddresses declareC: 'static char *trampolineAddresses[NumTrampolines*2]'; var: #objectReferencesInRuntime declareC: 'static usqInt objectReferencesInRuntime[NumObjRefsInRuntime+1]'; var: #labelCounter type: #int; var: #traceFlags declareC: 'int traceFlags = 8 /* prim trace log on by default */'; var: #cStackAlignment declareC: 'const int cStackAlignment = STACK_ALIGN_BYTES'. aCCodeGenerator declareVar: #minValidCallAddress type: #'usqIntptr_t'. aCCodeGenerator vmClass generatorTable ifNotNil: [:bytecodeGenTable| aCCodeGenerator var: #generatorTable declareC: 'static BytecodeDescriptor generatorTable[', bytecodeGenTable size printString, ']', (self tableInitializerFor: bytecodeGenTable in: aCCodeGenerator)]. "In C the abstract opcode names clash with the Smalltalk generator syntactic sugar. Most of the syntactic sugar is inlined, but alas some remains. Rename the syntactic sugar to avoid the clash." (self organization listAtCategoryNamed: #'abstract instructions') do: [:s| aCCodeGenerator addSelectorTranslation: s to: 'g', (aCCodeGenerator cFunctionNameFor: s)]. aCCodeGenerator addSelectorTranslation: #halt: to: 'haltmsg'. self declareFlagVarsAsByteIn: aCCodeGenerator! From noreply at github.com Thu Feb 11 06:10:13 2021 From: noreply at github.com (Eliot Miranda) Date: Wed, 10 Feb 2021 22:10:13 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] e3be59: CogVM source as per VMMaker.oscog-eem.2945 Message-ID: Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: e3be599cf289f33b2913868bd32b8317b1fb6fa6 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/e3be599cf289f33b2913868bd32b8317b1fb6fa6 Author: Eliot Miranda Date: 2021-02-10 (Wed, 10 Feb 2021) Changed paths: M nsspur64src/vm/cogit.h M nsspur64src/vm/cogitARMv8.c M nsspur64src/vm/cogitX64SysV.c M nsspur64src/vm/cogitX64WIN64.c M nsspur64src/vm/cointerp.c M nsspur64src/vm/cointerp.h M nsspur64src/vm/gcc3x-cointerp.c M nsspursrc/vm/cogit.h M nsspursrc/vm/cogitARMv5.c M nsspursrc/vm/cogitIA32.c M nsspursrc/vm/cogitMIPSEL.c M nsspursrc/vm/cointerp.c M nsspursrc/vm/cointerp.h M nsspursrc/vm/gcc3x-cointerp.c M nsspurstack64src/vm/gcc3x-interp.c M nsspurstack64src/vm/interp.c M nsspurstacksrc/vm/gcc3x-interp.c M nsspurstacksrc/vm/interp.c M spur64src/vm/cogit.h M spur64src/vm/cogitARMv8.c M spur64src/vm/cogitX64SysV.c M spur64src/vm/cogitX64WIN64.c M spur64src/vm/cointerp.c M spur64src/vm/cointerp.h M spur64src/vm/cointerpmt.c M spur64src/vm/cointerpmt.h M spur64src/vm/gcc3x-cointerp.c M spur64src/vm/gcc3x-cointerpmt.c M spurlowcode64src/vm/cogit.h M spurlowcode64src/vm/cogitARMv8.c M spurlowcode64src/vm/cogitX64SysV.c M spurlowcode64src/vm/cogitX64WIN64.c M spurlowcode64src/vm/cointerp.c M spurlowcode64src/vm/cointerp.h M spurlowcode64src/vm/gcc3x-cointerp.c M spurlowcodesrc/vm/cogit.h M spurlowcodesrc/vm/cogitARMv5.c M spurlowcodesrc/vm/cogitIA32.c M spurlowcodesrc/vm/cogitMIPSEL.c M spurlowcodesrc/vm/cointerp.c M spurlowcodesrc/vm/cointerp.h M spurlowcodesrc/vm/gcc3x-cointerp.c M spurlowcodestack64src/vm/gcc3x-interp.c M spurlowcodestack64src/vm/interp.c M spurlowcodestacksrc/vm/gcc3x-interp.c M spurlowcodestacksrc/vm/interp.c M spursista64src/vm/cogit.h M spursista64src/vm/cogitARMv8.c M spursista64src/vm/cogitX64SysV.c M spursista64src/vm/cogitX64WIN64.c M spursista64src/vm/cointerp.c M spursista64src/vm/cointerp.h M spursista64src/vm/gcc3x-cointerp.c M spursistasrc/vm/cogit.h M spursistasrc/vm/cogitARMv5.c M spursistasrc/vm/cogitIA32.c M spursistasrc/vm/cogitMIPSEL.c M spursistasrc/vm/cointerp.c M spursistasrc/vm/cointerp.h M spursistasrc/vm/gcc3x-cointerp.c M spursrc/vm/cogit.h M spursrc/vm/cogitARMv5.c M spursrc/vm/cogitIA32.c M spursrc/vm/cogitMIPSEL.c M spursrc/vm/cointerp.c M spursrc/vm/cointerp.h M spursrc/vm/cointerpmt.c M spursrc/vm/cointerpmt.h M spursrc/vm/gcc3x-cointerp.c M spursrc/vm/gcc3x-cointerpmt.c M spurstack64src/vm/gcc3x-interp.c M spurstack64src/vm/interp.c M spurstack64src/vm/validImage.c M spurstacksrc/vm/gcc3x-interp.c M spurstacksrc/vm/interp.c M spurstacksrc/vm/validImage.c M src/vm/cogit.h M src/vm/cogitARMv5.c M src/vm/cogitIA32.c M src/vm/cogitMIPSEL.c M src/vm/cointerp.c M src/vm/cointerp.h M src/vm/gcc3x-cointerp.c M stacksrc/vm/gcc3x-interp.c M stacksrc/vm/interp.c Log Message: ----------- CogVM source as per VMMaker.oscog-eem.2945 If sqMemoryAccess.h is to define EXPORT et al then sqPlatformSpecific.h, which provides platform-specific overrides, must precede it. This affects the cogit files. Add explicit variables for the handler and unwind primitive markers (PrimNumberHandlerMarker & PrimNumberUnwindMarker), and add 123 as the no-context-switch marker (PrimNumberNoContextSwitchMarker). From no-reply at appveyor.com Thu Feb 11 06:29:48 2021 From: no-reply at appveyor.com (AppVeyor) Date: Thu, 11 Feb 2021 06:29:48 +0000 Subject: [Vm-dev] Build failed: opensmalltalk-vm 1.0.2405 Message-ID: <20210211062948.1.C600C8D2BB2866F0@appveyor.com> An HTML attachment was scrubbed... URL: From noreply at github.com Thu Feb 11 07:48:58 2021 From: noreply at github.com (Eliot Miranda) Date: Wed, 10 Feb 2021 23:48:58 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] ae3d99: Windows MSVC Makefiles. Message-ID: Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: ae3d9915ba0c224ad5c7fd93972ba6edfdbd35c3 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/ae3d9915ba0c224ad5c7fd93972ba6edfdbd35c3 Author: Eliot Miranda Date: 2021-02-10 (Wed, 10 Feb 2021) Changed paths: M build.win32x86/common/Makefile.msvc M build.win32x86/common/Makefile.msvc.plugin M build.win64x64/common/Makefile.msvc M build.win64x64/common/Makefile.msvc.plugin Log Message: ----------- Windows MSVC Makefiles. Ensure that plugin dlls and libs get rebuilt by adding LIBSRC as dependencies. No longer nuke the internal plugin libs. Copy enhancements in the 64-bit Makefiles to the 32-bit Makefiles. [ci skip] From noreply at github.com Fri Feb 12 20:34:00 2021 From: noreply at github.com (Eliot Miranda) Date: Fri, 12 Feb 2021 12:34:00 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] b7c939: Fix the circular dependency between sqMemoryAccess... Message-ID: Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: b7c93957e773a6f1e90f77972d8a3255e78a2698 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/b7c93957e773a6f1e90f77972d8a3255e78a2698 Author: Eliot Miranda Date: 2021-02-12 (Fri, 12 Feb 2021) Changed paths: M platforms/Cross/vm/sqMemoryAccess.h M platforms/Mac OS/vm/sqPlatformSpecific.h M platforms/iOS/vm/OSX/sqPlatformSpecific.h M platforms/iOS/vm/iPhone/sqPlatformSpecific.h M platforms/unix/vm/sqPlatformSpecific.h Log Message: ----------- Fix the circular dependency between sqMemoryAccess.h and sqPlatformSpecific.h which derives from sqPlatformSpecific.h trying to do two different things. First sqPlatformSpecific.h provides platform implementations of prerequisites such as the EXPORT macros. Second sqPlatformSpecific.h defines platform specific support functions which need types declared by sqMemoryAccess.h. But sqMemoryAccess.h needs those platform implementations prerequisites first. So have sqMemoryAccess.h include sqPlatformSpecific.h a second time if it detects that sqPlatformSpecific.h has already been included, and have sqPlatformSpecific.h only declare the support funcitons if it detects that sqMemoryAccess.h has been included. A better solution would be to cleanly separate the two functions of sqPlatformSpecific.h but this is too much work in teh short term. From no-reply at appveyor.com Fri Feb 12 20:52:59 2021 From: no-reply at appveyor.com (AppVeyor) Date: Fri, 12 Feb 2021 20:52:59 +0000 Subject: [Vm-dev] Build failed: opensmalltalk-vm 1.0.2406 Message-ID: <20210212205259.1.D69CAFD635CC5DD2@appveyor.com> An HTML attachment was scrubbed... URL: From stes at telenet.be Sun Feb 14 16:04:17 2021 From: stes at telenet.be (stes@PANDORA.BE) Date: Sun, 14 Feb 2021 17:04:17 +0100 (CET) Subject: [Vm-dev] Squeak VM update on OpenIndiana Message-ID: <1792710994.5254873.1613318657203.JavaMail.zimbra@telenet.be> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, Here's some news on Squeak on "OpenIndiana". OpenIndiana is an illumos based operating system derived from OpenSolaris; Current upgrades in the repository, http://pkg.openindiana.org/hipster/en/index.shtml squeak-4 : version 4.19.5 squeak-5 : version 5.0.2945 There are packages for 'headless' (-nodisplay) operation and with GUI. I've made up the version 5.0.2945 myself this corresponds roughly to VM Maker: VMMaker.oscog-eem.2945 This is because normally there is a 3 digit version number, but for OpenSmalltalk VM I just use the number 5.0.2945. Special thanks to everybody in the "Squeak" and "opensmalltalk-vm" team. Thanks, David Stes -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJgKUmSAAoJEAwpOKXMq1MaVh4IAJtxIumLVPANaFvcq7EXuHtw 1VRYnkdlessPYq05efp3sl2PV5fRGXMINCB4ZQKHjrzppoisEtX2BNql5mEF6B+A n24lOWC0Df7C+4wjoXYaBosswLa3y6wzLh4l8nDjECLEaBM9MjE9kkmhUUt8Ap4R iEdwad+QfAHTQpey5AfNVWIxxdZuKPv5ym4PITlIH8y1XImSTxwjedLbcJvsmO2u DeRMz6mu0JFg29cNMbh4bszgn8kVQKRB546KTKuxMaHkoed5435W3od91iXjHmed j6Ykgxds7H0EU39BsBiElN3PH7Zbd1KmkVb0o9dVPHb8amGH5dPFuoDOEyFnhAQ= =Z4FX -----END PGP SIGNATURE----- From tim at rowledge.org Sun Feb 14 21:01:22 2021 From: tim at rowledge.org (tim Rowledge) Date: Sun, 14 Feb 2021 13:01:22 -0800 Subject: [Vm-dev] Building UnicodePlugin on ARM64 Message-ID: <8AC6ECA7-5527-4552-AFC1-27744114342B@rowledge.org> I swear this worked a couple of weeks ago, but who knows? I'm building a nice clean AARCH64 VM for NuScratch - which means it needs the UnicodePlugin working for the pango font rendering. I'm sure this was ok a couple of weeks ago when I tested it... but I can't see any way it could have changed. So maybe I was hallucinating. The problem is that the glib-2.0 package is in a different path than on the 32bit ARM OS - no big surprise there , though I am surprised that the machine specific directory isn't linked to a generic path to, you know, make life less stupid. But then this is unix, where the entire idea is to make people feel stupid. At first I thought I hadn't' installed the glib stuff properly, and indeed there are plenty of google-hits for the error message. After faffing around with that I spotted the opensmalltalk-vm/platforms/unix/plugins/UnicodePlugin/acinclude.m4 file that simply lists the (hopefully) releveant paths. Ah-Hah! thought I, add the path here and away we go. It even says that in the opensmalltalk-vm/platforms/unix/plugins/UnicodePlugin/README.UnicodePlugin Nope. It's also explicitly listed in opensmalltalk-vm/platforms/unix/plugins/UnicodePlugin/Makefile.inc for some reason - so let's add it there as well. Nope. When one examines the config.log the command to run a test prog to find out if the glib/pango/cairo stuff is there looks like this - configure:15962: gcc -c -Wall -march=armv8-a -mtune=cortex-a72 -g -O2 -DNDEBUG -DDEBUGVM=0 -DMUSL -D_GNU_SOURCE -DUSEEVDEV -DCOGMTVM=0 -DDUAL_MAPPED_CODE_ZONE=1 -pthread -DLSB_FIRST=1 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/lib/arm-linux-gnueabihf/glib-2.0/include -I/usr/lib/i386-linux-gnu/glib-2.0/include conftest.c >&5 Notice how it does not have the -I/usr/lib/aarch64-linux-gnu/glib-2.0/include path I've now added to acinclude.m4 Makefile.inc And now, for added excitement, the actual opensmalltalk-vm/platforms/unix/config/configure script, which seems to also have the paths hard coded, is edited to add the new path explicitly. And at last the damned thing builds properly and even runs NuScratch. The obvious question is what the 'proper' way to solve this is. I had the vague idea floating around the back of my skull that the 'configure' script stuff built itself from things like the acinclude.m4 fragments - and it certainly seems to include exactly the text from the original acinclude file. tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Useful random insult:- In serious need of attitude adjustment. From stes at telenet.be Mon Feb 15 07:32:22 2021 From: stes at telenet.be (stes@PANDORA.BE) Date: Mon, 15 Feb 2021 08:32:22 +0100 (CET) Subject: [Vm-dev] Building UnicodePlugin on ARM64 Message-ID: <1692085850.6423914.1613374342681.JavaMail.zimbra@telenet.be> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > Notice how it does not have the -I/usr/lib/aarch64-linux-gnu/glib-2.0/include path I've now added to > acinclude.m4 Makefile.inc I think this is because the configure script needs to be rebuilt. > The obvious question is what the 'proper' way to solve this is. > I had the vague idea floating around the back of my skull that the > 'configure' script stuff built itself from things like the acinclude.m4 fragments - > and it certainly seems to include exactly the text from the original acinclude file. Yes this is true. Something like 'autoconf' or perhaps 'autoreconf' to generate the configure script. As the README in the plugin directory for UnicodePlugin indicates, an approach may be (it is a possibility) to use "pkg-config" Assuming that pkgconfig on your system gives some results such as: # pkg-config --cflags glib-2.0 # PKG_CONFIG_PATH=/usr/lib/64/pkgconfig pkg-config --cflags glib-2.0 it may be able to find the required --cflags using pkg-config However I can imagine that approach has its own disadvantages. My understanding is that historically pkg-config was used, and that the opensmalltalk-vm team wants to migrate/move away from pkg-config. If I'm not mistaken the Squeak VM "Classic" (squeak-4) uses the approach, with cmake/pkg-config. Squeak VM classic (in subversion) uses pkg-config. The GNU configure script could use also the same approach using: PKG_CHECK_MODULES(UNICODE_PLUGIN,[glib-2.0 pangocairo],,AC_PLUGIN_DISABLE) AC_SUBST(UNICODE_PLUGIN_CFLAGS) AC_SUBST(UNICODE_PLUGIN_LIBS) However I agree that no approach is without faults, they all have their own advantages and disadvantages, I suppose. Currently on Solaris 11.4 I just disable the UnicodePlugin, as it used to build fine for GNOME 2 (on OpenIndiana with MATE or Solaris 11.3), but not on GNOME 3 with 64bit (Solaris 11.4) for me. Provided I reconfigure with the right path to #include, UnicodePlugin builds, on Solaris 11.4 as well. This is basically unrelated to Solaris 11.3 or Solaris 11.4 etc. It is just where Linux/Unix distributions (or operating systems in general), put their #include files and the configuration tools to figure out the settings. Regards, David Stes -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJgKiHRAAoJEAwpOKXMq1Maxw4H/29SCg+YABqmJhd3s4LhCmnt 9fp2ogOTGFWdj4OXeBTDG0QnqTwEuJWLAruispEMiwtCoFWFoJKzpHt0yW78VjEu vhivE/TmOVPYPAzzU1DwSjttGP5XOpul3Pl9kAZvXXR2bNece93FqKBb+6Kjb47Z aRch60dw+XXc+ZoaxnUl4DOw5qKQQJLNq/tFIfKcYN3ZHuwUi2NGxPXtoxy9fsDY z5hBVE3aj58X1kKyFJs9wvT2uJG8VdQReAjSHYxOxRXJaQCPhzaSMnN14KKmvGyr GnakeHLgrUKyldvvv0FFj4u9kioYJKknRndS1tSkxbrVF1KUbrpHKrv4teDliYA= =+siH -----END PGP SIGNATURE----- From lewis at mail.msen.com Mon Feb 15 16:27:48 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Mon, 15 Feb 2021 11:27:48 -0500 Subject: [Vm-dev] Squeak VM update on OpenIndiana In-Reply-To: <1792710994.5254873.1613318657203.JavaMail.zimbra@telenet.be> References: <1792710994.5254873.1613318657203.JavaMail.zimbra@telenet.be> Message-ID: <20210215162748.GA58987@shell.msen.com> Hello David, Thanks for the update. On Sun, Feb 14, 2021 at 05:04:17PM +0100, stes at PANDORA.BE wrote: > > Hello, > > Here's some news on Squeak on "OpenIndiana". > > OpenIndiana is an illumos based operating system derived from OpenSolaris; > > Current upgrades in the repository, > > http://pkg.openindiana.org/hipster/en/index.shtml > > squeak-4 : version 4.19.5 > squeak-5 : version 5.0.2945 Are users able to load both "squeak-4" and "squeak-5" on the same machine? If there are issues, I can share the shell script that I use to resolve naming conflicts. Dave > > There are packages for 'headless' (-nodisplay) operation and with GUI. > > I've made up the version 5.0.2945 myself this corresponds roughly to > VM Maker: VMMaker.oscog-eem.2945 > > This is because normally there is a 3 digit version number, but for > OpenSmalltalk VM I just use the number 5.0.2945. > > Special thanks to everybody in the "Squeak" and "opensmalltalk-vm" team. > > Thanks, > David Stes > From lewis at mail.msen.com Mon Feb 15 16:35:43 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Mon, 15 Feb 2021 11:35:43 -0500 Subject: [Vm-dev] Building UnicodePlugin on ARM64 In-Reply-To: <8AC6ECA7-5527-4552-AFC1-27744114342B@rowledge.org> References: <8AC6ECA7-5527-4552-AFC1-27744114342B@rowledge.org> Message-ID: <20210215163543.GB58987@shell.msen.com> On Sun, Feb 14, 2021 at 01:01:22PM -0800, tim Rowledge wrote: > > I swear this worked a couple of weeks ago, but who knows? > There are some recent changes to header file configurations that may not yet be completely sorted out. For me, a recent good working version is git commit 9f1b4644e7396e473bd9bb4cf67f8a9d5a4e11d6 so you may want to try checking that version out (git checkout 9f1b4644e7396e473bd9bb4cf67f8a9d5a4e11d6) to see if the problem goes away. Stash your local work first before doing the git checkout. Dave From stes at telenet.be Mon Feb 15 18:42:43 2021 From: stes at telenet.be (stes@PANDORA.BE) Date: Mon, 15 Feb 2021 19:42:43 +0100 (CET) Subject: [Vm-dev] Squeak VM update on OpenIndiana In-Reply-To: <1792710994.5254873.1613318657203.JavaMail.zimbra@telenet.be> References: <1792710994.5254873.1613318657203.JavaMail.zimbra@telenet.be> Message-ID: <1188953642.8508818.1613414563789.JavaMail.zimbra@telenet.be> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > Are users able to load both "squeak-4" and "squeak-5" on the same > machine? If there are issues, I can share the shell script that I > use to resolve naming conflicts. Yes, both packages can be installed at the same time. The packages are also delivered in both 32bit and 64bit (but only Intel/AMD, not SPARC). The packaging uses "mediators" which is something that can be used to have multiple versions of some system installed. For example if I have squeak-4 installed (medatior version: 4), and then install squeak-5 it changes version and implementation: Changed mediators: mediator squeak: version: 4 (system default) -> 5 (system default) implementation: None -> cog-spur (system default) So the mediator squeak is a property of the packages, to have multiple "builds" or "variations" of the same package installed. I am not building debug or profile VMs, but for example if a debug VM would be built, then it could set the mediator to some value, so that both the non-debug and the debug VM can be installed together. David Stes -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJgKsAeAAoJEAwpOKXMq1Ma2RoIAJFiPzqJF1SkShwR6cGOG3tU 8eHf/6r6pvOkQHZVZdW/+NKbDLbQiTZBrzvvQO8UxARTem2QDlfGoWX0bZ66bjKU T7iqqI2OgCKd1QEsH4jpD/TZTa7gTzeGTB/CkLvKoXKMRmrR56a8jacDgZOeVlTw asC/gjiTpB+S551AXSvRhTtANUUUYJFusGA+DnJVKwFGaDCMLMcyu4LHDxMbj3rI Bxt16S8b3B/QEAcY34/QR9kW6qlH0SaeCzsRMRMbeJIkpDfo2w3p4x2Xr2/zUmhB f/AQWHK8rYN1yti9985Cj0YpaNCkHFfyxBcPfaOrATbiHD7/fUgtJaYB+t94+9U= =Mpqd -----END PGP SIGNATURE----- From noreply at github.com Wed Feb 17 20:13:26 2021 From: noreply at github.com (Eliot Miranda) Date: Wed, 17 Feb 2021 12:13:26 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] 40ce4b: HostWindowPlugin: Generalize ioSetTitleOfWindow on... Message-ID: Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 40ce4b725bf37fabc61e25f5051a40fa1ca1df45 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/40ce4b725bf37fabc61e25f5051a40fa1ca1df45 Author: Eliot Miranda Date: 2021-02-17 (Wed, 17 Feb 2021) Changed paths: M platforms/iOS/plugins/HostWindowPlugin/sqMacHostWindow.m Log Message: ----------- HostWindowPlugin: Generalize ioSetTitleOfWindow on Mac to be the same as Windows. [ci skip] cuz not a significant change for other than Terf. From noreply at github.com Thu Feb 18 23:42:34 2021 From: noreply at github.com (Eliot Miranda) Date: Thu, 18 Feb 2021 15:42:34 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] 692fb7: Implement the old named primitive API for window t... Message-ID: Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 692fb729691e9e7c8f68e41710c1e416224e94e4 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/692fb729691e9e7c8f68e41710c1e416224e94e4 Author: Eliot Miranda Date: 2021-02-18 (Thu, 18 Feb 2021) Changed paths: M platforms/iOS/vm/Common/Classes/sqSqueakNullScreenAndWindow.h M platforms/iOS/vm/Common/Classes/sqSqueakNullScreenAndWindow.m M platforms/iOS/vm/Common/Classes/sqSqueakScreenAPI.m M platforms/iOS/vm/Common/Classes/sqSqueakScreenAndWindow.m Log Message: ----------- Implement the old named primitive API for window title on Mac iOS. From no-reply at appveyor.com Fri Feb 19 00:01:49 2021 From: no-reply at appveyor.com (AppVeyor) Date: Fri, 19 Feb 2021 00:01:49 +0000 Subject: [Vm-dev] Build failed: opensmalltalk-vm 1.0.2407 Message-ID: <20210219000149.1.94F805EEEB3FF852@appveyor.com> An HTML attachment was scrubbed... URL: From stes at telenet.be Fri Feb 19 18:47:01 2021 From: stes at telenet.be (stes@PANDORA.BE) Date: Fri, 19 Feb 2021 19:47:01 +0100 (CET) Subject: [Vm-dev] Squeak VM update on OpenIndiana In-Reply-To: <1188953642.8508818.1613414563789.JavaMail.zimbra@telenet.be> References: <1792710994.5254873.1613318657203.JavaMail.zimbra@telenet.be> <1188953642.8508818.1613414563789.JavaMail.zimbra@telenet.be> Message-ID: <1142784744.21514154.1613760421595.JavaMail.zimbra@telenet.be> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 More info also at the webpage on the OpenIndiana website : http://docs.openindiana.org/handbook/community/squeak/index.html Regards, David Stes -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJgMAdQAAoJEAwpOKXMq1MaNGIH+wXFOAVBUt9vdq8vaZhRt1Jv b/+Pr1JTPe3Z34UJGPlJUBFJPKqyue4y1SULmPiYCo5ABhUBNx04XIle6P/5i3nS LPaWEjq2AcHY42N4zKfDi7sl3BUb/EzVSctx8K5LGpv1z9c+EeCkwHt9gtZQBk6N lWi3HI5vn0PBhF9UvITs9z4dxIL/5vAwX+xNKdCFZv8Ztu9uahO9DHMjtI0I373u d92w5VHIOzw9eNMX/2YX/0ByJsLW/rp0Zx3iPubOqr0Uu6L4HkXRp0Hn2PV9zHOs 8ToSGEMctM4M7v2cWXP3j6sD1JjqN51dBPKVW6xOze4zPWpbZSnLZSOZTGv0BkQ= =ffnX -----END PGP SIGNATURE----- From eliot.miranda at gmail.com Sat Feb 20 17:20:32 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Sat, 20 Feb 2021 09:20:32 -0800 Subject: [Vm-dev] Squeak VM update on OpenIndiana In-Reply-To: <1142784744.21514154.1613760421595.JavaMail.zimbra@telenet.be> References: <1142784744.21514154.1613760421595.JavaMail.zimbra@telenet.be> Message-ID: Hi David, > On Feb 19, 2021, at 10:47 AM, stes at telenet.be wrote: > >  > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > More info also at the webpage on the OpenIndiana website : > > http://docs.openindiana.org/handbook/community/squeak/index.html Super cool. I would like to see “ The squeak-4 package corresponds to the classic virtual machine (VM). The squeak-5 packages are OpenSmalltalk based virtual machines, where squeak-5 is the OpenSmalltalk stack VM and squeak-5c is the OpenSmalltalk cog VM.” extended with something like “The relative performance of these virtual machines is approximately 1 to 1.5 to 15.” > Regards, > David Stes > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJgMAdQAAoJEAwpOKXMq1MaNGIH+wXFOAVBUt9vdq8vaZhRt1Jv > b/+Pr1JTPe3Z34UJGPlJUBFJPKqyue4y1SULmPiYCo5ABhUBNx04XIle6P/5i3nS > LPaWEjq2AcHY42N4zKfDi7sl3BUb/EzVSctx8K5LGpv1z9c+EeCkwHt9gtZQBk6N > lWi3HI5vn0PBhF9UvITs9z4dxIL/5vAwX+xNKdCFZv8Ztu9uahO9DHMjtI0I373u > d92w5VHIOzw9eNMX/2YX/0ByJsLW/rp0Zx3iPubOqr0Uu6L4HkXRp0Hn2PV9zHOs > 8ToSGEMctM4M7v2cWXP3j6sD1JjqN51dBPKVW6xOze4zPWpbZSnLZSOZTGv0BkQ= > =ffnX > -----END PGP SIGNATURE----- From stes at telenet.be Sun Feb 21 12:49:41 2021 From: stes at telenet.be (stes@PANDORA.BE) Date: Sun, 21 Feb 2021 13:49:41 +0100 (CET) Subject: [Vm-dev] Squeak VM update on OpenIndiana In-Reply-To: <1142784744.21514154.1613760421595.JavaMail.zimbra@telenet.be> References: <1792710994.5254873.1613318657203.JavaMail.zimbra@telenet.be> <1188953642.8508818.1613414563789.JavaMail.zimbra@telenet.be> <1142784744.21514154.1613760421595.JavaMail.zimbra@telenet.be> Message-ID: <1511577064.25541029.1613911781797.JavaMail.zimbra@telenet.be> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, Related to additional information such as: > "The relative performance of these virtual machines is approximately 1 to 1.5 to 15." Under their github.com openindiana webpage they accept pull requests (PR's) for the documentation so I suppose that you can create a PR , adding whatever information is considered appropriate. Regards, David Stes -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJgMladAAoJEAwpOKXMq1MagQ8H/A9WD9kBZIh82ZZXI5xLtymS rnjFeZYBcyb9DDyY4h1cMhJMdEVlhn0q5p2g6XmDLX/2wyydQkPNIPTD6pMsaguE EowSNt/MNXLCmVQ7rEC/gazLzY4k6xulD9LRADJYFZ27HseLmC/66UPvf3162655 WOMdsD1k1umWjft8swUcNMoazfTB70J1msGJiTOc4u6lxj9xQKwo6guObbOm4tZl h2w50Avx7jHP2IttxK+Q8xGcdwcXMIzEoOsxWjvgQlPmMclHwwD88kNXmS8ZPnoD 1m1JYME3Woz6aO5/i97vBC5tXSJGyW9iU+yVz74gt6i7tkLIn/Hvav8S14i+EkI= =fkQw -----END PGP SIGNATURE----- From stes at telenet.be Sun Feb 21 15:02:38 2021 From: stes at telenet.be (stes@PANDORA.BE) Date: Sun, 21 Feb 2021 16:02:38 +0100 (CET) Subject: [Vm-dev] regression: TestObjectsAsMethods crash in 4.19.5 (not in 4.16.7) Message-ID: <949389016.25753821.1613919758428.JavaMail.zimbra@telenet.be> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 As can be seen in the screenshot at: http://docs.openindiana.org/handbook/community/squeak/index.html I'm deselecting the Tests-ObjectsAsMethods test (1 test), because it causes (reproducible) SIGSEGV on Solaris cc/OpenIndiana gcc. I think the segmentation fault is new in recent 4.19, I think it didn't happen a while ago in 4.16. I can test this as follows: when I install an older version squeak -version 4.16.7-3775 then I go into test runner: Tests-ObjectsAsMethods and select TestObjectsAsMethods that works in 4.16.7 Test Runner ... TestObjectsAsMethods 3 run, 3 passes, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes But it stopped working in 4.19.x which is from I believe from: ContextInterpreter VMMaker-dtl.422 uuid: e72b95a0-204e-45a1-a4e4-3ac3c9e7a51a the interp.c file is automatically generated from VMMaker-dtl.422. It's reproducible in the sense that if I deselect all tests, and just select that one single test, I can repeatedly and reproducible SIGSEGV the VM. When I run the VM under a debugger: dbx: warning: Bad transition in runtime linker interface. CONSISTENT->CONSISTENT t at 1 (l at 1) signal SEGV (no mapping at the fault address) in interpret at line 9120 in file "interp.c" 9120 foo->freeContexts = longAt((newContext + (BASE_HEADER_SIZE)) + (0 << (SHIFT_FOR_WORD))); (dbx) where current thread: t at 1 =>[1] interpret(), line 9120 in "interp.c" [2] main(argc = 1, argv = 0xfeffe250, envp = 0xfeffe258), line 1484 in "sqUnixMain.c" The above is from Solaris with cc/dbx but the same thing appears to happen for me on OpenIndiana with gcc/gdb. Unfortunately because the code of interp.c is automatically generated, it looks complicated to me and I don't see what's wrong with those " freeContext" code. The crash appears to be in: /* begin internalActivateNewMethod */ methodHeader = longAt((foo->newMethod + (BASE_HEADER_SIZE)) + (HeaderIndex << (SHIFT_FOR_WORD))); needsLarge = methodHeader & LargeContextBit; if ((needsLarge == 0) && (foo->freeContexts != NilContext)) { newContext = foo->freeContexts; /* begin setFreeContextsAfter: */ foo->freeContexts = longAt((newContext + (BASE_HEADER_SIZE)) + (0 << (SHIFT_FOR_WORD))); } else { /* begin externalizeIPandSP */ Has anyone seen this ? Also what is the test TestObjectsAsMethods actually doing please ? what is it testing ? Regards, David Stes -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJgMnV5AAoJEAwpOKXMq1MafEgH/3EWQxaSaVm2g4r/2p99Wc21 P+U+ijqKpVTDfJ1smwV/GsgF0V8ZrZky0k7BzRDAyq3Gi/HGVm0e2bqOAKa1fo2Y MUS9JHOW4Lys+9qWgT0aLiWypjYlzThtYS0/Lfh013tsF1bBv2eppTceUyq/Zitv 6J0IFvDOspMN/zHwBw/ux3H6uR049boZ3mvk23sp3KIHDc2Yw2kF4TAXBwjZXmVO UFlIAC4EAahrtNZyLZSIBDbsXOl+wJGmQTsOIBG81pfSFpP6RBrIARcu6enZC3Wc bwsvWYADs49SKgVq3NBovfyzkZBIW30V82xlVKpOnp6A4FnOYXxQiVm9sNaOVXc= =34TJ -----END PGP SIGNATURE----- From ken.dickey at whidbey.com Sun Feb 21 15:56:35 2021 From: ken.dickey at whidbey.com (ken.dickey at whidbey.com) Date: Sun, 21 Feb 2021 07:56:35 -0800 Subject: [Vm-dev] MultiCore [response to: partially Squeak based OS] Message-ID: Other useful idea mines: L4 microkernel and Genode UI: https://microkerneldude.wordpress.com/2019/03/07/how-to-and-how-not-to-use-sel4-ipc/ https://genode.org/about/index -- multiple concurrent window systems https://sel4.systems/ -- very fast message based IPC (think multiple VM spaces) Just thinking of making multicore more useful & robust.. I think Aarch64 and particularly RISC-V are more useful starting points, BTW. (BeagleV is coming soon.. https://beagleboard.org/beaglev :) $0.02, -KenD From lewis at mail.msen.com Sun Feb 21 16:29:13 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Sun, 21 Feb 2021 11:29:13 -0500 Subject: [Vm-dev] regression: TestObjectsAsMethods crash in 4.19.5 (not in 4.16.7) In-Reply-To: <949389016.25753821.1613919758428.JavaMail.zimbra@telenet.be> References: <949389016.25753821.1613919758428.JavaMail.zimbra@telenet.be> Message-ID: <20210221162913.GA15590@shell.msen.com> Thanks. Confirmed on Linux amd64, so it is not Solaris/OpenIndiana issue. Dave On Sun, Feb 21, 2021 at 04:02:38PM +0100, stes at PANDORA.BE wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > As can be seen in the screenshot at: > > http://docs.openindiana.org/handbook/community/squeak/index.html > > I'm deselecting the Tests-ObjectsAsMethods test (1 test), > because it causes (reproducible) SIGSEGV on Solaris cc/OpenIndiana gcc. > > I think the segmentation fault is new in recent 4.19, I think it didn't happen > a while ago in 4.16. > > I can test this as follows: when I install an older version > > squeak -version > 4.16.7-3775 > > then I go into test runner: Tests-ObjectsAsMethods and select > TestObjectsAsMethods that works in 4.16.7 > > Test Runner > > ... > TestObjectsAsMethods > > 3 run, 3 passes, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes > > But it stopped working in 4.19.x which is from I believe from: > > ContextInterpreter VMMaker-dtl.422 uuid: e72b95a0-204e-45a1-a4e4-3ac3c9e7a51a > > the interp.c file is automatically generated from VMMaker-dtl.422. > > It's reproducible in the sense that if I deselect all tests, and just select > that one single test, I can repeatedly and reproducible SIGSEGV the VM. > > When I run the VM under a debugger: > > dbx: warning: Bad transition in runtime linker interface. CONSISTENT->CONSISTENT > t at 1 (l at 1) signal SEGV (no mapping at the fault address) in interpret at line 9120 in file "interp.c" > 9120 foo->freeContexts = longAt((newContext + (BASE_HEADER_SIZE)) + (0 << (SHIFT_FOR_WORD))); > > (dbx) where > current thread: t at 1 > =>[1] interpret(), line 9120 in "interp.c" > [2] main(argc = 1, argv = 0xfeffe250, envp = 0xfeffe258), line 1484 in "sqUnixMain.c" > > The above is from Solaris with cc/dbx but the same thing appears to happen > for me on OpenIndiana with gcc/gdb. > > Unfortunately because the code of interp.c is automatically generated, > it looks complicated to me and I don't see what's wrong with those " > freeContext" code. > > The crash appears to be in: > > /* begin internalActivateNewMethod */ > methodHeader = longAt((foo->newMethod + (BASE_HEADER_SIZE)) + (HeaderIndex << (SHIFT_FOR_WORD))); > needsLarge = methodHeader & LargeContextBit; > if ((needsLarge == 0) && (foo->freeContexts != NilContext)) { > newContext = foo->freeContexts; > /* begin setFreeContextsAfter: */ > foo->freeContexts = longAt((newContext + (BASE_HEADER_SIZE)) + (0 << (SHIFT_FOR_WORD))); > } else { > /* begin externalizeIPandSP */ > > Has anyone seen this ? > > Also what is the test > TestObjectsAsMethods > actually doing please ? what is it testing ? > > > Regards, > David Stes > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJgMnV5AAoJEAwpOKXMq1MafEgH/3EWQxaSaVm2g4r/2p99Wc21 > P+U+ijqKpVTDfJ1smwV/GsgF0V8ZrZky0k7BzRDAyq3Gi/HGVm0e2bqOAKa1fo2Y > MUS9JHOW4Lys+9qWgT0aLiWypjYlzThtYS0/Lfh013tsF1bBv2eppTceUyq/Zitv > 6J0IFvDOspMN/zHwBw/ux3H6uR049boZ3mvk23sp3KIHDc2Yw2kF4TAXBwjZXmVO > UFlIAC4EAahrtNZyLZSIBDbsXOl+wJGmQTsOIBG81pfSFpP6RBrIARcu6enZC3Wc > bwsvWYADs49SKgVq3NBovfyzkZBIW30V82xlVKpOnp6A4FnOYXxQiVm9sNaOVXc= > =34TJ > -----END PGP SIGNATURE----- From lewis at mail.msen.com Sun Feb 21 17:20:52 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Sun, 21 Feb 2021 12:20:52 -0500 Subject: [Vm-dev] regression: TestObjectsAsMethods crash in 4.19.5 (not in 4.16.7) In-Reply-To: <20210221162913.GA15590@shell.msen.com> References: <949389016.25753821.1613919758428.JavaMail.zimbra@telenet.be> <20210221162913.GA15590@shell.msen.com> Message-ID: <20210221172052.GA25623@shell.msen.com> I'm not yet sure what to do about it, but the problem was introduced last April in VMMaker-dtl.415. Apparently the obsolete primitiveInvokeObjectAsMethod was not quite as obsolete as I thought it was. Dave Name: VMMaker-dtl.415 Author: dtl Time: 19 April 2020, 5:30:30.208 pm UUID: 747f8591-57e6-4950-858a-c7fbc22ad1c2 Ancestors: VMMaker-dtl.414 VMMaker 4.19.1 Required for Squeak trunk Collections-eem.885 and above. Install primitiveArrayBecomeOneWayNoCopyHash as primitive 248, replacing obsolete primitiveInvokeObjectAsMethod. Fix 128 primitiveArrayBecome to match oscog logic. This a fix from VMMaker.oscog-eem.647 which Eliot explained as follows: Fix primitiveArrayBecome (the two-way become); it should /not/ specify copyHash. ObjectMemory ignores the copyHash flag when doing a two-way become, hence the wrong sense of the flag had no effect. Hence correctly evaluate testBecomeIdentityHash. The primitives now do this: primitive 72: twoWay: false copyHash: true primitive 128: twoWay: true copyHash: false primitive 248: twoWay: false copyHash: false primitive 249: twoWay: false copyHash: On Sun, Feb 21, 2021 at 11:29:13AM -0500, David T. Lewis wrote: > > Thanks. > > Confirmed on Linux amd64, so it is not Solaris/OpenIndiana issue. > > Dave > > On Sun, Feb 21, 2021 at 04:02:38PM +0100, stes at PANDORA.BE wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > > > As can be seen in the screenshot at: > > > > http://docs.openindiana.org/handbook/community/squeak/index.html > > > > I'm deselecting the Tests-ObjectsAsMethods test (1 test), > > because it causes (reproducible) SIGSEGV on Solaris cc/OpenIndiana gcc. > > > > I think the segmentation fault is new in recent 4.19, I think it didn't happen > > a while ago in 4.16. > > > > I can test this as follows: when I install an older version > > > > squeak -version > > 4.16.7-3775 > > > > then I go into test runner: Tests-ObjectsAsMethods and select > > TestObjectsAsMethods that works in 4.16.7 > > > > Test Runner > > > > ... > > TestObjectsAsMethods > > > > 3 run, 3 passes, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes > > > > But it stopped working in 4.19.x which is from I believe from: > > > > ContextInterpreter VMMaker-dtl.422 uuid: e72b95a0-204e-45a1-a4e4-3ac3c9e7a51a > > > > the interp.c file is automatically generated from VMMaker-dtl.422. > > > > It's reproducible in the sense that if I deselect all tests, and just select > > that one single test, I can repeatedly and reproducible SIGSEGV the VM. > > > > When I run the VM under a debugger: > > > > dbx: warning: Bad transition in runtime linker interface. CONSISTENT->CONSISTENT > > t at 1 (l at 1) signal SEGV (no mapping at the fault address) in interpret at line 9120 in file "interp.c" > > 9120 foo->freeContexts = longAt((newContext + (BASE_HEADER_SIZE)) + (0 << (SHIFT_FOR_WORD))); > > > > (dbx) where > > current thread: t at 1 > > =>[1] interpret(), line 9120 in "interp.c" > > [2] main(argc = 1, argv = 0xfeffe250, envp = 0xfeffe258), line 1484 in "sqUnixMain.c" > > > > The above is from Solaris with cc/dbx but the same thing appears to happen > > for me on OpenIndiana with gcc/gdb. > > > > Unfortunately because the code of interp.c is automatically generated, > > it looks complicated to me and I don't see what's wrong with those " > > freeContext" code. > > > > The crash appears to be in: > > > > /* begin internalActivateNewMethod */ > > methodHeader = longAt((foo->newMethod + (BASE_HEADER_SIZE)) + (HeaderIndex << (SHIFT_FOR_WORD))); > > needsLarge = methodHeader & LargeContextBit; > > if ((needsLarge == 0) && (foo->freeContexts != NilContext)) { > > newContext = foo->freeContexts; > > /* begin setFreeContextsAfter: */ > > foo->freeContexts = longAt((newContext + (BASE_HEADER_SIZE)) + (0 << (SHIFT_FOR_WORD))); > > } else { > > /* begin externalizeIPandSP */ > > > > Has anyone seen this ? > > > > Also what is the test > > TestObjectsAsMethods > > actually doing please ? what is it testing ? > > > > > > Regards, > > David Stes > > > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v2 > > > > iQEcBAEBCAAGBQJgMnV5AAoJEAwpOKXMq1MafEgH/3EWQxaSaVm2g4r/2p99Wc21 > > P+U+ijqKpVTDfJ1smwV/GsgF0V8ZrZky0k7BzRDAyq3Gi/HGVm0e2bqOAKa1fo2Y > > MUS9JHOW4Lys+9qWgT0aLiWypjYlzThtYS0/Lfh013tsF1bBv2eppTceUyq/Zitv > > 6J0IFvDOspMN/zHwBw/ux3H6uR049boZ3mvk23sp3KIHDc2Yw2kF4TAXBwjZXmVO > > UFlIAC4EAahrtNZyLZSIBDbsXOl+wJGmQTsOIBG81pfSFpP6RBrIARcu6enZC3Wc > > bwsvWYADs49SKgVq3NBovfyzkZBIW30V82xlVKpOnp6A4FnOYXxQiVm9sNaOVXc= > > =34TJ > > -----END PGP SIGNATURE----- From stes at telenet.be Tue Feb 23 09:06:19 2021 From: stes at telenet.be (stes@PANDORA.BE) Date: Tue, 23 Feb 2021 10:06:19 +0100 (CET) Subject: [Vm-dev] regression: TestObjectsAsMethods crash in 4.19.5 (not in 4.16.7) In-Reply-To: <949389016.25753821.1613919758428.JavaMail.zimbra@telenet.be> References: <949389016.25753821.1613919758428.JavaMail.zimbra@telenet.be> Message-ID: <605876499.30501015.1614071179388.JavaMail.zimbra@telenet.be> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > Install primitiveArrayBecomeOneWayNoCopyHash as primitive 248 > replacing obsolete primitiveInvokeObjectAsMethod. That must be it, I guess. TestObjectsAsMethods used to work for me with the VM 4.16.7 Test Runner ... TestObjectsAsMethods 3 run, 3 passes, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes I have no idea whether the test can be simply removed, maybe if the test is obsoleted, the problem is solved! But that still leaves the issue of how to use the new VM with an *OLD* image! I must add that I'm not sure what TestObjectsAsMethods is doing, and whether there is any code out there that uses this functionality. Regards, David Stes -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJgNMTZAAoJEAwpOKXMq1Ma33QH/joLL1fRFiOiOWVowpB6ESX0 qeVlQvRm02HFk9+che3d3eirqqpp73Vucj4TQabgXsAfJ4GwYKWugNgReyMTJVeK M62Ue5+UkuiRBQUTxlw5wR3FPsI8OxDP0XBIiad0Qqk8uPjLWcx6uBGXR4NCNE0r D4Jy94o7L9g+b0zuGhJ711zfLCoicAIkipifCqCjneHzbZK8VXcY7kgdg62PaXcw JH7DN/glh8gkOyt8qWY+mt13BchEswIh/8m0LdIruviMJtQYUy27/zqadbcf3BFL 2bnkRlVQj+bDLfxhVhr4GAsZHYSrF1zFdNqrO9Xb1fTSj8IAMcDi2exISNsceCs= =Gqk7 -----END PGP SIGNATURE----- From noreply at github.com Wed Feb 24 02:55:15 2021 From: noreply at github.com (Eliot Miranda) Date: Tue, 23 Feb 2021 18:55:15 -0800 Subject: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] c53f3e: Mac builds: Message-ID: Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: c53f3e77564d1f5c128aa30a01fc601568bc3470 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/c53f3e77564d1f5c128aa30a01fc601568bc3470 Author: Eliot Miranda Date: 2021-02-23 (Tue, 23 Feb 2021) Changed paths: M build.macos32x86/common/Makefile.app M build.macos64ARMv8/common/Makefile.app M build.macos64x64/common/Makefile.app Log Message: ----------- Mac builds: To reliably codesign xattr must be used to remove finder info etc. Also sign the bundles in both ARMv8 and x86. [ci skip] From tim at rowledge.org Thu Feb 25 19:42:23 2021 From: tim at rowledge.org (tim Rowledge) Date: Thu, 25 Feb 2021 11:42:23 -0800 Subject: [Vm-dev] unix SqueakSource socket 'too many open files' problem Message-ID: <0E53D947-69DB-46D1-906F-E173B1FD3661@rowledge.org> I've been running a squeaksource system on a 64bit linux server for a year or so and just started having odd problems. Talking with Chris about it, and looking into the assorted logs, lead to the theory that sometihng (unknown and I can't see how possible) caused the image to save and quit at some point when the expected behaviour is to *not* ever save. That lead to some complaints about Magma related details that don't matter here. I had much fun (the usual linux user names/permissions stuff) but eventually got a new copy of the squeaksource image running. Yay! Except after an indeterminate time (several hours, not a whole day) the webpage part of the sytem became unaccessible even though it had not actually crashed out. The log contained a bunch of lines like this - 3729ab18e70dac 2021-02-24T23:37:53.41687-05:00 CurrentEnvironment: @40000000603729ab18e71d4c 2acceptHandler: Too many open files @4000000060379f1127814ddc acceptHandler: aborting server 12 pss=0x14df900 @4000000060379f112782dc4c socketStatus: freeing invalidated pss=0x14df900 @400000006037b1ef0d99c214 acceptHandler: Too many open files @400000006037b1ef0d9a5e54 acceptHandler: aborting server 12 pss=0x7f2f8c8d4630 @400000006037b1ef0d9c7194 socketStatus: freeing invalidated pss=0x7f2f8c8d4630 ... which are errors from the VM socket handlers. I've not seen this happening before that I recall. Any ideas? Stuff to check? Solutions? tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Strange OpCodes: TDB: Transfer and Drop Bits From lewis at mail.msen.com Thu Feb 25 21:12:02 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Thu, 25 Feb 2021 16:12:02 -0500 Subject: [Vm-dev] unix SqueakSource socket 'too many open files' problem In-Reply-To: <0E53D947-69DB-46D1-906F-E173B1FD3661@rowledge.org> References: <0E53D947-69DB-46D1-906F-E173B1FD3661@rowledge.org> Message-ID: <20210225211202.GA55616@shell.msen.com> Socket leaks were always a problem on the older squeaksource.com images, although I don't think it has been happening since I updated it to a Squeak 5.3 image, and I don't recall that it was ever a problem on source.squeak.org. I don't know what the root cause was, and it's certainly possible that socket leak issues still exist but are not showing up with the usage or load on our servers. If you are using image based persistence (as opposed to Magma back end), then the utility that I used to use for squeaksource.com is a handy workaround (actually it is still running on our squeaksource.com image, which is the reason I am not entirely sure if the socket leak problem is actually gone). Take a look in the http://www.squeaksource.com/SSImageInit repository and have a look at the socket leak monitor. Again to be clear, you don't want to run this with Magma, but in any case it may give you and idea for how to handle it. I do have to note that the error messages you are getting may be a different issue entirely. The socket leaks I was dealing with menifested as open file descriptors (visible in /proc//fd/*). The error messages you are getting may be another issue entirely. If you run out of file descriptors the image will hang, and if I recall correctly it may have crashed the VM. Possibly that would lead to the later symptoms you are seeing now. Dave On Thu, Feb 25, 2021 at 11:42:23AM -0800, tim Rowledge wrote: > > I've been running a squeaksource system on a 64bit linux server for a year or so and just started having odd problems. > > Talking with Chris about it, and looking into the assorted logs, lead to the theory that sometihng (unknown and I can't see how possible) caused the image to save and quit at some point when the expected behaviour is to *not* ever save. That lead to some complaints about Magma related details that don't matter here. > > I had much fun (the usual linux user names/permissions stuff) but eventually got a new copy of the squeaksource image running. Yay! > > Except after an indeterminate time (several hours, not a whole day) the webpage part of the sytem became unaccessible even though it had not actually crashed out. The log contained a bunch of lines like this - > 3729ab18e70dac 2021-02-24T23:37:53.41687-05:00 CurrentEnvironment: > @40000000603729ab18e71d4c 2acceptHandler: Too many open files > @4000000060379f1127814ddc acceptHandler: aborting server 12 pss=0x14df900 > @4000000060379f112782dc4c socketStatus: freeing invalidated pss=0x14df900 > @400000006037b1ef0d99c214 acceptHandler: Too many open files > @400000006037b1ef0d9a5e54 acceptHandler: aborting server 12 pss=0x7f2f8c8d4630 > @400000006037b1ef0d9c7194 socketStatus: freeing invalidated pss=0x7f2f8c8d4630 > > > ... which are errors from the VM socket handlers. > > I've not seen this happening before that I recall. Any ideas? Stuff to check? Solutions? > > tim > -- > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim > Strange OpCodes: TDB: Transfer and Drop Bits > > From tim at rowledge.org Thu Feb 25 21:47:16 2021 From: tim at rowledge.org (tim Rowledge) Date: Thu, 25 Feb 2021 13:47:16 -0800 Subject: [Vm-dev] unix SqueakSource socket 'too many open files' problem In-Reply-To: <20210225211202.GA55616@shell.msen.com> References: <0E53D947-69DB-46D1-906F-E173B1FD3661@rowledge.org> <20210225211202.GA55616@shell.msen.com> Message-ID: <237F031E-D0DC-4CAE-ADB9-1D3BF5A93CB0@rowledge.org> Thanks Dave - that's all rather scary sounding. It seems really weird that this has only just started and yet the system has been running happily for over a year. It's a 'PersonalSqueakSource' image built on a very late 5.2 /5.3 alpha image. Are there unix system settings for allowable numbers of sockets etc that might have been changed by a sysadmin? Anything like that? tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Strange OpCodes: STOP: No Op From lewis at mail.msen.com Thu Feb 25 23:17:14 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Thu, 25 Feb 2021 18:17:14 -0500 Subject: [Vm-dev] unix SqueakSource socket 'too many open files' problem In-Reply-To: <237F031E-D0DC-4CAE-ADB9-1D3BF5A93CB0@rowledge.org> References: <0E53D947-69DB-46D1-906F-E173B1FD3661@rowledge.org> <20210225211202.GA55616@shell.msen.com> <237F031E-D0DC-4CAE-ADB9-1D3BF5A93CB0@rowledge.org> Message-ID: <20210225231714.GA78767@shell.msen.com> On Thu, Feb 25, 2021 at 01:47:16PM -0800, tim Rowledge wrote: > > Thanks Dave - > that's all rather scary sounding. > Scary, no. But hard to debug? Yes. A file and/or socket handle leak just means that the image is failing to close connections properly, possibly because of some completely unrelated error that was not handled by closing the socket. > It seems really weird that this has only just started and yet the system has been running happily for over a year. It's a 'PersonalSqueakSource' image built on a very late 5.2 /5.3 alpha image. > > Are there unix system settings for allowable numbers of sockets etc that might have been changed by a sysadmin? Anything like that? > Yes I'm sure it's configurable, but it's highly unlikely that a sysadmin would bother to fool around with something like that. I think the default is 1000 open file descriptors (including sockets, pipes, files) per process, and that is way more than you need for a squeaksource server. Assuming you have access to the server, the best place to start is by looking in the directory /proc//fd/* (where is the process ID of the Squeak VM (you can find it with something like "$ ps -aef | grep squeak"). If you look at that once a day for a week, you will be able to see a growing number of file descriptors hanging around. Eventually it gets to be too many, and bad things happen. If you do /not/ see these file descriptors accumulating over time, then it would indicate some other kind of issue entirely. Good luck and keep us posted. Dave From tim at rowledge.org Fri Feb 26 04:04:27 2021 From: tim at rowledge.org (tim Rowledge) Date: Thu, 25 Feb 2021 20:04:27 -0800 Subject: [Vm-dev] unix SqueakSource socket 'too many open files' problem In-Reply-To: <20210225231714.GA78767@shell.msen.com> References: <0E53D947-69DB-46D1-906F-E173B1FD3661@rowledge.org> <20210225211202.GA55616@shell.msen.com> <237F031E-D0DC-4CAE-ADB9-1D3BF5A93CB0@rowledge.org> <20210225231714.GA78767@shell.msen.com> Message-ID: > On 2021-02-25, at 3:17 PM, David T. Lewis wrote: > > Assuming you have access to the server, the best place to start > is by looking in the directory /proc//fd/* (where is > the process ID of the Squeak VM (you can find it with something > like "$ ps -aef | grep squeak"). If you look at that once a day > for a week, you will be able to see a growing number of file > descriptors hanging around. Eventually it gets to be too many, > and bad things happen. After an hour or so there are 350 entries in that directory, virtually all sockets. I imagine somehow something has caused an issue that ... well, no idea. Pretty sure it isn't going to last for a week at this rate! I've found a backup copy of the image from before the problem so I think I'll probably install that and see if things improve. Maybe a new VM. Strange stuff. tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Fac me cocleario vomere! = Gag me with a spoon! From Das.Linux at gmx.de Fri Feb 26 07:40:17 2021 From: Das.Linux at gmx.de (Tobias Pape) Date: Fri, 26 Feb 2021 08:40:17 +0100 Subject: [Vm-dev] unix SqueakSource socket 'too many open files' problem In-Reply-To: References: <0E53D947-69DB-46D1-906F-E173B1FD3661@rowledge.org> <20210225211202.GA55616@shell.msen.com> <237F031E-D0DC-4CAE-ADB9-1D3BF5A93CB0@rowledge.org> <20210225231714.GA78767@shell.msen.com> Message-ID: > On 26. Feb 2021, at 05:04, tim Rowledge wrote: > > > > >> On 2021-02-25, at 3:17 PM, David T. Lewis wrote: >> >> Assuming you have access to the server, the best place to start >> is by looking in the directory /proc//fd/* (where is >> the process ID of the Squeak VM (you can find it with something >> like "$ ps -aef | grep squeak"). If you look at that once a day >> for a week, you will be able to see a growing number of file >> descriptors hanging around. Eventually it gets to be too many, >> and bad things happen. > > After an hour or so there are 350 entries in that directory, virtually all sockets. I imagine somehow something has caused an issue that ... well, no idea. Pretty sure it isn't going to last for a week at this rate! Maybe sockets the other end closed but we did not notice, so hang on to them. I'm quite sure I saw that not too few times when caring for Seaside on Squeak. There was often something strange with the sockets going on when the talking between browser and Seaside was already done but somehow the Squeak hang on to the socket… Best regards -Tobias > > I've found a backup copy of the image from before the problem so I think I'll probably install that and see if things improve. Maybe a new VM. Strange stuff. > > > tim From lewis at mail.msen.com Fri Feb 26 13:00:05 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Fri, 26 Feb 2021 08:00:05 -0500 Subject: [Vm-dev] unix SqueakSource socket 'too many open files' problem In-Reply-To: References: <0E53D947-69DB-46D1-906F-E173B1FD3661@rowledge.org> <20210225211202.GA55616@shell.msen.com> <237F031E-D0DC-4CAE-ADB9-1D3BF5A93CB0@rowledge.org> <20210225231714.GA78767@shell.msen.com> Message-ID: <20210226130005.GA8862@shell.msen.com> On Fri, Feb 26, 2021 at 08:40:17AM +0100, Tobias Pape wrote: > > > On 26. Feb 2021, at 05:04, tim Rowledge wrote: > > > >> On 2021-02-25, at 3:17 PM, David T. Lewis wrote: > >> > >> Assuming you have access to the server, the best place to start > >> is by looking in the directory /proc//fd/* (where is > >> the process ID of the Squeak VM (you can find it with something > >> like "$ ps -aef | grep squeak"). If you look at that once a day > >> for a week, you will be able to see a growing number of file > >> descriptors hanging around. Eventually it gets to be too many, > >> and bad things happen. > > > > After an hour or so there are 350 entries in that directory, virtually all sockets. I imagine somehow something has caused an issue that ... well, no idea. Pretty sure it isn't going to last for a week at this rate! > > Maybe sockets the other end closed but we did not notice, so hang on to them. > I'm quite sure I saw that not too few times when caring for Seaside on Squeak. > There was often something strange with the sockets going on when the talking > between browser and Seaside was already done but somehow the Squeak hang on to > the socket??? > It may be that the socket leak problem on squeaksource.com is "fixed" now simply because the it is so much faster now that it is running on 64-bit Spur, so timeouts and other errors simply do not happen any more. In other words, an underlying problem may still be there, but it rarely happens for squeaksource on the faster VM. The responsibility for closing the sockets is entirely on the Squeak side. Regardless of what the client does or does not do, the Squeak image must always close its socket in order to free the file descriptor. Tim, one other thing to look out for is the event handling in the VM. Since last October it now uses the Linux-specific epoll mechanism. If the problem you see now started happening after updating to a newer VM, then consider this as a possible suspect. Dave From tim at rowledge.org Fri Feb 26 20:04:26 2021 From: tim at rowledge.org (tim Rowledge) Date: Fri, 26 Feb 2021 12:04:26 -0800 Subject: [Vm-dev] unix SqueakSource socket 'too many open files' problem In-Reply-To: References: <0E53D947-69DB-46D1-906F-E173B1FD3661@rowledge.org> <20210225211202.GA55616@shell.msen.com> <237F031E-D0DC-4CAE-ADB9-1D3BF5A93CB0@rowledge.org> <20210225231714.GA78767@shell.msen.com> Message-ID: <41B85629-A9EF-48E7-807B-3EA8CDD6652B@rowledge.org> > On 2021-02-25, at 8:04 PM, tim Rowledge wrote: > > After an hour or so there are 350 entries in that directory, virtually all sockets. I imagine somehow something has caused an issue that ... well, no idea. Pretty sure it isn't going to last for a week at this rate! This morning there were 976 fds. So I restarted and watched and .. 18. It's sitting there all happy and as if, as we say in the UK, "butter wouldn't melt in its mouth". What, me? Cause problems? How can you be so cruel to a young server? Maybe a port scanning/attack of some sort flooded it? tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Oxymorons: Living dead From asqueaker at gmail.com Fri Feb 26 20:20:45 2021 From: asqueaker at gmail.com (Chris Muller) Date: Fri, 26 Feb 2021 14:20:45 -0600 Subject: [Vm-dev] unix SqueakSource socket 'too many open files' problem In-Reply-To: <41B85629-A9EF-48E7-807B-3EA8CDD6652B@rowledge.org> References: <0E53D947-69DB-46D1-906F-E173B1FD3661@rowledge.org> <20210225211202.GA55616@shell.msen.com> <237F031E-D0DC-4CAE-ADB9-1D3BF5A93CB0@rowledge.org> <20210225231714.GA78767@shell.msen.com> <41B85629-A9EF-48E7-807B-3EA8CDD6652B@rowledge.org> Message-ID: Still curious as to what VM you're using... On Fri, Feb 26, 2021 at 2:04 PM tim Rowledge wrote: > > > > > On 2021-02-25, at 8:04 PM, tim Rowledge wrote: > > > > After an hour or so there are 350 entries in that directory, virtually > all sockets. I imagine somehow something has caused an issue that ... well, > no idea. Pretty sure it isn't going to last for a week at this rate! > > This morning there were 976 fds. So I restarted and watched and .. 18. > It's sitting there all happy and as if, as we say in the UK, "butter > wouldn't melt in its mouth". What, me? Cause problems? How can you be so > cruel to a young server? > > Maybe a port scanning/attack of some sort flooded it? > > tim > -- > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim > Oxymorons: Living dead > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lewis at mail.msen.com Fri Feb 26 21:12:44 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Fri, 26 Feb 2021 16:12:44 -0500 Subject: [Vm-dev] unix SqueakSource socket 'too many open files' problem In-Reply-To: <41B85629-A9EF-48E7-807B-3EA8CDD6652B@rowledge.org> References: <0E53D947-69DB-46D1-906F-E173B1FD3661@rowledge.org> <20210225211202.GA55616@shell.msen.com> <237F031E-D0DC-4CAE-ADB9-1D3BF5A93CB0@rowledge.org> <20210225231714.GA78767@shell.msen.com> <41B85629-A9EF-48E7-807B-3EA8CDD6652B@rowledge.org> Message-ID: <20210226211244.GA85415@shell.msen.com> On Fri, Feb 26, 2021 at 12:04:26PM -0800, tim Rowledge wrote: > > > > > On 2021-02-25, at 8:04 PM, tim Rowledge wrote: > > > > After an hour or so there are 350 entries in that directory, virtually all sockets. I imagine somehow something has caused an issue that ... well, no idea. Pretty sure it isn't going to last for a week at this rate! > > This morning there were 976 fds. So I restarted and watched and .. 18. It's sitting there all happy and as if, as we say in the UK, "butter wouldn't melt in its mouth". What, me? Cause problems? How can you be so cruel to a young server? > > Maybe a port scanning/attack of some sort flooded it? > Keep an eye on it, you probably still have a socket leak. Here is what I saw on the squeaksource.com server a few minutes ago: squeaksourcecom at dan:~$ ls -l /proc/16147/fd total 0 lr-x------ 1 squeaksourcecom www-data 64 Feb 14 03:25 0 -> /dev/null l-wx------ 1 squeaksourcecom www-data 64 Feb 14 03:25 1 -> pipe:[11697] l-wx------ 1 squeaksourcecom www-data 64 Feb 14 03:25 2 -> pipe:[11697] lr-x------ 1 squeaksourcecom www-data 64 Feb 14 03:25 3 -> /srv/squeaksourcecom/SqueakSource/ss/Pharo lr-x------ 1 squeaksourcecom www-data 64 Feb 14 03:25 4 -> /srv/squeaksourcecom/SqueakSource/squeaksource.8.image lr-x------ 1 squeaksourcecom www-data 64 Feb 14 03:25 6 -> /srv/squeaksourcecom/SqueakSource/SqueakV50.sources lrwx------ 1 squeaksourcecom www-data 64 Feb 14 03:25 7 -> socket:[25825763] lrwx------ 1 squeaksourcecom www-data 64 Feb 14 03:25 8 -> socket:[25825764] lrwx------ 1 squeaksourcecom www-data 64 Feb 14 06:25 9 -> /srv/squeaksourcecom/SqueakSource/squeaksource.8.changes And then a few minutes later: squeaksourcecom at dan:~$ ls -l /proc/16147/fd total 0 lr-x------ 1 squeaksourcecom www-data 64 Feb 14 03:25 0 -> /dev/null l-wx------ 1 squeaksourcecom www-data 64 Feb 14 03:25 1 -> pipe:[11697] l-wx------ 1 squeaksourcecom www-data 64 Feb 14 03:25 2 -> pipe:[11697] lr-x------ 1 squeaksourcecom www-data 64 Feb 14 03:25 3 -> /srv/squeaksourcecom/SqueakSource/ss/metacello lr-x------ 1 squeaksourcecom www-data 64 Feb 14 03:25 4 -> /srv/squeaksourcecom/SqueakSource/squeaksource.8.image lr-x------ 1 squeaksourcecom www-data 64 Feb 14 03:25 6 -> /srv/squeaksourcecom/SqueakSource/SqueakV50.sources lrwx------ 1 squeaksourcecom www-data 64 Feb 14 03:25 7 -> socket:[25825763] lrwx------ 1 squeaksourcecom www-data 64 Feb 14 03:25 8 -> socket:[25825764] lrwx------ 1 squeaksourcecom www-data 64 Feb 14 06:25 9 -> /srv/squeaksourcecom/SqueakSource/squeaksource.8.changes If your server is not actively handling requests, you should see similar socket usage. You'll see more file descriptors when you are using Magma, but keep an eye on the socket entries, and they should not accumulate over time. Dave From johnmci at smalltalkconsulting.com Fri Feb 26 22:30:00 2021 From: johnmci at smalltalkconsulting.com (John M McIntosh) Date: Fri, 26 Feb 2021 22:30:00 +0000 Subject: [Vm-dev] unix SqueakSource socket 'too many open files' problem In-Reply-To: <20210226211244.GA85415@shell.msen.com> References: <0E53D947-69DB-46D1-906F-E173B1FD3661@rowledge.org> <20210225211202.GA55616@shell.msen.com> <237F031E-D0DC-4CAE-ADB9-1D3BF5A93CB0@rowledge.org> <20210225231714.GA78767@shell.msen.com> <41B85629-A9EF-48E7-807B-3EA8CDD6652B@rowledge.org> <20210226211244.GA85415@shell.msen.com> Message-ID: Historically it's up to finalization to cleanup a socket. Anyone confirmed that code is there and runs with this VM? .... John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, February 26, 2021 1:12 PM, David T. Lewis wrote: > > > On Fri, Feb 26, 2021 at 12:04:26PM -0800, tim Rowledge wrote: > > > > On 2021-02-25, at 8:04 PM, tim Rowledge tim at rowledge.org wrote: > > > After an hour or so there are 350 entries in that directory, virtually all sockets. I imagine somehow something has caused an issue that ... well, no idea. Pretty sure it isn't going to last for a week at this rate! > > > > This morning there were 976 fds. So I restarted and watched and .. 18. It's sitting there all happy and as if, as we say in the UK, "butter wouldn't melt in its mouth". What, me? Cause problems? How can you be so cruel to a young server? > > Maybe a port scanning/attack of some sort flooded it? > > Keep an eye on it, you probably still have a socket leak. > > Here is what I saw on the squeaksource.com server a few minutes ago: > > squeaksourcecom at dan:~$ ls -l /proc/16147/fd > total 0 > lr-x------ 1 squeaksourcecom www-data 64 Feb 14 03:25 0 -> /dev/null > l-wx------ 1 squeaksourcecom www-data 64 Feb 14 03:25 1 -> pipe:[11697] > l-wx------ 1 squeaksourcecom www-data 64 Feb 14 03:25 2 -> pipe:[11697] > lr-x------ 1 squeaksourcecom www-data 64 Feb 14 03:25 3 -> /srv/squeaksourcecom/SqueakSource/ss/Pharo > lr-x------ 1 squeaksourcecom www-data 64 Feb 14 03:25 4 -> /srv/squeaksourcecom/SqueakSource/squeaksource.8.image > lr-x------ 1 squeaksourcecom www-data 64 Feb 14 03:25 6 -> /srv/squeaksourcecom/SqueakSource/SqueakV50.sources > lrwx------ 1 squeaksourcecom www-data 64 Feb 14 03:25 7 -> socket:[25825763] > lrwx------ 1 squeaksourcecom www-data 64 Feb 14 03:25 8 -> socket:[25825764] > lrwx------ 1 squeaksourcecom www-data 64 Feb 14 06:25 9 -> /srv/squeaksourcecom/SqueakSource/squeaksource.8.changes > > And then a few minutes later: > > squeaksourcecom at dan:~$ ls -l /proc/16147/fd > total 0 > lr-x------ 1 squeaksourcecom www-data 64 Feb 14 03:25 0 -> /dev/null > l-wx------ 1 squeaksourcecom www-data 64 Feb 14 03:25 1 -> pipe:[11697] > l-wx------ 1 squeaksourcecom www-data 64 Feb 14 03:25 2 -> pipe:[11697] > lr-x------ 1 squeaksourcecom www-data 64 Feb 14 03:25 3 -> /srv/squeaksourcecom/SqueakSource/ss/metacello > lr-x------ 1 squeaksourcecom www-data 64 Feb 14 03:25 4 -> /srv/squeaksourcecom/SqueakSource/squeaksource.8.image > lr-x------ 1 squeaksourcecom www-data 64 Feb 14 03:25 6 -> /srv/squeaksourcecom/SqueakSource/SqueakV50.sources > lrwx------ 1 squeaksourcecom www-data 64 Feb 14 03:25 7 -> socket:[25825763] > lrwx------ 1 squeaksourcecom www-data 64 Feb 14 03:25 8 -> socket:[25825764] > lrwx------ 1 squeaksourcecom www-data 64 Feb 14 06:25 9 -> /srv/squeaksourcecom/SqueakSource/squeaksource.8.changes > > If your server is not actively handling requests, you should see similar > socket usage. You'll see more file descriptors when you are using Magma, > but keep an eye on the socket entries, and they should not accumulate > over time. > > Dave From tim at rowledge.org Fri Feb 26 23:11:03 2021 From: tim at rowledge.org (tim Rowledge) Date: Fri, 26 Feb 2021 15:11:03 -0800 Subject: [Vm-dev] unix SqueakSource socket 'too many open files' problem In-Reply-To: References: <0E53D947-69DB-46D1-906F-E173B1FD3661@rowledge.org> <20210225211202.GA55616@shell.msen.com> <237F031E-D0DC-4CAE-ADB9-1D3BF5A93CB0@rowledge.org> <20210225231714.GA78767@shell.msen.com> <41B85629-A9EF-48E7-807B-3EA8CDD6652B@rowledge.org> Message-ID: <35E3C889-2805-4A7A-B260-CACDF494E748@rowledge.org> Didn't I mention that before? - the vm I can only identify as 5.0-201807260206 from the lib/squeak directory name. Levente thinks that's the default one for the original 5.3 alpha package that is almost certainly what I downloaded to build this system 18 months ago. Sounds plausible to me. If I have to restart anytime soon I'll try the latest VM and see if it makes any difference. So far today nothing is going wrong though; it has crept up to 20 fds open - 4 sockets right now. > On 2021-02-26, at 12:20 PM, Chris Muller wrote: > > Still curious as to what VM you're using... > > On Fri, Feb 26, 2021 at 2:04 PM tim Rowledge wrote: > > > > > On 2021-02-25, at 8:04 PM, tim Rowledge wrote: > > > > After an hour or so there are 350 entries in that directory, virtually all sockets. I imagine somehow something has caused an issue that ... well, no idea. Pretty sure it isn't going to last for a week at this rate! > > This morning there were 976 fds. So I restarted and watched and .. 18. It's sitting there all happy and as if, as we say in the UK, "butter wouldn't melt in its mouth". What, me? Cause problems? How can you be so cruel to a young server? > > Maybe a port scanning/attack of some sort flooded it? > > tim > -- > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim > Oxymorons: Living dead > > tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Calm down -- it's only ones and zeros. From kksubbu.ml at gmail.com Sat Feb 27 06:32:39 2021 From: kksubbu.ml at gmail.com (K K Subbu) Date: Sat, 27 Feb 2021 12:02:39 +0530 Subject: [Vm-dev] unix SqueakSource socket 'too many open files' problem In-Reply-To: <20210226211244.GA85415@shell.msen.com> References: <0E53D947-69DB-46D1-906F-E173B1FD3661@rowledge.org> <20210225211202.GA55616@shell.msen.com> <237F031E-D0DC-4CAE-ADB9-1D3BF5A93CB0@rowledge.org> <20210225231714.GA78767@shell.msen.com> <41B85629-A9EF-48E7-807B-3EA8CDD6652B@rowledge.org> <20210226211244.GA85415@shell.msen.com> Message-ID: <1afb3b3d-82b7-413e-5f5c-2fa155cbc3b9@gmail.com> On 27/02/21 2:42 am, David T. Lewis wrote: > Here is what I saw on the squeaksource.com server a few minutes ago: > > squeaksourcecom at dan:~$ ls -l /proc/16147/fd The socket count can be generated directly with: $ ls -l /proc/$(pgrep squeak)/fd | grep -c socket: This can then be visually graphed every, say, 3600s with: bars='======================================================+'; while true; do echo $bars | cut -c 1-$(ls -l /proc/$(pgrep squeak)/fd | grep -c socket:) sleep 3600 done If this shows a monotonic growth, then a leak can be suspected. HTH .. Subbu