- Pharo-dev - lists.pharo.org

[Pharo 8.0] Build #30: transform_32_into_64.sh: call envvars.sh
by ci-pharo-ci-jenkins2＠inria.fr Jan. 28, 2019

Jan. 28, 2019

There is a new Pharo build available! The status of the build #30 was: SUCCESS. The Pull Request #2368 was integrated: "transform_32_into_64.sh: call envvars.sh" Pull request url: https://github.com/pharo-project/pharo/pull/2368 Issue Url: https://pharo.fogbugz.com/f/cases/transform32into64 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 8.0] Build #29: FAILURE
by ci-pharo-ci-jenkins2＠inria.fr Jan. 28, 2019

Jan. 28, 2019

There is a new Pharo build available! The status of the build #29 was: FAILURE. Could not extract further issue information from commit message: ping ci Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 8.0] Build #28: FAILURE
by ci-pharo-ci-jenkins2＠inria.fr Jan. 28, 2019

Jan. 28, 2019

There is a new Pharo build available! The status of the build #28 was: FAILURE. Could not extract further issue information from commit message: update links to Pharo 8.0 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Esteban's ChangeLog week of 21 January 2019
by estebanlm＠gmail.com Jan. 28, 2019

Jan. 28, 2019

Hello! This is my weekly ChangeLog, from 21 January 2019 to 27 January 2019. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=21/1/2019&to=27/1/2019 ChangeLog ========= 25 January 2019: ---------------- * Sent a [simple PR](https://github.com/pharo-project/pharo/pull/2327) to fix a simple but annoying problem :) It just uses the icons assigned to inspector and playground (calypso needs to be fixed too, and for that there is [also a PR](https://github.com/pharo-ide/Calypso/pull/434)) 23 January 2019: ---------------- * Not much to say. Last two weeks I didn't do anything but releasing Pharo 7.0 :) I hope this stream gets smoother from now on. cheers! Esteban

1 0

[Pharo 8.0] Build #27: Issue 2345 envversion.sh causes out-of-repository bootstrap to fail
by ci-pharo-ci-jenkins2＠inria.fr Jan. 27, 2019

Jan. 27, 2019

There is a new Pharo build available! The status of the build #27 was: FAILURE. The Pull Request #2346 was integrated: "Issue 2345 envversion.sh causes out-of-repository bootstrap to fail" Pull request url: https://github.com/pharo-project/pharo/pull/2346 Issue Url: https://pharo.fogbugz.com/f/cases/Issue2345 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 8.0] Build #26: 2347 BaselineOfIDE references non-existant Iceberg 1.5.5
by ci-pharo-ci-jenkins2＠inria.fr Jan. 27, 2019

Jan. 27, 2019

There is a new Pharo build available! The status of the build #26 was: SUCCESS. The Pull Request #2348 was integrated: "2347 BaselineOfIDE references non-existant Iceberg 1.5.5" Pull request url: https://github.com/pharo-project/pharo/pull/2348 Issue Url: https://pharo.fogbugz.com/f/cases/Issue2347 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Re: [Pharo-dev] Better management of encoding of environment variables
by Sven Van Caekenberghe Jan. 27, 2019

Jan. 27, 2019

Dave, > On 18 Jan 2019, at 01:54, David T. Lewis via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > > From: "David T. Lewis" <lewis(a)mail.msen.com> > Subject: Re: [Pharo-dev] Better management of encoding of environment variables > Date: 18 January 2019 at 01:54:34 GMT+1 > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > > > On Thu, Jan 17, 2019 at 04:57:18PM +0100, Sven Van Caekenberghe wrote: >> >>> On 16 Jan 2019, at 23:23, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>> >>> On Wed, Jan 16, 2019 at 2:37 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> The image side is perfectly capable of dealing with platform differences >>> in a clean/clear way, and at least we can then use the full power of our >>> language and our tools. >>> >> Agreed. At the same time I think it is very important that we don't reply >> on the FFI for environment variable access. This is a basic cross-platform >> facility. So I would like to see the environment accessed through primitives, >> but have the image place interpretation on the result of the primitive(s), >> and have the primitive(s) answer a raw result, just a sequence of uninterpreted >> bytes. >> >> OK, I can understand that ENV VAR access is more fundamental than FFI >> (although FFI is already essential for Pharo, also during startup). >> >>> VisualWorks takes this approach and provides a class UninterpretedBytes >>> that the VM is aware of. That's always seemed like an ugly name and >>> overkill to me. I would just use ByteArray and provide image level >>> conversion from ByteArray to String, which is what I believe we have anyway. >> >> Right, bytes are always uninterpreted, else they would be something else. >> We got ByteArray>>#decodedWith: and ByteArray>>#utf8Decoded and our ByteArray >> inspector decodes automatically if it can. >> > > Hi Sven, > > I am the author of the getenv primitives, and I am also sadly uninformed > about matters of character sets and strings in a multilingual environment. > > The primitives answer environment variable variable values as ByteString > rather than ByteArray. This made sense to me at the time that I wrote it, > because ByteString is easy to display in an inspector, and because it is > easily converted to ByteArray. > > For an American English speaker this seems like a good choice, but I > wonder now if it is a bad decision. After all, it is also trivially easy > to convert a ByteArray to ByteString for display in the image. > > Would it be helpful to have getenv primitives that answer ByteArray > instead, and to let all conversion (including in OSProcess) be done in > the image? > > Thanks, > Dave Normally, the correct way to represent uninterpreted bytes is with a ByteArray. Decoding these bytes as characters is the specific task of a character encoder/decoder, with a deliberate choice as to which to use. Since the getenv() system call uses simple C strings, it is understandable that this was carried over. It is probably not worth or too risky to change that - as long as the receiver understands that it is a raw OS string that needs more work. Like with file path encoding/decoding, environment variable encoding/decoding is plain messy and complex. IMHO it is better to manage that at the image level where we are more agile and can better handle that complexity. Sven BTW: using funny Unicode chars, like ð [https://www.fileformat.info/info/unicode/char/1f388/index.htm] is something even English speakers do.

2 2

[ANN] Pharo 7.0 released!
by Esteban Lorenzano Jan. 26, 2019

Jan. 26, 2019

Pharo 7.0 released! =============== Dear World and dynamic language lovers: The time has come for Pharo 7.0! Pharo is a pure object-oriented programming language and a powerful environment, focused on simplicity and immediate feedback. This is our most significant release yet. Here are the key highlights of this release: â¢ Pharo is now provided in 64-bit version in Linux and OSX and brings even better performance and stability. The 64-bit version is now recommended for Linux and Mac, and is provided as technical preview for Windows. â¢ Pharo comes with a new version of the PharoLauncher (https://pharo.org/download) THE tool to manage your distributions (access to regular versions, jenkins builds, and older versions). â¢ Pharo build has a fully new build process that supports its full bootstrap from sources. This will enable the production to specific (micro) images. â¢ Iceberg, the git client for Pharo has been significantly improved, and is the default CMS. â¢ Calypso, the angular stone of PharoThings, is the new system Pharo browser. It replaces Nautilus and brings better remote working and more advanced browsing capabilities. â¢ IoT is now an important part of Pharo. Installing PharoThings (https://github.com/pharo-iot/PharoThings) provides an impressive amount of tools to develop applications in small devices. â¢ The unified foreign function interface (UnifiedFFI) for interfacing with the outside world is significantly improved to work properly on Windows 64-bit. Pharo 70âs new infrastructure and process set the stage for a new generation of version. The visibility of GitHub combined with the powerful tools that have been validated with more than one year of beta testing is massively pay off. These are just the more prominent highlights, but the details are just as important. We have closed a massive amount of issues: 2142 issues! (A comprehensive changelog can be found at: https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo70Change…) While the technical improvements are significant, still the most impressive fact is that the new code that got in the main Pharo 7.0 image was contributed by more than 75 people. Pharo is more than code. It is an exciting project involving energetic people. We thank all the contributors of this release: Gabriel Omar Cotelli, Gustavo Santos, Marcus Denker, Torsten Bergmann, Esteban Lorenzano, Bernardo Ezequiel Contreras, Guille Polito, Pablo Tesone, Yoan Geran, StÃ©phane Ducasse, Cyril Ferlicot, Vincent Blondeau, Denis Kudriashov, Julien Delplanque, Tim Mackinnon, Max Leske, Andrew P. Black, Tomohiro Oda, ClÃ©ment BÃ©ra, Ben Coman, Eric Gade, Yuriy Tymchuk, Nicolas Cellier, Biyalou-Sama Asbath, Myroslava, Sean DeNigris, Juraj Kubelka, Noury Bouraqadi, Holger Freyther, Geoff Reedy, Norbert Hartl, Paul DeBruicker, Alain Plantec, MartÃn Dias, Peter Uhnak, Tomohiro Oda, BenoÃ®t Verhaeghe, Santiago Bragagnolo, Wouter van Zuilen, Bernhard Pieber, Damien Pollet, Geoff Hill, Hans-Martin Mosner, Ronie Salgado, Philippe Back, Aliaksei Syrel, Dayne Guerra, Rafael Luque, Serge Stinckwich, Vincent Aranega, HernÃ¡n Morales Durand, Petr Fischer, Rajula Vineet Reddy, Alexandre Bergel, Esteban A. Maringolo, Jan BlizniÄenko, Johan Brichau, Luc Fabresse, Quentin Ducasse, SÃ©bastien Roccaserra, Stephan Eggermont, Sven Van Caekenberghe, Takano Mitsuhiro, Pavel Krivanek, Allex Oliveira, Christophe Demarey, Lionel Akue, Nicolai Hess, Martin McClure, Alistair Grant, Pierre Tsapliayev, Milton Mamani, Matteo Marra, Thomas Dupriez, Asbathou Biyalou-Sama. (If you contributed with Pharo 7.0 development in any way and we missed your name, please send us a mail and we will add you). Enjoy! The Pharo Team Try Pharo: http://pharo.org/download Learn Pharo: http://pharo.org/documentation

17 28

[Off Topic] Michel Bauwens on the history and immediate future of work
by Eliot Miranda Jan. 26, 2019

Jan. 26, 2019

Hi All, I find this talk profound and key to making functional open source communities as we try and survive. Iâve skipped an introduction in Portuguese and some slide control issues. https://youtu.be/vDjazcMm-eE?t=4m40s _,,,^..^,,,_ (phone)

2 1

Re: [Pharo-dev] [Pharo-users] macOS VM builds with AddressSanitizer/LeakSanitizer
by Ben Coman Jan. 25, 2019

Jan. 25, 2019

Hi Manuel, This level question would be better handled on pharo-dev and vm-dev mail lists (forwarded a copy). http://lists.pharo.org/mailman/listinfo/pharo-dev_lists.pharo.org http://lists.squeakfoundation.org/mailman/listinfo/vm-dev On Fri, 25 Jan 2019 at 16:09, Manuel Leuenberger <leuenberger(a)inf.unibe.ch> wrote: > Hi, > > Anybody has experience building the VM (pharo.cog.spur) on macOS with > custom compiler and flags? > > I am observing a memory leak on macOS Sierra/Pharo 7/GToolkit. I cannot > precisely locate the issue, e.g. I cannot reliably reproduce the problem. > So I tried to use AddressSanitizer/LeakSanitizer with custom debug builds > of the VM and libMoz2D (used by GToolkit). As building on Linux is easier > than on macOS, I got myself some help from a colleague and we managed to > build those two artifacts on Linux by sprinkling "-g3 -O0 -fsanitize=leak > -fsanitize-memory-track-origins" into the CFLAGS wherever they appear or > are picked up. This works fine on Debian 9 with "CC=clang-6.0 > CXX=clang++-6.0 ./mvm -d" and some on-the-fly patches for other breaking > things. > > Unfortunately, I cannot reproduce the problem on Linux, so it seems to be > platform specific. Even more so, I seem to be the only one observing the > issue. Other GToolkit users do not report this issue. As these kind of > issues are freaking me out, I cannot let go and need to learn what causes > them. So, here I am, trying to build the VM on macOS Sierra and miserably > failing to include the sanitizer tags with Clang and giving me those tasty > leak reports on VM shutdown. > > The leak is not observable in the image memory, i.e. the image size > reported by the VM is not growing, I am suspecting FFI, possibly in Moz2D, > to leak. > The FFI registry in the VM also does not report many or large surviving > objects, so I would assume the problem to be either on the plugin or VM > side. > > My two concrete questions are: > 1. Is it even feasible to detect leaks with this approach? E.g., how does > the VM behave on shutdown? Will the leaks show up in the report or will > they not be covered, as the VM actually frees everything before shutting > down? > 2. How do I swap compiler and inject flags on macOS builds? On Linux it > was fairly easily done by replacing some variables. But on macOS, Xcode > seems to like to mess with me. I got myself Clang-6.0 on macOS from > MacPorts, the same as version as I took on Linux. I can build the VM with > this, but it there is no leak report on VM shutdown. Anybody has an idea > how to debug the build? > > Bonus question: Can the VM provide an inspectable view of all the > allocated memory to the image? That would be perfect. I think Luke Gorrie > does some magic like this in his Studio for core dumps etc. > > Cheers, > Manuel > > >

2 1