[Vm-dev] [Pharo-dev] Removing most of the windowing code

Sun Nov 27 21:44:23 UTC 2016

Hi Phil,

It is on the MinimalisticHeadless branch of (
https://github.com/ronsaldo/opensmalltalk-vm/tree/MinimalisticHeadless ).

With VS you are going to receive a lot of messages such as:

> GIV(remapBufferCount) == 0 55758
>
These are false positives due to the macro expansion bug.

> Nice to give me an excuse to get an XBox One for XMas in order to try
> Pharo on it.
>
For me it is also an excuse for XMas ;) .

Best regards,
Ronie

2016-11-27 18:01 GMT-03:00 phil at highoctane.be <phil at highoctane.be>:

>
> Ronie,
>
> Is all of this in a branch somewhere so that I can have a look?
>
> For cairo, I think that I can build it with another compiler than MinGW,
> it doesn't really matter as it just makes a dll (or well, I can just skip
> that and reuse an already built one).
>
> -ltro is the flag that makes the whole thing trips up in GCC5 and requires
> additional flags, but adding them just kicked the can down the road a bit
> further as they were still unresolved symbols. Need to see why cairo build
> gives that but seems a cairo issue that others are facing as well. May end
> up building cairo with the old compiler but this defeats the purpose.
>
> For VS2015, I've got it too and yes, the debugging facilities are much
> better, not to mention that the compilation times are much nicer. GCC is
> just dog slow on Windows compared to Linux. I read that it was because of
> sub-bar fork support in Windows.
>
> Nice to give me an excuse to get an XBox One for XMas in order to try
> Pharo on it.
>
> Best,
> Phil
>
>
>
> On Sat, Nov 26, 2016 at 11:16 PM, Ronie Salgado <roniesalg at gmail.com>
> wrote:
>
>> Hi,
>>
>> 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.
>>>
>> Now I am building in Windows using both, MinGW version 4.9.3, and Visual
>> Studio 2015 Community Edition.
>>
>> I got working pharo,exe -headless Pharo-minimal.image eval "1+1" (the
>> -headless parameter is for the image to quit after finishing).
>> When running a normal Pharo.image, I am getting a FFI related crash (with
>> Visual Studio and MinGW), when the image tries to read the APPDATA
>> environment variable.
>>
>> Right now I am using the same main function for both, the Unix and Win32
>> VM. This means, that we are close of having the embedded version.
>>
>> In windows I am build two variants of the VM, pharo.exe (or squeak.exe)
>> and pharow.exe (or squeakw.exe). The executable without the w is a console
>> program, so it can use stdin, stdout and stderr. The executable with the w
>> is a windows program that does not create a console window on startup, but
>> it cannot use stdout, stderr, or stdin. This is the standard workaround for
>> an annoying limitation of Windows itself (Python does the same in windows,
>> with the same nomenclature).
>>
>> Visual Studio is unstable than MinGW, but it has an excellent debugger.
>> With Visual Studio, I am getting some false positives for an assertion
>> because they get miscompiled. For some reason, the
>> assert(GIV(remapBufferCount) == 0) gets compiled into the same as
>> assert(GIV(remapBufferCount)). Apart from this assertion, these two
>> versions of the VM are crashing in the same place.
>>
>>
>>> Fantastic, except:
>>>
>>>
>>> - Unified standard CMake building scripts for Unixes. I hate autoconf. I
>>> want to use them in Windows too.
>>>
>>>
>>> We have agreed that we will use makefiles and restrict make to
>>> generating platform config.h files that define platform facilities.  I have
>>> very good reasons for doing this.  I have discussed this at length this
>>> year.  Please don't make me argue this all over again.
>>> ...
>>> [goodness deleted]
>>>
>> I cannot just use makefile, because I am also compiling in Windows using
>> Visual Studio 2015 Community Edition, by generating the visual studio
>> projects with CMake. I looked for the older discussions on the mailing
>> lists, I could not find, a long discussion on the mailing list, except for
>> several short ones.
>> I have also seen some projects(LLVM, Boost) that have more than one build
>> system, an official based on autoconf(or something else), and an
>> alternative based on CMake.
>>
>> As for the config.h, I can also generate it using CMake, and I will start
>> doing it now because I think that it is related to the FFI crashing issues
>> that I am experimenting on Windows. Currently I am already using CMake for
>> generating the git version string. As long as git is in the path and cmake
>> founds it, the header with the version string is generated correctly, even
>> when using the Visual Studio projects.
>>
>> Anyway, I am not using the old CMakeVMMaker that Igor did(and I just
>> learned about Ian CMake work by finding in the mailing list). I just
>> adapted the plain CMake scripts that I normally use for building my own
>> projects to build the VM.
>>
>>   Are you on board?  Would you like to discuss this on skype or somewhere?
>>
>> Sure we can discuss it, I am on chile so we are not far apart in time
>> zones.
>>
>> As long as building the VM can be done automatically in Unixes by running
>> a short number of commands, that work most of the time, I am OK with it.
>> As for Windows, it has to be possible to use Visual Studio in addition to
>> MinGW or Cygwin. Visual Studio is required to be able to build for the
>> Universal Windows Platform, and getting the VM working in a retail XBox One
>> ( https://msdn.microsoft.com/en-us/windows/uwp/xbox-apps/index ).
>>
>> Best regards,
>> Ronie
>>
>> 2016-11-26 14:09 GMT-03:00 Eliot Miranda <eliot.miranda at gmail.com>:
>>
>>>
>>> Hi Roni,
>>>
>>>
>>> On Nov 23, 2016, at 11:12 PM, Ronie Salgado <roniesalg at gmail.com> 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/op
>>> ensmalltalk-vm I made the following changes:
>>>
>>>
>>> Fantastic, except:
>>>
>>>
>>> - Unified standard CMake building scripts for Unixes. I hate autoconf. I
>>> want to use them in Windows too.
>>>
>>>
>>> We have agreed that we will use makefiles and restrict make to
>>> generating platform config.h files that define platform facilities.  I have
>>> very good reasons for doing this.  I have discussed this at length this
>>> year.  Please don't make me argue this all over again.  Are you on board?
>>> Would you like to discuss this on skype or somewhere?
>>> ...
>>> [goodness deleted]
>>>
>>> Does it make sense, to always trying to create a display in startup time?
>>>
>>>
>>> Good question.  The answer should be "no" but that only makes sense if
>>> the system is written to not depend on a display when in headless mode.
>>>
>>>
>>> Best regards,
>>> Ronie
>>>
>>>
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20161127/1682a2e0/attachment-0001.html>