November 2019 - Pharo-dev - lists.pharo.org

Erlang/OTP/Pony-style concurrency in Smalltalk

by Shaping

(I posted this earlier to the OS VM group (vm-dev(a)lists.squeakfoundation.org) but the message appeared as an attachment. I'm not sure that was the right place; so I'm reposting here.) Hi all. I was reading about the RoarVM, recently. The project seems to be at a standstill. Why, as in the RoarVM, would someone try to build a Smalltalk VM supporting concurrency, and not also resolve to use a strict actor model in which each process has its own, usually small heap that is very quickly and simply GCed? If I understand correctly, RoarVM still had one big heap for all processes. With one heap per process, many times no GC happens at all: the process finishes and the heap is discarded. This finer-grained memory-management dynamic gets us closer to deterministic latencies, which are needed in simulations (and almost anything graphical you want to render smoothly). The idea with the actor model (and the OTP-style work-stealing that accompanies it) is not only to use very continuously all cores in all CPUs in all machine-nodes on the network, all of the time (until the program exits or goes idle), but also to make using the usual synchronization devices (semaphores, mutexes, monitors, and the like) unnecessary. This is where all the complexity is and where the time and effort go when coding and debugging concurrent apps. No one wants to use these devices if he needn't. The actor model is an elegant way to solve the concurrent-programming problem, which mostly reduces to advancing program state with only asynchronous messaging, while causing no blocking and no idle cores if there is still work left to do. The actor model works if you are willing to build a proper state-machine for your app (I have some ideas for a GUI to help in this respect) and the asynchronous messaging is fast. It is very fast in Pony (https://www.ponylang.io/) (Smalltalk images linked by WS connections won't be fast enough.) I'm learning to use Pony these days. It's a good tool, and it's improving at a good pace with an enthusiastic community. It's statically compiled; so it's not speeding development/experimentation as much as it is the resulting program. However, Pony vastly reduces the amount of concurrency-related debugging you would otherwise do if you did not, after a successful compile, have a provably non-deadlocking/non-data racing program. This is the new thing that Pony gives you, and it's great. But I want a dynamic development environment and very efficient Erlang/OTP/Pony-style concurrency. How do we get that? Why wasn't this the path chosen by the RoarVM developers? What is happening in OpenSmalltalk VM regarding such concurrency? I'm considering using Pony somehow in a 5-pane browser (but that's some work), dumping compiler errors to the Transcript. I'm not fond of editing text files (scrolling/searching) even when the process is very graceful. That's too 20th-century. VS Code is a very nice tool with great extensions, but it does not replace what happens in a Smalltalk browser. Please share your thoughts on what is happening or what could be done to create Erlang/OTP/Pony-style concurrency in Smalltalk. Cheers, Shaping

Nov. 29, 2019

[Pharo 8.0] Build #1026: 5190-Match-comments-should-turned-into-executable-comments

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

There is a new Pharo build available! The status of the build #1026 was: SUCCESS. The Pull Request #5265 was integrated: "5190-Match-comments-should-turned-into-executable-comments" Pull request url: https://github.com/pharo-project/pharo/pull/5265 Issue Url: https://github.com/pharo-project/pharo/issues/5190 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 29, 2019

ECOOP'20 Berlin - Call for Papers

by Fabio Niephaus

============================================================ The 34th Edition of ECOOP Call for Papers 13th-17th July 2020 Berlin, Germany https://2020.ecoop.org/ ============================================================ ECOOP is a conference about programming. Originally its primary focus was on object orientation, but now it looks at a much broader range of programming topics. Areas of interest include, at least, the design, implementation, optimization, analysis, and theory of programs, programming languages, and programming environments. It solicits both innovative and creative solutions to real problems as well as evaluations of existing solutionsâevaluations that provide new insights. It also encourages the submission of reproduction studies. ECOOP 2020 solicits high-quality submissions describing original, unpublished results. The program committee will evaluate the technical contribution of each submission as well as its general relevance and accessibility to the ECOOP audience according to the following criteria: - Originality. Papers must present new ideas and place them appropriately within the context established by previous research in the field. - Significance. The results in the paper must have the potential to add significantly to the state of the art or practice. - Evidence. The paper must present evidence supporting its claims. Examples of evidence include implemented systems, experimental results, statistical analyses, case studies, formalizations, and proofs. - Clarity. The paper must present its contributions and results clearly. On submission, authors will be asked to identify their paper with one of the following categories: - Research Paper. This is the most traditional category and solicits high quality research papers that demonstrate advances in the field. (As an alternative to being published in the conference proceedings, authors may wish to submit research papers to be considered for publication in ACM TOPLAS or Science of Computer Programming.) - Tool Insights Paper. These submissions focus on the practical details of the design and implementation of PL toolsâdetails that are often omitted from regular research papers, despite being fascinating and worthy of communication. A strong Tool Insights Paper should communicate engineering experience and insights that are likely to be useful to other members of the PL community, who may face similar problems in future. Examples of issues that Tool Insights Papers might focus on include, but are not limited to: performance, reliability, portability, inter-tool integration, infrastructure re-use, evaluation issues, theory/practice gaps, precision/efficiency, and soundness/efficiency trade-offs. - Reproduction Study. A Reproduction Study is an empirical evaluation. It reconstructs an already published experiment but in a different context (for example, using a different virtual machine or platform, or in a different class of applications) in order to validate or refute important results of earlier work. A good Reproduction Study includes thorough empirical evaluation as well as a detailed comparison with the previous results, providing reasons for possible disagreements. (A thoroughly-conducted Reproduction Study that perfectly replicates an existing experiment and reaches the same conclusions will be regarded as significant, so long as said experiment is significant enough to be worthy of reproduction.) - Experience Report. Such reports focus on noteworthy applications of known PL techniques, tools, and ideas in interesting domains and by other communities. Examples include, but are not limited to, applications of PL techniques in industry, open source, education, and other academic disciplines. We welcome reports on successful applications of PL ideas and reports that shed light on limitations and problems that may provide inspiration for future research. - Pearl. This category solicits articles that explain a known idea in a new and elegant way, to the benefit of the PL community. A Pearl may well be shorter than a regular research paper, but there is no hard requirement on this. - Brave New Idea. The Brave New Idea category solicits forward-looking articles on ideas in the field of PL that may take some time to substantiate, but for which early communication to the community is likely to be of benefit. For this category we welcome papers that are particularly conceptually novel or unconventional and that as a result may be harder to back up by traditional evaluation methods. A Brave New Idea paper may well be shorter than a regular research paper, but there is no requirement for it to be so. Paper Submission ================ Only papers that have not been published and are not under review for publication elsewhere may be submitted. Double submissions will be rejected without review. If major parts of an ECOOP submission have appeared elsewhere in any form, authors are required to notify the ECOOP program chair and explain the overlap and relationship. Authors are also required to inform the program chair about closely related work submitted to another conference while the ECOOP submission is under review. Papers must be no longer than 25 pages, excluding references. See below for information about appendices. Authors will not be penalized for papers that are shorter than the page limit. Submissions will be carried out electronically via the conference website [1]. ECOOP Proceedings are published by Dagstuhl LIPIcs. Papers must be written in English and follow the Dagstuhl LIPIcs LaTeX-style template [2]. Authors retain ownership of their content. Note: Submitted papers do not need to include the ACM classification or keywords. Also, please DO NOT put your name in either the \author or \Copyright macro, in order to maintain anonymity for double-blind reviewing (see below). Anonymity ========= ECOOP will use light double-blind reviewing: authorsâ identities are withheld until a reviewer submits his or her review (as usual, reviews are anonymous). To facilitate this, submitted papers must adhere to two rules: - Author names and institutions must be omitted. - References to authorsâ own other work should be in the third person (for example, not âWe build on our previous workâ¦â but rather âWe build on the work ofâ¦â). When in doubt, contact the Program Chair. Additional Material =================== Clearly marked additional appendices containing analyses, statistics, supporting proofs, etc. of possible value to reviewers but not published in the final publication, may be included beyond the page limit. The submission system provides an option to submit supplementary material; for example, a technical report including proofs, or web pages and repositories that cannot easily be anonymized. This supplementary material will be made available to reviewers after the initial reviews have been completed, when author names are revealed. Reviewers are under no obligation to examine such appendices and supplementary material. Therefore, the paper must be a stand-alone document - the appendices and supplementary material are a way of providing useful information that cannot fit in the page limit; they are not a means to extend the page limit. Authors of papers that have been submitted but not accepted by previous conferences may optionally submit a Note to Reviewers. The Note to Reviewers should provide the following information: - the identity of the previous venue(s) (for example, ESOP 2020, â¹Programmingâº 2020, POPL 2020, OOPSLA 2019) - a list the major issues identified by the reviews at those venues - a description of the changes made to the paper in response to those reviews These notes will be made available to reviewers after their initial reviews have been completed and author names have been revealed. Response Period =============== Authors will be given a three-day period to read and respond to the reviews of their papers before the program committee meeting. Responses have no formal length limit, but concision is likely to be effective. Artifact Evaluation =================== To reward the creation of artifacts and support replication of experiments, authors of accepted research papers may submit artifacts (such as tools, data, models, or videos) to be evaluated by an Artifact Evaluation Committee. Artifacts that pass muster will be recognized officially. Important Dates =============== - Paper submission: 10 January 2020 (Fri) - Author response: 16â18 March 2020 (Mon-Wed) - Author notification: 8 April 2020 (Wed) Journal First ============= We have Journal First arrangements with ACM Transactions on Programming Languages and Systems and Elsevier Science of Computer Programming. Common to both routes --------------------- Only new research papers are eligible for the Journal First routes to ECOOP 2020. That is, it is not acceptable to submit an extension of a previous conference paper, even if the associated journal solicits extended papers via its standard submission route. Authors of all accepted Journal First papers will be invited to submit a short abstract for their paper to appear in the ECOOP 2020 conference proceedings. Journal First papers will be included along with research papers submitted directly to the conference when a Distinguished Paper is selected. Science of Computer Programming route ------------------------------------- See this dedicated web page [3] for full details of how to submit to the ECOOP 2020 Science of Computer Programming (SCP) special issue. Submission deadline: December 2, 2019 (Mon) ACM Transactions on Programming Languages and Systems route ----------------------------------------------------------- See this announcement [4] for details of the TOPLAS scheme whereby papers submitted to TOPLAS can be presented at selected conferences. Authors interested in this route should submit their paper to TOPLAS via its usual submission system and mark it as an ECOOP 2020 submission. The ECOOP Program Chair will then be informed of this submission and will have some input into the review process. Submission deadline: October 10, 2019 (Thu) More Information ================ For additional information, please contact the ECOOP Program Chair, Robert Hirschfeld [5]. [1] https://2020.ecoop.org/track/ecoop-2020-papers [2] https://www.dagstuhl.de/en/publications/lipics/instructions-for-authors/ [3] https://www.journals.elsevier.com/science-of-computer-programming/call-for-… [4] https://toplas.acm.org/announcements.cfm#submit-a-paper-for-pldi-2016 [5] https://www.hpi.uni-potsdam.de/hirschfeld/people/hirschfeld/

Nov. 29, 2019

[Pharo 8.0] Build #1025: CompletionFallBack

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

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

Nov. 28, 2019

Re: [Pharo-dev] BlueInk removal

by Esteban Maringolo

On Thu, Nov 28, 2019 at 6:14 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > This is all true, BUT ... > > Very few people attempt to do fundamental changes/cleanups/subsystem-replacements in the core image. This all true, BUT ... :-) > This takes a lot of work, is never easy and almost always has issues. This is exactly why you "roll out" features. > Resources are limited as well, in theory things can be done better, in practice in the real world, not so much. Resources are limited to everyone, commercial vendors, sponsored ones like Pharo and, last but not least, "users" [1]. [1] That, like me, read these discussions and only participate in the list because sometimes they seem biased because of a lack of consideration/feedback. I won't argue against the enormous progress and things being done by the whole Pharo team, but IMO minimizing the use of resources (time/effort) as a whole is more an objective than a resources thing. > The alternative is to never touch anything and stay stagnant. This is a false dichotomy. But can't deny its punch. :-) Regards, Esteban A. Maringolo

Nov. 28, 2019

[Pharo 8.0] Build #1024: CompletionFallBack

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

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

Nov. 28, 2019

Re: [Pharo-dev] [Mm10s] 2019-11-25

by Steven Costiou

Le 2019-11-28 14:15, ducasse a Ã©crit : > Thanks steven > If you need beta tester please let me know. Yes please, the halt/bp window in the debugger needs feedback. Start a P8 image, then reload spec https://github.com/pharo-spec/Spec then load NewTools https://github.com/pharo-spec/NewTools It should be active by default. Steven. > S. > >> On 28 Nov 2019, at 11:29, Steven Costiou <steven.costiou(a)kloum.io> wrote: >> >> ### Last week: >> >> - halt/breakpoint manager in the spec debugger: see all halt/breakpoints and (de)activate them in one click. When deactivated, a halt/breakpoint just prints a log message in the Transcript. >> >> - Pharo IOT book writing >> >> ### This week (starting 2019-11-25): >> >> - Pharo IOT book writing >> >> - add a "watch variable" window in the debugger to track variables during debugging >> >> ### Pipeline >> >> - Pharo IOT book >> >> - Enhancing the spec debugger: better breakpoint support, adding missing features (menus, options), fixing bugs >> >> - Integrating object-centric debugging in the spec2 tools >> >> - Writing a chapter/documentation about the Pharo debugger

Nov. 28, 2019

[Pharo 8.0] Build #1023: 5102-FastTable-Horizontal-Scrolling-not-implemented

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

There is a new Pharo build available! The status of the build #1023 was: SUCCESS. The Pull Request #5107 was integrated: "5102-FastTable-Horizontal-Scrolling-not-implemented" Pull request url: https://github.com/pharo-project/pharo/pull/5107 Issue Url: https://github.com/pharo-project/pharo/issues/5102 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 28, 2019

[ANN] freezing Pharo 8.0 development

by Esteban Lorenzano

Hi, After talk about current situation of P8 development, we decided we have already a version that is very stable (with some remaining problems, we know) and we think this is something we can release before start the new batch of breaking changes (move to headless vm by default, new object centric debugger, etc, etc, etc.) So, I am declaring the development status on âcode freezeâ and we will start working on stabilisation hoping to have a releasable version by end December, beginning of January (yes, this will be a short cycle, but that will allow us to make some iterations needed without the pressure of releasing on April). Enjoy, Esteban

Nov. 28, 2019

Re: [Pharo-dev] [Mm10s] 2019-11-25

by ducasse

Thanks steven If you need beta tester please let me know. S. > On 28 Nov 2019, at 11:29, Steven Costiou <steven.costiou(a)kloum.io> wrote: > > ### Last week: > > - halt/breakpoint manager in the spec debugger: see all halt/breakpoints and (de)activate them in one click. When deactivated, a halt/breakpoint just prints a log message in the Transcript. > > - Pharo IOT book writing > > > > ### This week (starting 2019-11-25): > > - Pharo IOT book writing > > - add a "watch variable" window in the debugger to track variables during debugging > > > ### Pipeline > > - Pharo IOT book > > - Enhancing the spec debugger: better breakpoint support, adding missing features (menus, options), fixing bugs > > - Integrating object-centric debugging in the spec2 tools > > - Writing a chapter/documentation about the Pharo debugger >

Nov. 28, 2019