As Estaban said: wow, a new world opens. Amazing.
Phil On Thu, Nov 24, 2016 at 8:24 AM, Esteban Lorenzano <[email protected]> wrote: > Hi Ronie, > > First, this is super cool! I want this to happen since a lot of time :) > Second, observation below > > On 24 Nov 2016, at 08:12, Ronie Salgado <[email protected]> wrote: > > 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. > > > you cannot unilaterally do this. > I hate autoconf too, but in VM list we have a general agreement on how to > manage the VM build process, and unless you manage to convince the rest of > people working there (and specially Eliot, who works there more than the > rest), you have literally zero chance this will be adopted (and then, your > work will be a general lose of time…). > In any case, you have my vote :) > > - 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. > > > this is sooo super :) > > > 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. > > > even more super :) > > where can I see the code? > > Esteban > > > 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 > > >
