Re: [Pharo-users] Latest PharoJS Success Story; Wasm/WASI; very keen on Pony for the Pharo VM
All:
Brain Treats got stuck during launch on my LG.
Which android version are you using ? The phone is old and this is likely the problem. Android version: 4.4.2 Kernel version: 3.4.0
Is there a plan to move PharoJS to Wasm/WASI?
Dave and I talked about it a long time ago. This sounds like a good idea. Actually, Dave has a very ambition idea = turn PharoJS into Pharo* where * can be different targets. But, there's a lot to do before reaching this goal. So, don't expect it any time soon. Not to change the topic too much, but the following is related and I often think of it. Consider writing the pharo VM in Wasm or, better, with Pony (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. 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. 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: https://www.youtube.com/watch?v=ODBd9S1jV2s https://www.youtube.com/watch?v=u1JfYa413fY https://www.youtube.com/watch?v=fNdnr1MUXp8 https://www.ponylang.io/ 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. 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. Anyone interested? 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. 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. 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. 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, without burdening the programmer. I don't see a better way to do this now than with Pony. Thoughts and suggestions are welcome. Shaping
-----Original Message-----
From: Pharo-users [ <mailto:pharo-users-bounces@lists.pharo.org> mailto:pharo-users-bounces@lists.pharo.org] On
Behalf Of N. Bouraqadi
Sent: Tuesday, 28 January, 2020 12:18
To: Any question about pharo is welcome < <mailto:pharo-users@lists.pharo.org> pharo-users@lists.pharo.org>
Subject: [Pharo-users] Latest PharoJS Success Story
The latest PharoJS-powered smartphone app is now live.
Development has been made using Pharo.
Then, javascript code is generated using PharoJS.
Last, the app is built to target both iOS and Android thanks to Apache
Cordova.
Learn more and Download at
<https://nootrix.com/projects/brain-treats-app/> https://nootrix.com/projects/brain-treats-app/
Noury
Shaping, That's right. Your phone's OS is too old. The Brain Treats app requires Android 4.4.4 or above. Thanks for the pointer to pony. Looks interesting. I'll have a look. But, I'm not involved in Pharo VM. You should instead send it to the VM mailing-list in a dedicated message. Best, Noury
On 3 Apr 2020, at 21:05, Shaping <shaping@uurda.org> wrote:
All:
Brain Treats got stuck during launch on my LG.
Which android version are you using ?
The phone is old and this is likely the problem.
Android version: 4.4.2 Kernel version: 3.4.0
Is there a plan to move PharoJS to Wasm/WASI?
Dave and I talked about it a long time ago. This sounds like a good idea. Actually, Dave has a very ambition idea = turn PharoJS into Pharo* where * can be different targets. But, there's a lot to do before reaching this goal. So, don't expect it any time soon.
Not to change the topic too much, but the following is related and I often think of itâ¦
Consider writing the pharo VM in Wasm or, better, with Pony (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.
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.
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:
https://www.youtube.com/watch?v=ODBd9S1jV2s <https://www.youtube.com/watch?v=ODBd9S1jV2s> https://www.youtube.com/watch?v=u1JfYa413fY <https://www.youtube.com/watch?v=u1JfYa413fY> https://www.youtube.com/watch?v=fNdnr1MUXp8 <https://www.youtube.com/watch?v=fNdnr1MUXp8> https://www.ponylang.io/ <https://www.ponylang.io/>
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. 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.
Anyone interested?
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.
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.
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.
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, without burdening the programmer. I donât see a better way to do this now than with Pony.
Thoughts and suggestions are welcome.
Shaping
-----Original Message----- From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org <mailto:pharo-users-bounces@lists.pharo.org>] On Behalf Of N. Bouraqadi Sent: Tuesday, 28 January, 2020 12:18 To: Any question about pharo is welcome <pharo-users@lists.pharo.org <mailto:pharo-users@lists.pharo.org>> Subject: [Pharo-users] Latest PharoJS Success Story
The latest PharoJS-powered smartphone app is now live. Development has been made using Pharo. Then, javascript code is generated using PharoJS. Last, the app is built to target both iOS and Android thanks to Apache Cordova.
Learn more and Download at https://nootrix.com/projects/brain-treats-app/ <https://nootrix.com/projects/brain-treats-app/>
Noury
participants (2)
-
Noury Bouraqadi -
Shaping