Re: Minheadless trial

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Minheadless trial

EstebanLM
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: 


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 <[hidden email]> wrote:

On 7 August 2018 at 05:12, Eliot Miranda <[hidden email]> wrote:
 
Hi Ben, 
Feel free to make this edit and commit

I'm pushing changes here...

and the diff can be tracked here...


------------------------
On 6 August 2018 at 13:22, Ben Coman <[hidden email]> wrote:
On 6 August 2018 at 11:50, Ben Coman <[hidden email]> wrote:

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"

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);


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

Reply | Threaded
Open this post in threaded view
|

Re: Minheadless trial

NorbertHartl
What keeps you from doing a pull request to opensmalltalk-vm ?

Am 07.08.2018 um 07:47 schrieb Esteban Lorenzano <[hidden email]>:

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: 


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 <[hidden email]> wrote:

On 7 August 2018 at 05:12, Eliot Miranda <[hidden email]> wrote:
 
Hi Ben, 
Feel free to make this edit and commit

I'm pushing changes here...

and the diff can be tracked here...


------------------------
On 6 August 2018 at 13:22, Ben Coman <[hidden email]> wrote:
On 6 August 2018 at 11:50, Ben Coman <[hidden email]> wrote:

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"

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);


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

Reply | Threaded
Open this post in threaded view
|

Re: Minheadless trial

EstebanLM
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 <[hidden email]> wrote:

What keeps you from doing a pull request to opensmalltalk-vm ?

Am 07.08.2018 um 07:47 schrieb Esteban Lorenzano <[hidden email]>:

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: 


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 <[hidden email]> wrote:

On 7 August 2018 at 05:12, Eliot Miranda <[hidden email]> wrote:
 
Hi Ben, 
Feel free to make this edit and commit

I'm pushing changes here...

and the diff can be tracked here...


------------------------
On 6 August 2018 at 13:22, Ben Coman <[hidden email]> wrote:
On 6 August 2018 at 11:50, Ben Coman <[hidden email]> wrote:

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"

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);


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


Reply | Threaded
Open this post in threaded view
|

Re: Minheadless trial

Tim Mackinnon
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 <[hidden email]> 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 <[hidden email]> wrote:

What keeps you from doing a pull request to opensmalltalk-vm ?

Am 07.08.2018 um 07:47 schrieb Esteban Lorenzano <[hidden email]>:

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: 


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 <[hidden email]> wrote:

On 7 August 2018 at 05:12, Eliot Miranda <[hidden email]> wrote:
 
Hi Ben, 
Feel free to make this edit and commit

I'm pushing changes here...

and the diff can be tracked here...


------------------------
On 6 August 2018 at 13:22, Ben Coman <[hidden email]> wrote:
On 6 August 2018 at 11:50, Ben Coman <[hidden email]> wrote:

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"

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);


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



Reply | Threaded
Open this post in threaded view
|

Re: Minheadless trial

EstebanLM
In reply to this post by EstebanLM
Hi,

On 8 Aug 2018, at 09:33, Ben Coman <[hidden email]> wrote:



On 7 August 2018 at 13:47, Esteban Lorenzano <[hidden email]> wrote:
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: 


I'll have a look at it.
 
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.

That is good to know.  So just to be clear... 
even though its name indicates "headless", you are running a full graphical Image?

Yes, using SDL2 and OSWindow (with some modifications). Advantages of Pharo investment on this, even in things that seemed useless at the beginning ;)
Also, the minheadless VM has a “traditional display” flag that will start a word too.

I got more curious about the original announcement saying... 
"minheadless is a VM variant that unifies a lot of the code for Windows, Linux and OS X.”

Yes, I like what Ronie did there, even if there is still work to do, but is cool.


I compare...
   find "platforms/Win32/vm" -exec wc {} \;
   find "platforms/Unix/vm" -exec wc {} \;
   find "platforms/Mac OS/vm" -exec wc {} \;
to...
   find "platforms/minheadless" -exec wc {} \; 

and if nothing important has been missed it seems about 30% of the original size. 
I'd expect Ronie's effort to produce this should have a massive impact on future maintainability.  

It depends, but this is one of the reasons why we want to move into it. 
Our strategy is let the less possible in the VM (ideally, just the “core” VM and a great FFI support), and move all the rest into the image.

Esteban


cheers -ben

P.S. I excluded the following presuming its common before/after.
   find "platforms/Cross/vm" -exec wc {} \;
btw, its about half the size of platforms/minheadless.