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

[Pharo 9.0] Build #238: Improve Spacetally perfs and clean code

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

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…

April 15, 2020

[Pharo 9.0] Build #237: Pharo project is not the Pharo Launcher project

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

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…

April 15, 2020

Re: [Pharo-dev] [Vm-dev] Pony for Pharo VM

by Shaping

Just to get in the right frame of mind, consider that because of the Blub Paradox (http://www.paulgraham.com/avg.html) you are going to have a hard time convincing people to "change to this language because of Feature X" just by saying so. You need to dig deeper. The Pony compiler and runtime need to be studied. Iâm not trying to convince; Iâm presenting facts, observations, and resources for study of the problem and its solution. Hardware constraints now are intensely multicore, and everyone knows this. The changing programming paradigm in apparent. Hardware structure is forcing that change. Convincing yourself will not be difficult when you have the facts. You likely do already, at least on the problem-side. The issue is not whether to use Pony. I donât like Pony, the language; itâs okay, even very good, but itâs not Smalltalk. I like Smalltalk, who concurrency model is painfully lame. I like Orca because it works on many cores (as many as 64, currently) without a synchronization step for GC, and has wonderful concurrency abilities. Pony and Orca were co-designed. The deferred reference counts managed by Orca run on the messages between the actors (send/receive tracing). GCs happen in Pony/Orca when each actor finishes its response to the last received message, and goes idle. The actor then GCs all objects no longer referenced by other actors. The runtime scheduler takes this time needed for each actorâs GCing into account. No actor waits to GC objects. An actorâs allocated objectsâ ref counts are checked at idle-time, and unreferenced objects are GCed in an ongoing, fluid way, in small, high-frequency bursts, with very small, predictable tail latencies, as a result. Thatâs very interesting if you need smoothly running apps (graphics), design/program real-time control systems, or process data at high rates, as in financial applications at banks and exchanges. The issue is how most efficiently to use Orca, which happens to be working in Pony. Pony is in production in two internal, speed-demanding, banking apps and in Wallaroo Labsâ high-rate streaming product. Pony is a convenient way to study and use a working implementation of Orca. Ergo, use Pony, even if we only study it as a good example of how to use Orca. Some tweaks (probably a lot of them) could allow use of dynamic types. We could roll our own implementation of Orca for the current Pharo VM, but that seems like more work than tweaking a working Pony compiler and runtime. Iâm not sure about that. You know the VM better than I. (I was beginning my study of the Pharo/OpenSmalltalkVM when I found Pony.) Now I I took a quick look to see what I could learn about Pony and the main interesting thing is its "Reference Capabilities". Indeed, it seems Pony's purpose is the POC for that research. I watched two videos... [1] Ãredev 2017 - Joe McIlvain - Pony - A Language for Provably Safe Lockless Concurrency https://www.youtube.com/watch?v=9NH4bVfbvYI [2] Sophia Drossopoulou - Pony for Safe, Fast, concurrent programs - Codemesh 2017 https://www.youtube.com/watch?v=e_bES30tFqI So my "quick" assessment is to consider Reference Capabilities not a Type System but a Meta-type System. Yes, ref-caps control sharing of both mutable and immutable objects. [2] says "They are not a property of an object, but define how I can look at an object." To summarize the videos... [1]@29:15... [2]@13:40... [2]@24:40... [2]@28:30... So you say... > 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. I believe you have the wrong end of the the stick promoting that the VM needs to be redeveloped using Pony to get the Reference Capabilities at the Smalltalk level. See my recent response to Ken in vm-dev. After you Ahead-Of-Time compile the VM, the compiler is left behind. The features of the compiler don't automatically flow through to Smalltalk level. Yes. JIT and AOT are needed. Adjustments need to be made for dynamic typing, but such adjustments need not violate invariants needed to provide the ref-cap concurrency guarantees. A third option could be to extend to the existing "Immutability capability" of the VM. Ref-caps control access to both immutable and mutable objects. Pony ascertains at compile time that only one actor at a time can hold a reference to a mutable object at runtime. The six Reference Capabilities might be stored in the Spur Object Header using a re-purposed Immutability bit plus the two free "green" bits. https://clementbera.wordpress.com/2014/01/16/spurs-new-object-format/ We canât use a single big system heap, and also use the actor model and many cores productively. The big heap must go. Thatâs the crux of what we need to learn at this juncture. Iâm not sure everyone is getting this. I donât need to convince you; you can do that for yourself. We donât currently have a better choice of programming model or memory management, if we want maximum speed, and are paying attention to hard constraints. Multicore hardware is here to stay. If you know a way to use your multicore CPUs more efficiently than by use of actor-based programming and Orca memory management, please share your facts. Everyone needs to understand the big-heap problem in order to commit to fine-grain, actor-based (and therefore state-machine-based) programming. We wonât realize productive multicore programming without an actor model. We still need new tools to help, as mentioned, lest our state-machine programming be tedious and painful, causing us to default to old coding habits, and not make the needed state-machines. Iâm working on one of those tools. Orca manages memory as fast as possible in an actor-based program/runtime, without any synchronization. The big-heap problem has been solved for the statically typed case in Pony. The lack of discipline/tools for building state-machines remains a broad problem. Such new tools are therefore essential during the change of programming model. I suggest studying the current Pony/Orca solution (see the Orca paper linked below), to see how it can be tweaked to accommodate dynamic types. Iâve not studied the Pony compiler and runtime enough to be certain, but they may be closer to what we need, even if the first rough implementation of a Smalltalk-with-Orca must be AOT, instead of JIT. We want both ultimately. We should do first whichever is easiest to implement and test in small steps. "Reference Capabilities for Dynamic Languages" could be a strong PhD project. Itâs a good idea. Is this needed to make a Smalltalk that works with Orca? I donât think so. Orca matters more than Pony. But both can be useful to us. Studying the Orca paper and its implementation in the Pony compiler and runtime is the easiest way to understand the constraints imposed by the current static type system in Ponyâand how to change them to accommodate dynamic types. Everyone, please read and study https://www.ponylang.io/media/papers/orca_gc_and_type_system_co-design_for_… if you are interested in building a VM/runtime that guarantees no data-races, and fully uses all your machineâs cores, with the least programming effort. Then study Pony: https://www.ponylang.io/ And ask questions on Pony Zulip: https://ponylang.zulipchat.com/ (BTW, Zulip seems easier to use than Discord and e-mail. Has anyone considered using it for the Pharo/Squeak lists?) Shaping On Fri, 10 Apr 2020 at 17:56, Shaping <shaping(a)uurda.org <mailto:shaping@uurda.org> > wrote: > > 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. > > 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.

April 15, 2020

Re: [Pharo-dev] looking for input for a lecture on TDD and XtremeTDD

by Boris Shingarov

April 15, 2020

Re: [Pharo-dev] [Esug-list] looking for input for a lecture on TDD and XtremeTDD

by Stephan Eggermont

Hi Stef, Iâve done some workshops and screencasts. In the workshops (oops, already a few years ago) I used a morph that was moving on the screen to emphasize the liveness. The BabyMock2 work by Attila Magyar is also great for that. It also is good to show the difference between Chicago and London style TDD, and connect to BDD. In Smalltalk, that is more represented by the exploratory modeling I was introduced to by Rob Vens. https://www.reflektis.nl/blog/exploratory-modelling-explained/ For a lecture TDD as if you meant is is a good starting point: https://cumulative-hypotheses.org/2011/08/30/tdd-as-if-you-meant-it/ GToolkit of course provides some nice example-driven development, that combines well with literate programming In my latest screencasts I ran into the following issues: - restarting a test does not make it green after going through it if it needed a fix - canât step into simple accessors (and other optimized code?) - in addition to create, need to be able to create/change setUp/initialize/shutDown - a refactoring âturn fake into classâ is missing where instVar := self and there are methods categorized as âfaking instVarâ https://vimeo.com/329317634 https://vimeo.com/329368348 Stephan Verstuurd vanaf mijn iPhone > Op 14 apr. 2020 om 14:36 heeft StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> het volgende geschreven: > > ï»¿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 > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

April 15, 2020

Re: [Pharo-dev] looking for input for a lecture on TDD and XtremeTDD

by HernÃ¡n Morales Durand

Hi Stef, One of the funniest talks about TDD is the one from HernÃ¡n Wilkinson : https://youtu.be/x4CXWBW5fMo (minute 29 starts the TDD coding show) It's in Argentine Spanish dialect, but it's worth to see. Cheers, HernÃ¡n El mar., 14 abr. 2020 a las 9:36, StÃ©phane Ducasse (< stephane.ducasse(a)inria.fr>) escribiÃ³: > 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 > >

April 15, 2020

[Pharo 9.0] Build #236: Fix 6160 Cleanup two tests in BlockClosureTest

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

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…

April 14, 2020

[Pharo 9.0] Build #235: Review Spotter preview logic of SpEntry

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

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…

April 14, 2020

[Pharo 9.0] Build #234: Fix https://github.com/pharo-project/pharo/issues/6173

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

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…

April 14, 2020

looking for input for a lecture on TDD and XtremeTDD

by StÃ©phane Ducasse

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

April 14, 2020