April 2020 - Pharo-dev - lists.pharo.org

[Pharo 9.0] Build #242: Integrate Heuristic Completion v3.0.2
by ci-pharo-ci-jenkins2＠inria.fr April 16, 2020

April 16, 2020

There is a new Pharo build available! The status of the build #242 was: SUCCESS. The Pull Request #6187 was integrated: "Integrate Heuristic Completion v3.0.2" Pull request url: https://github.com/pharo-project/pharo/pull/6187 Issue Url: https://github.com/pharo-project/pharo/issues/fix/integratecompletion301 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 9.0] Build #241: Try fix #6021
by ci-pharo-ci-jenkins2＠inria.fr April 16, 2020

April 16, 2020

There is a new Pharo build available! The status of the build #241 was: FAILURE. The Pull Request #6185 was integrated: "Try fix #6021 " Pull request url: https://github.com/pharo-project/pharo/pull/6185 Issue Url: https://github.com/pharo-project/pharo/issues/fix/6021 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 9.0] Build #240: Fix Warning defaultAction
by ci-pharo-ci-jenkins2＠inria.fr April 16, 2020

April 16, 2020

There is a new Pharo build available! The status of the build #240 was: SUCCESS. The Pull Request #6179 was integrated: "Fix Warning defaultAction" Pull request url: https://github.com/pharo-project/pharo/pull/6179 Issue Url: https://github.com/pharo-project/pharo/issues/unhandledExceptionHier Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

looking for input for a lecture on TDD and XtremeTDD
by StÃ©phane Ducasse April 15, 2020

April 15, 2020

Hello I would like to build a lecture around TDD and XtremeTDD (coding in the debugger). Iâm looking around to see if someone already did such a lecture. S. -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

4 4

[Pharo 9.0] Build #239: CompilerCleanup-hasIncompleteIdentifier
by ci-pharo-ci-jenkins2＠inria.fr April 15, 2020

April 15, 2020

There is a new Pharo build available! The status of the build #239 was: SUCCESS. The Pull Request #6168 was integrated: "CompilerCleanup-hasIncompleteIdentifier" Pull request url: https://github.com/pharo-project/pharo/pull/6168 Issue Url: https://github.com/pharo-project/pharo/issues/CompilerCleanup Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 9.0] Build #238: Improve Spacetally perfs and clean code
by ci-pharo-ci-jenkins2＠inria.fr April 15, 2020

April 15, 2020

There is a new Pharo build available! The status of the build #238 was: FAILURE. The Pull Request #6177 was integrated: "Improve Spacetally perfs and clean code" Pull request url: https://github.com/pharo-project/pharo/pull/6177 Issue Url: https://github.com/pharo-project/pharo/issues/improveSpaceTallyPerfs Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 9.0] Build #237: Pharo project is not the Pharo Launcher project
by ci-pharo-ci-jenkins2＠inria.fr April 15, 2020

April 15, 2020

There is a new Pharo build available! The status of the build #237 was: FAILURE. The Pull Request #6175 was integrated: "Pharo project is not the Pharo Launcher project" Pull request url: https://github.com/pharo-project/pharo/pull/6175 Issue Url: https://github.com/pharo-project/pharo/issues/patch Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Vm-dev] Pony for Pharo VM (typo fix)
by Shaping April 15, 2020

April 15, 2020

Hi Ken. Not to discourage people, but I have not seen cases where a "strong" type system would be able to scale for _real_ Smalltalk applications. Youâre right. It doesn't. I'm not suggesting that. The type safety is not for app-level Smalltalk development. It's for building the VM only. I want to use the Pony concurrency model at the Smalltalk level. Thatâs the gist of it. Otherwise, I want a Smalltalk, not a statically compiled language. Six ref-caps explicitly represent Ponyâs concurrency model in code. They are essentially type qualifiers related specifically to concurrency. The plan is to reduce, if possible, the number of ref-caps the programmer must explicitly use/place in the code when coding a state-machine in Smalltalk, without producing a toy or straightjacket (without making it too simple or too rigid). This may require implementing the VM more as a change to (fork of) Pony instead of using Pony to implement the VM. Iâm not sure yet. The six ref-cap ideas for sharing data reliably between actors are not hard to grasp, but they take some getting used to, and involve some mental load. I don't want that much (concurrency-related or any other) implementation detail in the domain layer, much in the same vein as: I donât use Forth because I donât want to see stack acrobatics (ROTs and DUPs, etc.) amidst domain-level state-changes (FirePhotonTorpedo). Itâs distracting. It dilutes focus on the domain work/layer, and tends to cause mistakes there. The programmerâs domain logic and the concurrency-integrity provided by the ref-caps are different layers of thought and structure. The ref-caps are, however, mixed freely with domain logic in current Pony code. I think thatâs a mistake. But thatâs how it is now. I think of this layer mixing as an intermediate design stage of Pony. I want to abstract-out some or all ref-caps as the VM is built. Pony language is not the remarkable thing here. I see it as a better C or better Rust. Itâs very good (as Algol-60-ish-looking crap-syntaxes go), but thatâs not what this is about. Itâs about the actor programming, the concurrency model, and the guarantees given by use of the ref-caps. We would still obviously need to respect the Pony compilerâs determination of where ref-cap use is correct or not. Your Pony program wonât compile if you donât use the ref-caps correctly, and you donât get the guarantees or a running program without the compile. Much easier, therefore, might be to go the other way by changing Pony to support dynamic types without violating the invariants that allow the ref-caps (under the hood, abstracted out) to make the concurrency guarantees. Work Smalltalk dynamism into Pony, instead of building a Smalltalk VM with Pony. Shaping "Rational numbers" (1/2) + (1/3) + (1/6). "--> 1 " "Complex numbers" [ :n | n * n] value: (-4 sqrt). "--> -4 " "BigNums" 111 factorial. " --> 1762952551090244663872161047107075788761409536026565516041574063347346955087248316436555574598462315773196047662837978913145847497199871623320096254145331200000000000000000000000000 " Just this is hugely complex to model in a "type safe" language. Add metaprogramming (e.g. #doesNotUnderstand:), source level debugging of live stacks and GC of large object spaces and you have a very large (space) and very slow (interlocking cache granularity) interpreter. Please prove me wrong. $0.02, -KenD

2 2

[Pharo 9.0] Build #236: Fix 6160 Cleanup two tests in BlockClosureTest
by ci-pharo-ci-jenkins2＠inria.fr April 14, 2020

April 14, 2020

There is a new Pharo build available! The status of the build #236 was: FAILURE. The Pull Request #6178 was integrated: "Fix 6160 Cleanup two tests in BlockClosureTest" Pull request url: https://github.com/pharo-project/pharo/pull/6178 Issue Url: https://github.com/pharo-project/pharo/issues/6160 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 9.0] Build #235: Review Spotter preview logic of SpEntry
by ci-pharo-ci-jenkins2＠inria.fr April 14, 2020

April 14, 2020

There is a new Pharo build available! The status of the build #235 was: SUCCESS. The Pull Request #6156 was integrated: "Review Spotter preview logic of SpEntry" Pull request url: https://github.com/pharo-project/pharo/pull/6156 Issue Url: https://github.com/pharo-project/pharo/issues/6155 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 9.0] Build #234: Fix https://github.com/pharo-project/pharo/issues/6173
by ci-pharo-ci-jenkins2＠inria.fr April 14, 2020

April 14, 2020

There is a new Pharo build available! The status of the build #234 was: SUCCESS. The Pull Request #6174 was integrated: "Fix https://github.com/pharo-project/pharo/issues/6173" Pull request url: https://github.com/pharo-project/pharo/pull/6174 Issue Url: https://github.com/pharo-project/pharo/issues/addedSomeRunnableExamples Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Mm10s] 2020-04-13
by tesonep＠gmail.com April 14, 2020

April 14, 2020

Monday morning, time for the weekly status mail in 10 seconds! ### Last week: - Reviewing Iceberg PR - Pharo-COM problem with BSTR - VM Printing Errors & Messages - [PharoCOM] Pharo 7 errors - Testing LLVM capabilities as Testable JIT: Impossible to extract the machine code without reading the object format. - Fixing problem with WorldMorph install - Consortium Meeting - Journal Club: Pretenuring - Multiples Edens & Application Servers optimizations - Async Files / Async Streams (WIP) - [VM] Writing tests for JIT generation with Guille (WIP) - Checking large image problems. - Improving crash reports of the VM in endless loops. ### This week (starting 2020-04-13): - [Port to Pharo 8] Traits in class side fix - New iceberg release: Issue 1356 - [VM] Fix symbolic links in Pharo8 VM - Fixing Package List / Categories in Calypso - [VM] Fixing Tests in Idle. - Adding a label to a PR when it has no test errors. - [Pharo9] Propose a PR for Fuel to support Sista - [Doc] Pass on VM booklet: Callback chapter / Preface - [VM] Documenting GC, participating in the GC code dojo. - [VM] SDL Plugin for Idle. - [VM] Improving Speed of TFFI. - [VM] REPL example / Interacting with an image from outside (?) - [PharoCOM] Making it run with TFFI. - [VM] Writing tests for JIT generation - [OSSubprocess] Integrate Pavel + Christophe windows version. - [VM/Image] New version of Async Streams and use them with StdOut and StdErr -- Pablo Tesone. tesonep(a)gmail.com

2 1

Migrating your projects to GitHub? Do not forget to tag your project!
by Esteban Lorenzano April 14, 2020

April 14, 2020

Hello, Just a gentle reminder to tag your project as âPharoâ, so a search engine can find it better! Esteban

1 0

Not seeing hidden character is confusing :)
by StÃ©phane Ducasse April 14, 2020

April 14, 2020

Hi I have the impression that we can introduce hidden characters while typing code and this is a problem to me because we do not see them :) I got for example selhiddenf and it can lead to strange situations. I will try to chase the key combinations that produce them and see how we can control and avoid this situation. If you find the key combination please let me know. S. -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

5 5

[Pharo 9.0] Build #233: Introduce UnhandledException hierarchy
by ci-pharo-ci-jenkins2＠inria.fr April 13, 2020

April 13, 2020

There is a new Pharo build available! The status of the build #233 was: FAILURE. The Pull Request #6131 was integrated: "Introduce UnhandledException hierarchy" Pull request url: https://github.com/pharo-project/pharo/pull/6131 Issue Url: https://github.com/pharo-project/pharo/issues/unhandledExceptionHier Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 9.0] Build #232: FAILURE
by ci-pharo-ci-jenkins2＠inria.fr April 13, 2020

April 13, 2020

There is a new Pharo build available! The status of the build #232 was: FAILURE. Could not extract further issue information from commit message: Update cleanup-report.md Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 9.0] Build #231: SUCCESS
by ci-pharo-ci-jenkins2＠inria.fr April 13, 2020

April 13, 2020

There is a new Pharo build available! The status of the build #231 was: SUCCESS. Could not extract further issue information from commit message: Update enhancement-request.md adding expected costs Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 9.0] Build #230: Fixing the installation of a different world.
by ci-pharo-ci-jenkins2＠inria.fr April 12, 2020

April 12, 2020

There is a new Pharo build available! The status of the build #230 was: FAILURE. The Pull Request #6162 was integrated: "Fixing the installation of a different world." Pull request url: https://github.com/pharo-project/pharo/pull/6162 Issue Url: https://github.com/pharo-project/pharo/issues/fixing Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Spec] CodePresenter line numbering and fontize
by Hilaire April 12, 2020

April 12, 2020

Hi, For the DrGeo workspace for kid programming, I will need these features in the code presenter. I did not find how to do it, nor example I can transfer knowledge from: * line numbering, when mentoring kid it is useful to point to a particular line of code * fontsize, when video-projecting to a class, I need larger font size for the code Any tips, direction or know how is welcome. Keep safe Hilaire Here is another the situation, maybe it is bugs: When I set the code presenter behavior to nil, the highlight is correct, and there is no left column: Then when the behavior is set, below to Object (I previously set to UndefinedObject), the syntax highlight is not right and there is a left column(for numbering?): -- Dr. Geo http://drgeo.eu

1 0

How to execute code
by Hilaire April 11, 2020

April 11, 2020

Hi, Need some orientation here. How to write the code to execute a piece of code in code presenter? Thanks Hilaire /* frustration on Ok, it is very frustrating learning from Pharo now. Since when Pharo is not anymore discoverable? I try to find from context menu how to code some sort of action. Here how to execute a piece of code from a workspace. I look in Playground contextual menu, then in Spec code presenter menu. Both implement some sort of different way of doing this. Yes, why doing think simple when you can just duplicate it. But the worst I can not make sense of what I read, totally lost in the level of abstraction. my productivity == 0 frustration off*/ -- Dr. Geo http://drgeo.eu

4 8

[Spec] SpCodePresenter
by Hilaire April 11, 2020

April 11, 2020

Hi, When one wants to use the code presenter for workspace, how should be set the its behavior class? Thanks PS: what about my other questions? Hilaire -- Dr. Geo http://drgeo.eu

1 0

Re: [Pharo-dev] [Vm-dev] Pony for Pharo VM
by Shaping April 10, 2020

April 10, 2020

Hi Ken. Not to discourage people, but I have not seen cases where a "strong" type system would be able to scale for _real_ Smalltalk applications. Youâre right. It doesn't. I'm not suggesting that. The type safety is not for app-level Smalltalk development. It's for building the VM only. I want to use the Pony concurrency model at the Smalltalk level. Thatâs the gist of it. Otherwise, I want a Smalltalk, not a statically compiled language. Six ref-caps that explicitly represent Ponyâs concurrency model in code. They are essentially type qualifiers related specifically to concurrency. The plan is to reduce, if possible, the number of ref-caps the programmer must explicitly use/place in the code when coding a state-machine in Smalltalk, without producing a toy or straightjacket (without making it too simple or too rigid). This may require implementing the VM more as a change to (fork of) Pony instead of using Pony to implement the VM. Iâm not sure yet. The six ref-cap ideas for sharing data reliably between actors are not hard to grasp, but they take some getting used to, and involve some mental load. I don't want that much (concurrency-related or any other) implementation detail in the domain layer, much in the same vein as: I donât use Forth because I donât want to see stack acrobatics (ROTs and DUPs, etc.) amidst domain-level state-changes (FirePhotonTorpedo). Itâs distracting. It dilutes focus on the domain work/layer, and tends to cause mistakes there. The programmerâs domain logic and the concurrency-integrity provided by the ref-caps are different layers of thought and structure. The ref-caps are, however, mixed freely with domain logic in current Pony code. I think thatâs a mistake. But thatâs how it is now. I think of this layer mixing as an intermediate design stage of Pony. I want to abstract-out some or all ref-caps as the VM is built. Pony language is not the remarkable thing here. I see it as a better C or better Rust. Itâs very good (as Algol-60-ish-looking crap-syntaxes go), but thatâs not what this is about. Itâs about the actor programming, the concurrency model, and the guarantees given by use of the ref-caps. We would still obviously need to respect the Pony compilerâs determination of where ref-cap use is correct or not. Your Pony program wonât compile if you donât use the ref-caps correctly, and you donât get the guarantees or a running program without the compile. Much easier, therefore, might be to go the other way by changing Pony to support dynamic types without violating the invariants that allow the ref-caps (under the hood, abstracted out) to make the concurrency guarantees. Work Smalltalk dynamism into Pony, instead of building a Smalltalk VM with Pony. Shaping "Rational numbers" (1/2) + (1/3) + (1/6). "--> 1 " "Complex numbers" [ :n | n * n] value: (-4 sqrt). "--> -4 " "BigNums" 111 factorial. " --> 1762952551090244663872161047107075788761409536026565516041574063347346955087248316436555574598462315773196047662837978913145847497199871623320096254145331200000000000000000000000000 " Just this is hugely complex to model in a "type safe" language. Add metaprogramming (e.g. #doesNotUnderstand:), source level debugging of live stacks and GC of large object spaces and you have a very large (space) and very slow (interlocking cache granularity) interpreter. Please prove me wrong. $0.02, -KenD

1 0

Pony for the Pharo VM
by Shaping April 10, 2020

April 10, 2020

I have to admit that that language looks quite interesting, but it is not appropriate for writing an actual VM. The point of the Pony language and concurrency model is to be able to write any program, 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). 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. 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: Orca: GC and Type System Co-Design for Actor Languages: https://www.ponylang.io/media/papers/orca_gc_and_type_system_co-design_for_… Can you be more specific about which program construct cannot be written in Pony or cannot be written to run fast enough? 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. In fact, most of the methods are actually interpreted and they are only compiled after being executed several times for reducing this startup time. 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. 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. In this problem domain, the actor model and the thread safeness guaranteed by it does not help you at all, and deadlocks can always be produced. 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: Deadlocks and data-races are not possible in a Pony program that compiles. This is mathematically guaranteed. You can glean this fact from the videos or study the details in Pony papers. I did have deadlocks problems with synchronous messages in Erlang 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. 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! 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 livelocking. 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. 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. See above concerning the difference between livelock and deadlock. 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: 1. Implementing the garbage collector. 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. 2. Direct access to object slots for implementing the bytecode interpreter. Not a problem. Itâs just a program feature. So we write it as it needs to be. 3. Copying compiled machine code into executable memory and performing position dependent relocations. Doable. The Pony FFI works well even at this early stage. 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. Then do that. 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). â¦as needed. Pony is changing quickly: https://ponylang.zulipchat.com/. 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. If there were no Smalltalk, I would certainly use Pony before C, Rust, or Go, even at this early pre-1.0 stage. 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. 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. 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. 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 must go away, 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. 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. 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 (not a compliment). But Pony solves more concurrency-related problems at compile-time than any other available tool. How complete is the documentation on the current Pharo VM? As for myself, I am putting my bets on another language that I am developing (Sysmel: https://github.com/ronsaldo/sysmel ), 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. Iâve read some on Sysmel. It appears to be an outstanding tool. Does Sysmel implement multicore concurrency, and guarantee no deadlocks/data-races on compile? 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.) 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: https://github.com/ronsaldo/sysmel/blob/master/module-sources/Sysmel.Core/S… 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 Wasm and WASI will be good when they are ready. (vtable layouts, and some intrinsics that I am using for non-local returns), but they should not be that complicated to fix. 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. 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. Best, Shaping El lun., 6 abr. 2020 a las 6:05, Shaping (<shaping(a)uurda.org <mailto:shaping@uurda.org> >) escribiÃ³: I should have initially posted this to the Pharo-dev list, as well. From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org <mailto:pharo-users-bounces@lists.pharo.org> ] On Behalf Of Shaping Sent: Friday, 3 April, 2020 14:05 To: 'Any question about pharo is welcome' <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org> > Subject: 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(a)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 > >

2 2

[spec| On update
by Hilaire April 9, 2020

April 9, 2020

Hi, When my source code presenter content is edited I want to change the badge of a toolbar button. In the code bellow, the block is executed but the button badge does not change. You have to move the whole window to get the badge updated accordingly. Â Â Â source whenTextChangedDo: [:txt | Â Â Â Â Â Â saveBtn badge: '*'. Â Â Â Â Â Â self update: saveBtnself]. What update mechanism am I missing? Is it observable slot things? Hilaire -- Dr. Geo http://drgeo.eu

1 0

[Spec] Selected item in a list off screen
by Hilaire April 9, 2020

April 9, 2020

Hi, When I programmatically selects an item in a presenter list *and* when this item is off screen -- for example at the end of a long list -- the list widget is not scrolled to make it visible. (DrGScriptBrowser2 new script: DrGeoUserScript allSubclasses last; yourself) openWithSpec Is it a bug or am I missing something Thanks Hilaire -- Dr. Geo http://drgeo.eu

3 7