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

[Pharo 8.0] Build #606: Repackage PositionableStream class >> with:do:

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

There is a new Pharo build available! The status of the build #606 was: FAILURE. The Pull Request #4247 was integrated: "Repackage PositionableStream class >> with:do: " Pull request url: https://github.com/pharo-project/pharo/pull/4247 Issue Url: https://github.com/pharo-project/pharo/issues/PositionableStream_class_with… Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 9, 2019

[Pharo 8.0] Build #605: Cleaning class names, comments, method formatting of Spec2-PolyWidgets

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

There is a new Pharo build available! The status of the build #605 was: FAILURE. The Pull Request #4257 was integrated: "Cleaning class names, comments, method formatting of Spec2-PolyWidgets" Pull request url: https://github.com/pharo-project/pharo/pull/4257 Issue Url: https://github.com/pharo-project/pharo/issues/4250 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 9, 2019

Re: [Pharo-dev] [ANN] Pharo Headless - Beta (Actually what is between Alpha and Beta)

by Norbert Hartl

This way cooler than expected. Lot of stuff already done. Great! Norbert > Am 08.08.2019 um 09:53 schrieb "tesonep(a)gmail.com" <tesonep(a)gmail.com>: > > TL;DR; > ====== > > For the anxious, you can get real headless vm and image from zero-conf. > > $ wget get.pharo.org/64/80+vmHeadlessLatest | bash > > Zero conf scripts remain unchanged for users. > > However, if you are launching the VM by hand from the executable > instead of the launcher scripts (pharo and pharo-ui) as in > > $ ./pharoexecutable Pharo.image > > the image will launch in headless mode and will not open a window. > To launch it in headfull, you can use the --interactive argument after > the image, which will make the image open a window using SDL2. > > $ ./pharoexecutable Pharo.image --interactive > > Long version > ============ > > Hi, this mail is the happy intermediate result of the work that us, > the Pharo Consortium Team, has been doing in the last couple of > months. > Our main objective is to have a real headless implementation of Pharo > where all the responsibility to open or not a World window (or other) > is handled by the image. > For doing so we have done a series of modifications in the image and > the VM side. > We consider this is the path that Pharo 8 and following versions > should follow, as it will severely improve server-side and command > line Pharo and in building custom desktop applications. > > These modifications are available only in 64-bits machines (Windows, > OSX, and Linux). > ARM32 and 64bits headless is in the roadmap, but it is delayed because > we have prioritized our three major platforms for this first couple of > months. > > All this work is based in Opensmalltalk-VM and Ronnie's initial work > on headless. > We are really grateful to all the contributors in the history of this > nice product. > To achieve a real headless VM we have brought modifications in the > source tree because most of the platform code to open and manipulate > windows is not required anymore. > Instead, we use the SDL2 library that implements a nice layer on top > of the OS and allows us to manage on the image side through FFI. > > So this mail is now an open call for (beta?)testing. > The sources of the current VM we are building are in the headless branch in > https://github.com/pharo-project/opensmalltalk-vm > And we have set up a CI that is both building and testing the VM in > https://ci.inria.fr/pharo-ci-jenkins2/job/pharo-vm/job/headless/ > > For the future we have a lot of ideas, that will wait for another long > email or a beer-talk @ESUG. > We want to hear your ideas!! > > Image-Side Improvements > ======================= > > - The image handles the creation or not of the main world window. > - We incorporated the idea of World renderer, where different backends > are used to render the world. > - We have 3 backends: VM support (compatibility with non-headless > VMs), and OSWindow with two backends: SDL and GTK3+. > - The modifications in the image are fully backward compatible with > the non-headless VM and are pushed since weeks in the latest 8.0 > image. > - We move the handling of events to the image side when using SDL and > GTK3+, opening the door to a richer set of events and finer-grained > control over them. > - SDL and GTK versions are implemented using FFI calls. > > VM-Side Improvements > ==================== > > - VMMaker code migrated to Tonel thanks to Feenk and included in the > repository of the VM. > - Making VMMaker execute in Pharo 7 and 8. > - Removing GPL code from the VM repository (GDB). > > - Slowly adding new tests for the JIT / Slang and VMGeneration. > - Restructuring of the source code. > - A new simpler CMake build. > - Generate VM code from Slang on each build. > - A CI process to validate (including the run of the tests in Pharo > and the ones adding to the VM). > - Simplification of the codebase. > > - Maximize the reuse of code between the platforms (preferring the > standard versions over the platform-specific). > - Cleaning up duplicated code. > - All the plugins are now external plugins. > - The VM is now a dynamic library. This is a first step towards > embedding Pharo into other applications. > - The main executable is a thin frontend (you can change it or > implement your own). > > - Removing unused plugins. > - Improved crash dump. Especially the crash dump works now in Windows 64bits. > - Dummy implementation of Security plugin (it is going away.... eventually). > - Cleanup of SSL, UUID, and Socket plugin. > > - Cleanup of conditional code (Still to improve). > - Improving the types used in the functions (we have to be neat to be > multiplatform/multi-arch). > - Improving the lookup of modules > - Improving the logging of the VM > - Improving the handling of VM arguments > > > Thanks a lot for reading so long!! > We hope you enjoy the VM and please tell us all the problems you find!! > > Pablo, Guille, and Esteban >

Aug. 8, 2019

Call for Papers, The Programming Journal, Volume 4, Issue 3

by Fabio Niephaus

======================================================================== The Programming Journal The Art, Science, and Engineering of Programming Call for Papers for Volume 4, Issue 3 http://programming-journal.org/cfp/ Follow us on Twitter: @programmingconf ======================================================================== The Art, Science, and Engineering of Programming was created with the goal of placing the wonderful art of programming on the map of scholarly works. Many academic journals and conferences exist that publish research related to programming, starting with programming languages, software engineering, and expanding to the whole Computer Science field. Yet, many of us feel that, as the field of Computer Science expanded, programming, in itself, has been neglected to a secondary role not worthy of scholarly attention. That is a serious gap, as much of the progress in Computer Science lies on the basis of computer programs, the people who write them, and the concepts and tools available to them to express computational tasks. The Art, Science, and Engineering of Programming aims at closing this gap by focusing primarily on programming: the art itself (programming styles, pearls, models, languages), the emerging science of understanding what works and what doesnât work in general and in specific contexts, as well as more established engineering and mathematical perspectives. We solicit papers describing work from one of the following perspectives: Art: knowledge and technical skills acquired through practice and personal experiences. Examples include libraries, frameworks, languages, APIs, programming models and styles, programming pearls, and essays about programming. Science (Theoretical): knowledge and technical skills acquired through mathematical formalisms. Examples include formal programming models and proofs. Science (Empirical): knowledge and technical skills acquired through experiments and systematic observations. Examples include user studies and programming-related data mining. Engineering: knowledge and technical skills acquired through designing and building large systems and through calculated application of principles in building those systems. Examples include measurements of artifactsâ properties, development processes and tools, and quality assurance methods. Independent of the type of work, the journal accepts submissions covering several areas of expertise, including but not limited to: - General-purpose programming - Data mining and machine learning programming, and for programming - Database programming - Distributed systems programming - Graphics and GPU programming - Interpreters, virtual machines, and compilers - Metaprogramming and reflection - Model-based development - Modularity and separation of concerns - Parallel and multi-core programming - Program verification - Programming education - Programming environments - Security programming - Social coding - Testing and debugging - User interface programming - Visual and live programming All details, including the selection process are described on http://programming-journal.org/cfp/ Details on the submission processed are available at http://programming-journal.org/submission/ Authors of accepted papers will be invited to present at the <Programming>â20 conference in Porto, Portugal from March 23-26: https://2020.programming-conference.org/ ## Upcoming Deadlines We solicit submissions for the following upcoming deadlines: Submission: October 1 First notification: December 1 Revised submission: January 1 Final notification: January 7 Camera-ready: January 15 ## Standing Review Committee Volume 4 Christophe Scholliers, Ghent University Coen De Roover, Vrije Universiteit Brussel Craig Anslow, Victoria University of Wellington, New Zealand Didier Verna, EPITA / LRDE, France Diego Garbervetsky, University of Buenos Aires Edd Barrett, King's College London Erik Ernst, Google Felienne Hermans, Leiden University Francisco Sant'Anna, Rio de Janeiro State University Friedrich Steimann, University of Hagen Gordana Rakic, University of Novi Sad Guido Salvaneschi, TU Darmstadt Hidehiko Masuhara, Tokyo Institute of Technology Jeremy Gibbons, University of Oxford Jonathan Edwards, US Jun Kato, AIST, Japan Luke Church, University of Cambridge Matthew Flatt, University of Utah Michael L. Van De Vanter, Cal Poly San Luis Obispo NicolÃ¡s Cardozo, Universidad de los Andes, Colombia Stephen Kell, University of Kent ## Editors Stefan Marr (Editor Volume 4), University of Kent Cristina V. Lopes (Editor-in-Chief), University of California, Irvine

Aug. 8, 2019

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Headless - Beta (Actually what is between Alpha and Beta)

by Sven Van Caekenberghe

That is very impressive, thank you all ! > On 8 Aug 2019, at 09:53, tesonep(a)gmail.com wrote: > > TL;DR; > ====== > > For the anxious, you can get real headless vm and image from zero-conf. > > $ wget get.pharo.org/64/80+vmHeadlessLatest | bash > > Zero conf scripts remain unchanged for users. > > However, if you are launching the VM by hand from the executable > instead of the launcher scripts (pharo and pharo-ui) as in > > $ ./pharoexecutable Pharo.image > > the image will launch in headless mode and will not open a window. > To launch it in headfull, you can use the --interactive argument after > the image, which will make the image open a window using SDL2. > > $ ./pharoexecutable Pharo.image --interactive > > Long version > ============ > > Hi, this mail is the happy intermediate result of the work that us, > the Pharo Consortium Team, has been doing in the last couple of > months. > Our main objective is to have a real headless implementation of Pharo > where all the responsibility to open or not a World window (or other) > is handled by the image. > For doing so we have done a series of modifications in the image and > the VM side. > We consider this is the path that Pharo 8 and following versions > should follow, as it will severely improve server-side and command > line Pharo and in building custom desktop applications. > > These modifications are available only in 64-bits machines (Windows, > OSX, and Linux). > ARM32 and 64bits headless is in the roadmap, but it is delayed because > we have prioritized our three major platforms for this first couple of > months. > > All this work is based in Opensmalltalk-VM and Ronnie's initial work > on headless. > We are really grateful to all the contributors in the history of this > nice product. > To achieve a real headless VM we have brought modifications in the > source tree because most of the platform code to open and manipulate > windows is not required anymore. > Instead, we use the SDL2 library that implements a nice layer on top > of the OS and allows us to manage on the image side through FFI. > > So this mail is now an open call for (beta?)testing. > The sources of the current VM we are building are in the headless branch in > https://github.com/pharo-project/opensmalltalk-vm > And we have set up a CI that is both building and testing the VM in > https://ci.inria.fr/pharo-ci-jenkins2/job/pharo-vm/job/headless/ > > For the future we have a lot of ideas, that will wait for another long > email or a beer-talk @ESUG. > We want to hear your ideas!! > > Image-Side Improvements > ======================= > > - The image handles the creation or not of the main world window. > - We incorporated the idea of World renderer, where different backends > are used to render the world. > - We have 3 backends: VM support (compatibility with non-headless > VMs), and OSWindow with two backends: SDL and GTK3+. > - The modifications in the image are fully backward compatible with > the non-headless VM and are pushed since weeks in the latest 8.0 > image. > - We move the handling of events to the image side when using SDL and > GTK3+, opening the door to a richer set of events and finer-grained > control over them. > - SDL and GTK versions are implemented using FFI calls. > > VM-Side Improvements > ==================== > > - VMMaker code migrated to Tonel thanks to Feenk and included in the > repository of the VM. > - Making VMMaker execute in Pharo 7 and 8. > - Removing GPL code from the VM repository (GDB). > > - Slowly adding new tests for the JIT / Slang and VMGeneration. > - Restructuring of the source code. > - A new simpler CMake build. > - Generate VM code from Slang on each build. > - A CI process to validate (including the run of the tests in Pharo > and the ones adding to the VM). > - Simplification of the codebase. > > - Maximize the reuse of code between the platforms (preferring the > standard versions over the platform-specific). > - Cleaning up duplicated code. > - All the plugins are now external plugins. > - The VM is now a dynamic library. This is a first step towards > embedding Pharo into other applications. > - The main executable is a thin frontend (you can change it or > implement your own). > > - Removing unused plugins. > - Improved crash dump. Especially the crash dump works now in Windows 64bits. > - Dummy implementation of Security plugin (it is going away.... eventually). > - Cleanup of SSL, UUID, and Socket plugin. > > - Cleanup of conditional code (Still to improve). > - Improving the types used in the functions (we have to be neat to be > multiplatform/multi-arch). > - Improving the lookup of modules > - Improving the logging of the VM > - Improving the handling of VM arguments > > > Thanks a lot for reading so long!! > We hope you enjoy the VM and please tell us all the problems you find!! > > Pablo, Guille, and Esteban >

Aug. 8, 2019

[Pharo 8.0] Build #604: Fix allocation tests

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

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

Aug. 8, 2019

[Pharo 8.0] Build #603: Fix word layouts and friends

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

There is a new Pharo build available! The status of the build #603 was: SUCCESS. The Pull Request #4243 was integrated: "Fix word layouts and friends" Pull request url: https://github.com/pharo-project/pharo/pull/4243 Issue Url: https://github.com/pharo-project/pharo/issues/fix/wordlayouts Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 8, 2019

[ANN] Pharo Headless - Beta (Actually what is between Alpha and Beta)

by tesonep＠gmail.com

TL;DR; ====== For the anxious, you can get real headless vm and image from zero-conf. $ wget get.pharo.org/64/80+vmHeadlessLatest | bash Zero conf scripts remain unchanged for users. However, if you are launching the VM by hand from the executable instead of the launcher scripts (pharo and pharo-ui) as in $ ./pharoexecutable Pharo.image the image will launch in headless mode and will not open a window. To launch it in headfull, you can use the --interactive argument after the image, which will make the image open a window using SDL2. $ ./pharoexecutable Pharo.image --interactive Long version ============ Hi, this mail is the happy intermediate result of the work that us, the Pharo Consortium Team, has been doing in the last couple of months. Our main objective is to have a real headless implementation of Pharo where all the responsibility to open or not a World window (or other) is handled by the image. For doing so we have done a series of modifications in the image and the VM side. We consider this is the path that Pharo 8 and following versions should follow, as it will severely improve server-side and command line Pharo and in building custom desktop applications. These modifications are available only in 64-bits machines (Windows, OSX, and Linux). ARM32 and 64bits headless is in the roadmap, but it is delayed because we have prioritized our three major platforms for this first couple of months. All this work is based in Opensmalltalk-VM and Ronnie's initial work on headless. We are really grateful to all the contributors in the history of this nice product. To achieve a real headless VM we have brought modifications in the source tree because most of the platform code to open and manipulate windows is not required anymore. Instead, we use the SDL2 library that implements a nice layer on top of the OS and allows us to manage on the image side through FFI. So this mail is now an open call for (beta?)testing. The sources of the current VM we are building are in the headless branch in https://github.com/pharo-project/opensmalltalk-vm And we have set up a CI that is both building and testing the VM in https://ci.inria.fr/pharo-ci-jenkins2/job/pharo-vm/job/headless/ For the future we have a lot of ideas, that will wait for another long email or a beer-talk @ESUG. We want to hear your ideas!! Image-Side Improvements ======================= - The image handles the creation or not of the main world window. - We incorporated the idea of World renderer, where different backends are used to render the world. - We have 3 backends: VM support (compatibility with non-headless VMs), and OSWindow with two backends: SDL and GTK3+. - The modifications in the image are fully backward compatible with the non-headless VM and are pushed since weeks in the latest 8.0 image. - We move the handling of events to the image side when using SDL and GTK3+, opening the door to a richer set of events and finer-grained control over them. - SDL and GTK versions are implemented using FFI calls. VM-Side Improvements ==================== - VMMaker code migrated to Tonel thanks to Feenk and included in the repository of the VM. - Making VMMaker execute in Pharo 7 and 8. - Removing GPL code from the VM repository (GDB). - Slowly adding new tests for the JIT / Slang and VMGeneration. - Restructuring of the source code. - A new simpler CMake build. - Generate VM code from Slang on each build. - A CI process to validate (including the run of the tests in Pharo and the ones adding to the VM). - Simplification of the codebase. - Maximize the reuse of code between the platforms (preferring the standard versions over the platform-specific). - Cleaning up duplicated code. - All the plugins are now external plugins. - The VM is now a dynamic library. This is a first step towards embedding Pharo into other applications. - The main executable is a thin frontend (you can change it or implement your own). - Removing unused plugins. - Improved crash dump. Especially the crash dump works now in Windows 64bits. - Dummy implementation of Security plugin (it is going away.... eventually). - Cleanup of SSL, UUID, and Socket plugin. - Cleanup of conditional code (Still to improve). - Improving the types used in the functions (we have to be neat to be multiplatform/multi-arch). - Improving the lookup of modules - Improving the logging of the VM - Improving the handling of VM arguments Thanks a lot for reading so long!! We hope you enjoy the VM and please tell us all the problems you find!! Pablo, Guille, and Esteban

Aug. 8, 2019

[Pharo 8.0] Build #601: 4214-Code-Completion-DNU-on-visitAssignmentNode

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

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

Aug. 6, 2019

Iceberg and package renamings

by Torsten Bergmann

Hi, usually when contributing I download a fresh Pharo 8 image (built by CI) using either Launcher or ZeroConf and use the Iceberg "repair" functionality to connect to / checkout the existing local clone of the repo with the Pharo 8 branch. This way I usually easily come easily to the "up to date" state and can start own modifications. But this time I used an older Pharo 8 image. So I pulled from upstream, pushed to my origin (forked git repo) and updated an already existing image also using the "repair" functionality. The changes where assembled and loaded. This way I also got into the "up to date" state for this image. But as one of the last changes done was a package renaming of "ReleaseTest" into "Release-Tests" this was reflected on the "src" folder on disk but not in the image itself. So unfortunately - the git repo was already having a "Release-Tests" folder in synch with the upstream - the local "up to date" image stayed with the old "ReleaseTests" package name as it was updated and not freshly bootstrapped from Baselines and with this out of synch. See attached screenshot. So I guess Iceberg's updating can not yet properly handle package renamings, maybe this is a known bug / not yet implemented feature - or something that is not easy to fix due to the renaming. Is this known? Could it be handled in the future? Just want to mention this as this could be a source of further problems when contributors update their image instead of using a new CI built one as they may hit such a renamed package. Bye T.

Aug. 6, 2019