<div dir="ltr">+10000000000000000000000000000000<br><br>amen to that.<br><br>especially this:<br>><span style="font-size:12.8px">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.</span><br style="font-size:12.8px"><br>This is a holy grail!!!<br>Go, Ronie, Go!!!<br><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 24 November 2016 at 09:24, Esteban Lorenzano <span dir="ltr"><<a href="mailto:estebanlm@gmail.com" target="_blank">estebanlm@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><div style="word-wrap:break-word">Hi Ronie, <div><br></div><div>First, this is super cool! I want this to happen since a lot of time :)</div><div>Second, observation below </div><div><br><div><blockquote type="cite"><div>On 24 Nov 2016, at 08:12, Ronie Salgado <<a href="mailto:roniesalg@gmail.com" target="_blank">roniesalg@gmail.com</a>> wrote:</div><br class="m_1143405779556643042Apple-interchange-newline"><div><div dir="ltr"><div><div><div><div><div><div><div><div>Hello,<br><br></div>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 <a href="https://github.com/ronsaldo/opensmalltalk-vm" target="_blank">https://github.com/ronsaldo/<wbr>opensmalltalk-vm</a> I made the following changes:<br><br></div>- Unified standard CMake building scripts for Unixes. I hate autoconf. I want to use them in Windows too.<br></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>you cannot unilaterally do this. </div><div>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…). </div><div>In any case, you have my vote :)</div><br><blockquote type="cite"><div><div dir="ltr"><div><div><div><div><div>- Refactoring the Unix entry points. I am trying to remove a lot of code for simplfying stuff.<br></div>- Null window driver for true headless.<br></div>- Optional SDL2 based traditional display backend for compatibility reasons, and because the extra Morphic worlds using OSWindow are a bit unstable.<br></div><br></div>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.<br></div></div></div></blockquote><div><br></div><div>this is sooo super :)</div><br><blockquote type="cite"><div><div dir="ltr"><div><br>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.<br></div></div></div></blockquote><div><br></div><div>even more super :)</div><div><br></div><div>where can I see the code?</div><div><br></div><div>Esteban</div><br><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>BTW. When I tried the minimalistic Pharo image, in a completely headless VM, I got the following error:<br><br>[ "Ugh .... now this is a biggie - a system that does not support<br> any of the display depths at all."<br>Smalltalk<br> logError:<br> 'Fatal error: This system has no support for any display depth at all.'<br> inContext: thisContext.<br>Smalltalk quitPrimitive "There is no way to continue from here" ] in DisplayScreen>><wbr>findAnyDisplayDepth<br>DisplayScreen>><wbr>findAnyDisplayDepthIfNone:<br>DisplayScreen>><wbr>findAnyDisplayDepth<br>DisplayScreen>>setExtent:<wbr>depth:<br>DisplayScreen class>>startUp<br><br></div><div>As a workaround, I am doing the following for ioHasDisplayDepth with the null driver:<br><br>sqInt ioHasDisplayDepth(sqInt depth)<br>{<br> return true;<br>}<br><br></div><div>In DisplayScreen class >> startUp we have the following:<br>startUp "DisplayScreen startUp"<br> Display setExtent: self actualScreenSize depth: Display nativeDepth.<br> Display beDisplay<br></div><div><br></div><div>Does it make sense, to always trying to create a display in startup time?<br><br></div><div>Best regards,<br></div><div>Ronie<br></div></div>
</div></blockquote></div><br></div></div><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Best regards,<br>Igor Stasenko.</div>
</div>