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.back@highoctane.be <philippe.back@gmail.com>:

Need help with the VM cleaning?

Le��24 nov. 2016 08:13, "Ronie Salgado" <roniesalg@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/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