> > 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 [email protected] < [email protected]>: > Need help with the VM cleaning? > > Le 24 nov. 2016 08:13, "Ronie Salgado" <[email protected]> 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/opensmalltalk-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 >> >
