Guys - do keep pushing on this - I think its quite important in this world of serverless… it shows we are very relevant. +10
> On 7 Aug 2018, at 13:36, Esteban Lorenzano <esteba...@gmail.com> wrote: > > I’m slowly working on that VM because we want it to be the default for Pharo > 8. > In our vision, it should be a responsibility of the image to start or not a > graphical UI, so we are preparing (we have been preparing to it for years, > actually) to achieve this behaviour. > To make this work, we need all platforms covered (and another huge quantity > of changes here and there). > Anyway, I didn’t merge because I wanted to have win64 covered, not just what > we have now, and since no-one was using that VM I didn’t feel pression to do > it :) > > Cheers, > Esteban > > >> On 7 Aug 2018, at 08:50, Norbert Hartl <norb...@hartl.name >> <mailto:norb...@hartl.name>> wrote: >> >> What keeps you from doing a pull request to opensmalltalk-vm ? >> >> Am 07.08.2018 um 07:47 schrieb Esteban Lorenzano <esteba...@gmail.com >> <mailto:esteba...@gmail.com>>: >> >>> Hi Ben, >>> >>> Sorry for coming here so late, I didn’t see this thread before. >>> I already have a working minheadless branch that was adapted to Eliot’s >>> process. >>> It was working for Pharo in Linux and Mac (Windows was ongoing but not >>> finished, that’s why is not pushed). >>> >>> You can find this branch here: >>> >>> https://github.com/estebanlm/opensmalltalk-vm/tree/add-minheadless-vm >>> <https://github.com/estebanlm/opensmalltalk-vm/tree/add-minheadless-vm> >>> >>> Interesting part is that I didn’t tackled any of the issues you are working >>> on, so the work is easily mergeable :) >>> >>> Cheers, >>> Esteban >>> >>> Ps: with some changes in image, I’m using exclusively this VM since a >>> couple of months and it works fine. >>> >>> >>>> On 7 Aug 2018, at 07:22, Ben Coman <b...@openinworld.com >>>> <mailto:b...@openinworld.com>> wrote: >>>> >>>> On 7 August 2018 at 05:12, Eliot Miranda <eliot.mira...@gmail.com >>>> <mailto:eliot.mira...@gmail.com>> wrote: >>>> >>>> Hi Ben, >>>> Feel free to make this edit and commit >>>> >>>> I'm pushing changes here... >>>> https://github.com/bencoman/opensmalltalk-vm/tree/MinimalisticHeadless-x64-msvc2017 >>>> >>>> <https://github.com/bencoman/opensmalltalk-vm/tree/MinimalisticHeadless-x64-msvc2017> >>>> >>>> and the diff can be tracked here... >>>> https://github.com/bencoman/opensmalltalk-vm/compare/MinimalisticHeadless...bencoman:MinimalisticHeadless-x64-msvc2017 >>>> >>>> <https://github.com/bencoman/opensmalltalk-vm/compare/MinimalisticHeadless...bencoman:MinimalisticHeadless-x64-msvc2017> >>>> >>>> >>>> ------------------------ >>>> On 6 August 2018 at 13:22, Ben Coman <b...@openinworld.com >>>> <mailto:b...@openinworld.com>> wrote: >>>> On 6 August 2018 at 11:50, Ben Coman <b...@openinworld.com >>>> <mailto:b...@openinworld.com>> wrote: >>>> >>>> https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minheadless/windows/sqPlatformSpecific-Win32.c#L80 >>>> >>>> <https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minheadless/windows/sqPlatformSpecific-Win32.c#L80> >>>> typedef HRESULT WINAPI (*SetProcessDpiAwarenessFunctionPointer) (int >>>> awareness); >>>> C2059 sqPlatformSpecific-Win32.c:80 syntax error: '(' >>>> E0651 a calling convention may not be followed by a nested declarator. >>>> >>>> The following change reduces build errors to 1... >>>> typedef HRESULT (*SetProcessDpiAwarenessFunctionPointer) (int awareness); >>>> >>>> but I'm not sure of the implications. >>>> >>>> I found the correct solution to this... >>>> "The trick is placing the [call declaration] inside the parentheses" >>>> https://stackoverflow.com/questions/4830355/function-pointer-and-calling-convention >>>> >>>> <https://stackoverflow.com/questions/4830355/function-pointer-and-calling-convention> >>>> >>>> i.e. the following compiles cleanly >>>> typedef HRESULT (WINAPI *SetProcessDpiAwarenessFunctionPointer) (int >>>> awareness); >>>> >>>> >>>> ----------------------------- >>>> Now running the VM (without parameters) I get... >>>> Debug Assertion Failed! >>>> Program: ...\x64-Debug\dist\pharo.exe >>>> File: minkernel\crts\ucrt\src\appcrt\tran\amd64\ieee.c >>>> Line: 106 >>>> Expression: (mask&~(_MCW_DN | _MCW_EM | _MCW_RC))==0 >>>> >>>> at the call to _controlfp(FPU_DEFAULT, _MCW_EM | _MCW_RC | _MCW_PC | >>>> _MCW_IC); >>>> https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minheadless/windows/sqPlatformSpecific-Win32.c#L118 >>>> >>>> <https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minheadless/windows/sqPlatformSpecific-Win32.c#L118> >>>> >>>> >>>> According to https://msdn.microsoft.com/en-us/library/e9b52ceh.aspx >>>> <https://msdn.microsoft.com/en-us/library/e9b52ceh.aspx> >>>> x64 does not support _MCW_PC or _MCW_IC >>>> but I'm clueless about the implications of these FPU flags. >>>> Could our math guys please advise? >>>> >>>> Eliminating those two flags allows a VM run successfully without loading >>>> an Image. >>>> i.e. it successfully passes... >>>> osvm_initialize(); >>>> osvm_parseCommandLineArguments(argc, argv); >>>> osvm_initializeVM(); >>>> >>>> Next is to try loading an Image. >>>> >>>> cheers -ben >>> >
