Hi, For a job I have to adapt old Squeak code (B3DAcceleratorPlugin) to newer graphics APIs (Metal and D3D11). The VM window has to use the same rendering interface as the plugin for rendering. Recently for trying to solve the issue with the older machines I implemented support selecting the older renderers with a command line option, and I added code for trying to detect whether the current Metal implementation is valid, or not. These command line options are the followings (can be obtained by using -help):
-metal Use metal if the Metal detection code works. -opengl Use OpenGL. The previous default. -core-graphics Use the older CoreGraphics based backend. -headless Null without rendering This command line option has to be the first command line option passed to the VM program. This is because the normal command line parsing is done after creating the VM window. As a workaround I am parsing the command line option on the main() function as the first command line argument. On my Mac machine I have Mojave installed. If someone could give pointers on how to setup a VM with the older version, or a way to emulate the older version I could be able to debug the problem. Perhaps as a workaround, for Pharo we should disable the Metal support (Remove the -DUSE_METAL from the makefile), and maybe go for the CoreGraphics backend, which seems to be better tested and I think does not give conflict problems when trying to use OpenGL from the image side. In Pharo we do not use the B3DAcceleratorPlugin, which in my opinion is a complete mess. Best regards, Ronie El mar., 2 abr. 2019 a las 10:58, Guillermo Polito (< [email protected]>) escribió: > > > On Tue, Apr 2, 2019 at 2:11 PM ducasse <[email protected]> wrote: > >> Thanks guille and pablo for you dedication for Pharo, I love you :) >> >> Now just that I understand, does it mean that the latest open smalltalk >> vm does not run on anything else that Mojave and High Sierra? >> > > I don't know exactly on what versions it is not working because I have > Windows10 and Mojave. > But I know that it's not working for Pablo on OSX Sierra (which dates from > 2016...). > > AFAIU, Ronie has updated the VM's code to render on Metal, which made that > at some point the VM was not compiling for latest versions of OSX. > In these last weeks Ronie has also updated the code to make it compile in > older machines, but still in those versions that not support Metal the main > window just renders a black screen. > > I don't know what are the following steps regarding this, I put Ronie in > cc, he may clarify a bit the situation. > In the meanwhile, using the build I say in the email above may suffice us > all I think ^^. > > >> >> Stef (back writing research proposal…..) >> >> On 2 Apr 2019, at 13:40, Guillermo Polito <[email protected]> >> wrote: >> >> Hi all, Esteban, >> >> In the last sprint with Pablo and Pierre we have detected several >> misbehaviours with files. >> The issue was particular reproducible when trying to run iceberg tests: >> the VM kind of ran out of slots for opening files. The strangest thing is >> that the leaks seemed to happen when deleting directories, so we had a look >> at the changes done to iterate directories, get file attributes and so on. >> >> While on the FileReference code everything seemed ok, we have observerd >> with `lsof` that still several directories remained open even after >> deleting them. >> >> Latest VM fixes this issue but contains another one related to Metal >> rendering, which prevents rendering in OSX versions < than High Sierra. >> >> Tracking the issue a bit, this seems to be a bug in the FileAttributes >> plugin that was fixed by this PR by alistair ( >> https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/a838346b1a67712cc28298534dafbd0c26ea34fb >> ). >> >> We have tested that particular commit ( >> a838346b1a67712cc28298534dafbd0c26ea34fb >> <https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/a838346b1a67712cc28298534dafbd0c26ea34fb>) >> and this one contains Alistair's fixes but not yet the new rendering using >> Metal. We have been testing that VM since yesterday and it seems stable, >> what do you think about marking it stable for Pharo8? >> >> Regarding Pharo7, Pharo7's stable VM is the same as Pharo8's, so it >> contains the same issue. However, since on the image side the code does not >> use the problematic primitives, we do not think we need to change the VM >> for Pharo7 (yet). However, there is seemingly a fix for directories >> containing blanks, maybe Alistair can give us some input here? :) >> >> Ideas? >> >> Thanks, >> Guille and Pablo >> >> >> > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 >
