Re: [Pharo-dev] Minheadless trial

[Ben Coman]

On Thu, 6 Dec 2018 at 01:25, Nicolas Cellier <
nicolas.cellier.aka.n...@gmail.com> wrote:

> Hi Esteban, Ronie,
> Forking, branching and merging is certainly the clean way to do it!
> The question is about the frequency of merges. Like Ben I prefer short
> cycles, because otherwise we just can't review the code, it' too many diffs
> at once. We can just trust, or not, take it or leave it...
> So who is going to take the responsibility?
>
> How i did it for win64 support? The canonicle way would have been to
> develop a long branch with hundreds of changed files/lines, then merge when
> ready. Instead of that, i integrated small batches of changes, none of
> which were sufficient to have win64 working, but none of which completely
> broke the trunk. Small steps... I know some purists that don't like my way
> of doing because we obtain interleaved features in the history preventing
> to easily bissect regressions, but i don't like puritanism either :).
>
> In fact, i did experiment like Ronie in my own private fork, then when
> ready, (not when perfect, but just when it reached a minimum of usability),
> i redone everything in smaller steps (cherry pick, rebase, squash,
> whatever...).
>
> I did also commit some changes in trunk, or accepted my own merge, which
> is questionable, but IMO more acceptable than rotting PR: that just means
> that i have to assume the responsibility of changes, I break it, I repair
> it. Ronie, you could adopt such strategy too, because in some aspects of
> the VM, you are the expert :)!
>
> It's certainly easier to concentrate on own changes and forget about the
> drag of legacy, but it's only a short term view. The burden of integration
> is differed, not eliminated, and the impact of changes not really mastered,
> because at the end we say let's integrate now and see later what is
> broken... We cannot always avoid such strategy when legacy code is too much
> intricated... But in this case, my own view of refactoring is untwist
> first, then replace.
>
> I don't want to discourage good will, on the contrary, thanks a lot for
> taking the burden of these essential changes!!! I rather want to encourage
> more frequent refactorings. Don't hesitate to flood opensmalltalk with
> small PR.
>

An enlightening moment for me was reading an article about how PRs should
not just be for the final product to integrate,
but also be used heavily for discussion.  Just put prepend something like
"WIP" to the title.  Then the PR is updated every time you commit to your
source branch.
There is even a github app to help manage that...
https://github.com/wip/app#configuration
https://github.com/wip/app/blob/master/pro-plan-for-free.js

The "compare" tool is then available to draw attention to particular
changes between particular commits...
https://help.github.com/articles/comparing-commits-across-time/

cheers -ben

They don't need to be perfect nor complete, as long as they go in the right
> direction.
>


> Smaller changes means less burden and less responsibility for the
> integrators, so more people can effectively integrate, not just Eliot or
> Ben.
>
> Cheers and thanks again!
>
>
>
> Le 5 déc. 2018 16:29, "Esteban Lorenzano"  a écrit :
>
>
>
> On 5 Dec 2018, at 16:19, Ben Coman  wrote:
>
>
>
> On Wed, 5 Dec 2018 at 21:53, Esteban Lorenzano 
> wrote:
>
>> Hi Eliot,
>>
>> On 5 Dec 2018, at 14:46, Eliot Miranda  wrote:
>>
>> Hi Esteban,
>>
>> On Aug 7, 2018, at 4:36 AM, Esteban Lorenzano 
>> 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 :)
>>
>>
>> How does that answer Norbert’s question?  By doing the work in your own
>> fork you risk forking.  Do you want to fork?  If not, why not do the work
>> in opensmalltalk-vm?
>>
>> I guess you mean "why not do the work directly on the Cog branch of the
> OpenSmalltalk account”,
>
>
> That’s not how you work on git/github and I prefer to keep it “as
> intended”.
>
> because any other branch is no different to any other branch regardless of
> which account its stored in.
> The "opensmaltalk-vm repo" is a single big commit graph across all
> accounts, as you can see...
> https://github.com/OpenSmalltalk/opensmalltalk-vm/network
>
> Whether any development-branch becomes a real-fork in the old vernacular
> is not how long it stays unmerged from the mainline-branch
> but how often the development-branch is updated to merge in the
> mainline-branch.  The network graph is useful to understand the situation
> here.
>
>
> This is old thing 

Re: [Pharo-dev] Minheadless trial

[Nicolas Cellier]

Hi Esteban, Ronie,
Forking, branching and merging is certainly the clean way to do it!
The question is about the frequency of merges. Like Ben I prefer short
cycles, because otherwise we just can't review the code, it' too many diffs
at once. We can just trust, or not, take it or leave it...
So who is going to take the responsibility?

How i did it for win64 support? The canonicle way would have been to
develop a long branch with hundreds of changed files/lines, then merge when
ready. Instead of that, i integrated small batches of changes, none of
which were sufficient to have win64 working, but none of which completely
broke the trunk. Small steps... I know some purists that don't like my way
of doing because we obtain interleaved features in the history preventing
to easily bissect regressions, but i don't like puritanism either :).

In fact, i did experiment like Ronie in my own private fork, then when
ready, (not when perfect, but just when it reached a minimum of usability),
i redone everything in smaller steps (cherry pick, rebase, squash,
whatever...).

I did also commit some changes in trunk, or accepted my own merge, which is
questionable, but IMO more acceptable than rotting PR: that just means that
i have to assume the responsibility of changes, I break it, I repair it.
Ronie, you could adopt such strategy too, because in some aspects of the
VM, you are the expert :)!

It's certainly easier to concentrate on own changes and forget about the
drag of legacy, but it's only a short term view. The burden of integration
is differed, not eliminated, and the impact of changes not really mastered,
because at the end we say let's integrate now and see later what is
broken... We cannot always avoid such strategy when legacy code is too much
intricated... But in this case, my own view of refactoring is untwist
first, then replace.

I don't want to discourage good will, on the contrary, thanks a lot for
taking the burden of these essential changes!!! I rather want to encourage
more frequent refactorings. Don't hesitate to flood opensmalltalk with
small PR. They don't need to be perfect nor complete, as long as they go in
the right direction. Smaller changes means less burden and less
responsibility for the integrators, so more people can effectively
integrate, not just Eliot or Ben.

Cheers and thanks again!



Le 5 déc. 2018 16:29, "Esteban Lorenzano"  a écrit :



On 5 Dec 2018, at 16:19, Ben Coman  wrote:



On Wed, 5 Dec 2018 at 21:53, Esteban Lorenzano  wrote:

> Hi Eliot,
>
> On 5 Dec 2018, at 14:46, Eliot Miranda  wrote:
>
> Hi Esteban,
>
> On Aug 7, 2018, at 4:36 AM, Esteban Lorenzano  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 :)
>
>
> How does that answer Norbert’s question?  By doing the work in your own
> fork you risk forking.  Do you want to fork?  If not, why not do the work
> in opensmalltalk-vm?
>
> I guess you mean "why not do the work directly on the Cog branch of the
OpenSmalltalk account”,


That’s not how you work on git/github and I prefer to keep it “as
intended”.

because any other branch is no different to any other branch regardless of
which account its stored in.
The "opensmaltalk-vm repo" is a single big commit graph across all
accounts, as you can see...
https://github.com/OpenSmalltalk/opensmalltalk-vm/network

Whether any development-branch becomes a real-fork in the old vernacular is
not how long it stays unmerged from the mainline-branch
but how often the development-branch is updated to merge in the
mainline-branch.  The network graph is useful to understand the situation
here.


This is old thing (there is a pull request now, since like 3 weeks).
> I worked on my fork because that’s how you do it with git: you fork, you
> work, and you do a Pull Request when ready.
> I was explaining why the PR was not still done: I wanted to have covered
> the three platforms before doing it.
>

On the flip side, release early release is a good policy.


Yeah, but for that you need to have something that you can release.
minheadless was developed by Ronie (I just made the makefiles and adapted
to build pharovms). And then it stalled around until I decided to took it
and merge it… I’m going to be susceptible and say that frankly I do not
understand the tone of this mails.

It was your merge of minheadless into Cog that stimulated me to add my
minor minheadless tweaks.


And I’m grateful :)

I know I could have submitted a PR direct to your minheadless branch, but
somehow it just felt 

Re: [Pharo-dev] Minheadless trial

[Eliot Miranda]

Hi Esteban,

On Wed, Dec 5, 2018 at 5:53 AM Esteban Lorenzano 
wrote:

> Hi Eliot,
>
> On 5 Dec 2018, at 14:46, Eliot Miranda  wrote:
>
> Hi Esteban,
>
> On Aug 7, 2018, at 4:36 AM, Esteban Lorenzano  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 :)
>
>
> How does that answer Norbert’s question?  By doing the work in your own
> fork you risk forking.  Do you want to fork?  If not, why not do the work
> in opensmalltalk-vm?
>
>
> This is old thing (there is a pull request now, since like 3 weeks).
>

Ah, OK.  I should;d have checked the dates more carefully.


> I worked on my fork because that’s how you do it with git: you fork, you
> work, and you do a Pull Request when ready.
>

I hope you forked opensmalltalk-vm not pharo-vm/opensmalltalk-vm, that's
all.


> I was explaining why the PR was not still done: I wanted to have covered
> the three platforms before doing it.
>
> I guess the terminology is confusing you?
>

I get forking in a single repository.  I also get forking across
repositories.  These are two different things.  I had misunderstood where
you were forking.  I apologize.


>
> Cheers!
> Esteban
>
>
>
> Cheers,
> Esteban
>
>
> On 7 Aug 2018, at 08:50, Norbert Hartl  wrote:
>
> What keeps you from doing a pull request to opensmalltalk-vm ?
>
> Am 07.08.2018 um 07:47 schrieb Esteban Lorenzano :
>
> 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
>
> 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  wrote:
>
> On 7 August 2018 at 05:12, Eliot Miranda  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
>
> and the diff can be tracked here...
>
> https://github.com/bencoman/opensmalltalk-vm/compare/MinimalisticHeadless...bencoman:MinimalisticHeadless-x64-msvc2017
>
>
> 
> On 6 August 2018 at 13:22, Ben Coman  wrote:
>
>> On 6 August 2018 at 11:50, Ben Coman  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"
>
> 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
>
>
> According to 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
>
>
>
>
>

-- 
_,,,^..^,,,_
best, Eliot

Re: [Pharo-dev] Minheadless trial

[Ben Coman]

On Wed, 5 Dec 2018 at 23:29, Esteban Lorenzano  wrote:

>
>
> On 5 Dec 2018, at 16:19, Ben Coman  wrote:
>
>
>
> On Wed, 5 Dec 2018 at 21:53, Esteban Lorenzano 
> wrote:
>
>> Hi Eliot,
>>
>> On 5 Dec 2018, at 14:46, Eliot Miranda  wrote:
>>
>> Hi Esteban,
>>
>> On Aug 7, 2018, at 4:36 AM, Esteban Lorenzano 
>> 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 :)
>>
>>
>> How does that answer Norbert’s question?  By doing the work in your own
>> fork you risk forking.  Do you want to fork?  If not, why not do the work
>> in opensmalltalk-vm?
>>
>> I guess you mean "why not do the work directly on the Cog branch of the
> OpenSmalltalk account”,
>
>
> That’s not how you work on git/github and I prefer to keep it “as
> intended”.
>
> because any other branch is no different to any other branch regardless of
> which account its stored in.
> The "opensmaltalk-vm repo" is a single big commit graph across all
> accounts, as you can see...
> https://github.com/OpenSmalltalk/opensmalltalk-vm/network
>
> Whether any development-branch becomes a real-fork in the old vernacular
> is not how long it stays unmerged from the mainline-branch
> but how often the development-branch is updated to merge in the
> mainline-branch.  The network graph is useful to understand the situation
> here.
>
>
> This is old thing (there is a pull request now, since like 3 weeks).
>> I worked on my fork because that’s how you do it with git: you fork, you
>> work, and you do a Pull Request when ready.
>> I was explaining why the PR was not still done: I wanted to have covered
>> the three platforms before doing it.
>>
>
> On the flip side, release early release is a good policy.
>
>
> Yeah, but for that you need to have something that you can release.
> minheadless was developed by Ronie (I just made the makefiles and adapted
> to build pharovms). And then it stalled around until I decided to took it
> and merge it… I’m going to be susceptible and say that frankly I do not
> understand the tone of this mails.
>
> It was your merge of minheadless into Cog that stimulated me to add my
> minor minheadless tweaks.
>
>
> And I’m grateful :)
>
> I know I could have submitted a PR direct to your minheadless branch, but
> somehow it just felt more comfortable
> submitting it to the mainline Cog branch.
>
>
>>
>> I guess the terminology is confusing you?
>>
>
> That doesn't help.
>
>
> Why? Terminology *is* confusing, at least for me.
>

It came across sarcastic.  My apologies.  Email is a poor medium sometimes.

cheers -ben

Re: [Pharo-dev] Minheadless trial

[Esteban Lorenzano]

> On 5 Dec 2018, at 16:19, Ben Coman  wrote:
> 
> 
> 
> On Wed, 5 Dec 2018 at 21:53, Esteban Lorenzano  > wrote:
> Hi Eliot,
> 
>> On 5 Dec 2018, at 14:46, Eliot Miranda > > wrote:
>> 
>> Hi Esteban,
>> 
>> On Aug 7, 2018, at 4:36 AM, Esteban Lorenzano > > 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 :)
>> 
>> How does that answer Norbert’s question?  By doing the work in your own fork 
>> you risk forking.  Do you want to fork?  If not, why not do the work in 
>> opensmalltalk-vm?
> 
> I guess you mean "why not do the work directly on the Cog branch of the 
> OpenSmalltalk account”,

That’s not how you work on git/github and I prefer to keep it “as intended”. 

> because any other branch is no different to any other branch regardless of 
> which account its stored in.
> The "opensmaltalk-vm repo" is a single big commit graph across all accounts, 
> as you can see...  https://github.com/OpenSmalltalk/opensmalltalk-vm/network 
> 
> 
> Whether any development-branch becomes a real-fork in the old vernacular is 
> not how long it stays unmerged from the mainline-branch
> but how often the development-branch is updated to merge in the 
> mainline-branch.  The network graph is useful to understand the situation 
> here.
> 
> 
> This is old thing (there is a pull request now, since like 3 weeks).
> I worked on my fork because that’s how you do it with git: you fork, you 
> work, and you do a Pull Request when ready. 
> I was explaining why the PR was not still done: I wanted to have covered the 
> three platforms before doing it. 
> 
> On the flip side, release early release is a good policy.

Yeah, but for that you need to have something that you can release.
minheadless was developed by Ronie (I just made the makefiles and adapted to 
build pharovms). And then it stalled around until I decided to took it and 
merge it… I’m going to be susceptible and say that frankly I do not understand 
the tone of this mails.

> It was your merge of minheadless into Cog that stimulated me to add my minor 
> minheadless tweaks.

And I’m grateful :)

> I know I could have submitted a PR direct to your minheadless branch, but 
> somehow it just felt more comfortable 
> submitting it to the mainline Cog branch.
>  
> 
> I guess the terminology is confusing you?
> 
> That doesn't help.

Why? Terminology *is* confusing, at least for me. 

Esteban

> 
> cheers -ben

Re: [Pharo-dev] Minheadless trial

[Ben Coman]

On Wed, 5 Dec 2018 at 21:53, Esteban Lorenzano  wrote:

> Hi Eliot,
>
> On 5 Dec 2018, at 14:46, Eliot Miranda  wrote:
>
> Hi Esteban,
>
> On Aug 7, 2018, at 4:36 AM, Esteban Lorenzano  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 :)
>
>
> How does that answer Norbert’s question?  By doing the work in your own
> fork you risk forking.  Do you want to fork?  If not, why not do the work
> in opensmalltalk-vm?
>
> I guess you mean "why not do the work directly on the Cog branch of the
OpenSmalltalk account",
because any other branch is no different to any other branch regardless of
which account its stored in.
The "opensmaltalk-vm repo" is a single big commit graph across all
accounts, as you can see...
https://github.com/OpenSmalltalk/opensmalltalk-vm/network

Whether any development-branch becomes a real-fork in the old vernacular is
not how long it stays unmerged from the mainline-branch
but how often the development-branch is updated to merge in the
mainline-branch.  The network graph is useful to understand the situation
here.


This is old thing (there is a pull request now, since like 3 weeks).
> I worked on my fork because that’s how you do it with git: you fork, you
> work, and you do a Pull Request when ready.
> I was explaining why the PR was not still done: I wanted to have covered
> the three platforms before doing it.
>

On the flip side, release early release is a good policy.
It was your merge of minheadless into Cog that stimulated me to add my
minor minheadless tweaks.
I know I could have submitted a PR direct to your minheadless branch, but
somehow it just felt more comfortable
submitting it to the mainline Cog branch.


>
> I guess the terminology is confusing you?
>

That doesn't help.

cheers -ben

Re: [Pharo-dev] Minheadless trial

[Esteban Lorenzano]

Hi Eliot,

> On 5 Dec 2018, at 14:46, Eliot Miranda  wrote:
> 
> Hi Esteban,
> 
> On Aug 7, 2018, at 4:36 AM, Esteban Lorenzano  > 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 :)
> 
> How does that answer Norbert’s question?  By doing the work in your own fork 
> you risk forking.  Do you want to fork?  If not, why not do the work in 
> opensmalltalk-vm?

This is old thing (there is a pull request now, since like 3 weeks).
I worked on my fork because that’s how you do it with git: you fork, you work, 
and you do a Pull Request when ready. 
I was explaining why the PR was not still done: I wanted to have covered the 
three platforms before doing it. 

I guess the terminology is confusing you?

Cheers!
Esteban

> 
>> 
>> Cheers, 
>> Esteban
>> 
>> 
>>> On 7 Aug 2018, at 08:50, Norbert Hartl >> > wrote:
>>> 
>>> What keeps you from doing a pull request to opensmalltalk-vm ?
>>> 
>>> Am 07.08.2018 um 07:47 schrieb Esteban Lorenzano >> >:
>>> 
 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 
 
 
 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  > wrote:
> 
> On 7 August 2018 at 05:12, Eliot Miranda  > 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
>  
> 
> 
> and the diff can be tracked here...
> https://github.com/bencoman/opensmalltalk-vm/compare/MinimalisticHeadless...bencoman:MinimalisticHeadless-x64-msvc2017
>  
> 
> 
> 
> 
> On 6 August 2018 at 13:22, Ben Coman  > wrote:
> On 6 August 2018 at 11:50, Ben Coman  > 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"
> 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);
> 

Re: [Pharo-dev] Minheadless trial

[Eliot Miranda]

Hi Esteban,

> On Aug 7, 2018, at 4:36 AM, Esteban Lorenzano  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 :)

How does that answer Norbert’s question?  By doing the work in your own fork 
you risk forking.  Do you want to fork?  If not, why not do the work in 
opensmalltalk-vm?

> 
> Cheers, 
> Esteban
> 
> 
>> On 7 Aug 2018, at 08:50, Norbert Hartl  wrote:
>> 
>> What keeps you from doing a pull request to opensmalltalk-vm ?
>> 
>>> Am 07.08.2018 um 07:47 schrieb Esteban Lorenzano :
>>> 
>>> 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
>>> 
>>> 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  wrote:
 
> On 7 August 2018 at 05:12, Eliot Miranda  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
 
 and the diff can be tracked here...
 https://github.com/bencoman/opensmalltalk-vm/compare/MinimalisticHeadless...bencoman:MinimalisticHeadless-x64-msvc2017
 
 
 
> On 6 August 2018 at 13:22, Ben Coman  wrote:
> On 6 August 2018 at 11:50, Ben Coman  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"
 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
 
 
 According to 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
>>> 
> 

Re: [Pharo-dev] Minheadless trial

[Esteban Lorenzano]

Hi,

> On 8 Aug 2018, at 09:33, Ben Coman  wrote:
> 
> 
> 
> On 7 August 2018 at 13:47, Esteban Lorenzano  > 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: 
> 
> https://github.com/estebanlm/opensmalltalk-vm/tree/add-minheadless-vm 
> 
> 
> 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.

> 
> So here 
> https://docs.google.com/spreadsheets/d/183GnSKZSMSEgVQZ0Fqa7-vITqKSpAlW_AxnZKl7x048/edit?usp=sharing
>  
> 
> 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.

Re: [Pharo-dev] 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  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 > > wrote:
>> 
>> What keeps you from doing a pull request to opensmalltalk-vm ?
>> 
>> Am 07.08.2018 um 07:47 schrieb Esteban Lorenzano > >:
>> 
>>> 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 
>>> 
>>> 
>>> 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 >>> > wrote:
 
 On 7 August 2018 at 05:12, Eliot Miranda >>> > 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
  
 
 
 and the diff can be tracked here...
 https://github.com/bencoman/opensmalltalk-vm/compare/MinimalisticHeadless...bencoman:MinimalisticHeadless-x64-msvc2017
  
 
 
 
 
 On 6 August 2018 at 13:22, Ben Coman >>> > wrote:
 On 6 August 2018 at 11:50, Ben Coman >>> > 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"
 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
  
 
 
 
 According to 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 

Re: [Pharo-dev] Minheadless trial

[Esteban Lorenzano]

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  wrote:
> 
> What keeps you from doing a pull request to opensmalltalk-vm ?
> 
> Am 07.08.2018 um 07:47 schrieb Esteban Lorenzano  >:
> 
>> 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 
>> 
>> 
>> 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 >> > wrote:
>>> 
>>> On 7 August 2018 at 05:12, Eliot Miranda >> > 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
>>>  
>>> 
>>> 
>>> and the diff can be tracked here...
>>> https://github.com/bencoman/opensmalltalk-vm/compare/MinimalisticHeadless...bencoman:MinimalisticHeadless-x64-msvc2017
>>>  
>>> 
>>> 
>>> 
>>> 
>>> On 6 August 2018 at 13:22, Ben Coman >> > wrote:
>>> On 6 August 2018 at 11:50, Ben Coman >> > 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"
>>> 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
>>>  
>>> 
>>> 
>>> 
>>> According to 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
>> 

Re: [Pharo-dev] Minheadless trial

[Norbert Hartl]

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

> Am 07.08.2018 um 07:47 schrieb Esteban Lorenzano :
> 
> 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
> 
> 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  wrote:
>> 
>>> On 7 August 2018 at 05:12, Eliot Miranda  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
>> 
>> and the diff can be tracked here...
>> https://github.com/bencoman/opensmalltalk-vm/compare/MinimalisticHeadless...bencoman:MinimalisticHeadless-x64-msvc2017
>> 
>> 
>> 
>>> On 6 August 2018 at 13:22, Ben Coman  wrote:
>>> On 6 August 2018 at 11:50, Ben Coman  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"
>> 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
>> 
>> 
>> According to 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
> 

Re: [Pharo-dev] Minheadless trial

[Esteban Lorenzano]

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 


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  wrote:
> 
> On 7 August 2018 at 05:12, Eliot Miranda  > 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
>  
> 
> 
> and the diff can be tracked here...
> https://github.com/bencoman/opensmalltalk-vm/compare/MinimalisticHeadless...bencoman:MinimalisticHeadless-x64-msvc2017
>  
> 
> 
> 
> 
> On 6 August 2018 at 13:22, Ben Coman  > wrote:
> On 6 August 2018 at 11:50, Ben Coman  > 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"
> 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
>  
> 
> 
> 
> According to 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

Re: [Pharo-dev] Minheadless trial

[Ben Coman]

 On 7 August 2018 at 05:12, Eliot Miranda  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

and the diff can be tracked here...
https://github.com/bencoman/opensmalltalk-vm/compare/MinimalisticHeadless...bencoman:MinimalisticHeadless-x64-msvc2017



On 6 August 2018 at 13:22, Ben Coman  wrote:

> On 6 August 2018 at 11:50, Ben Coman  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"
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


According to 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

Re: [Pharo-dev] Minheadless trial

[Ben Coman]

On 6 August 2018 at 11:50, Ben Coman  wrote:
> wow time flies, its been 18 months since Ronie announced his
> Minheadless VM branch...
> [1] http://forum.world.st/Minheadless-VM-flavour-status-update-td4928091.html

In Visual Studio...
> (with x64-Debug & pharo.exe selected)
> I went Cmake > Build All
> ==> 10 Errors, 9 Warnings, which I'll discuss in a followup post.
and btw, the build finishes too quick

Here are the errors...

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.

Could be "the parenthesis around the function name" [2]
Or "there's already a C standard function [of that name]" [3]
The Microsoft definition returns a BOOL [4].

[2] https://software.intel.com/en-us/forums/intel-c-compiler/topic/385282
[3] 
https://social.msdn.microsoft.com/Forums/vstudio/en-US/2c57ada8-e1c9-4030-a058-6a7afd2fd29f/a-calling-convention-may-not-be-followed-by-a-nested-declarator?forum=vcgeneral
[4] 
https://docs.microsoft.com/en-us/windows/desktop/api/winuser/nf-winuser-setprocessdpiawarenesscontext



https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minheadless/common/sqWindow-Dispatch.c#L68
  sqInt ioSetCursorARGB(sqInt cursorBitsIndex, sqInt extentX, sqInt
extentY, sqInt offsetX, sqInt offsetY)
C2371 'ioSetCursorARGB': redefinition; different basic types

where sqInt is "long long".
but the function declaration is
https://github.com/ronsaldo/opensmalltalk-vm/blob/21cc02b6bf/platforms/minheadless/windows/sqPlatformSpecific-Win32.h#L117
  int ioSetCursorARGB(sqInt bitsIndex, sqInt w, sqInt h, sqInt x, sqInt y);

After modifying that function declaration to return 'sqInt',
"Cmake > Build all" runs much longer



and ends up with 4 link errors (and 6600 warnings)
Pharo.exe LNK1120 - 1 unresolved external
Pharow.exe LNK1120 - 1unresolved external
sqMain.c.obj LNK2019 - unresolved external symbol _imp_osvm_main
referenced in function main
sqWin32Main.c.obj LNK2019 - unresolved external symbol _imp_osvm_main
referenced in function WinMain

I do see osvm_main is defined here...
https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minheadless/common/sqVirtualMachineInterface.c#L618

but I'm stuck, I don't understand why its looking for "_imp_osvm_main"

I'd be glad if anyone can advise on this, and the two errors above.

cheers -ben