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

[Pharo 8.0] Build #975: Completion: More Cleanups

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

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

Nov. 15, 2019

[Pharo 8.0] Build #974: Revert "Rules-are-failing-on-bytearrays"

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

There is a new Pharo build available! The status of the build #974 was: SUCCESS. The Pull Request #5144 was integrated: "Revert "Rules-are-failing-on-bytearrays"" Pull request url: https://github.com/pharo-project/pharo/pull/5144 Issue Url: https://github.com/pharo-project/pharo/issues/revert Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 15, 2019

[Pharo 8.0] Build #973: Completion: #completionEntries creates entries

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

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

Nov. 15, 2019

[Pharo 8.0] Build #972: 4967-Base-image-contains-invalid-source-pointers

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

There is a new Pharo build available! The status of the build #972 was: FAILURE. The Pull Request #5120 was integrated: "4967-Base-image-contains-invalid-source-pointers" Pull request url: https://github.com/pharo-project/pharo/pull/5120 Issue Url: https://github.com/pharo-project/pharo/issues/4967 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 15, 2019

Re: [Pharo-dev] two issues: GC and wrong pointers

by Juraj Kubelka

Hi, we found a script that reproduces the GC segmentation fault. The report is here - https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/444 <https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/444> - which is likely the same issue as reported here: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/391 <https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/391> Best, Juraj > On 12 Nov 2019, at 12:40, ducasse <stepharo(a)netcourrier.com> wrote: > > ok > It may be related to the bug pablo is working on. > So it would be good to see how many times the image is saved. > > Stef > >> On 12 Nov 2019, at 08:58, Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote: >> >> ith all other bug reports. >

Nov. 13, 2019

MoreVMs 2020 : Workshop on Modern Language Runtimes, Ecosystems, and VMs

by Fabio Niephaus

============================================================================ Call for Extended Abstracts and Talks: MoreVMsâ20 4th Workshop on Modern Language Runtimes, Ecosystems, and VMs Co-located with â¹Programmingâºâ20 March 23rd or 24th, 2020, Porto, Portugal https://2020.programming-conference.org/home/MoreVMs-2020 ============================================================================ Following three previous successful editions, the MoreVMsâ20 workshop aims to bring together industrial and academic programmers to discuss the design, implementation, and usage of modern languages and runtimes. This includes aspects such as reuse of language runtimes, modular implementation, language design, and compilation strategies. By bringing together both researchers and practitioners, the workshop aims to enable a diverse discussion on how languages and runtimes are currently being utilized, and where they need to improve further. In addition to conventional workshop-style submissions, MoreVMs also accepts (and encourages) submissions that present early-stage work and emerging ideas. Relevant topics include, but are definitely not limited to, the following: - Extensible VM design (compiler- or interpreter-based VMs) - Reusable components (e.g. interpreters, garbage collectors, ...) - Static and dynamic compilation techniques - Techniques for targeting high-level languages such as JavaScript - Interoperability between languages - Tooling support (e.g. debugging, profiling, etc.) - Programming language development environments - Case studies of existing language implementation approaches - Language implementation challenges and trade-offs - Surveys and usage reports to understand usage in the wild - Ideas for more predictable performance - Ideas for how VMs could take advantage of new hardware features - Ideas for how we should build languages in the future Workshop Format and Submissions ------------------------------- We welcome presentation proposals in the form of extended abstracts (2 to 4 pages long) and talk proposals (title and 400 words abstract) discussing new techniques, insights, experiences, works-in-progress, as well as future visions, from either an academic or industrial perspective. The extended abstracts and talk proposals, and if the speakers wish, their slides, will be published on the workshop's website. Alternatively, extended abstracts can be published as part of the companion of â¹Programmingâºâ20 in the ACM DL. Publication in the ACM DL is conditional on the acceptance by the program committee. Please note that MoreVMsâ20 is organized as an academic workshop, and as such, speakers will be required to register for the workshop. We regret that we are unable to cover registration, travel, or accommodation costs for authors. Author Instructions ------------------- Submissions should use the ACM `acmart` format: https://www.acm.org/publications/proceedings-template If you are using LaTeX, submissions should use the 'acmart' document class with the 'sigconf' option, and with a font size of 9 point. Please use the Libertine/Biolinum font family. Please include page numbers in your submission using the LaTeX command `\settopmatter{printfolios=true}`. All submissions should be in PDF format. Please also ensure that your submission is legible when printed on a black and white printer. In particular, please check that colors remain distinct and font sizes are legible. Submission Site: https://easychair.org/conferences/?conf=morevms20 Important Dates --------------- Extended abstract and talk submissions: 2020-01-10 Author notification: 2020-02-10 Camera Ready: 2020-02-21 Workshop: 2020-03-23 or 2020-03-24 All deadlines are Anywhere on Earth (AoE), i.e. GMT/UTC-12:00 hour. Invited Speakers ----------------- Roman Kennke, Shenandoah GC Project Lead, Red Hat Leszek Swirski, Software Engineer, V8 Team, Google Program Committee ----------------- Nicolas B. Pierron, Mozilla, France ClÃ©ment BÃ©ra, Google, Denmark Elisa Gonzalez Boix, Vrije Universiteit Brussel, Belgium Stephen Kell, University of Kent, United Kingdom Christoph Kirsch, University of Salzburg, Austria Hidehiko Masuhara, Tokyo Institute of Technology, Japan Gabriela Alexandra Moldovan, Cloudflare, United Kingdom David Pearce, Victoria University of Wellington, New Zealand Manuel Rigger, ETH Zurich, Switzerland Jennifer B. Sartor, Ghent University and Vrije Universiteit Brussel, Belgium Tomoharu Ugawa, Kochi University of Technology, Japan Michael Van De Vanter, Cal Poly, San Luis Obispo, United States Andy Wingo, Igalia, S.L., United States Organizers ---------- Edd Barrett, King's College London, United Kingdom Fabio Niephaus, Hasso Plattner Institute, University of Potsdam, Germany

Nov. 13, 2019

Re: [Pharo-dev] deprecating use traditional formatter

by ducasse

So I did it in https://github.com/Ducasse/enlumineur I will work on the removal of the previous formatter and the introduction of the new one. Stef > On 13 Nov 2019, at 10:06, ducasse <stepharo(a)netcourrier.com> wrote: > > I will do it :) > >> On 13 Nov 2019, at 10:05, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> >> >> >>> On 13 Nov 2019, at 09:04, ducasse <stepharo(a)netcourrier.com <mailto:stepharo@netcourrier.com>> wrote: >>> >>> Hi >>> >>> In the new implementation of the code formattter I will remove useTraditionalPrecedence. >>> This settings put additional parentheses around binary selector but I find it cumbersome >>> >>> While it may make sense for >>> >>> it turns >>> foo >>> ^ 1 + 2 * 3 >>> >>> into >>> >>> foo >>> ^ (1 + 2) * 3 >>> >>> foo >>> ^ 1 * 3 + 2 >>> >>> foo >>> ^ (1 | 2) % 3 >>> >>> foo >>> >>> ^ 1 % 2 | 3 >>> >>> So let me know what you think but I will be hard to convince :) >>> >> I vote to remove it. >> >> The RB AST encodes parenthesis information, so that means that we can have >> a pretty printer keeping the parenthesis if they have been added by the original author. >> >> Adding new ones makes no sense to me. >> >> So I vote to remove. >> >> Marcus >

Nov. 13, 2019

Re: [Pharo-dev] deprecating use traditional formatter

by ducasse

I will do it :) > On 13 Nov 2019, at 10:05, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > >> On 13 Nov 2019, at 09:04, ducasse <stepharo(a)netcourrier.com> wrote: >> >> Hi >> >> In the new implementation of the code formattter I will remove useTraditionalPrecedence. >> This settings put additional parentheses around binary selector but I find it cumbersome >> >> While it may make sense for >> >> it turns >> foo >> ^ 1 + 2 * 3 >> >> into >> >> foo >> ^ (1 + 2) * 3 >> >> foo >> ^ 1 * 3 + 2 >> >> foo >> ^ (1 | 2) % 3 >> >> foo >> >> ^ 1 % 2 | 3 >> >> So let me know what you think but I will be hard to convince :) >> > I vote to remove it. > > The RB AST encodes parenthesis information, so that means that we can have > a pretty printer keeping the parenthesis if they have been added by the original author. > > Adding new ones makes no sense to me. > > So I vote to remove. > > Marcus

Nov. 13, 2019

Re: [Pharo-dev] deprecating use traditional formatter

by Marcus Denker

> On 13 Nov 2019, at 09:04, ducasse <stepharo(a)netcourrier.com> wrote: > > Hi > > In the new implementation of the code formattter I will remove useTraditionalPrecedence. > This settings put additional parentheses around binary selector but I find it cumbersome > > While it may make sense for > > it turns > foo > ^ 1 + 2 * 3 > > into > > foo > ^ (1 + 2) * 3 > > foo > ^ 1 * 3 + 2 > > foo > ^ (1 | 2) % 3 > > foo > > ^ 1 % 2 | 3 > > So let me know what you think but I will be hard to convince :) > I vote to remove it. The RB AST encodes parenthesis information, so that means that we can have a pretty printer keeping the parenthesis if they have been added by the original author. Adding new ones makes no sense to me. So I vote to remove. Marcus

Nov. 13, 2019

deprecating use traditional formatter

by ducasse

Hi In the new implementation of the code formattter I will remove useTraditionalPrecedence. This settings put additional parentheses around binary selector but I find it cumbersome While it may make sense for it turns foo ^ 1 + 2 * 3 into foo ^ (1 + 2) * 3 foo ^ 1 * 3 + 2 foo ^ (1 | 2) % 3 foo ^ 1 % 2 | 3 So let me know what you think but I will be hard to convince :) Stef

Nov. 13, 2019