Hi Esteban, On Wed, Dec 5, 2018 at 5:53 AM Esteban Lorenzano <esteba...@gmail.com> wrote:
> Hi Eliot, > > On 5 Dec 2018, at 14:46, Eliot Miranda <eliot.mira...@gmail.com> wrote: > > Hi Esteban, > > On Aug 7, 2018, at 4:36 AM, Esteban Lorenzano <esteba...@gmail.com> wrote: > > I’m slowly working on that VM because we want it to be the default for > Pharo 8. > In our vision, it should be a responsibility of the image to start or not > a graphical UI, so we are preparing (we have been preparing to it for > years, actually) to achieve this behaviour. > To make this work, we need all platforms covered (and another huge > quantity of changes here and there). > Anyway, I didn’t merge because I wanted to have win64 covered, not just > what we have now, and since no-one was using that VM I didn’t feel pression > to do it :) > > > 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 <norb...@hartl.name> wrote: > > What keeps you from doing a pull request to opensmalltalk-vm ? > > Am 07.08.2018 um 07:47 schrieb Esteban Lorenzano <esteba...@gmail.com>: > > 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 <b...@openinworld.com> wrote: > > On 7 August 2018 at 05:12, Eliot Miranda <eliot.mira...@gmail.com> wrote: > >> >> Hi Ben, >> > Feel free to make this edit and commit >> > > I'm pushing changes here... > > https://github.com/bencoman/opensmalltalk-vm/tree/MinimalisticHeadless-x64-msvc2017 > > 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 <b...@openinworld.com> wrote: > >> On 6 August 2018 at 11:50, Ben Coman <b...@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-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
