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

[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/opensmalltalk-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/1d0f296a/attachment.html>