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

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

by ducasse

> On 11 Aug 2019, at 13:19, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Excellent news! > > I should say that for GT we are currently using the minheadlessVM (Ronieâs work) out of the opensmalltalk-vm repo (https://bintray.com/opensmalltalk/vm/cog) and it works remarkably well. > > We started to play with your minheadlessVM. So far it looks like there are differences, although I am sure they are not large. like what? > > So, what is the difference between the minheadlessVM built by you versus the one from opensmalltalk-vm? > > Cheers, > Doru > > >> On Aug 8, 2019, at 9:53 AM, 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 >> > > -- > feenk.com > > "Being happy is a matter of choice." > > > > > > >

Aug. 11, 2019

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

by Santiago Bragagnolo

Hey! I just see this email! This is exciting! <3 <3 <3 <3 El jue., 8 ago. 2019 a las 9:54, tesonep(a)gmail.com (<tesonep(a)gmail.com>) escribiÃ³: > 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. 11, 2019

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

by Tudor Girba

Excellent news! I should say that for GT we are currently using the minheadlessVM (Ronieâs work) out of the opensmalltalk-vm repo (https://bintray.com/opensmalltalk/vm/cog) and it works remarkably well. We started to play with your minheadlessVM. So far it looks like there are differences, although I am sure they are not large. So, what is the difference between the minheadlessVM built by you versus the one from opensmalltalk-vm? Cheers, Doru > On Aug 8, 2019, at 9:53 AM, 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 > -- feenk.com "Being happy is a matter of choice."

Aug. 11, 2019

An old but insightful critique of Eric Raymondâs The Cathedral and the Bazaar by Nikolai Bezroukov

by Eliot Miranda

This may be old news. It was news to me and apart from being an excellent critique of tCatB it also includes many truths about large software systems and if open source communities in general. If you havenât read it already may I suggest it is well worth your time reading. https://firstmonday.org/article/view/708/618/ _,,,^..^,,,_ (phone)

Aug. 10, 2019

(7.0.3) writing a large(?) string to stdout is mangled

by Dale Henrichs

I've run into an issue with pharo 7.0.3 where writing a string that contains embedded crs or lfs to stdout causes the output to be corrupted in odd ways. I have provided the details and a reproducible test case up on github[1]. Stef suggested I post the issue here as well ... Dale [1] https://github.com/pharo-project/pharo/issues/4266

Aug. 10, 2019

[Pharo 8.0] Build #611: Zinc-Character-Encoding-test-cases-should-end-with-Test

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

There is a new Pharo build available! The status of the build #611 was: FAILURE. The Pull Request #4267 was integrated: "Zinc-Character-Encoding-test-cases-should-end-with-Test" Pull request url: https://github.com/pharo-project/pharo/pull/4267 Issue Url: https://github.com/pharo-project/pharo/issues/Zinc Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 10, 2019

[Pharo 8.0] Build #610: Remove-duplicated-method-in-TraitedClass

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

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

Aug. 9, 2019

[Pharo 8.0] Build #609: ReTestClassNameShouldEndWithTest-should-also-accept-TestCase

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

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

Aug. 9, 2019

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

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

There is a new Pharo build available! The status of the build #608 was: SUCCESS. 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 #607: Exposing icon from the worldState with a form as argument.

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

There is a new Pharo build available! The status of the build #607 was: FAILURE. The Pull Request #4249 was integrated: "Exposing icon from the worldState with a form as argument." Pull request url: https://github.com/pharo-project/pharo/pull/4249 Issue Url: https://github.com/pharo-project/pharo/issues/fix/icontests Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 9, 2019

[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

[Pharo 8.0] Build #600: Remove-shadow-variables

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

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

Aug. 6, 2019

[Pharo 8.0] Build #599: 4206-Cleaning-arcTan-comment-and-adding-executable-comments

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

There is a new Pharo build available! The status of the build #599 was: SUCCESS. The Pull Request #4207 was integrated: "4206-Cleaning-arcTan-comment-and-adding-executable-comments" Pull request url: https://github.com/pharo-project/pharo/pull/4207 Issue Url: https://github.com/pharo-project/pharo/issues/4206 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 6, 2019

[Pharo 8.0] Build #598: Move method to make it work

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

There is a new Pharo build available! The status of the build #598 was: FAILURE. The Pull Request #4202 was integrated: "Move method to make it work" Pull request url: https://github.com/pharo-project/pharo/pull/4202 Issue Url: https://github.com/pharo-project/pharo/issues/fix/udptest Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 6, 2019

[Pharo 8.0] Build #597: Fixing the dependency analysis of BaselineOfIDE

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

There is a new Pharo build available! The status of the build #597 was: SUCCESS. The Pull Request #4200 was integrated: "Fixing the dependency analysis of BaselineOfIDE" Pull request url: https://github.com/pharo-project/pharo/pull/4200 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…

Aug. 6, 2019

Re: [Pharo-dev] [FileReference] why this class don't provide a method isAHiddenFile ?

by Alistair Grant

I should have looked before typing :-) My memory of the FileSystemDirectoryEntry hierarchy was wrong, so it isn't as simple as I thought. But I'll still take a look at this. Cheers, Alistair On Tue, 6 Aug 2019 at 12:19, ducasse <stepharo(a)netcourrier.com> wrote: > > Ok then this is good. > > > > > Something like this will work: > > > > aDirectoryFileReference entries select: [ :each | each isHidden ] > > > > Cheers, > > Alistair > > > > >

Aug. 6, 2019

Re: [Pharo-dev] [FileReference] why this class don't provide a method isAHiddenFile ?

by ducasse

Ok then this is good. > > Something like this will work: > > aDirectoryFileReference entries select: [ :each | each isHidden ] > > Cheers, > Alistair >

Aug. 6, 2019

Re: [Pharo-dev] [FileReference] why this class don't provide a method isAHiddenFile ?

by Alistair Grant

On Tue, 6 Aug 2019 at 12:05, ducasse <stepharo(a)netcourrier.com> wrote: > > > > > On 6 Aug 2019, at 12:01, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > Hi Stef, > > > > On Fri, 2 Aug 2019 at 09:19, ducasse <stepharo(a)netcourrier.com> wrote: > >> > >> It would be good to encapsulate this behavior may be with double dispatch with the platform. > >> Else clients end up to be forced to check. > > > > Why do you think this might need double dispatch? > > I thought that it is specific and different on each platform. > > > > > My idea was that it can be added to FileSystemDirectoryEntry and > > subclasses (FileReference is already fairly heavily loaded, and should > > be kept to the basic, platform common attributes). The main reason I > > didn't was because most of the attributes are windows specific, and I > > was focusing on getting the basic behaviour working and integrated. > > > > Adding just this attribute is fairly simple. I'll submit a PR soon(ish). > > You see as a user I would like to be able to write. > > aFileReference allHiddenFiles > > and do not care that Iâm on windows or mac but this is probably too naive. Something like this will work: aDirectoryFileReference entries select: [ :each | each isHidden ] Cheers, Alistair

Aug. 6, 2019

Re: [Pharo-dev] [FileReference] why this class don't provide a method isAHiddenFile ?

by Alistair Grant

For future reference: https://github.com/pharo-project/pharo/issues/4201 On Tue, 6 Aug 2019 at 12:01, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Stef, > > On Fri, 2 Aug 2019 at 09:19, ducasse <stepharo(a)netcourrier.com> wrote: > > > > It would be good to encapsulate this behavior may be with double dispatch with the platform. > > Else clients end up to be forced to check. > > Why do you think this might need double dispatch? > > My idea was that it can be added to FileSystemDirectoryEntry and > subclasses (FileReference is already fairly heavily loaded, and should > be kept to the basic, platform common attributes). The main reason I > didn't was because most of the attributes are windows specific, and I > was focusing on getting the basic behaviour working and integrated. > > Adding just this attribute is fairly simple. I'll submit a PR soon(ish). > > Cheers, > Alistair > > > > > > Stef > > > > > On 1 Aug 2019, at 21:22, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > > > On Thu, 1 Aug 2019 at 20:51, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > >> > > >> I imagine because it is quite a rare edge-case use and is not easy to implement: > > >> - for Linux you check for dot > > >> - for Windows you need to either modify the VM (see File class>>lookupDirectory:filename: to provide more information), or directly use WinAPI from Pharo to retrieve the hidden file attribute > > >> - for MacOS it is my understanding that you need to do both of the above and then some > > >> > > >> Peter > > >> > > > > > > As Peter wrote, this hasn't been requested much, but... > > > > > > In Pharo 8: > > > > > > (aFileReference entry statAttributes at: 13) anyMask: 16r2 > > > > > > Will answer a boolean indicating whether it is hidden or not (only on Windows). > > > > > > "aFileReference entry statAttributes at: 13" is the > > > WIN32_FILE_ATTRIBUTE_DATA: > > > https://docs.microsoft.com/en-us/windows/win32/fileio/file-attribute-consta… > > > > > > HTH, > > > Alistair > > > > > > > > >

Aug. 6, 2019

Re: [Pharo-dev] [FileReference] why this class don't provide a method isAHiddenFile ?

by ducasse

> On 6 Aug 2019, at 12:01, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Stef, > > On Fri, 2 Aug 2019 at 09:19, ducasse <stepharo(a)netcourrier.com> wrote: >> >> It would be good to encapsulate this behavior may be with double dispatch with the platform. >> Else clients end up to be forced to check. > > Why do you think this might need double dispatch? I thought that it is specific and different on each platform. > > My idea was that it can be added to FileSystemDirectoryEntry and > subclasses (FileReference is already fairly heavily loaded, and should > be kept to the basic, platform common attributes). The main reason I > didn't was because most of the attributes are windows specific, and I > was focusing on getting the basic behaviour working and integrated. > > Adding just this attribute is fairly simple. I'll submit a PR soon(ish). You see as a user I would like to be able to write. aFileReference allHiddenFiles and do not care that Iâm on windows or mac but this is probably too naive. > > Cheers, > Alistair > > > > >> Stef >> >>> On 1 Aug 2019, at 21:22, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>> >>> On Thu, 1 Aug 2019 at 20:51, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>>> >>>> I imagine because it is quite a rare edge-case use and is not easy to implement: >>>> - for Linux you check for dot >>>> - for Windows you need to either modify the VM (see File class>>lookupDirectory:filename: to provide more information), or directly use WinAPI from Pharo to retrieve the hidden file attribute >>>> - for MacOS it is my understanding that you need to do both of the above and then some >>>> >>>> Peter >>>> >>> >>> As Peter wrote, this hasn't been requested much, but... >>> >>> In Pharo 8: >>> >>> (aFileReference entry statAttributes at: 13) anyMask: 16r2 >>> >>> Will answer a boolean indicating whether it is hidden or not (only on Windows). >>> >>> "aFileReference entry statAttributes at: 13" is the >>> WIN32_FILE_ATTRIBUTE_DATA: >>> https://docs.microsoft.com/en-us/windows/win32/fileio/file-attribute-consta… >>> >>> HTH, >>> Alistair >>> >> >> >> >

Aug. 6, 2019

Re: [Pharo-dev] [FileReference] why this class don't provide a method isAHiddenFile ?

by Alistair Grant

Hi Stef, On Fri, 2 Aug 2019 at 09:19, ducasse <stepharo(a)netcourrier.com> wrote: > > It would be good to encapsulate this behavior may be with double dispatch with the platform. > Else clients end up to be forced to check. Why do you think this might need double dispatch? My idea was that it can be added to FileSystemDirectoryEntry and subclasses (FileReference is already fairly heavily loaded, and should be kept to the basic, platform common attributes). The main reason I didn't was because most of the attributes are windows specific, and I was focusing on getting the basic behaviour working and integrated. Adding just this attribute is fairly simple. I'll submit a PR soon(ish). Cheers, Alistair > Stef > > > On 1 Aug 2019, at 21:22, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > On Thu, 1 Aug 2019 at 20:51, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > >> > >> I imagine because it is quite a rare edge-case use and is not easy to implement: > >> - for Linux you check for dot > >> - for Windows you need to either modify the VM (see File class>>lookupDirectory:filename: to provide more information), or directly use WinAPI from Pharo to retrieve the hidden file attribute > >> - for MacOS it is my understanding that you need to do both of the above and then some > >> > >> Peter > >> > > > > As Peter wrote, this hasn't been requested much, but... > > > > In Pharo 8: > > > > (aFileReference entry statAttributes at: 13) anyMask: 16r2 > > > > Will answer a boolean indicating whether it is hidden or not (only on Windows). > > > > "aFileReference entry statAttributes at: 13" is the > > WIN32_FILE_ATTRIBUTE_DATA: > > https://docs.microsoft.com/en-us/windows/win32/fileio/file-attribute-consta… > > > > HTH, > > Alistair > > > > >

Aug. 6, 2019

Re: [Pharo-dev] [ANN] Pharo Launcher 1.9.1 released

by Christophe Demarey

Hi Sean, > Le 26 juil. 2019 Ã 15:23, Sean P. DeNigris <sean(a)clipperadams.com> a Ã©crit : > > demarey wrote >> we want more feedback before promoting it. > > "Show in folder" doesn't work - still trying to use OSProcess which appears > to no longer be loaded. BTW IMHO it would be better to create a layer to > hide the process differences on different OSes. This new world of a > different lib for each OS is hopefully a milestone on a path to a more > unified future, and it will be harder to clean out all the "if windows" > conditionals later. True. I also discovered that juste after the 1.9.1 release. Thatâs why I did the 1.9.2 release (see https://github.com/pharo-project/pharo-launcher/releases/tag/1.9.2 <https://github.com/pharo-project/pharo-launcher/releases/tag/1.9.2>). It is fixed in this version. Christophe.

Aug. 6, 2019

Re: [Pharo-dev] Two Surprising and Scary FS Behaviors

by ducasse

I like your analysis because indeed it can bring bad news. Can you turn this behaviour into memory file system tests? So that we make sure that we should find a solution. Stf > On 6 Aug 2019, at 00:41, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > I may be ignorant of some key principle in the filesystem world, but IMHO > conceptually, `location / somethingElse` should always return either > location or something inside of it, unless the request explicitly requests > otherwise (e.g. location / '..'). To do otherwise could be disastrous. > > Behavior #1 > rootDataFolder := FileLocator home / 'a' / 'b' / . > subfolderName := self accidentallyReturnAnEmptyString. > assumedToBeInRootData := rootDataFolder / subfolderName. > assumedToBeInRootData deleteAll. > > "I hope I have a recent machine backup, because..." > assumedToBeInRootData resolve = FileLocator root resolve. "WTH?!" > > Behavior 2 (similar) > Path * 'a' / 'b' / '/' = Path root. "WTH?!" > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Aug. 6, 2019

Two Surprising and Scary FS Behaviors

by Sean P. DeNigris

I may be ignorant of some key principle in the filesystem world, but IMHO conceptually, `location / somethingElse` should always return either location or something inside of it, unless the request explicitly requests otherwise (e.g. location / '..'). To do otherwise could be disastrous. Behavior #1 rootDataFolder := FileLocator home / 'a' / 'b' / . subfolderName := self accidentallyReturnAnEmptyString. assumedToBeInRootData := rootDataFolder / subfolderName. assumedToBeInRootData deleteAll. "I hope I have a recent machine backup, because..." assumedToBeInRootData resolve = FileLocator root resolve. "WTH?!" Behavior 2 (similar) Path * 'a' / 'b' / '/' = Path root. "WTH?!" ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Aug. 5, 2019

[Pharo 8.0] Build #596: 4137-Code-completion-error

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

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

Aug. 5, 2019

[Pharo 8.0] Build #595: Refactor a few tests to new classes

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

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

Aug. 5, 2019

Re: [Pharo-dev] Some new bindings for native emulation stuff

by Norbert Hartl

There is much sense in this mail, I like it. The unicorn GPL shouldnât be an issue in this usage scenario. Well done, Norbert > Am 05.08.2019 um 11:48 schrieb Guillermo Polito <guillermopolito(a)gmail.com>: > > >> El 3 ago 2019, a las 13:59, Norbert Hartl <norbert(a)hartl.name> escribiÃ³: >> >> That is pretty awesome. Couldnât be an constraint umbrella for VMMaker. This way it would be possible to write tests that check for resulting code. Or writing tests for the JIT (does sista has something like this). Could be one step closer to a deterministic code generation, no? > > Just to be fair, there are in Cog machine code simulation capabilities by using Bochs for intel and gdb 7.10 for arm32. > And there is also a starting point for testing the JIT. > > However, we have seen that for this the opensmalltalk-vm contains a copy of bochs and gdb source code > https://github.com/OpenSmalltalk/opensmalltalk-vm/tree/Cog/processors > > And with Pablo we have thought this was a suboptimal (both regarding building and licencingâ¦), so we started to look at alternatives. > Thatâs why we took a look at unicorn and llvm. Unicorn is ultimately based on qemu, which is fairly mature from our point of view. > There is not much to say about llvm :). > > What is nice is that with a single set of bindings we can cover lots of platforms. E.g., no need for new bindings for arm64. > > Aaand, with some little adjustments here and there, we have ~85% of 114 existing tests passing for arm32, x86 and x86-64. > <PastedGraphic-6.png> > > Of course there are not many tests, and they are only testing the basic compiler (just instructions) and not the Jitting of methods. > But itâs a good start. > > Now, also we were a bit picky about licensing: > - The llvm disassembler bindings are MIT. > - We have licensed the unicorn bindings as LGPL because Unicorn is GPL, and this would allow people to use the bindings without any requirements on licensing. However, any modifications to the bindings or unicorn itself should be further published as LGPL or GPL. > > Guille > >> >> Norbert >> >>> Am 02.08.2019 um 18:09 schrieb Guillermo Polito <guillermopolito(a)gmail.com>: >>> >>> Hi everybody, >>> >>> Iâve been playing around with machine code simulation this last week and Iâve made bindings for the unicorn library and the llvm disassembler: >>> >>> https://github.com/guillep/pharo-unicorn >>> https://github.com/guillep/pharo-llvmDisassembler >>> >>> Funny thing: both support lots of platforms (x86 and arm both 32 and 64 bits and moreâ¦). So out of the box we can simulate and disassemble lots of platforms. >>> >>> And in one afternoon Iâve played with them to do a native debugger with Spec2 just for fun. >>> Hope this evolves a bit more soon, and that it helps somebody. >>> >>> Guille >>> >>> <PastedGraphic-5.png> >>> >

Aug. 5, 2019

Looking for project using System-History

by ClÃ©ment Dutriez

Hello, I'm looking for a project using the Pharo System-History (class HistoryNode, HistoryLeaf). I want to use it in the fileDialog can someone send me a link to his project? Thank you in advance. -- Dutriez ClÃ©ment dutriezcle(a)gmail.com 0605199489 [image: www.linkedin.com/in/clÃ©ment-dutriez-407275173] <http://www.linkedin.com/in/clÃ©ment-dutriez-407275173>

Aug. 5, 2019

Re: [Pharo-dev] Some new bindings for native emulation stuff

by Guillermo Polito

> El 3 ago 2019, a las 13:59, Norbert Hartl <norbert(a)hartl.name> escribiÃ³: > > That is pretty awesome. Couldnât be an constraint umbrella for VMMaker. This way it would be possible to write tests that check for resulting code. Or writing tests for the JIT (does sista has something like this). Could be one step closer to a deterministic code generation, no? Just to be fair, there are in Cog machine code simulation capabilities by using Bochs for intel and gdb 7.10 for arm32. And there is also a starting point for testing the JIT. However, we have seen that for this the opensmalltalk-vm contains a copy of bochs and gdb source code https://github.com/OpenSmalltalk/opensmalltalk-vm/tree/Cog/processors <https://github.com/OpenSmalltalk/opensmalltalk-vm/tree/Cog/processors> And with Pablo we have thought this was a suboptimal (both regarding building and licencingâ¦), so we started to look at alternatives. Thatâs why we took a look at unicorn and llvm. Unicorn is ultimately based on qemu, which is fairly mature from our point of view. There is not much to say about llvm :). What is nice is that with a single set of bindings we can cover lots of platforms. E.g., no need for new bindings for arm64. Aaand, with some little adjustments here and there, we have ~85% of 114 existing tests passing for arm32, x86 and x86-64. Of course there are not many tests, and they are only testing the basic compiler (just instructions) and not the Jitting of methods. But itâs a good start. Now, also we were a bit picky about licensing: - The llvm disassembler bindings are MIT. - We have licensed the unicorn bindings as LGPL because Unicorn is GPL, and this would allow people to use the bindings without any requirements on licensing. However, any modifications to the bindings or unicorn itself should be further published as LGPL or GPL. Guille > > Norbert > > Am 02.08.2019 um 18:09 schrieb Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>>: > >> Hi everybody, >> >> Iâve been playing around with machine code simulation this last week and Iâve made bindings for the unicorn library and the llvm disassembler: >> >> https://github.com/guillep/pharo-unicorn <https://github.com/guillep/pharo-unicorn> >> https://github.com/guillep/pharo-llvmDisassembler <https://github.com/guillep/pharo-llvmDisassembler> >> >> Funny thing: both support lots of platforms (x86 and arm both 32 and 64 bits and moreâ¦). So out of the box we can simulate and disassemble lots of platforms. >> >> And in one afternoon Iâve played with them to do a native debugger with Spec2 just for fun. >> Hope this evolves a bit more soon, and that it helps somebody. >> >> Guille >> >> <PastedGraphic-5.png> >>

Aug. 5, 2019

Re: [Pharo-dev] Breakpoint restart error

by Thomas Dupriez

Hi ben, If you don't touch the new error and keep stepping over in the original debugger, it does not get confused. It's not really a "solution" though, merely an observation. The issue is not related to the restart. It comes from stepping over a message with a breakpoint. For example, if you also set a breakpoint on the "b := 2" node and step over it, there is the same issue. Example code: Object compile: 'myTest2 Â |a b c| Â a := 1. Â b := 2. Â c := 3'. Breakpoint new node: (Object>>#myTest2) ast; install. Breakpoint new node: (Object>>#myTest2) ast children first statements second; install. "Installing breakpoint on node b := 2" Object new myTest2. "<over>, <over>, <over> -> issue" In your example, here's what happens: - you run the test - the breakpoint triggers, and stops the execution - you step over two times - you restart, which means the next code to be executed is now the breakpoint that was inserted at the start of the test method - you step over a breakpoint, which causes the issue. A very similar issue occurs when stepping over a 'self halt'. Cheers, Thomas On 04/08/2019 17:09, Ben Coman wrote: > I trying to set a breakpoint programatically so that users can be > dropped into the custom script they can add to a system. I try... > > Object compile: 'myTest > Â |a b c| > Â a := 1. > Â b := 2. > Â c := 3'. > Breakpoint new node: (Object>>#myTest) ast; install. > Object new myTest. > "click <over>Â <over>Â <restart> <over>" > > but the following error appears and the debugger gets confused... > image.png > > What am I doing wrong? > > cheers -ben

Aug. 5, 2019

Breakpoint restart error

by Ben Coman

I trying to set a breakpoint programatically so that users can be dropped into the custom script they can add to a system. I try... Object compile: 'myTest |a b c| a := 1. b := 2. c := 3'. Breakpoint new node: (Object>>#myTest) ast; install. Object new myTest. "click <over> <over> <restart> <over>" but the following error appears and the debugger gets confused... [image: image.png] What am I doing wrong? cheers -ben

Aug. 4, 2019

[Pharo 8.0] Build #594: UFFI-test-cases-should-end-with-Test

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

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

Aug. 4, 2019

[Pharo 8.0] Build #593: Test-cases-should-end-with-Test-instead-of-Tests

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

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

Aug. 4, 2019

Re: [Pharo-dev] Some new bindings for native emulation stuff

by Javier PimÃ¡s

Just in time :P This is really cool! On Fri, Aug 2, 2019 at 1:10 PM Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi everybody, > > Iâve been playing around with machine code simulation this last week and > Iâve made bindings for the unicorn library and the llvm disassembler: > > https://github.com/guillep/pharo-unicorn > https://github.com/guillep/pharo-llvmDisassembler > > Funny thing: both support lots of platforms (x86 and arm both 32 and 64 > bits and moreâ¦). So out of the box we can simulate and disassemble lots of > platforms. > > And in one afternoon Iâve played with them to do a native debugger with > Spec2 just for fun. > Hope this evolves a bit more soon, and that it helps somebody. > > Guille > > > -- Javier PimÃ¡s Ciudad de Buenos Aires

Aug. 3, 2019

Re: [Pharo-dev] Some new bindings for native emulation stuff

by ducasse

> That is pretty awesome. Couldnât be an constraint umbrella for VMMaker. Guille is doing that to see if we can reduce the number of plugin and how to build tools to support assembly generation :) And also to be able to write much nicer tests (I mean with real assertions and not transcript show: ;) > This way it would be possible to write tests that check for resulting code. Or writing tests for the JIT (does sista has something like this). Could be one step closer to a deterministic code generation, no? :) Stef > > Norbert > > Am 02.08.2019 um 18:09 schrieb Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>>: > >> Hi everybody, >> >> Iâve been playing around with machine code simulation this last week and Iâve made bindings for the unicorn library and the llvm disassembler: >> >> https://github.com/guillep/pharo-unicorn <https://github.com/guillep/pharo-unicorn> >> https://github.com/guillep/pharo-llvmDisassembler <https://github.com/guillep/pharo-llvmDisassembler> >> >> Funny thing: both support lots of platforms (x86 and arm both 32 and 64 bits and moreâ¦). So out of the box we can simulate and disassemble lots of platforms. >> >> And in one afternoon Iâve played with them to do a native debugger with Spec2 just for fun. >> Hope this evolves a bit more soon, and that it helps somebody. >> >> Guille >> >> <PastedGraphic-5.png> >>

Aug. 3, 2019

[Pharo 8.0] Build #592: Add option to rename parameters when extract a method

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

There is a new Pharo build available! The status of the build #592 was: FAILURE. The Pull Request #4168 was integrated: "Add option to rename parameters when extract a method" Pull request url: https://github.com/pharo-project/pharo/pull/4168 Issue Url: https://github.com/pharo-project/pharo/issues/RenameParametersVersion2 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 3, 2019

Re: [Pharo-dev] Some new bindings for native emulation stuff

by Norbert Hartl

That is pretty awesome. Couldnât be an constraint umbrella for VMMaker. This way it would be possible to write tests that check for resulting code. Or writing tests for the JIT (does sista has something like this). Could be one step closer to a deterministic code generation, no? Norbert > Am 02.08.2019 um 18:09 schrieb Guillermo Polito <guillermopolito(a)gmail.com>: > > Hi everybody, > > Iâve been playing around with machine code simulation this last week and Iâve made bindings for the unicorn library and the llvm disassembler: > > https://github.com/guillep/pharo-unicorn > https://github.com/guillep/pharo-llvmDisassembler > > Funny thing: both support lots of platforms (x86 and arm both 32 and 64 bits and moreâ¦). So out of the box we can simulate and disassemble lots of platforms. > > And in one afternoon Iâve played with them to do a native debugger with Spec2 just for fun. > Hope this evolves a bit more soon, and that it helps somebody. > > Guille > > <PastedGraphic-5.png> >

Aug. 3, 2019

[Pharo 8.0] Build #591: Add submenu, and new shortcuts

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

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

Aug. 3, 2019

Re: [Pharo-dev] [ANN] Pharo Harbour

by Torsten Bergmann

Hi ClÃ©ment, yes - having a better FileBrowser and a FileDialog closer together makes sense. You can freely use the code / project or reuse it for other implementation. Thats why I opened the repo to public. Unfortunately no time to work on it or help the next weeks. Bye Torsten > Gesendet: Donnerstag, 01. August 2019 um 10:17 Uhr > Von: "CafeKrem" <dutriezcle(a)gmail.com> > An: pharo-dev(a)lists.pharo.org > Betreff: Re: [Pharo-dev] [ANN] Pharo Harbour > > Hello Torsten, > > It's ClÃ©ment, actually, I'm working on the FileDialog ( of Peter ) so I will > merge your FileBrowser with my FileDialog. > > Thanks. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >

Aug. 2, 2019

Some new bindings for native emulation stuff

by Guillermo Polito

Hi everybody, Iâve been playing around with machine code simulation this last week and Iâve made bindings for the unicorn library and the llvm disassembler: https://github.com/guillep/pharo-unicorn <https://github.com/guillep/pharo-unicorn> https://github.com/guillep/pharo-llvmDisassembler <https://github.com/guillep/pharo-llvmDisassembler> Funny thing: both support lots of platforms (x86 and arm both 32 and 64 bits and moreâ¦). So out of the box we can simulate and disassemble lots of platforms. And in one afternoon Iâve played with them to do a native debugger with Spec2 just for fun. Hope this evolves a bit more soon, and that it helps somebody. Guille

Aug. 2, 2019

Re: [Pharo-dev] Pharo Launcher 1.9.2 Crash

by Sean P. DeNigris

demarey wrote > Could you test it? Yes, works now! Thanks :) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Aug. 2, 2019