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 <shap...@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-boun...@lists.pharo.org > > <mailto:pharo-users-boun...@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 > > > >
