September 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] iceberg PrimitiveFailed allocateExecutablePage
by Alistair Grant Sept. 23, 2018

Sept. 23, 2018

Hi Petr, On Sun, 23 Sep 2018 at 19:52, Petr Fischer via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > Hello, I want to propose some small fixes to Pharo, it took me hours just to run Pharo with Iceberg on CentOS 7 (I don't care about Ubuntu)... > > Now I am stuck with this Iceberg error: > https://app.box.com/file/321243070589 I was presented with a login box when I tried to view this. > I am using 64bit Pharo VM + latest Pharo7 image from zeroconf (and latest CentOS7) - is Iceberg OK on 64bits? Yes, I use it all the time (on Ubuntu 16.04 64 bit). Cheers, Alistair

2 1

iceberg PrimitiveFailed allocateExecutablePage
by Petr Fischer Sept. 23, 2018

Sept. 23, 2018

Hello, I want to propose some small fixes to Pharo, it took me hours just to run Pharo with Iceberg on CentOS 7 (I don't care about Ubuntu)... Now I am stuck with this Iceberg error: https://app.box.com/file/321243070589 I am using 64bit Pharo VM + latest Pharo7 image from zeroconf (and latest CentOS7) - is Iceberg OK on 64bits? Thanks! pf

1 0

update linux info page again, please [CentOS/RHEL]
by Petr Fischer Sept. 23, 2018

Sept. 23, 2018

Hello, please, edit CentOS7 installation page: https://pharo.org/gnu-linux-installation-64 and add workaround for CentOS7 section, wihout this symlink, iceberg is broken: (do as root) cd /usr/lib64 ln -s libcurl.so.4 libcurl-gnutls.so.4 Best solution is to put this in the RPM post installation step (I mean RPM from official Pharo CentOS repository) - but we will wait for this fix for months, maybe years, so, workaround info on that page is necessary and easy to manage. More details here: http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2018-July/272624… Thanks! pf

1 0

Float should not implement #to:, #to:by:, etc...
by Julien Sept. 23, 2018

Sept. 23, 2018

Hello, I realised that it is possible to create an interval of floats. I think this is bad because, since intervals are computed by successively adding a number, it might result in precision errors. (0.0 to: 1.0 by: 0.1) asArray >>> #(0.0 0.1 0.2 0.30000000000000004 0.4 0.5 0.6000000000000001 0.7000000000000001 0.8 0.9 1.0) The correct (precise) way to do it would be to use ScaledDecimal: (0.0s1 to: 1.0s1 by: 0.1s1) asArray >>> #(0.0s1 0.1s1 0.2s1 0.3s1 0.4s1 0.5s1 0.6s1 0.7s1 0.8s1 0.9s1 1.0s1) I opened an issue about it: https://pharo.fogbugz.com/f/cases/22467/Float-should-not-implement-to-to-by… <https://pharo.fogbugz.com/f/cases/22467/Float-should-not-implement-to-to-by…> And Iâd like to discuss this with you. What do you think? Cheers, Julien --- Julien Delplanque Doctorant Ã lâUniversitÃ© de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria BÃ¢timent B 40, Avenue Halley 59650 Villeneuve d'Ascq NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40

7 11

[Pharo 7.0-dev] Build #1261: Bug fix for bindings to inherited pool dictionaries (issue 22470)
by ci-pharo-ci-jenkins2＠inria.fr Sept. 22, 2018

Sept. 22, 2018

There is a new Pharo build available! The status of the build #1261 was: FAILURE. The Pull Request #1816 was integrated: "Bug fix for bindings to inherited pool dictionaries (issue 22470)" Pull request url: https://github.com/pharo-project/pharo/pull/1816 Issue Url: https://pharo.fogbugz.com/f/cases/22470 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #1260: 22432 New Release test: NoUnusedTemporaryVariablesLeftTest
by ci-pharo-ci-jenkins2＠inria.fr Sept. 21, 2018

Sept. 21, 2018

There is a new Pharo build available! The status of the build #1260 was: FAILURE. The Pull Request #1782 was integrated: "22432 New Release test: NoUnusedTemporaryVariablesLeftTest" Pull request url: https://github.com/pharo-project/pharo/pull/1782 Issue Url: https://pharo.fogbugz.com/f/cases/22432 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Mailing list Archive - Bandwidth Limit Exceeded
by Torsten Bergmann Sept. 21, 2018

Sept. 21, 2018

Hi Marcus, I receive a "Bandwidth Limit Exceeded - The server is temporarily unable to service your request due to the site owner reaching his/her bandwidth limit. Please try again later." message on http://lists.pharo.org If I remember correctly we already had this one or two years ago. Thanks T.

2 2

Deprecation guide for methods, classes and packages
by Torsten Bergmann Sept. 21, 2018

Sept. 21, 2018

Hi, >From Bug #20900/ PR 1818 it looked like it is not really clear on how to "deprecate" correctly. Therefore I summarized and wrote a short guide following what we contributors used as best practice so far. Also read [1], [2] and [3] and check some of the deprecation settings in the Pharo settings browser. Just open SettingsBrowser and search for "Depre". I write this mail to "pharo-dev" with CC: "pharo-users" list - because of common interest. But comments and replies should please go to "pharo-dev" so we do not disrupt the thread too much. Thanks! Please review what I wrote and ideally we can put the text or a link to it as "Deprecation guide" into the documentation / wiki / ... on GitHub afterwards. Hope this helps a little bit. Thanks T. [1] https://en.wikipedia.org/wiki/Deprecation [2] https://www.peteruhnak.com/blog/2015/08/06/transforming-deprecated-code-wit… [3] https://pharoweekly.wordpress.com/2016/06/17/automatic-deprecation-refactor… ------------------------------------------------------------------------------------------------------------------------------ In any Pharo version we have a special package hosting deprecated methods and classes. This allows smooth migration for Pharo users as code should still load and runs to some extent - but deprecation warnings and possibly a helping hand (in form of automatic code transformations) could be given to support migration. As we currently work on Pharo7 there is a "Deprecated70" package in the image hosting deprecated methods and classes intended to be removed for Pharo 8. When Pharo 7 is released the users can easily spot the deprecations - also because they are striked through (more on this below). When Pharo 8 iteration starts the "Deprecated70" will be replaced with an empty "Deprecated80" package. DEPRECATING METHODS =================== If you deprecate a METHOD use #deprecated: message and switch it to be an extension method in *Deprecated70*. If the method could be replaced by calling another method then dispatch the call to the new method and ideally provide a transformation so next time the old method is called the sender method is automagically rewritten and could be adopted/migrated: oldMethod "An old method we do not use anymore. But luckily there is a replacement." self deprecated: 'Please use #newMethod instead' transformWith: '`@receiver oldMethod' -> '`@receiver newMethod'. ^ self newMethod So if there is a method like foo self oldMethod sending the old deprecated method it will be migrated to foo self newMethod as soon as foo, the oldMethod and the transformation is called. If the automatically migrated method is under version control (Monticello or git) you will easily see that #foo was modified. In case there is no replacement for a method you would like to deprecate then it is best to throw an error when it is used: veryOldMethod "A very old method hopefully nobody uses. So we do no provide a replacement." self deprecated: 'The method #veryOldMethod is deprecated without any replacement'. ^ self error: 'Do not use #veryOldMethod anymore' Note that the method is striked through in the Pharo system browser in both cases to show that it should not be used anymore. In the standard image calling a deprecated method is logged on the Transcript and flagged with a warning dialog. This should help users and maintainers of external packages to easily spot when they still use deprecated code. You can change these settings in Pharo Settings Browser under Tools -> Debugging -> Deprecation Handling. DEPRECATING CLASSES =================== If you deprecate a CLASS implement #isDeprecated on class side to return true and move it to package "Deprecated70" Ideally write in the class comment why it is deprecated and if there is a replacement class what to use instead Object subclass: #OldClass instanceVariableNames: '' classVariableNames: '' package: 'Deprecated70-OldTag' and comment to explain the reasons: OldClass comment: 'Use NewClass instead'. and implement in class side method category 'testing' isDeprecated "We do not need this class anymore" ^true Note that the class is striked through in the system browser. DEPRECATING PACKAGES ==================== If you deprecate a PACKAGE then rename it with "Deprecated" in the name. Let the class side of the package manifest (typically a subclass of PackageManifest within the package) als return #isDeprecated with true. In the class comment of the package manifest (which also serves as package comment) explain why the package is deprecated and if there is a replacement or not. Example: your package name is "OldPackage-Core", so the new name is "OldPackage-Deprecated-Core". Create a manifest or use the existing one. A Manifest should be a subclass of PackageManifest and should be categorized within a 'Manifest' tag. PackageManifest subclass: #ManifestOldPackageCore instanceVariableNames: '' classVariableNames: '' package: 'OldPackage-Deprecated-Core-Manifest' and comment to explain the reasons: ManifestOldPackageCore comment: 'This package is not useful anymore. Check NewPackage for replacement'. and implement in class side method category 'testing' isDeprecated "We do not need this package anymore" ^true Note that the manifest class and the package is striked through in the system browser. Be aware that a deprecated package might be removed completely already in the next Pharo major version iteration.

1 0

Debugger should step silently over #halt
by Ben Coman Sept. 20, 2018

Sept. 20, 2018

I'll often put several breakpoints in code like this... ``` debug := true. "Somewhere else in application code..." debug ifTrue: [ self halt ]. 1 + 1. "Representing some longer bit of application code" debug ifTrue: [ self halt ]. 2 + 2. "Representing some longer bit of application code" debug ifTrue: [ self halt ]. 3 + 3. "Representing some longer bit of application code" ``` While stepping <Over> code after hitting the first halt, I am used to subsequent halts being silently stepped over. I just confirmed this with http://files.pharo.org/platform/Pharo6.0-win.zip and also build 60541 started from PharoLauncher. However build 71231 and build 60542 do not silently step over a #halt. Each produces slightly different results (pics attached). [image: P01-Double-Halt-Pharo7.png] [image: P02-Double-Halt-Pharo60542.png] I've logged an issue... https://pharo.fogbugz.com/f/cases/22474/Debugger-should-step-silently-over-… cheers -ben

2 2

Platform file encoding for FFI
by Alistair Grant Sept. 19, 2018

Sept. 19, 2018

Hi Esteban, Guille and Everyone, I haven't looked at using FFI much, however it is easy to imagine that different file encoding rules on different platforms will make writing FFI calls more difficult, i.e. some of the different formats are: - OSX uses Mac specific decomposed UTF8 encoding - Windows uses Wide Strings (16 bit Unicode characters) - Linux allows pretty much anything, but precomposed UTF8 is common Believe it or not, I'm still working on getting the FileAttributesPlugin working (file name encoding on Windows being the latest issue - the tests in Pharo need to be extended). Would it be useful for future FFI work to have primitives available which convert file names to and from the various platform specific formats? (Linux is basically a no-op, and Windows could be written in-image, but OSX requires the platform routines to be called). Cheers, Alistair

5 10