Vm-dev June 2020

vm-dev@lists.squeakfoundation.org

23 participants
106 discussions

Errored: OpenSmalltalk/opensmalltalk-vm#2085 (Cog - 7a6fcd0)
by Travis CI 12 Jun '20

12 Jun '20

Build Update for OpenSmalltalk/opensmalltalk-vm ------------------------------------- Build: #2085 Status: Errored Duration: 20 mins and 5 secs Commit: 7a6fcd0 (Cog) Author: Eliot Miranda Message: MSVC x64 makefiles. Remove a trailing backslash from the SDK dir. Provide for a variable to pass flags down to sub makes for testing. View the changeset: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/e4f17ad30945...7a… View the full build log and details: https://travis-ci.org/github/OpenSmalltalk/opensmalltalk-vm/builds/69740562… -- You can unsubscribe from build emails from the OpenSmalltalk/opensmalltalk-vm repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=8795279&ut…. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notificati…. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.

1 0

[OpenSmalltalk/opensmalltalk-vm] 7a6fcd: MSVC x64 makefiles.
by Eliot Miranda 11 Jun '20

11 Jun '20

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 7a6fcd00dea63bdbc2e602245f54d6e50b132734 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/7a6fcd00dea63bdbc2… Author: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2020-06-11 (Thu, 11 Jun 2020) Changed paths: M build.win64x64/common/Makefile.msvc M build.win64x64/common/Makefile.msvc.flags Log Message: ----------- MSVC x64 makefiles. Remove a trailing backslash from the SDK dir. Provide for a variable to pass flags down to sub makes for testing.

1 0

Re: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] Change sk_GENERAL_NAME_freefunc void* to GENERAL_NAME* (dcdd632)
by Tobias Pape 11 Jun '20

11 Jun '20

@cstes Can you have a look at the defined `OPENSSL_VERSION_NUMBER`? The definition to `void*` is necessary in earlier versions of OpenSSL, only later versions have the stacks typed. -- 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/dcdd632efcb63e2d55…

1 0

Re: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] Change sk_GENERAL_NAME_freefunc void* to GENERAL_NAME* (dcdd632)
by Tobias Pape 11 Jun '20

11 Jun '20

Why? I don't think that the freefunc is declared as such in the old openssl version. -- 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/dcdd632efcb63e2d55…

1 0

64 bit FFI (was: porting Croquet to Squeak6.0 alpha...)
by Bert Freudenberg 09 Jun '20

09 Jun '20

I'd suggest to get OpenGL working outside of Croquet first: http://www.squeaksource.com/CroquetGL.html Step 1: Verify this works in 32 bits. (assuming you are doing this on Linux, you can run 32 bit Squeak side-by-side with the 64 bit one) Step 2: Make it work in 64 bits. The second step requires that you understand how FFI works, and how it handles e.g. pointers and integer sizes. I am assuming we do have a working 64 bit FFI, at least for x86_64 machines. E.g. the OGLUnix>>glExtGetProcAddress: method returns a pointer. On a 32 bit system, that fits into a 'ulong' which is 32 bits. On a 64 bit system, a pointer is 64 bits wide so it would not fit into a 32 bit word. Now I don't know how many bits 'ulong' has in our 64 bit FFI, but that declaration may have to change. Etc. pp. If you have questions about FFI then those are best directed at the vm-dev list since it is dealing with VM-level interfaces. CC'ing, please follow up there. - Bert - On Wed, Mar 11, 2020 at 2:54 PM gettimothy via Squeak-dev < squeak-dev(a)lists.squeakfoundation.org> wrote: > Okey dokey, > > Poking along, there is a stray glyph in OGLUnix openGLLibraryName after > > openGLLibraryName > ^Smalltalk osVersion = 'linux' > ifTrue: ['libGL.so.1'] > ifFalse: ['GL'] > > I removed it in my install and got past that error. > > Working exclusively with Croquet(Master)... > > > > My next error is in OGLUnixX11LE(OpenGL)>>glMatrixMode: > > glMatrixMode: mode > "This method was automatically generated." > "void glMatrixMode(GLenum mode);" > <apicall: void 'glMatrixMode' (ulong) module: '#openGLLibraryName'> > ^self externalCallFailed > > The <apicall:...> fails > > How to think about this? > > Is Croquet behind OpenGL latest? > Would teaching myself OpenGL programming be of use to the Croquet project? > > cheers, > > tty > > >

7 13

Build completed: opensmalltalk-vm 1.0.2081
by AppVeyor 09 Jun '20

09 Jun '20

1 0

Is squeak.cog.spur_linux64x64_202006010135.tar.gz solid?
by David T. Lewis 05 Jun '20

05 Jun '20

Following links from squeak.org to latest VMs, I grabbed squeak.cog.spur_linux64x64_202006010135.tar.gz. I want to use this for running the squeaksource.com server image. Is there any reason that I should *not* use this VM? I am assuming that it is solid but just want to check. The reason for my question is that I tried deploying an updated image/VM today. I was using squeak.cog.spur_linux64x64_202003021730.tar.gz`(from the "stable" link on squeak.org) and ran into the problem that Tobias fixed here: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/491 So I want to use a never VM to avoid the problem. Just checking, thanks. Dave

1 0

[OpenSmalltalk/opensmalltalk-vm] POWER (ppc64le) port. (#493)
by kgardas 03 Jun '20

03 Jun '20

It would be great if there is also ppc64le/power platform supported. -- 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/493

9 27

[OpenSmalltalk/opensmalltalk-vm] ᴀᴍᴅ⁶⁴ (long mode) : align branches within 32-Byte boundary (fix erratum skx102). (#506)
by ytrezq 03 Jun '20

03 Jun '20

https://www.intel.com/content/www/us/en/processors/xeon/scalable/xeon-scala… > The Decoded ICache caches decoded instructions, called micro‑ops (μops), coming out of the legacy decode pipeline. The next time the processor accesses the same code, the Decoded ICache provides the μops directly, speeding up program execution. In some Intel® Processors, there’s an erratum (sk102) that may occur under complex microarchitectural conditions involving jump instructions that span across 64‑byte boundaries (cross cache lines). Though not sure about other modes like protected mode which would means that if the ᴊɪᴛ is running on bare metal 32 bits ᴏꜱ (not in a ᴠᴍ) that the program would remain unaffected. The aim is to mend the performance penalty on fixed ᴄᴘᴜs as well as prevent computers not running Linux that didn’t received a manufacturer’s ʙɪᴏꜱ update from crashing. In that way, the ɢɴᴜ’s binutils are already patched. Other projects [not related to smatalk are applying patches too](https://github.com/dolphin-emu/dolphin/pull/8475/files). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/506

1 0

Cog on ARM
by Boris Shingarov 02 Jun '20

02 Jun '20

To build the latest Cog VM with the ARM simulation plugins doesn't seem to work for me. I thought maybe I had dirty state, so I started from a clean clone (this is the current tip of the Cog branch, 60973ef): $ git clone git@github.com:OpenSmalltalk/opensmalltalk-vm.git $ cd opensmalltalk-vm $ cd build.linux64x64/gdbarm32 $ ./conf.COG checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking target system type... arm-unknown-linux-gnu checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out ... checking for working strncmp... yes configure: creating ./config.status config.status: creating Makefile config.status: error: cannot find input file: `testsuite/Makefile.in' $ _ Is this the supposed way? Has anyone built ARM recently? I build a fair amount of ARM code somewhat regularly on this machine, therefore I doubt this is some basic dysfunctionality of my dev environment. My first reflex was to go and just hack into the problem, but if it doesn't even go this far out of the box, then I'd expect I am somehow wrong and I thought I'd ask before digging myself too deep into the wrong direction. Also I've been having doubts, if these configure scripts were broken, people would be complaining? does anyone do ARM? (and by that I mean "develop the VM" for which you need the simulator) Why isn't CI complaining? does CI only cover Intel? does CI only cover production-packaging?

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev June 2020