December 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Fwd: Announcing Repl.it Multiplayer

by Evan Donahue

Also Croquet: https://en.wikipedia.org/wiki/Croquet_Project#Open_Cobalt -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 6, 2018

Re: [Pharo-dev] Fwd: Announcing Repl.it Multiplayer

by Santiago Bragagnolo

Yeah I think I see your point. I'm going to check out those projects and learn some :). Thx! El jue., 6 de dic. de 2018 23:03, Eliot Miranda <eliot.miranda(a)gmail.com> escribiÃ³: > Hi Santiago, > > On Thu, Dec 6, 2018 at 1:52 PM Santiago Bragagnolo < > santiagobragagnolo(a)gmail.com> wrote: > >> Would this be interesting to have in pharo?? >> > > There is already previous relevant work. Look up Kansas for Self > http://wiki.squeak.org/squeak/1357 and Nebraska for Squeak > http://wiki.squeak.org/squeak/1356. Focussing on the Multiplayer like UI > would be a major regression. Note that we already have lots fo relevant > infrastructure, such as a VNC server that allows desktops to be shared. > Building a shared programming environment for Pharo doesn't need to start > from such limited models as the Multiplayer. > > >> >> What do you think? >> >> ---------- Forwarded message --------- >> From: Amjad from Repl.it <contact(a)repl.it> >> Date: jue., 6 de dic. de 2018 21:55 >> Subject: Announcing Repl.it Multiplayer >> To: <santiagobragagnolo(a)gmail.com> >> >> >> The official release of Repl.it Multiplayer, the collaborative coding >> experience. >> [image: Repl.it Logo] >> <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy0-2F0rOvSNWPLVoxcc…> >> >> Hey Santiago, >> >> Professional programmers all know that software development is a >> fundamentally social experience. But coding remains a single-player >> experience by default â today, we're changing this! >> >> As part of our mission to make computing more accessible, we believe >> connecting coders, learners, and teachers together in real time, in the >> development environment, is a big piece of the puzzle. That's why we're >> proud to announce *Multiplayer*. >> >> Multiplayer lets you code with friends in the same editor, execute >> programs in the same interpreter, interact with the same terminal, chat in >> the IDE, edit files and share the same system resources, and ship >> applications from the same interface! We've redesigned every part of our >> infrastructure to work in multiplayer mode -- from the filesystem to the >> interpreter. >> [image: Repl.it Multiplayer] >> <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy2nGqoz6hoT3s1h4Iok…> >> >> Read more about it here >> <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy2nGqoz6hoT3s1h4Iok…>, >> or, better yet, hop in >> <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy7y9lyv5Ff-2FoVbyQr…>, >> invite your friends and start coding! >> >> Amjad from Repl.it >> >> 767 Bryant St, #210, San Francisco, CA 94107 >> >> Unsubscribe >> <http://url1361.repl.it/asm/unsubscribe/?user_id=8107274&data=346ff9QOfXR57C…> >> - Unsubscribe Preferences >> <http://url1361.repl.it/asm/?user_id=8107274&data=USDh4jRtVtwga9cUFmXIXfBZ19…> >> > > > -- > _,,,^..^,,,_ > best, Eliot >

Dec. 6, 2018

Re: [Pharo-dev] Fwd: Announcing Repl.it Multiplayer

by Eliot Miranda

Hi Santiago, On Thu, Dec 6, 2018 at 1:52 PM Santiago Bragagnolo < santiagobragagnolo(a)gmail.com> wrote: > Would this be interesting to have in pharo?? > There is already previous relevant work. Look up Kansas for Self http://wiki.squeak.org/squeak/1357 and Nebraska for Squeak http://wiki.squeak.org/squeak/1356. Focussing on the Multiplayer like UI would be a major regression. Note that we already have lots fo relevant infrastructure, such as a VNC server that allows desktops to be shared. Building a shared programming environment for Pharo doesn't need to start from such limited models as the Multiplayer. > > What do you think? > > ---------- Forwarded message --------- > From: Amjad from Repl.it <contact(a)repl.it> > Date: jue., 6 de dic. de 2018 21:55 > Subject: Announcing Repl.it Multiplayer > To: <santiagobragagnolo(a)gmail.com> > > > The official release of Repl.it Multiplayer, the collaborative coding > experience. > [image: Repl.it Logo] > <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy0-2F0rOvSNWPLVoxcc…> > > Hey Santiago, > > Professional programmers all know that software development is a > fundamentally social experience. But coding remains a single-player > experience by default â today, we're changing this! > > As part of our mission to make computing more accessible, we believe > connecting coders, learners, and teachers together in real time, in the > development environment, is a big piece of the puzzle. That's why we're > proud to announce *Multiplayer*. > > Multiplayer lets you code with friends in the same editor, execute > programs in the same interpreter, interact with the same terminal, chat in > the IDE, edit files and share the same system resources, and ship > applications from the same interface! We've redesigned every part of our > infrastructure to work in multiplayer mode -- from the filesystem to the > interpreter. > [image: Repl.it Multiplayer] > <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy2nGqoz6hoT3s1h4Iok…> > > Read more about it here > <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy2nGqoz6hoT3s1h4Iok…>, > or, better yet, hop in > <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy7y9lyv5Ff-2FoVbyQr…>, > invite your friends and start coding! > > Amjad from Repl.it > > 767 Bryant St, #210, San Francisco, CA 94107 > > Unsubscribe > <http://url1361.repl.it/asm/unsubscribe/?user_id=8107274&data=346ff9QOfXR57C…> > - Unsubscribe Preferences > <http://url1361.repl.it/asm/?user_id=8107274&data=USDh4jRtVtwga9cUFmXIXfBZ19…> > -- _,,,^..^,,,_ best, Eliot

Dec. 6, 2018

Fwd: Announcing Repl.it Multiplayer

by Santiago Bragagnolo

Would this be interesting to have in pharo?? What do you think? ---------- Forwarded message --------- From: Amjad from Repl.it <contact(a)repl.it> Date: jue., 6 de dic. de 2018 21:55 Subject: Announcing Repl.it Multiplayer To: <santiagobragagnolo(a)gmail.com> The official release of Repl.it Multiplayer, the collaborative coding experience. [image: Repl.it Logo] <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy0-2F0rOvSNWPLVoxcc…> Hey Santiago, Professional programmers all know that software development is a fundamentally social experience. But coding remains a single-player experience by default â today, we're changing this! As part of our mission to make computing more accessible, we believe connecting coders, learners, and teachers together in real time, in the development environment, is a big piece of the puzzle. That's why we're proud to announce *Multiplayer*. Multiplayer lets you code with friends in the same editor, execute programs in the same interpreter, interact with the same terminal, chat in the IDE, edit files and share the same system resources, and ship applications from the same interface! We've redesigned every part of our infrastructure to work in multiplayer mode -- from the filesystem to the interpreter. [image: Repl.it Multiplayer] <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy2nGqoz6hoT3s1h4Iok…> Read more about it here <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy2nGqoz6hoT3s1h4Iok…>, or, better yet, hop in <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy7y9lyv5Ff-2FoVbyQr…>, invite your friends and start coding! Amjad from Repl.it 767 Bryant St, #210, San Francisco, CA 94107 Unsubscribe <http://url1361.repl.it/asm/unsubscribe/?user_id=8107274&data=346ff9QOfXR57C…> - Unsubscribe Preferences <http://url1361.repl.it/asm/?user_id=8107274&data=USDh4jRtVtwga9cUFmXIXfBZ19…>

Dec. 6, 2018

[Pharo 7.0] Build #21: 22733-Some-menubar-cleaning

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #21 was: FAILURE. The Pull Request #2044 was integrated: "22733-Some-menubar-cleaning" Pull request url: https://github.com/pharo-project/pharo/pull/2044 Issue Url: https://pharo.fogbugz.com/f/cases/22733 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 6, 2018

[Pharo 7.0] Build #20: 22313-Packages-are-created-for-extension-methods-that-does-not-are-exactly-the-package-name

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #20 was: SUCCESS. The Pull Request #1741 was integrated: "22313-Packages-are-created-for-extension-methods-that-does-not-are-exactly-the-package-name" Pull request url: https://github.com/pharo-project/pharo/pull/1741 Issue Url: https://pharo.fogbugz.com/f/cases/22313 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 6, 2018

OSSubprocess equivalent in Pharo7?

by Hans-Martin

Hello, I noticed that theOSSubprocess functionality for communicating with OS subprocesses depends on OSSAttachableFileStream which is a subclass of deprecated FileStream (incidentally, the project is not marked as being compatible with Pharo7). The popen()/fgetc() based examples in UNIXProcess are blocking, which is unusable for any but the most basic external command executions. Are there plans to implement a proper replacement in Pharo7? Cheers, Hans-Martin -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 5, 2018

Re: [Pharo-dev] Minheadless trial

by Ben Coman

On Thu, 6 Dec 2018 at 01:25, Nicolas Cellier < nicolas.cellier.aka.nice(a)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" <estebanlm(a)gmail.com> a Ã©crit : > > > > On 5 Dec 2018, at 16:19, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Wed, 5 Dec 2018 at 21:53, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> Hi Eliot, >> >> On 5 Dec 2018, at 14:46, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> Hi Esteban, >> >> On Aug 7, 2018, at 4:36 AM, Esteban Lorenzano <estebanlm(a)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 > > > >

Dec. 5, 2018

Re: [Pharo-dev] Minheadless trial

by 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" <estebanlm(a)gmail.com> a Ã©crit : On 5 Dec 2018, at 16:19, Ben Coman <btc(a)openinworld.com> wrote: On Wed, 5 Dec 2018 at 21:53, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi Eliot, > > On 5 Dec 2018, at 14:46, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Esteban, > > On Aug 7, 2018, at 4:36 AM, Esteban Lorenzano <estebanlm(a)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

Dec. 5, 2018

Re: [Pharo-dev] Minheadless trial

by Eliot Miranda

Hi Esteban, On Wed, Dec 5, 2018 at 5:53 AM Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi Eliot, > > On 5 Dec 2018, at 14:46, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Esteban, > > On Aug 7, 2018, at 4:36 AM, Esteban Lorenzano <estebanlm(a)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(a)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(a)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(a)openinworld.com> wrote: > > On 7 August 2018 at 05:12, Eliot Miranda <eliot.miranda(a)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-… > > 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(a)openinworld.com> wrote: > >> On 6 August 2018 at 11:50, Ben Coman <btc(a)openinworld.com> wrote: >> >> >> https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhea… >> 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-co… > > 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/minhea… > > > 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

Dec. 5, 2018