<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
p.gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext, li.gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext, div.gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext
{mso-style-name:gmail-m_-3012011191253006350gmail-m-3504913714629177448msoplaintext;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle20
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><div><div><p class=MsoNormal style='margin-left:.5in'>You seem to misunderstand the problem. This is not a technical problem, but a political problem. <span style='color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Your last e-mail seemed very technical. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>I seek a technical solution to a technical problem. The solution is to write, with as much leverage as possible, a simple, fast, easy to maintain VM (that one person can maintain), using a well- maintained (by other people, mostly) tool (Pony, currently) that provably guarantees type safety and integral multicore, multiCPU, multinode (coming) concurrency, so that we don’t have to trouble ourselves with such potentially taxing matters. I’ll do it without community assistance if I must, but figure the community would like to be aware of this option, and perhaps learn some new skills and participate. The Pharo VM crew seem quite fluent and capable with their current problem space, trajectory, and tool set, but are still very busy with a very complicated VM for a very long time. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>I submit for consideration the idea that <u>conscious, concerted complexity reduction</u>—not making the program work and not making it run fast—is the priority. The Pharo VM has been going on for a while now, as you mentioned. Perhaps a change is needed. Taking some time to study the features and merits of Pony might prove fruitful for the overall VM effort. Yes, some new skills will be needed.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'>The language seems very cool,<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>Indeed, but I care little about ‘cool’ anymore. Pony is wicked-powerful compared to the competition (C, Rust, Go). It has extreme utility, especially for writing a VM that must efficiently use all cores. I care about that.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'> but it still have to be proven in production by a large company that shows that is actually being used, <span style='color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>It has already happened.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Production use of Pony: <a href="https://blog.wallaroolabs.com/2017/10/why-we-used-pony-to-write-wallaroo/">https://blog.wallaroolabs.com/2017/10/why-we-used-pony-to-write-wallaroo/</a><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'>it is maintained and will be keep being maintained for decades, which is something that can be said about about C/C++ (Many companies) and Rust (Mozilla) (Go (Google) is out of the question because of its mandatory garbage collector). All of the people already working on the VM has their own political and technical agendas, and they will continue working on that. Mathematical and safeness proofs are not enough. The usage of Slang is also bad on this regard, but with the difference that there is already an existing open source VM that works (and used by several companies), and making a new VM is a high risk endeavor from a technical point of view (and political and business also).<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>This means that if you really want to use Pony for making a Pharo or Squeak VM, then you are going to have to make it yourself, or to pay someone else willing to do it. You will not be able convince the existing people to adopt a new language <o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>Those here in the Pharo lists are likely sharp enough to evaluate Pony on their own, and determine its usefulness in the design of a leaner and faster VM, with little or no help and inspiration from me. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><a href="https://www.ponylang.io/">https://www.ponylang.io/</a><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>and<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><a href="https://ponylang.zulipchat.com/">https://ponylang.zulipchat.com/</a><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>are the best places to start learning about Pony. There are many YT presentations, too. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>unless you have something running in that language that actually proves that is worth it to change.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>How complete is the documentation on the current Pharo VM? </span><o:p></o:p></p></div></blockquote><div><p class=MsoNormal style='margin-left:10.9pt'> Very incomplete. The best documentation is the code itself, then you have old wiki articles in the Squeak wikis, and some technical articles in Eliot Miranda and Clément Bera blogs. There are some additional ongoing efforts on documenting the VM from the Pharo people: <a href="https://github.com/SquareBracketAssociates/Booklet-PharoVirtualMachine">https://github.com/SquareBracketAssociates/Booklet-PharoVirtualMachine</a> and here: <a href="https://github.com/pharo-open-documentation/pharo-wiki/tree/master/PharoVirtualMachine">https://github.com/pharo-open-documentation/pharo-wiki/tree/master/PharoVirtualMachine</a><o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:10.9pt'><span style='color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>Thanks for the links.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p></div><div><p class=MsoNormal style='margin-left:10.9pt'>I also wrote a very simplistic vm in pure C that can load a Pharo 64 bits image, interpret the bytecodes here: <a href="https://github.com/ronsaldo/crankvm">https://github.com/ronsaldo/crankvm</a> . <o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>That’s useful. Thank you. I’ll have look. It seems like a good starting point, if the current Pharo VM proves too opaque/crufty. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'>This cannot be used for actually running Pharo because most of the primitives are not yet implemented. I wrote this mostly for documenting myself on how things work, <o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>That would be my approach as well. Can you say more about what CrankVM can and can’t do? I suppose there is no GUI. This is a CLI only? Debugging? I suppose not. Is there any doc on it or how to use it?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'>and for getting into that I had to read several parts of the existing vm sources, and the blue book ( <a href="http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook.pdf">http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook.pdf</a> ).<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:25.1pt'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>We are talking about different, but related things: you can write a Pony program whose domain-level state-machine is wrong or unfinished and therefore not working correctly. This is called <i>livelocking</i>. It’s a domain-level problem, not a system problem (for Pony). Livelocking is the developer’s problem, not Pony’s. Compiled Pony code cannot deadlock/data-race. It’s not possible. Dealing with livelocking (programming a state machine thoroughly and correctly so that you get the behavior you want and describe in your code) is the subject of a special grammar and tool I’m working on for state-machine based programming. This would supplement or replace the system browser. Right now my approach to state-machine creation is a grammatical discipline that works very well for me. I use it in Smalltalk, increasingly, and won’t code without it anymore. I don’t want to be limited to green threads, however, and definitely don’t want explicit concurrency management. I don’t have that much time to waste, and hope everyone reading this has been burnt badly enough by concurrency bugs to have a similar view. </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:25.1pt'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:61.1pt'>You even need to model network and power failures in your state machine. So the programming language may help you a lot with you concurrent, distributed and fault tolerant system programming, but they are not a silver bullet that guarantees that your system is actually going to be correct.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:25.1pt'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:25.1pt'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>See above concerning the difference between livelock and deadlock.</span><o:p></o:p></p></div></blockquote><div><p class=MsoNormal style='margin-left:25.1pt'> <o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>Thanks for the correct terminology. But from the point of view of the user they are same. And a livelock seems to be far more dangerous than a traditional deadlock for which you already have some debugging tools that are relatively easy to use.<o:p></o:p></p><p class=MsoNormal style='margin-left:25.1pt'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:25.1pt'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>The causes of data-races can be hard to debug because their symptoms can be hard, sometimes impossible, to reproduce reliably. Such problems I do not want routinely to debug, along with my application logic, no matter what debugging tools I have, especially when the compiler/ Pony provides provable guarantees. I don’t want to do unneeded work because I know how to do the work and have tools to help me do the work. I’m trying to factor out and eliminate large blocks of work, categorically. Pony takes care of synchronization issues at compile-time. That is one very big problem solved. Pony has raw speed comparable to C. That is a second very big problem solved. Pony runs faster than C as it scales to more cores, and no significant additional effort is needed to make this happen (you are programming with actors, and must learn to do that, anyway). That is a third big problem solved, as long as you are willing to hone your state-machine writing skills, and learn to use actors. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'> You can create a pthread_mutex <o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>Pony doesn’t use mutexes because they aren’t needed. They waste bandwidth and increase complexity/maintenance cost, depending on how fine-grained your usage is. Don’t go there. It’s a mistake, and the practice doesn’t scale, neither for the machine nor in the mind of a human programmer.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'>with deadlock detection for detecting bug, or run your program through valgrind for detecting race conditions and deadlocks. The point of this is that the language safety net is not enough, and in fact it could actually be dangerous because it can instill a false sense of safeness.<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>Pony is far from dangerous (it is designed for safety and speed), based on my own limited use (still learning how to use it) and the reports of others who know it much better and use it regularly, like those at Wallaroo Labs, who use it in production (link above).<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>Pony’s type safety and concurrency model work as claimed. You still need to write your program as a state-machine, correctly. Consider studying the ref-caps to see how they provide the stated guarantees </span><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>(<a href="https://www.ponylang.io/">https://www.ponylang.io/</a>). <span style='color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>There is no false sense of anything with Pony. It is able to do what it claims. <o:p></o:p></span></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> <o:p></o:p></span></p><p class=MsoNormal style='margin-left:10.9pt'> That false sense of safeness can be very dangerous in real world projects with deadlines that have to be met, and non-technical managers which are going to underestimate the deadline far more on this false sense of safeness. And since in the real world deadlines have to bet met, bugs and incomplete solutions are simply shipped.<o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Can Sysmel manage many threads on many cores (running actor threads in parallel, not just green-thread-concurrently on one core), whilst guaranteeing no data-races, and switch automatically between actor-threads, without blocking (no wasted CPU cycles), in 5 to 15 ns? Pony can do that now.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>If Sysmel cannot do those operations, or cannot do them as fast, can you add the abilities cost-effectively? They already work in Pony, and a very active team drives the effort.</span><o:p></o:p></p></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:10.9pt'>I am developing the language, and if I want or need I can create a minimal vm suitable for my purpose (I am not even trying to convince existing people to use it for now, I will when I have the next version of Woden<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>Woden (and Vulkan) is actually my main reason for wanting a much faster VM. Woden is why I found Pony. Most of my work is simulation. I’m not willing to live through another quarter-century of slow Smalltalks. The split dev paradigm used by Google’s Flutter should work for a Smalltalk on a Pony-based VM: use JIT mode most of the time for highest dev-time speeds; use AOT mode some of the time for highest run-time speeds and reality checks. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:10.9pt'> running on it, and they will be able to just use a Pharo subset for scripting), for which I can adapt into my purposes and needs, which are currently only being fulfilled by C and C++ (and perhaps Rust, but I found it too complicated). I would just use C++ if it had runtime reflection, and easy to do, reliable and robust live programming support but it does not have these crucial features. You can implement live programming in C++ by serializing your program state, changing the dll with your code, and then deserialize your program state. Program state serialization is not easy.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:10.9pt'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:10.9pt'>Real multi-threading on Sysmel is already supported when you use it without garbage collection (the language is strongly modeled after C++11 when used in this way). When you enable the GC for Smalltalk semantics, it is currently using the Boehm conservative GC (I am using it for getting things running), so the concurrency will be limited by the stop the world semantics of the GC. When I implement a proper GC, I will be able to dissociate threads that only use the native runtime from the GC. <o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>Are you saying that Sysmel will have per-actor/thread heaps?</span><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'>But for "many threads", and high parallelism, what I use is the GPU where Sysmel can also be used as a shading language by generating Spir-V for Vulkan <o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>Yes, Vulkan is very interesting. I’m glad to see someone working in this area.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>Many thanks for your contributions to Pharo graphics. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>3D simulation is my main concern, and is why I’m focused on high-performance programming tools like Pony. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>Sysmel would still need to be able to use all cores on all CPUs, all of the time, for general application logic that cannot easily use the GPU. Is that planned?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'>consumption (for this the llvm backend is not used, it does not expose all of the required semantics, unless the changed it recently). As for the actor model and by default non-blocking semantics, I just do not care about them (for now) because I know they bring their own problem that can have their impact on other parts of system (e.g. non-blocking IO everywhere and by default, on operating systems that do not support it very well). Instead I prefer explicit semantics, and if the user wants actor, then implement them as just another library in the system.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>BTW: how do you implement an actor?<o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>S<span style='color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>ee the Pony pages below.</span><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'> with a message queue, and how do you implement a message queue? with a mutex and a condition variable. What about deadlock?<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>No deadlocks can happen. You are, however, free to screw up your app’s state-machine logic as much as you wish before you finally make it work correctly. This programming problem is culture-wide, no matter what language(s) you like, and can be fixed with a new tool and a different way of looking at what a program is and how it behaves. Editing text in a method pane doesn’t cover all that needs to happen during the building of a state-machine, not if you want your state-machine to work the first time you test it. The system browser is mostly just that--a way of browsing. I don’t consider it an adequate programming tool if efficient building of state-machines is your aim—and this must be your aim if you want to use multicore CPUs, efficiently.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'> you are only taking a single mutex on the queue, so you cannot have a deadlock, since you need at least two mutexes for the dead lock that are taken in a different order. If you have N mutexes, for not having a deadlock you only have to take these N mutexe in the same order.<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>Pony has no mutexes because they aren’t needed in state-machines whose state-changes are caused by actors asynchronously sending messages to each other. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'> That sounds easy, but in the practice is not and you would have to sort the actual addresses of the mutexes, and in many cases you will realize that you need to take an additional mutex after having already taken other mutexes (I know it from practice). The mutex of the queue is always the one taken last, and that is why it is safe to use the queue for message passing.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>So, what is so special about these actor languages? <o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>A nice overview of the interesting/unique parts of Pony:</span><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> <a href="https://www.ponylang.io/discover/">https://www.ponylang.io/discover/</a>.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>The following page has some meaty bits. Just skip the code examples and read the prose: </span><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><a href="https://www.ponylang.io/reference/pony-performance-cheatsheet/">https://www.ponylang.io/reference/pony-performance-cheatsheet/</a>.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'>they actually use a M:N threading model where they actually use green threads in order to multiplex multiple cooperative threads into the different cores of the CPU. They only need to create N native threads that are pinned into the different cores of the CPU (sched_setaffinity in Linux), and the green threads are created by allocating stack memory and having a simple trampoline that stores all of the caller saved registers in the stack, switches the stack pointer, restores these same registers and returns. BTW the operating system level context switching machinery is also implemented on the same way, but it could have some additional instructions for returning into unprivileged code.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>These 5 to 15 ns figures typically come from switching the stack. And with 64 bits addresses the simplest way for allocating the stack memory is by just allocating large uncommitted memory for the stack memory, or use some other fancier schemes (See here: <a href="https://blog.cloudflare.com/how-stacks-are-handled-in-go/">https://blog.cloudflare.com/how-stacks-are-handled-in-go/</a> ). You would also need a task queue (or process queue in OS terminology) for not blocking the different actors when they are waiting for messages. There are several papers that discuss how to implement this task queue which tends to be the main bottleneck of these system. In the case of userspace, since the OS is not aware of you green threads, you also need asynchronous IO for everything so that an IO operation does not block all of the tasks that running in a single core (I believe that I read from a different mechanism from a paper from Go that is more flexible, but I forgot about it).<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>If you do not actually need a coroutine, and model your actors in terms of a single function application that receives a single message and process it, then you only need a single stack. (Fetch message from queue, apply the function, done), and you do not even have that 5-15 ns overhead for stack switching (you may have another overhead on pushing the pending actor on the ready queue that could outweigh the performance advantage). This is similar to a traditional asynchronous job system for which you only need a thread pool. And this can also be implemented in C/C++.<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>I’m happy with the 5 to 15 ns time to switch interleaved actor threads on one core. This is orders of magnitude faster than what I can accomplish with communicating Smalltalk images.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>Here again are the main traction points:<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>Pony now gives us:<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>1. Raw speed comparable to C<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>2. Fast FFI--no marshalling.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>2. Strict type safety<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>3. Guaranteed no deadlocks/data-races.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>4. Graceful, low programming-effort scaling-up across more cores, more CPUs, and eventually more machine nodes when the Pony group implement the networking extension of Pony.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>5. 5 to 15 ns actor-thread switching time when two or more actors are running on one core.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>…<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>(There is more, but these are the main points for now.)<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>I need at least these abilities in any programming tool I use to make a VM that will use all cores reliably and smoothly.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>Can Sysmel do those five things now? In six months? In a year?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'> <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>You seem to be working hard on these abilities. If, as you contemplate the amount of work needed to realize the above, you cringe, moan, groan, or feel your heart sink from your chest to where you gonads are, then the workload and anxiety are too great. If you that is so, consider using Pony so that you needn’t do so much of the work by yourself. Maybe you can just re-implement Sysmel with Pony to take advantage of it unique abilities.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'> <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%'>Shaping<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p></div></div><div><div><p class=MsoNormal>El jue., 9 abr. 2020 a las 7:43, Shaping (<<a href="mailto:shaping@uurda.org">shaping@uurda.org</a>>) escribió:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><p class=MsoNormal> <o:p></o:p></p><div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>I have to admit that that language looks quite interesting, but it is not appropriate for writing an actual VM.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>The point of the Pony language and concurrency model is to be able to write <u>any program</u>, even a VM, at scale and use all of the cores, with minimal programming effort (compared to what the developer must endure when explicitly managing synchronization issues).</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>One thing is having the actor object model for writing an application that scales where it can be a very desirable property, but another thing is writing a virtual machine where you have time constraints for the just in time compiler in a single CPU to reduce initialization time.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>A VM is a program. You can write any program you want with Pony. The heaps are already actor-centric and usually very tiny, just the way we need them for high-performance, real-time apps:</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>Orca: GC and Type System Co-Design for Actor Languages:</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><a href="https://www.ponylang.io/media/papers/orca_gc_and_type_system_co-design_for_actor_languages.pdf" target="_blank">https://www.ponylang.io/media/papers/orca_gc_and_type_system_co-design_for_actor_languages.pdf</a></span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Can you be more specific about which program construct cannot be written in Pony or cannot be written to run fast enough?</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>You can write as much asynchronous and synchronous code as you wish, where and when you needed it. The balance point is yours, as the developer, to choose. </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>In fact, most of the methods are actually interpreted and they are only compiled after being executed several times for reducing this startup time.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Of course. But this is not a problem peculiar to Pony (or C or Rust or…). It’s just another programming task needed in the context of VM design. Note the comment about using both JIT and AOT, as desired, during development. In any case, if you use Pony, use a state-machine (which we all should do anyway). If the developer cannot or will not develop the discipline needed to build state-machines, systematically, Pony or any highly concurrent, actor-based programming model will only thwart and frustrate him. We can’t efficiently use all these cores without such a programming model. </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>I think I would start by using the Pony compiler from a Smalltalk browser (mod the browser to accommodate the actors too). Source code in files, searching, and scrolling are too inefficient. </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>In this problem domain, the actor model and the thread safeness guaranteed by it does not help you at all, and <span style='color:#00B0F0'>deadlocks can always be produced</span>.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>This statement is incorrect in the case of Pony (but we have a terminology problem; see below), and this was the main reason for the post. Here is the gist again: <b><u>Deadlocks and data-races are not possible in a Pony program that compiles.</u></b> This is mathematically guaranteed. You can glean this fact from the videos or study the details in Pony papers.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'> I did have deadlocks problems with synchronous messages in Erlang<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Pony is not Erlang. It is like Erlang is many ways, but vastly improved. My qualified (“in the round, for starters”) comparison was a mistake. I should have omitted the whole comment. The Erlang/Pony comparison never goes well. Pony is a different animal. And it’s seriously powerful. Forget about Erlang. Really. Just forget about it. Use what was learnt there, and implement it in Pony. </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>which forced me to go into using asynchronous messages, but if you do not model your domain state machine you could also end with a deadlock by using asynchronous messages, or even worse, an inconsistent state such as an incomplete credit card transaction in a highly distributed system!<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>We are talking about different, but related things: you can write a Pony program whose domain-level state-machine is wrong or unfinished and therefore not working correctly. This is called <i>livelocking</i>. It’s a domain-level problem, not a system problem (for Pony). Livelocking is the developer’s problem, not Pony’s. Compiled Pony code cannot deadlock/data-race. It’s not possible. Dealing with livelocking (programming a state machine thoroughly and correctly so that you get the behavior you want and describe in your code) is the subject of a special grammar and tool I’m working on for state-machine based programming. This would supplement or replace the system browser. Right now my approach to state-machine creating is a grammatical discipline that works very well for me. I use it in Smalltalk, increasingly, and tend not to code without it anymore. I don’t want to be limited to green threads, however, and definitely don’t want explicit concurrency management. I don’t have that much time to waste, and hope everyone reading this has been burnt badly enough by concurrency bugs to have a similar view. </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>You even need to model network and power failures in your state machine. So the programming language may help you a lot with you concurrent, distributed and fault tolerant system programming, but they are not a silver bullet that guarantees that your system is actually going to be correct.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>See above concerning the difference between livelock and deadlock. </span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>Going back to the task of developing a VM, you also need to be able to perform dangerous memory accessing operations for at least the following three tasks:<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>1. Implementing the garbage collector.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Actually no; there is nothing dangerous here. In Pony, a separate heap exists for each actor. These are generally tiny, and come and go quickly. If they are not tiny or at least very simple/uniform in structure, they should be made so by refactoring actor scope, until they are. Smallness and clarity of purpose are the main criteria for determining whether you’ve written an actor well. Those two properties also greatly ease debugging of the actor. If you have a big actor not factored as a network of smaller ones, you’ve done something wrong, or you’ve just started your state machine, and have some factoring yet to do. You still have classes, but these are an organizational tool for synchronous code used by Actors and their asynchronous behaviors.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>2. Direct access to object slots for implementing the bytecode interpreter.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Not a problem. It’s just a program feature. So we write it as it needs to be. </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>3. Copying compiled machine code into executable memory and performing position dependent relocations.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Doable. The Pony FFI works well even at this early stage.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>The machine code generation and installation can be separated in two stage (the current VM just generates the code directly into the executable memory), and in fact having these two separated stages for compilation and installation is a requirement for operating systems that enforce W^X page level permissions, specially if you want a concurrent VM.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Then do that. </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>You need to install the executable code in an atomic way, so you need to suspend the threads while changing the executable permission into the writable permission. You may get away of this restriction if you are allowed to map the same physical memory into different virtual addresses ranges with different permissions (one writeable, and one executable).<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>…as needed.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Pony is changing quickly: <a href="https://ponylang.zulipchat.com/" target="_blank">https://ponylang.zulipchat.com/</a>.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>It’s being improved weekly. The Pony group are also working on a security model (to deal with attacks via FFI and other sources), but this will be some time coming. Feel free to contribute. The language is highly moldable, especially at this stage. I think the version is 0.33. If you need a feature or convenience not present, request it. The group is very responsive, and eager to improve the tool.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>If there were no Smalltalk, I would certainly use Pony before C, Rust, or Go, even at this early pre-1.0 stage. </span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>For these reasons, you need an unsafe language such as C/C++ for at least these tasks, or a language that allows you to turn off the type and memory safeness net. I heard that Rust has an unsafe pointer that you could also for these purposes.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>The Pony FFI will work here. C libs are sometimes needed, and operations in C code are of course not guaranteed to be safe, in any case. </span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>The Pharo team is going with the existing virtual machine for quite a while. You cannot just replace something that is not well documented by something new, specially when you do not have that many resources for making a new vm. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>One of the main drivers in the choice of Pony is to reduce the resources needed to create a highly performant, simple VM. One notable, Pharo/Smalltalk-related problem for high-speed apps is stop-the-world GCing in the one large system heap. This won’t work for high-performance, highly concurrent, highly scalable apps, especially not for for real-time ones, and <u>must go away</u>, if latencies approaching deterministic are to be achieved. Pony has already solved this problem with per-actor heaps. That design feature is very interesting because it represents much hard work that need not be done. </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>You first need to document completely the existing one, the semantics of the bytecodes, how they are implemented, and also the same with the primitives.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Agreed. I’m not claiming that VM development is easy or trivial, generally or via Pony. VMs are arguably one of the most complicated things that humans create (<i>not a compliment</i>). But Pony solves more concurrency-related problems at compile-time than any other available tool.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>How complete is the documentation on the current Pharo VM? </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>As for myself, I am putting my bets on another language that I am developing (Sysmel: <a href="https://github.com/ronsaldo/sysmel" target="_blank">https://github.com/ronsaldo/sysmel</a> ), and in full ahead-of-time compilation, but my problem domain is video game programming, low-level operating system, driver development and embedded programming where I actually want to have control of the machine.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>I’ve read some on Sysmel. It appears to be an outstanding tool.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Does Sysmel implement multicore concurrency, and guarantee no deadlocks/data-races on compile?</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Pony, the language and concurrency model, will not stop us from doing anything that can be done with the machine and OS. The Pony language is not as interesting to me as its concurrency model. Don’t like Pony syntax (and I don’t)? Then fork and change it. You have all the source. (I’d prefer to see keyword selectors everywhere, even without the usual attendant polymorphism. Seriously.) </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>Since I have written my compiler in Pharo, I can just reuse the Opal Compiler for doing AST to AST translation and just compile Pharo (with some limitations, for example no thisContext) into my runtime environment. If I want a more dynamic environment, I can also serialize a Pharo CompiledMethod, send it through a socket and then interpret it on the Sysmel side: <a href="https://github.com/ronsaldo/sysmel/blob/master/module-sources/Sysmel.Core/Smalltalk-Bootstrap/InterpretedMethod.sysmel" target="_blank">https://github.com/ronsaldo/sysmel/blob/master/module-sources/Sysmel.Core/Smalltalk-Bootstrap/InterpretedMethod.sysmel</a> by just reusing the existing language semantics. Currently although I am just supporting Linux, and Windows support is coming in a couple of weeks after getting a proper module system working for reducing compilation times. For the backend I am using LLVM, wasm is not yet supported because I am generating some IR that are not supported by the wasm backend <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Wasm and WASI will be good when they are ready.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>(vtable layouts, and some intrinsics that I am using for non-local returns), but they should not be that complicated to fix.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Can Sysmel manage many threads on many cores (running actor threads in parallel, not just green-thread-concurrently on one core), whilst guaranteeing no data-races, and switch automatically between actor-threads, without blocking (no wasted CPU cycles), in 5 to 15 ns? Pony can do that now.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>If Sysmel cannot do those operations, or cannot do them as fast, can you add the abilities cost-effectively? They already work in Pony, and a very active team drives the effort.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Best,</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Shaping</span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>El lun., 6 abr. 2020 a las 6:05, Shaping (<<a href="mailto:shaping@uurda.org" target="_blank">shaping@uurda.org</a>>) escribió:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid windowtext 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt;border-color:currentcolor currentcolor currentcolor rgb(204,204,204)'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>I should have initially posted this to the Pharo-dev list, as well.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><o:p></o:p></p><div><div style='border:none;border-top:solid windowtext 1.0pt;padding:3.0pt 0in 0in 0in;border-color:currentcolor'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b>From:</b> Pharo-users [mailto:<a href="mailto:pharo-users-bounces@lists.pharo.org" target="_blank">pharo-users-bounces@lists.pharo.org</a>] <b>On Behalf Of </b>Shaping<br><b>Sent:</b> Friday, 3 April, 2020 14:05<br><b>To:</b> 'Any question about pharo is welcome' <<a href="mailto:pharo-users@lists.pharo.org" target="_blank">pharo-users@lists.pharo.org</a>><br><b>Subject:</b> Re: [Pharo-users] Latest PharoJS Success Story; Wasm/WASI; very keen on Pony for the Pharo VM<o:p></o:p></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext>All:<o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext style='margin-left:.5in'>> Brain Treats got stuck during launch on my LG.<o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext style='margin-left:.5in'>> <o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext style='margin-left:.5in'>Which android version are you using ?<o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext> <o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'>The phone is old and this is likely the problem.</span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'> </span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'>Android version: 4.4.2</span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'>Kernel version: 3.4.0</span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'> </span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext style='margin-left:.5in'>> Is there a plan to move PharoJS to Wasm/WASI?<o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext style='margin-left:.5in'>> <o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext style='margin-left:.5in'>Dave and I talked about it a long time ago. This sounds like a good idea.<o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext style='margin-left:.5in'>Actually, Dave has a very ambition idea = turn PharoJS into Pharo* where * can be different targets.<o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext style='margin-left:.5in'>But, there's a lot to do before reaching this goal. So, don't expect it any time soon.<o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'> </span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'>Not to change the topic too much, but the following is related and I often think of it…</span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'> </span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'>Consider writing the pharo VM in Wasm or, better, with <b><u>Pony</u></b> (which can emit Wasm, as needed). Pony’s reference-capability-based (ref-cap) concurrency-model guarantees provably that no data-races or deadlocks can happen if the code compiles; this solves a very large class of extremely ugly concurrency problems that no one ever wants to face. </span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'> </span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'>Pony gives high-performance concurrency (5 to 15 ns actor-thread switching time, depending on platform), and solves the most difficult class of synchronization problems at compile time. It runs as fast as C. It runs faster than C, as concurrency scales. You can’t scale a highly concurrent app efficiently in C, and really shouldn’t try if you wish to remain happy and mentally healthy.</span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'> </span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'>Pony is still pre-1.0, but the group is very active and competent. I think we should consider using it to build the VM. Have a look. Some videos for your amusement and information:</span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'> </span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'> </span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'><a href="https://www.youtube.com/watch?v=ODBd9S1jV2s" target="_blank">https://www.youtube.com/watch?v=ODBd9S1jV2s</a></span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'><a href="https://www.youtube.com/watch?v=u1JfYa413fY" target="_blank">https://www.youtube.com/watch?v=u1JfYa413fY</a></span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'><a href="https://www.youtube.com/watch?v=fNdnr1MUXp8" target="_blank">https://www.youtube.com/watch?v=fNdnr1MUXp8</a></span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'><a href="https://www.ponylang.io/" target="_blank">https://www.ponylang.io/</a></span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'> </span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'>There are many others. I mentioned the Pony concurrency architecture around the holidays, but there was no interest from the list—not a good time perhaps.</span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'> </span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'>The tentative plan is to do what Google does with Flutter: have the JIT in support of the usual dynamicity a Smalltalker needs for rapid development; and have AOT, fully optimized compiling for production or speed-related reality checks, presumably needed less often during development. There are other possibilities. </span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'> </span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'>Anyone interested? </span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'> </span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'>I have some ideas for simplifying use of the six ref caps in the context of Pharo/Smalltalk. If this path is chosen, one must commit to strict state-machine-based algorithm development, without exception. This should have happened anyway by now, broadly in the programming space, but didn’t. I’m working on a programming graphical tool and associated grammar (in VW) that make state-machine development easy and attractive. This , besides efficient use of machine resources, is the other reason for pushing in this direction. </span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'> </span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'>A Pony program is built from a net of asynchronously communicating actors. You change the state of your program with asynchronous messaging between actors. There is no blocking--no mutexes or semaphores—and therefore no wasted CPU cycles or mushrooming program complexity, as you try to use mutexes in a fine-grained way (a very bad idea). And as mentioned, there are never deadlocks or data-races. All cores on all CPUs stay busy, always, until the program goes idle or exits. The Pony group is also working on extending the model to the network level, so that all machine nodes in the network stay busy. In the round, as a start, think of Pony as Erlang/OTP, but much faster, with no legacy bugs, and provably no-deadlocking on compile. </span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'> </span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'>The asynchronous actor model is the programming pattern that Kay had in mind when he said “object-oriented.” It’s the one I want to implement in Pharo. The green threads are light, but don’t efficiently use the cores, and a net of VMs with their respective images still communicate too slowly.</span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'> </span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'>I your time permits, please study Pony for a bit, before rejecting the idea as too big a change in direction or too complicated. Using Pony looks like the ideal VM simplification strategy, if our aim is efficient use of networks of machines, each with at least one CPU (often more), each, in turn, with many cores (whose numbers are still increasing). This pattern in hardware probably won’t be changing much, now that speeds are topping out. Winning the performance game is therefore about efficiently using many cores at once, <u>without burdening the programmer</u>. I don’t see a better way to do this now than with Pony.</span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'> </span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'>Thoughts and suggestions are welcome.</span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'> </span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'> </span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext><span style='color:black'>Shaping</span><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext> <o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext> <o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext> <o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext> <o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext>> -----Original Message-----<o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext>> From: Pharo-users [<a href="mailto:pharo-users-bounces@lists.pharo.org" target="_blank"><span style='color:windowtext;text-decoration:none'>mailto:pharo-users-bounces@lists.pharo.org</span></a>] On <o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext>> Behalf Of N. Bouraqadi<o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext>> Sent: Tuesday, 28 January, 2020 12:18<o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext>> To: Any question about pharo is welcome <<a href="mailto:pharo-users@lists.pharo.org" target="_blank"><span style='color:windowtext;text-decoration:none'>pharo-users@lists.pharo.org</span></a>><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext>> Subject: [Pharo-users] Latest PharoJS Success Story<o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext>> <o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext>> The latest PharoJS-powered smartphone app is now live.<o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext>> Development has been made using Pharo.<o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext>> Then, javascript code is generated using PharoJS.<o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext>> Last, the app is built to target both iOS and Android thanks to Apache <o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext>> Cordova.<o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext>> <o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext>> Learn more and Download at<o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext>> <a href="https://nootrix.com/projects/brain-treats-app/" target="_blank"><span style='color:windowtext;text-decoration:none'>https://nootrix.com/projects/brain-treats-app/</span></a><o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext>> <o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext>> Noury<o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext>> <o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext>> <o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext> <o:p></o:p></p><p class=gmail-m-3012011191253006350gmail-m-3504913714629177448msoplaintext> <o:p></o:p></p></div></div></blockquote></div></div></div></blockquote></div></div></body></html>