On 6 August 2018 at 23:54, Ben Coman <btc@openinworld.com> wrote:

On 6 August 2018 at 13:22, Ben Coman <btc@openinworld.com> wrote:

...

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

So the following change to sqMain.c fixes the link error... #define BUILD_VM_CORE #include "OpenSmalltalkVM.h" int main(int argc, const char **argv) { return osvm_main(argc, argv); }

and similar for sqWin32Main.c.

The next roadbump is... LNK2019 unresolved external symbol 'alloca' referenced in function callIA32IntegralReturn -- File PharoVMCore.lib(xabicc.c.obj)

From the root folder, doing... find . -name xabicc.c result in... ./platforms/Cross/plugins/IA32ABI/xabicc.c

Googling for "alloca Visual Studio 2017" lead me to... https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/alloca which indicates there is no "alloca" only "_alloca" Now " xabicc.c" is a stub for including platform specific C code, and the lovely defines-highlighting of Visual Studio indicates "x64win64abicc.c" is the active one right now, so as a quick hack, jamming a define just above that include... #if i386|i486|i586|i686 # include "ia32abicc.c" #elif powerpc|ppc # include "ppc32abicc.c" #elif x86_64|x64|__x86_64|__x86_64__|_M_AMD64|_M_X64 # if _WIN64 # define alloca _alloca // <<<QUICK HACK # include "x64win64abicc.c" # else # include "x64sysvabicc.c" # endif #elif __ARM_ARCH__|__arm__|__arm32__|ARM32 # include "arm32abicc.c" #endif allows CMake > Build All ==> Build succeeded. Yay! To determine a suitable permanent home for that define, doing... grep -R " _alloca" * from the root folder shows... platforms/Cross/plugins/IA32ABI/arm32abicc.c:# define alloca _alloca platforms/Cross/plugins/IA32ABI/ia32abicc.c:# define alloca _alloca platforms/Cross/plugins/IA32ABI/ppc32abicc.c:# define alloca _alloca platforms/Cross/plugins/SqueakFFIPrims/sqFFIPlugin.c:# define alloca _alloca platforms/minheadless/windows/sqPlatformSpecific-Win32.h:# define alloca _alloca platforms/unix/config/configure:# define alloca _alloca platforms/win32/vm/sqPlatformSpecific.h:# define alloca _alloca processors/ARM/gdb-7.10/include/alloca-conf.h:# define alloca _alloca processors/IA32/bochs/bx_debug/parser.c:# define alloca _alloca src/plugins/SqueakFFIPrims/ARM32FFIPlugin.c:# define alloca _alloca src/plugins/SqueakFFIPrims/IA32FFIPlugin.c:# define alloca _alloca src/plugins/SqueakFFIPrims/X64SysVFFIPlugin.c:# define alloca _alloca src/plugins/SqueakFFIPrims/X64Win64FFIPlugin.c:# define alloca _alloca Interesting that there is a similar define for ia32abicc.c, so comparing that with x64win64abicc.c (at https://www.diffchecker.com/mqCWMaTV) looks like it should be slotted into the latter about line 41. Doing that ==> Build successful. cheers -ben

On 7 August 2018 at 05:12, Eliot Miranda <eliot.miranda@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-m... and the diff can be tracked here... https://github.com/bencoman/opensmalltalk-vm/compare/MinimalisticHeadless...... ------------------------ On 6 August 2018 at 13:22, Ben Coman <btc@openinworld.com> wrote:

On 6 August 2018 at 11:50, Ben Coman <btc@openinworld.com> 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-con... 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/minhead... 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

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

Am 07.08.2018 um 07:47 schrieb Esteban Lorenzano <estebanlm@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

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 <btc@openinworld.com> wrote:

...

On 7 August 2018 at 05:12, Eliot Miranda <eliot.miranda@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-m...

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

------------------------

...

On 6 August 2018 at 13:22, Ben Coman <btc@openinworld.com> wrote: On 6 August 2018 at 11:50, Ben Coman <btc@openinworld.com> wrote:

https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhead... 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-con...

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/minhead...

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

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 <estebanlm@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 <norbert@hartl.name <mailto:norbert@hartl.name>> wrote:

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

Am 07.08.2018 um 07:47 schrieb Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@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 <btc@openinworld.com <mailto:btc@openinworld.com>> wrote:

On 7 August 2018 at 05:12, Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@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-m... <https://github.com/bencoman/opensmalltalk-vm/tree/MinimalisticHeadless-x64-m...>

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

------------------------ On 6 August 2018 at 13:22, Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>> wrote: On 6 August 2018 at 11:50, Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>> wrote:

https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhead... <https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhead...> 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-con... <https://stackoverflow.com/questions/4830355/function-pointer-and-calling-con...>

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/minhead... <https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhead...>

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

Hi Eliot,

On 5 Dec 2018, at 14:46, Eliot Miranda <eliot.miranda@gmail.com> wrote:

Hi Esteban,

On Aug 7, 2018, at 4:36 AM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@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 :)

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 <norbert@hartl.name <mailto:norbert@hartl.name>> wrote:

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

Am 07.08.2018 um 07:47 schrieb Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@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 <btc@openinworld.com <mailto:btc@openinworld.com>> wrote:

On 7 August 2018 at 05:12, Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@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-m... <https://github.com/bencoman/opensmalltalk-vm/tree/MinimalisticHeadless-x64-m...>

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

------------------------ On 6 August 2018 at 13:22, Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>> wrote: On 6 August 2018 at 11:50, Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>> wrote:

https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhead... <https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhead...> 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-con... <https://stackoverflow.com/questions/4830355/function-pointer-and-calling-con...>

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/minhead... <https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhead...>

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

On 5 Dec 2018, at 16:19, Ben Coman <btc@openinworld.com> wrote:

On Wed, 5 Dec 2018 at 21:53, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote: Hi Eliot,

...

On 5 Dec 2018, at 14:46, Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>> wrote:

Hi Esteban,

On Aug 7, 2018, at 4:36 AM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@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 :)

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

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" <estebanlm@gmail.com> a écrit : On 5 Dec 2018, at 16:19, Ben Coman <btc@openinworld.com> wrote: On Wed, 5 Dec 2018 at 21:53, Esteban Lorenzano <estebanlm@gmail.com> wrote:

Hi Eliot,

On 5 Dec 2018, at 14:46, Eliot Miranda <eliot.miranda@gmail.com> wrote:

Hi Esteban,

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

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

Hi Esteban, On Wed, Dec 5, 2018 at 5:53 AM Esteban Lorenzano <estebanlm@gmail.com> wrote:

Hi Eliot,

On 5 Dec 2018, at 14:46, Eliot Miranda <eliot.miranda@gmail.com> wrote:

Hi Esteban,

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

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 <norbert@hartl.name> wrote:

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

Am 07.08.2018 um 07:47 schrieb Esteban Lorenzano <estebanlm@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

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 <btc@openinworld.com> wrote:

On 7 August 2018 at 05:12, Eliot Miranda <eliot.miranda@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-m...

and the diff can be tracked here...

https://github.com/bencoman/opensmalltalk-vm/compare/MinimalisticHeadless......

------------------------ On 6 August 2018 at 13:22, Ben Coman <btc@openinworld.com> wrote:

...

On 6 August 2018 at 11:50, Ben Coman <btc@openinworld.com> wrote:

https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhead... 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-con...

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/minhead...

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

Hi,

On 8 Aug 2018, at 09:33, Ben Coman <btc@openinworld.com> wrote:

On 7 August 2018 at 13:47, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> 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 <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_AxnZ... <https://docs.google.com/spreadsheets/d/183GnSKZSMSEgVQZ0Fqa7-vITqKSpAlW_AxnZ...> 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.

On 7 August 2018 at 19:47, Ben Coman <btc@openinworld.com> wrote:

it gets stuck the following loop... https://github.com/bencoman/

opensmalltalk-vm/blob/8231b96f9b/platforms/win32/vm/ sqWin32SpurAlloc.c#L139-L183 whoops, that was meant to be the minheadless file.... https://github.com/bencoman/opensmalltalk-vm/blob/8231b96f9b/platforms/minhe... In the meantime, I'll forge ahead to play with osvm_run();

I've hardly used Visual Studio before, and never combined with CMake, so I'll record a few things I discover in case others might find it interesting or advise a better way. To try with the Stack Interpreter first, in CMakeLists.txt changed... option(COG_JIT "Cog JIT" ON) to... option(COG_JIT "Cog JIT" OFF) then cleared the cache... Right-clicked on "CMakeLists.txt > Cache(x64-Debug only) > Delete cache folder..." otherwise it didn't seem to pick up that change. To give the VM an image to run and something to do... Right-clicked on "CMakeLists.txt > Debug and Launch Settings > pharo.exe" then edited the presented "launch.vs.json" as follows... { "version": "0.2.1", "defaults": {}, "configurations": [ { "type": "default", "project": "CMakeLists.txt", "projectTarget": "pharo.exe (dist\\pharo.exe)", "name": "pharo.exe minImage+eval (dist\\pharo.exe)", "args": [ "C:\\#Dev\\latest-minimal-64\\Pharo7.0-metacello-64bit-65cff7b.image eval 19 + 23", ] }, ] } Then... "CMake > Build All" followed by starting... "x64-Debug" with "pharo.exe minImage+eval" which opened a console window that doesn't do much besides output like this... GIV(remapBufferCount) == 0 47923 Now I notice the file "dist\stderr" says... "Your VM is too old for this image. Please download the latest VM." so probably I need to run "scripts\updateSCCSVersions" but thats a shell script. How to run it under Windows? Luckily my installed Git Windows has Git Bash which opens a cygwin environment. where I do... cd /c/#Repos/OpenSmalltalk/opensmalltalk-vm/ ./scripts/ updateSCCSVersions Now to give a bit more visibility to program execution, in "spurstack64src/interp.c" I inserted the following into main interpreter loop... "+" unsigned long long debugCountBytecode = 0; while (1) { "+" debugCountBytecode += 1; "+" if ((debugCountBytecode % 100000 == 0)) "+" { "+" printf("%llu\n", debugCountBytecode); "+" } Then... "CMake > Build All" followed by starting... "x64-Debug" with "pharo.exe minImage+eval" which opened a console window with the following output... GIV(remapBufferCount) == 0 47923 GIV(remapBufferCount) == 0 42469 100000 200000 300000 400000 500000 600000 700000 800000 900000 1000000 1100000 1200000 1300000 1400000 1500000 and updated contents of these files... yay! dist\stderr ==> #'EvaluateCommandLineHandler successfully finished' dist\stdout ==> 42 However the VM/Image keeps running. Adding "--quit" to the command line didn't help. I'm not really familiar with the command line handlers. Doing... "Debug > Break All" bring me up some warnings like... "winmm.pdb not loaded" "winmm.pdb contains the debug information required to find the source for the module winmm.dll" Never heard of a PDB, but loaded them by following these instructions... "Specify Symbol (.pdb) and Source Files in the Visual Studio Debugger" https://msdn.microsoft.com/en-us/library/ms241613.aspx and learnt a lot more about them... "PDB Files: What Every Developer Must Know" https://www.wintellect.com/pdb-files-what-every-developer-must-know/ Now the next few times I started... "x64-Debug" with "pharo.exe minImage+eval" it got hung up downloading the symbols. I had to terminate & restart debugging it a few times as it progressed a bit each time. When finally got running again and after 1500000 printed I did... "Debug > Break All" and... "Debug > Windows > Threads" and now it shows the proper names rather than just addresses... A little surprised by the number of threads. No clue what ntdll.dll!NtWaitForWorkViaWorkerFactory or winmm.dll!timeThread are, but leave that for later. Now with all thread stopped, trying... "Debug > Windows > Parallel Stacks"... shows the two application threads are "in external code" invoked from ioRelinquishProcessorForMicroseconds() and beatThreadStateMachine(). Clicking on each of those displays their source code indicating the "external code" for each is MsgWaitForMultipleObjects() and WaitForSingleObject() respectively . Its very easy to flip back and forth between the two application threads, stepping-out of the "external code" with Shift-F11, to observe a tiny window of VM operation. Well thats enough for one post! Success running a MSVC compiled Spur Stack "minheadless" VM. Next I'll try... option(COG_JIT "Cog JIT" ON) cheers -ben P.S. Definitions for the curious... sqInt ioRelinquishProcessorForMicroseconds(sqInt microSeconds) { /* wake us up if something happens */ ResetEvent(vmWakeUpEvent); MsgWaitForMultipleObjects(1, &vmWakeUpEvent, FALSE, microSeconds / 1000, QS_ALLINPUT); ioProcessEvents(); /* keep up with mouse moves etc. */ return microSeconds; } static DWORD WINAPI beatThreadStateMachine(void *careLess) { beatThreadState = active; while (beatThreadState != condemned) { DWORD res = WaitForSingleObject(beatSemaphore, beatThreadState == active ? beatMilliseconds : INFINITE); if (res == WAIT_TIMEOUT) heartbeat(); else if (res == WAIT_FAILED) abortMessage(TEXT("Fatal: WaitForSingleObject(beatSemaphore) %ld"), GetLastError()); else printLastError(TEXT("beatThreadStateMachine WaitForSingleObject")); } beatThreadState = dead; return 0; }