I am fighting Window VM compilation issues (e.g. Cairo with GCC5.x under Mingw). If you have a GCC5 instead of the old 4.6, I am interested in your config.
It is great that you are giving a solid kick in this. Do not get burned out. Peace. Phil On Thu, Nov 24, 2016 at 11:48 PM, Ronie Salgado <ronies...@gmail.com> wrote: > Need help with the VM cleaning? >> > Not for now. Now I will try to make this working on Windows. Once I manage > to isolate the most of the stubbed dependencies on Window(heartbeat, time, > asynchronous I/O), we will have a more unified core VM in a single static > library. When we have this unified VM, I will need help for testing, and > defining a definitive build system where the community also agrees. For now > I will just keep working on my private branch. > > 2016-11-24 17:29 GMT-03:00 philippe.b...@highoctane.be < > philippe.b...@gmail.com>: > >> Need help with the VM cleaning? >> >> Le 24 nov. 2016 08:13, "Ronie Salgado" <ronies...@gmail.com> a écrit : >> >>> Hello, >>> >>> I am working on removing most of windowing code from the VM, and in >>> trying to unify the platform specific code of the VM. In the >>> MinimalistHeadless branch of https://github.com/ronsaldo/op >>> ensmalltalk-vm I made the following changes: >>> >>> - Unified standard CMake building scripts for Unixes. I hate autoconf. I >>> want to use them in Windows too. >>> - Refactoring the Unix entry points. I am trying to remove a lot of code >>> for simplfying stuff. >>> - Null window driver for true headless. >>> - Optional SDL2 based traditional display backend for compatibility >>> reasons, and because the extra Morphic worlds using OSWindow are a bit >>> unstable. >>> >>> So far I managed to run a standard Pharo 6 image using this custom VM in >>> Linux. Windows and Mac are coming next. Hopefully this is going to fix the >>> problems with duplicated events when using OSWindow in Windows. >>> >>> I am also planning on making a standard interface for embedding the VM >>> in an application, at least as a static library. With this new building >>> system, this seems to be easy to do. >>> >>> BTW. When I tried the minimalistic Pharo image, in a completely headless >>> VM, I got the following error: >>> >>> [ "Ugh .... now this is a biggie - a system that does not support >>> any of the display depths at all." >>> Smalltalk >>> logError: >>> 'Fatal error: This system has no support for any display depth >>> at all.' >>> inContext: thisContext. >>> Smalltalk quitPrimitive "There is no way to continue from here" ] in >>> DisplayScreen>>findAnyDisplayDepth >>> DisplayScreen>>findAnyDisplayDepthIfNone: >>> DisplayScreen>>findAnyDisplayDepth >>> DisplayScreen>>setExtent:depth: >>> DisplayScreen class>>startUp >>> >>> As a workaround, I am doing the following for ioHasDisplayDepth with the >>> null driver: >>> >>> sqInt ioHasDisplayDepth(sqInt depth) >>> { >>> return true; >>> } >>> >>> In DisplayScreen class >> startUp we have the following: >>> startUp "DisplayScreen startUp" >>> Display setExtent: self actualScreenSize depth: Display nativeDepth. >>> Display beDisplay >>> >>> Does it make sense, to always trying to create a display in startup time? >>> >>> Best regards, >>> Ronie >>> >> >
