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

[Pharo 7.0-dev] Build #1336: 22583 Tag ManifestCollectionsStreams and related classes in Collections-Streams
by ci-pharo-ci-jenkins2＠inria.fr Oct. 15, 2018

Oct. 15, 2018

There is a new Pharo build available! The status of the build #1336 was: SUCCESS. The Pull Request #1916 was integrated: "22583 Tag ManifestCollectionsStreams and related classes in Collections-Streams" Pull request url: https://github.com/pharo-project/pharo/pull/1916 Issue Url: https://pharo.fogbugz.com/f/cases/22583 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #1335: 22582 Tag ManifestSystemFinalization and classes in System-Finalization
by ci-pharo-ci-jenkins2＠inria.fr Oct. 15, 2018

Oct. 15, 2018

There is a new Pharo build available! The status of the build #1335 was: SUCCESS. The Pull Request #1915 was integrated: "22582 Tag ManifestSystemFinalization and classes in System-Finalization" Pull request url: https://github.com/pharo-project/pharo/pull/1915 Issue Url: https://pharo.fogbugz.com/f/cases/22582 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #1334: 22570-add-method-reification-
by ci-pharo-ci-jenkins2＠inria.fr Oct. 15, 2018

Oct. 15, 2018

There is a new Pharo build available! The status of the build #1334 was: SUCCESS. The Pull Request #1907 was integrated: "22570-add-method-reification-" Pull request url: https://github.com/pharo-project/pharo/pull/1907 Issue Url: https://pharo.fogbugz.com/f/cases/22570 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #1333: Revert "22564-Spec-tests-has-a-class-that-need-to-be-moved-to-deprecated-pacakage"
by ci-pharo-ci-jenkins2＠inria.fr Oct. 15, 2018

Oct. 15, 2018

There is a new Pharo build available! The status of the build #1333 was: SUCCESS. The Pull Request #1914 was integrated: "Revert "22564-Spec-tests-has-a-class-that-need-to-be-moved-to-deprecated-pacakage"" Pull request url: https://github.com/pharo-project/pharo/pull/1914 Issue Url: https://pharo.fogbugz.com/f/cases/revert Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #1332: 22578 Tag ManifestCollectionsTests
by ci-pharo-ci-jenkins2＠inria.fr Oct. 15, 2018

Oct. 15, 2018

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

1 0

[Pharo 7.0-dev] Build #1331: 22579 Tag and comment ManifestSystemHashing
by ci-pharo-ci-jenkins2＠inria.fr Oct. 15, 2018

Oct. 15, 2018

There is a new Pharo build available! The status of the build #1331 was: FAILURE. The Pull Request #1911 was integrated: "22579 Tag and comment ManifestSystemHashing" Pull request url: https://github.com/pharo-project/pharo/pull/1911 Issue Url: https://pharo.fogbugz.com/f/cases/22579 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Esteban's ChangeLog week of 8 October 2018
by estebanlm＠gmail.com Oct. 15, 2018

Oct. 15, 2018

Hello! This is my weekly ChangeLog, from 8 October 2018 to 14 October 2018. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=8/10/2018&to=14/10/2018 ChangeLog ========= 10 October 2018: ---------------- * I finish an [extension to the GitHub plugin](https://github.com/pharo-vcs/iceberg/issues/1008) to allow users to create branchs from a GitHub issue (same as it works now with pharo fogbugz plugin). This will be used for Pharo 8, but it can also be used by other iceberg users in any project :) cheers! Esteban

1 0

GitHub Topics
by Sven Van Caekenberghe Oct. 13, 2018

Oct. 13, 2018

One of the goals of moving to GitHub.com is to gain visibility. There is https://github.com/topics I think we should standardise how we tag our projects. So at least 'Pharo' (capitalised) should be there. Do we also add 'Smalltalk' by default ? Any other suggestions, ideas ? Sven

8 14

[Pharo 7.0-dev] Build #1330: Added getter and setter methods to Reflectivity class for the argsAsAâ¦
by ci-pharo-ci-jenkins2＠inria.fr Oct. 13, 2018

Oct. 13, 2018

There is a new Pharo build available! The status of the build #1330 was: FAILURE. The Pull Request #1906 was integrated: "Added getter and setter methods to Reflectivity class for the argsAsAâ¦" Pull request url: https://github.com/pharo-project/pharo/pull/1906 Issue Url: https://pharo.fogbugz.com/f/cases/Reflectivity Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #1329: 22569-add-two-more-inspector-views-for-MetaLink-nodes-and-methods
by ci-pharo-ci-jenkins2＠inria.fr Oct. 13, 2018

Oct. 13, 2018

There is a new Pharo build available! The status of the build #1329 was: FAILURE. The Pull Request #1905 was integrated: "22569-add-two-more-inspector-views-for-MetaLink-nodes-and-methods" Pull request url: https://github.com/pharo-project/pharo/pull/1905 Issue Url: https://pharo.fogbugz.com/f/cases/22569 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Is ZipArchive broken?
by Stephane Ducasse Oct. 12, 2018

Oct. 12, 2018

Hi When I drop a MCZ on a Pharo 70 image I get an instance of Character does not understand bitOr: and I wonder if there is not a regression in ZipArchive. I can rename the file and dezip with an external tools and load the code. It happened to me with multiple mcz files. Stef

2 1

What you think about visibility of trait method in browser?
by Denis Kudriashov Oct. 12, 2018

Oct. 12, 2018

Hello. In next Calypso version the option to enable or disable trait method visibility will not be available anymore (not my choice). All trait methods installed to the class will be just a class methods like it was in Nautilus. No way to hide them. I want to ask you what you think about it. - do you prefer to see trait methods by default? - do you want feature to hide trait methods? Current Calypso support for traits follows simple principle which I found important for me. But I can be the only guy who think this way. Maybe because I meet traits in Self. So: I simply want to see in the browser what class is actually implements. If class uses TEmpty trait (with ifEmpty, isEmpty methods) I don't want to see its methods by default. When I open such class in the browser I want to see only code which class explicitly implements For me this logic is same as for superclass methods. It was my original intention for trait support in Calypso. And I would like to hear if people share it or not. (there are missing trait feature in the current approach but it is not a subject of my question. Think that everything is supported correctly) Best regards, Denis

5 5

MacOS instructions do not work on Mojave
by Jan BlizniÄenko Oct. 12, 2018

Oct. 12, 2018

Hello Before starting, note that I am not MacOS user. Most of experiments I have done on MacOS Mojave in VirualBox and with friend with mac with MacOS Mojave. On https://pharo.org/download there are instructions how to run Pharo on MacOS. These steps are however not needed for Pharo Launcher which is now default download - it runs out of a box, you just have to confirm you really want to start it. On the other hand, these instructions do not work for "Pharo standalone"/"platform"/"all in one" package at all and just with these instructions such package cannot be started. Possibility to use this package without Launcher is important to me. Error is: "Pharo6.1-64 is damaged and cannot be opened. You should move it to Trash." and not option to start anyway. There are two options on download page, but none of these work: 1) Right clicking and picking Open does not make any difference at all - same error message is the result. 2) Going through settings - Security & Privacy does not work either because option Anywhere does not appear after clicking on the lockpad and filling my password - it is just not there. Only way to overcome this is to run "sudo spctl --master-disable" in terminal, which is command that is supposed to completely turn off Gatekeeper. After this command is executed, Pharo opens just fine and even the Anywhere option appears in security settings. It means that the Pharo package is not damaged at all (as error message indicates), it is just not properly signed. <http://forum.world.st/file/t369698/Pharo-MacOS_Mojave.png> <http://forum.world.st/file/t369698/Pharo-MacOS_Mojave-2.png> Jan -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

1 0

[Call for testers] Pharo Launcher 1.4.5
by Guillermo Polito Oct. 12, 2018

Oct. 12, 2018

Hi all, We have been working these last ~two weeks with Christophe on the stability of the launcher. We have prepared version 1.4.5, and we would like to have some feedback. http://files.pharo.org/pharo-launcher/1.4.5 So, we would really LOVE, if somebody can play with this version and send us feedback. Specially, if your username in your machine has characters that encoded take more than 1 byte, we really would like your feedback. We have tested with japanese characters, and others like Ã®,Ã¼, etc, but the more the better. The main focus was on: - correct management of encodings (in all platforms) - of environment variables - of files and paths - of commands called through OSProcess - better error management in case of edge cases (like when we cannot determine the version of an image) Just FYI: the major limitation of the launcher right now (and it was like that since ever) is that we cannot call external processes with non-ascii characters in windows. This happens because ProcessWrapper uses the ascii version of the windows API to create a process. With what we have learnt this week, we would like to push some of these fixes to Pharo7 too soon: - Correct encoding/decoding of environment variables in linux/osx - Ability to access the encoded version of environment variables in linux/osx to give users control over the encoding they want (or even access binary data) - Correct encoding/decoding of environment variables in windows by using the correct windows API (current primitiveGetenv in windows uses Ascii version too...) In the long term, we also need a solution to enhance or replace ProcessWrapper using the W (wide) version of the windows API. But that is far more work... GC, Guille & Christophe

1 0

Laucher cannot start a fresh 7 image
by phil＠highoctane.be Oct. 12, 2018

Oct. 12, 2018

Used to work. Then does not anymore. Phil

3 3

Byte ordering in Form (urgent)
by Eliot Miranda Oct. 11, 2018

Oct. 11, 2018

Hi All, in trying to fix a bug in BitBLT to do with accessing a word following a bitmap I have had to understand Form and BitBlt's extensions for handling multiple byte order. In particular, if a Form has a negative depth its byte ordering is reversed w.r.t. a Form with positive depth. But in examining this code I think I have found an inconsistency, and I urgently need to check my understanding. In the Form and BitBlt code, a negative depth is stated to mean a Form whose bits are in little-endian byte order: *Form methods for accessing* *depth* ^ depth < 0 ifTrue:[0-depth] ifFalse:[depth] *nativeDepth* "Return the 'native' depth of the receiver, e.g., including the endianess" ^depth *Form methods for testing* *isBigEndian* "Return true if the receiver contains big endian pixels, meaning the left-most pixel is stored in the most significant bits of a word." ^depth > 0 *isLittleEndian* "Return true if the receiver contains little endian pixels, meaning the left-most pixel is stored in the least significant bits of a word." ^depth < 0 and BitBltSimulation (the Smalltalk code for the plugin that implements BitBlt) has two instance variables destMSW and sourceMSW that are true if the destination form or source form has a positive depth: *BitBltSimulation methods for interpreter interface* *loadBitBltDestForm* "Load the dest form for BitBlt. Answer false if anything is wrong, true otherwise." ... destDepth := interpreterProxy fetchInteger: FormDepthIndex ofObject: destForm. destMSB := destDepth > 0. destDepth < 0 ifTrue: [destDepth := 0 - destDepth]. ... *loadBitBltSourceForm* "Load the source form for BitBlt. Return false if anything is wrong, true otherwise." ... sourceDepth := interpreterProxy fetchInteger: FormDepthIndex ofObject: sourceForm. sourceMSB := sourceDepth > 0. sourceDepth < 0 ifTrue: [sourceDepth := 0 - sourceDepth]. ... But if I have a look at the actual layout of bytes in a Form I see that the meaning of depth is that if it is positive it is the *native* byte order (little endian on x86, x86-64, ARM, big end on SPARC, PowerPC): Display fill: (0@0 extent: 1@100) rule: Form over fillColor: Color black. (Display bits at: 1) hex '16rFF000001' | bytes | bytes := Display bits copy. ByteArray adoptInstance: bytes. bytes copyFrom: 1 to: 4 #[1 0 0 255] i.e. the first word of the Display after writing the color black into the first 32-bit pixel is 16rFF000001 on Mac OS x86-64, or #[1 0 0 255] , which is little endian. When the Squeak BttF VM was first written it was written on Motorola 68k Macs and PowerPC Macs, which are big-endian. So it is natural that at the time the terms isBigEndian and isLittleEndian and destMSB sourceMSB were as they are now, because the platform was big endian. But subsequently when the code was ported to Windows x86 by Andreas Raab, the meaning seems to me to have changed. Now depth > 0 implies *native* byte order, not big endian byte order, and depth < 0 implies the *opposite of native* byte order, not little endian order. Does anyone disagree? Does anyone have corroborating or contradicting evidence? I ask because to make sense of the code I would at least like to change the variables in BitBltSimulation to be destNativeByteOrder and sourceNativeByteOrder, and I want to either delete Form>>isBigEndian and Form>>isLittleEndian and replace it with Form>>isNativeByteOrder, or redefine isBigEndian and isLittleEndian, eg as *isBigEndian* "Return true if the receiver contains big endian pixels, meaning the left-most pixel is stored in the most significant bits of a word." ^depth > 0 == Smalltalk isBigEndian _,,,^..^,,,_ best, Eliot

1 0

[Pharo 7.0-dev] Build #1328: Revert "22553-Instances-are-not-indexable-after-double-clicking-item-in-Collection-Inspector"
by ci-pharo-ci-jenkins2＠inria.fr Oct. 11, 2018

Oct. 11, 2018

There is a new Pharo build available! The status of the build #1328 was: FAILURE. The Pull Request #1902 was integrated: "Revert "22553-Instances-are-not-indexable-after-double-clicking-item-in-Collection-Inspector"" Pull request url: https://github.com/pharo-project/pharo/pull/1902 Issue Url: https://pharo.fogbugz.com/f/cases/revert Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #1327: 22566-Add-a-Details-pane-to-Colors-GT-Inspector
by ci-pharo-ci-jenkins2＠inria.fr Oct. 11, 2018

Oct. 11, 2018

There is a new Pharo build available! The status of the build #1327 was: FAILURE. The Pull Request #1901 was integrated: "22566-Add-a-Details-pane-to-Colors-GT-Inspector" Pull request url: https://github.com/pharo-project/pharo/pull/1901 Issue Url: https://pharo.fogbugz.com/f/cases/22566 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #1326: 22564-Spec-tests-has-a-class-that-need-to-be-moved-to-deprecated-pacakage
by ci-pharo-ci-jenkins2＠inria.fr Oct. 11, 2018

Oct. 11, 2018

There is a new Pharo build available! The status of the build #1326 was: FAILURE. The Pull Request #1900 was integrated: "22564-Spec-tests-has-a-class-that-need-to-be-moved-to-deprecated-pacakage" Pull request url: https://github.com/pharo-project/pharo/pull/1900 Issue Url: https://pharo.fogbugz.com/f/cases/22564 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Array inspector Items view Selection broken
by Sven Van Caekenberghe Oct. 11, 2018

Oct. 11, 2018

When you inspect an array, like #(1 2 3), using the Items view in the GT Inspector, a selection of an item/element results in a sub GT tab with another array containing that item/element, not the item/element itself as it should be. Anyone else seeing this ? Sven

4 3

Conversion of my Libraries/Frameworks to GitHub/Tonel/TravisCI, Part 1
by Sven Van Caekenberghe Oct. 10, 2018

Oct. 10, 2018

Hi, I started converting my Libraries/Frameworks to GitHub/Tonel/TravisCI. So far I did the following: https://github.com/svenvc/NeoJSON https://github.com/svenvc/NeoCSV https://github.com/svenvc/ztimestamp https://github.com/svenvc/P3 https://github.com/svenvc/stamp https://github.com/svenvc/SimpleRedisClient https://github.com/svenvc/NeoConsole More will follow, in particular Zinc/Zodiac and STON, both of which are more complex. The TravisCI builds now run for Pharo 7 (32 & 64 bits) and Pharo 6.1. By loading the latest Metacello and Tonel, the code is also loadable in Pharo 6 or 5. After a while I will switch the Catalog entries and declare these repo the main ones. Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

5 7

[Pharo 7.0-dev] Build #1325: 16196-Move-Zinc-Examples-to-a-different-package
by ci-pharo-ci-jenkins2＠inria.fr Oct. 10, 2018

Oct. 10, 2018

There is a new Pharo build available! The status of the build #1325 was: SUCCESS. The Pull Request #1841 was integrated: "16196-Move-Zinc-Examples-to-a-different-package" Pull request url: https://github.com/pharo-project/pharo/pull/1841 Issue Url: https://pharo.fogbugz.com/f/cases/16196 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Fraction and ScaledDecimal should be not be serialized as Float in STON format
by Julien Oct. 10, 2018

Oct. 10, 2018

Hello, I realised that in the current implementation, when a number is serialised by STON it is either as an integer literal or as a float literal. There is a risk to loose precision, especially if what you serialise is a ScaledDecimal or a fraction. I propose a simple change to fix this: 1. Add STONWriter>>#isInJsonMode method which returns true if the STONWriter wants to write JSON 2. Add: Fraction>>#stonOn: stonWriter stonWriter isInJsonMode ifTrue: [ ^ super stonOn: stonWriter ]. stonWriter writeObject: self streamMap: [ :dictionary | dictionary at: #numerator put: numerator. dictionary at: #denominator put: denominator ] 3. Add: ScaledDecimal>>#stonOn: stonWriter stonWriter isInJsonMode ifTrue: [ ^ super stonOn: stonWriter ]. stonWriter writeObject: self streamMap: [ :dictionary | dictionary at: #numerator put: numerator. dictionary at: #denominator put: denominator. dictionary at: #scale put: scale ] This change has a main drawback, storing fractions and scaled decimal will result in a huge overhead. Maybe for ScaledDecimal we can use Pharoâs literal (e.g. 1.12s2). For fractions I donât know what literal could be used? Or maybe the overhead is fine? 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

3 6

[Pharo 7.0-dev] Build #1324: 22563-GTInspector-can-loop-on-WindowPresenter
by ci-pharo-ci-jenkins2＠inria.fr Oct. 9, 2018

Oct. 9, 2018

There is a new Pharo build available! The status of the build #1324 was: SUCCESS. The Pull Request #1898 was integrated: "22563-GTInspector-can-loop-on-WindowPresenter" Pull request url: https://github.com/pharo-project/pharo/pull/1898 Issue Url: https://pharo.fogbugz.com/f/cases/22563 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #1323: 22534-split-Refactoring2-package-to-extract-Tests
by ci-pharo-ci-jenkins2＠inria.fr Oct. 9, 2018

Oct. 9, 2018

There is a new Pharo build available! The status of the build #1323 was: SUCCESS. The Pull Request #1871 was integrated: "22534-split-Refactoring2-package-to-extract-Tests" Pull request url: https://github.com/pharo-project/pharo/pull/1871 Issue Url: https://pharo.fogbugz.com/f/cases/22534 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #1322: 22548-Typo-in-FractionTestclassst
by ci-pharo-ci-jenkins2＠inria.fr Oct. 9, 2018

Oct. 9, 2018

There is a new Pharo build available! The status of the build #1322 was: SUCCESS. The Pull Request #1895 was integrated: "22548-Typo-in-FractionTestclassst" Pull request url: https://github.com/pharo-project/pharo/pull/1895 Issue Url: https://pharo.fogbugz.com/f/cases/22548 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #1321: 22554-GlamourPresentationModel-has-a-name-out-of-synch-with-the-current-spec
by ci-pharo-ci-jenkins2＠inria.fr Oct. 9, 2018

Oct. 9, 2018

There is a new Pharo build available! The status of the build #1321 was: SUCCESS. The Pull Request #1891 was integrated: "22554-GlamourPresentationModel-has-a-name-out-of-synch-with-the-current-spec" Pull request url: https://github.com/pharo-project/pharo/pull/1891 Issue Url: https://pharo.fogbugz.com/f/cases/22554 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #1320: 22553-Instances-are-not-indexable-after-double-clicking-item-in-Collection-Inspector
by ci-pharo-ci-jenkins2＠inria.fr Oct. 9, 2018

Oct. 9, 2018

There is a new Pharo build available! The status of the build #1320 was: FAILURE. The Pull Request #1889 was integrated: "22553-Instances-are-not-indexable-after-double-clicking-item-in-Collection-Inspector" Pull request url: https://github.com/pharo-project/pharo/pull/1889 Issue Url: https://pharo.fogbugz.com/f/cases/22553 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #1319: 22556-Reverting-slots-to-return-the-set-of-installed-slots-in-the-class-
by ci-pharo-ci-jenkins2＠inria.fr Oct. 9, 2018

Oct. 9, 2018

There is a new Pharo build available! The status of the build #1319 was: FAILURE. The Pull Request #1892 was integrated: "22556-Reverting-slots-to-return-the-set-of-installed-slots-in-the-class-" Pull request url: https://github.com/pharo-project/pharo/pull/1892 Issue Url: https://pharo.fogbugz.com/f/cases/22556 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #1318: 22492-Self-Hosted Gitlab support
by ci-pharo-ci-jenkins2＠inria.fr Oct. 8, 2018

Oct. 8, 2018

There is a new Pharo build available! The status of the build #1318 was: SUCCESS. The Pull Request #1828 was integrated: "22492-Self-Hosted Gitlab support" Pull request url: https://github.com/pharo-project/pharo/pull/1828 Issue Url: https://pharo.fogbugz.com/f/cases/self_hosted_gitlab Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #1317: 22545-The-64-bit-image-does-not-have-the-correct-display-size-again
by ci-pharo-ci-jenkins2＠inria.fr Oct. 8, 2018

Oct. 8, 2018

There is a new Pharo build available! The status of the build #1317 was: SUCCESS. The Pull Request #1884 was integrated: "22545-The-64-bit-image-does-not-have-the-correct-display-size-again" Pull request url: https://github.com/pharo-project/pharo/pull/1884 Issue Url: https://pharo.fogbugz.com/f/cases/22545 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #1316: 22541 Tag and comment ManifestGTSpotter
by ci-pharo-ci-jenkins2＠inria.fr Oct. 8, 2018

Oct. 8, 2018

There is a new Pharo build available! The status of the build #1316 was: SUCCESS. The Pull Request #1879 was integrated: "22541 Tag and comment ManifestGTSpotter" Pull request url: https://github.com/pharo-project/pharo/pull/1879 Issue Url: https://pharo.fogbugz.com/f/cases/22541 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Esteban's ChangeLog week of 1 October 2018
by estebanlm＠gmail.com Oct. 8, 2018

Oct. 8, 2018

Hello! This is my weekly ChangeLog, from 1 October 2018 to 7 October 2018. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=1/10/2018&to=7/10/2018 ChangeLog ========= 5 October 2018: --------------- * I made a couple of backports to Pharo 6.1 * [case: 22517](https://pharo.fogbugz.com/f/cases/22517) : Update ProfStef and fix spelling mistakes * [case: 22535](https://pharo.fogbugz.com/f/cases/22535) : Backport Tonel v1.0.9 to Pharo 6.1 * I finished a "simple" [PR for Calypso](https://github.com/pharo-ide/Calypso/pull/330): It was about better exposing the usage of certain command when using the +cmd+/+ Calypso-Spotter help. Now, this was not obvious because this correspons to a command nobody is using it yet, but it will become important as we enhance discoverability of it :) 2 October 2018: --------------- * Well... I spent the full day debugging on smalltalkCI to send a [new fix](https://github.com/hpi-swa/smalltalkCI/pull/399) to allow the load of projects with packages already installed in the image. This is very useful for us, developing Pharo and their components. * Spec * Calypso * Iceberg * Zinc * etc. And maybe it will be useful for others in the future. cheers! Esteban

1 0

Re: [Pharo-dev] [squeak-dev] DelayIdleScheduler experiment
by Ben Coman Oct. 7, 2018

Oct. 7, 2018

Hi Tim, Thanks for your feedback On Mon, 8 Oct 2018 at 01:27, tim Rowledge <tim(a)rowledge.org> wrote: > I may be out of date on this but I think that the Cog setup makes it > possible to have a timer check every 2mS by default. The > relinquishProcessor stuff was a definite hack to try to reduce cpu usage on > laptoppy things and I don't think anyone ever expected it to be used for > more than 1mS sleeps. It was one of those "I wonder if this will improve > anything?" ideas that got left in place. > > Surely the ideal would be to > a) as you point out, add this delay to the main delay list > Its not a separate delay. The "activeDelay" is split into separate pieces relinquished around asynchronous I/O like mouse, etc. b) find a way to provide an outside timer to trigger the delay at the top > of the list rather than relying on the vm eventually checking the tick etc. > The key thing is to inform the VM that there are no runnable processes and pause the main-native-thread and heartbeat-thread until the next image-scheduled wakeup time. One alternative may be to adapt #primSignal:atUTCMicroseconds: to be #primSignal:atUTCMicroseconds:idle: > > Interestingly, we have the threaded ticker for many systems as part of the > Cog vm. I don't know if it works on all systems; I do know it would be > 'interesting' to implement on RISC OS, but that's life. A quick look at > unix/sqUnixHeartbeat.c suggests to me that it might be plausible to use > variable length beats Q: does the main-native-thread stop running if the heatbeat stops? > and tie the time to any sooner-than-2mS event wanted. We'd (probably) change Delay handling to behave as if there were always a 1 > or 2mS (fake)delay even if the nearest actual Delay were far beyond that. > I can't follow where you are going with that. If your on a cloud server, you may want to idle for minutes or hours without processing delays, and restarting delays when I/O comes in. cheers -ben > > > On 2018-10-07, at 1:11 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > > Cross posting since at this level systems are still very similar. > > > > I've sometimes wondered about how the idle process > > relinquishing the CPU interacted with delay scheduling, > > since they operate at the extreme opposite ends of process priorities. > > > > Historically there was... > > ProcessorScheduler class >> idleProcess > > [ "A default background process which is invisible." > > [true] whileTrue: > > [self relinquishProcessorForMicroseconds: 1000] > > > > which had the following performance this for later comparison... > > (1 to: 10) collect: [:i | [ (Delay forMilliseconds: 1) wait ] > timeToRun asMilliSeconds]. > > ==> "#(2 5 4 2 4 4 2 4 4 3)" > > > > To improve battery life yield time Pharo changed this to 50000 in... > > * > https://pharo.fogbugz.com/f/cases/20425/Yield-longer-in-ProcessorScheduler-… > > * https://github.com/pharo-project/pharo/commit/0b0d12dc > > but had a negative impact on delays... > > (1 to: 10) collect: [:i | [ (Delay forMilliseconds: 1) wait ] > timeToRun asMilliSeconds]. > > ==> "#(36 51 50 51 50 51 51 30 50 50)" > > as reported... > https://pharo.fogbugz.com/f/cases/22400/Delays-are-not-working-properly > > > > The problem seems to be that #relinquishProcessorForMicroseconds: > suspends the main VM thread for a fixed amount during which expired delays > cannot be dealt with. I'm not sure of the exact mechanism in the VM but > this looks related... > > Win: > https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/e2fa2d1/platforms/wi… > > Mac: > https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/a8a1dc1/platforms/un… > > I'm not sure about Linux > > > > One idea was to have a setting, but another path is to mix the > idle-relinquish > > into the delay-scheduling to dynamically relinquish up to exactly when > the activeDelay expires. > > > > After loading... > > https://github.com/pharo-project/pharo/pull/1887 > > you can do... > > DelayIdleTicker installExperiment. > > (1 to: 10) collect: [:i | [ (Delay forMilliseconds: 1) wait ] > timeToRun asMilliSeconds]. > > ==>"#(1 1 2 2 2 2 2 2 2 2)" which btw is half the latency of the original > > DelayIdleTicker debug: true. "CPU usage goes way up" > > DelayIdleTicker uninstall. > > > > I'm now seeking: > > * comment on how this might interact with parts of the VM I'm not > familiar with. > > * help to discover and stress test corner cases. > > * help to determine if there actually is a benefit and characterize what > that is, > > especially anyone familiar with headless images with reduced UI and I/O > events. > > I was surprised to see the existing system already often showed 0% CPU > usage (in Windows). > > > > cheers -ben > > > > > tim > -- > tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim > Bayard(n): a person armed with the self-confidence of ignorance > > >

1 0

[Pharo 7.0-dev] Build #1315: 22539 Tag ManifestRPackageCore and related classes in RPackage-Core
by ci-pharo-ci-jenkins2＠inria.fr Oct. 7, 2018

Oct. 7, 2018

There is a new Pharo build available! The status of the build #1315 was: SUCCESS. The Pull Request #1877 was integrated: "22539 Tag ManifestRPackageCore and related classes in RPackage-Core" Pull request url: https://github.com/pharo-project/pharo/pull/1877 Issue Url: https://pharo.fogbugz.com/f/cases/22539 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #1314: 20344-DualChangeSorter-shows-debug-context-menu
by ci-pharo-ci-jenkins2＠inria.fr Oct. 7, 2018

Oct. 7, 2018

There is a new Pharo build available! The status of the build #1314 was: SUCCESS. The Pull Request #1881 was integrated: "20344-DualChangeSorter-shows-debug-context-menu" Pull request url: https://github.com/pharo-project/pharo/pull/1881 Issue Url: https://pharo.fogbugz.com/f/cases/20344 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #1313: 22546 Tag classes in FuzzyMatcher-Tests
by ci-pharo-ci-jenkins2＠inria.fr Oct. 7, 2018

Oct. 7, 2018

There is a new Pharo build available! The status of the build #1313 was: SUCCESS. The Pull Request #1885 was integrated: "22546 Tag classes in FuzzyMatcher-Tests" Pull request url: https://github.com/pharo-project/pharo/pull/1885 Issue Url: https://pharo.fogbugz.com/f/cases/22546 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #1312: 22544 Comment File package
by ci-pharo-ci-jenkins2＠inria.fr Oct. 7, 2018

Oct. 7, 2018

There is a new Pharo build available! The status of the build #1312 was: FAILURE. The Pull Request #1883 was integrated: "22544 Comment File package" Pull request url: https://github.com/pharo-project/pharo/pull/1883 Issue Url: https://pharo.fogbugz.com/f/cases/22544 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Migrating XML support to github/PharoContributions/
by Stephane Ducasse Oct. 7, 2018

Oct. 7, 2018

Hi I contacted the maintainer (but I'm not sure in fact who it is :) ) about the XML related packages in Pharo extras. XMLParser XMLParserHTML XMLParserStAX XMLSupport XMLWriter XPath I did not get any answer so may be I sent a mail to the wrong email address. Probably. Now the question still remains: who is planning to migrate the XML packages. I was planning to do it but I will not consider history because I do not know how to do it and I do not have the time to do it (sorry). And yes I work the weekends and this is bad and this is not even on Pharo. I was planning to spend some time on the baseline and making sure that we can load everything and run the tests. So let me know. Stef

5 7

DelayIdleScheduler experiment
by Ben Coman Oct. 7, 2018

Oct. 7, 2018

Cross posting since at this level systems are still very similar. I've sometimes wondered about how the idle process relinquishing the CPU interacted with delay scheduling, since they operate at the extreme opposite ends of process priorities. Historically there was... ProcessorScheduler class >> idleProcess [ "A default background process which is invisible." [true] whileTrue: [self relinquishProcessorForMicroseconds: 1000] which had the following performance this for later comparison... (1 to: 10) collect: [:i | [ (Delay forMilliseconds: 1) wait ] timeToRun asMilliSeconds]. ==> "#(2 5 4 2 4 4 2 4 4 3)" To improve battery life yield time Pharo changed this to 50000 in... * https://pharo.fogbugz.com/f/cases/20425/Yield-longer-in-ProcessorScheduler-… * https://github.com/pharo-project/pharo/commit/0b0d12dc but had a negative impact on delays... (1 to: 10) collect: [:i | [ (Delay forMilliseconds: 1) wait ] timeToRun asMilliSeconds]. ==> "#(36 51 50 51 50 51 51 30 50 50)" as reported... https://pharo.fogbugz.com/f/cases/22400/Delays-are-not-working-properly The problem seems to be that #relinquishProcessorForMicroseconds: suspends the main VM thread for a fixed amount during which expired delays cannot be dealt with. I'm not sure of the exact mechanism in the VM but this looks related... Win: https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/e2fa2d1/platforms/wi… Mac: https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/a8a1dc1/platforms/un… I'm not sure about Linux One idea was to have a setting, but another path is to mix the idle-relinquish into the delay-scheduling to dynamically relinquish up to exactly when the activeDelay expires. After loading... https://github.com/pharo-project/pharo/pull/1887 you can do... DelayIdleTicker installExperiment. (1 to: 10) collect: [:i | [ (Delay forMilliseconds: 1) wait ] timeToRun asMilliSeconds]. ==>"#(1 1 2 2 2 2 2 2 2 2)" which btw is half the latency of the original DelayIdleTicker debug: true. "CPU usage goes way up" DelayIdleTicker uninstall. I'm now seeking: * comment on how this might interact with parts of the VM I'm not familiar with. * help to discover and stress test corner cases. * help to determine if there actually is a benefit and characterize what that is, especially anyone familiar with headless images with reduced UI and I/O events. I was surprised to see the existing system already often showed 0% CPU usage (in Windows). cheers -ben

1 0

[Pharo 7.0-dev] Build #1311: 22542 Tag and comment ManifestGTDebugger
by ci-pharo-ci-jenkins2＠inria.fr Oct. 6, 2018

Oct. 6, 2018

There is a new Pharo build available! The status of the build #1311 was: SUCCESS. The Pull Request #1880 was integrated: "22542 Tag and comment ManifestGTDebugger" Pull request url: https://github.com/pharo-project/pharo/pull/1880 Issue Url: https://pharo.fogbugz.com/f/cases/22542 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Re: [Pharo-dev] Slowness when loading code in Pharo 7?
by Alexandre Bergel Oct. 5, 2018

Oct. 5, 2018

Shouldnât the Metacello>>load be updated to disable EpMonitor? It seems to be an easy fix no? Alexandre > On Oct 2, 2018, at 11:31 PM, Juraj Kubelka via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > > From: Juraj Kubelka <juraj.kubelka(a)icloud.com> > Subject: Re: [Pharo-dev] Slowness when loading code in Pharo 7? > Date: October 2, 2018 at 11:31:59 PM GMT-3 > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > > > Hi Martin, > > By disabling EpMonitor, the slowdown disappears. > > EpMonitor current disable. > [ Metacello new > baseline: 'GToolkit'; > repository: 'github://feenkcom/gtoolkit/src'; > load. > ] timeToRun "0:00:08:03.504â > > > Cheers, > Juraj > >> On Oct 2, 2018, at 18:14, Martin Dias <tinchodias(a)gmail.com> wrote: >> >> Hi Andrei. You can evaluate "EpMonitor current disable" before loading >> to compare times. >> El mar., 2 de oct. de 2018 a la(s) 11:18, Andrei Chis >> (chisvasileandrei(a)gmail.com) escribiÃ³: >>> >>> Hi, >>> >>> Are there any know slowdowns when loading code in Pharo 7? Usually on my machine (Mac - HighSierra) loading GToolkit in a Pharo 6.1 images takes around 9 minutes. In the latest Pharo 7 it takes 20 minutes. On two other newer laptops running Mac results are similar (15 minutes on Pharo 7 64it, and 7 minutes on Pharo 6.1 64bit). >>> >>> We have the impression that most of the times, the regression happens because of reading sources file. And the sources files are read because of checking Epicea method changes. We have not done a deep research on it, just whenever we do CMD+. it stops in that stage. >>> >>> Cheers, >>> Andrei >> > > > >

1 0

Re: [Pharo-dev] Slowness when loading code in Pharo 7?
by Peter Uhnak Oct. 5, 2018

Oct. 5, 2018

On Wed, Oct 3, 2018 at 7:31 PM Juraj Kubelka via Pharo-dev < pharo-dev(a)lists.pharo.org> wrote: > Hi! > > I did the same measurement for Pharo 6.1. To summarize it I have those > results: > > By executing: > > -=-=-=- > EpMonitor current disable. > [ Metacello new > baseline: 'GToolkit'; > repository: 'github://feenkcom/gtoolkit/src'; > load. > ] timeToRun > -=-=-=- > > Pharo 6.1 64bit macOS: 6 minutes > Pharo 7.0 64bit macOS: 8 minutes > > With EpMonitor current enabled it is: > > Pharo 6.1 64bit macOS: 7 minutes > Pharo 7.0 64bit macOS: 15 minutes > So nice... I was just trying to install GToolkit in P6.1 on Windows (but with updated Iceberg)... it took over 1.5 hours (SmaCC was probably 30 minutes by itself), and then the image crashed... really looking forward to pre-made images :) Peter

3 2

Creating a new class using `Class new superclass:` blocks the image in Pharo 7
by Andrei Chis Oct. 5, 2018

Oct. 5, 2018

Hi, Executed in the latest Pharo 7 image (Pharo-7.0.0+alpha.build.1310.sha.a454977bb3d55bc4fcca3a57ac2fafcf137c0f30 (64 Bit)) the code below blocks the image (both with latest and stable vm on MacOs HighSierra). The vm does not crash but gets into a "Not Responding" state and does not get out: Class new superclass: GLMTransmission; setFormat: GLMTransmission format; classLayout: GLMTransmission classLayout copy; yourself Code like this is used in Moose in some tests and in SmaCC in the rewrite engine: Class new superclass: SmaCCRewriteMatchContext; setFormat: SmaCCRewriteMatchContext format; classLayout: SmaCCRewriteMatchContext classLayout copy; yourself. This worked in Pharo 6. Bug or here should be a different way to do this? Cheers, Andrei

2 4

[Pharo 7.0-dev] Build #1310: 22537 Tag ManifestMultilingualEncodings and related classes in Multilingual-Encodings-Manifest
by ci-pharo-ci-jenkins2＠inria.fr Oct. 5, 2018

Oct. 5, 2018

There is a new Pharo build available! The status of the build #1310 was: SUCCESS. The Pull Request #1875 was integrated: "22537 Tag ManifestMultilingualEncodings and related classes in Multilingual-Encodings-Manifest" Pull request url: https://github.com/pharo-project/pharo/pull/1875 Issue Url: https://pharo.fogbugz.com/f/cases/22537 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Re: [Pharo-dev] Migrating XML support to github/PharoContributions/
by monty Oct. 5, 2018

Oct. 5, 2018

2 1

[Pharo 7.0-dev] Build #1309: 22538 Tag ManifestFileSystemZip and related classes in FileSystem-Zip package
by ci-pharo-ci-jenkins2＠inria.fr Oct. 5, 2018

Oct. 5, 2018

There is a new Pharo build available! The status of the build #1309 was: FAILURE. The Pull Request #1876 was integrated: "22538 Tag ManifestFileSystemZip and related classes in FileSystem-Zip package" Pull request url: https://github.com/pharo-project/pharo/pull/1876 Issue Url: https://pharo.fogbugz.com/f/cases/22538 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #1308: 22532-Adding-repository-to-package-via-MonticelloBrowser-is-broken
by ci-pharo-ci-jenkins2＠inria.fr Oct. 5, 2018

Oct. 5, 2018

There is a new Pharo build available! The status of the build #1308 was: FAILURE. The Pull Request #1870 was integrated: "22532-Adding-repository-to-package-via-MonticelloBrowser-is-broken" Pull request url: https://github.com/pharo-project/pharo/pull/1870 Issue Url: https://pharo.fogbugz.com/f/cases/22532 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #1307: 22520-Deprecate-HistoryCollection
by ci-pharo-ci-jenkins2＠inria.fr Oct. 5, 2018

Oct. 5, 2018

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

1 0

[Pharo 7.0-dev] Build #1306: 22533-WelcomeHelp-should-not-have-hardcoded-version
by ci-pharo-ci-jenkins2＠inria.fr Oct. 5, 2018

Oct. 5, 2018

There is a new Pharo build available! The status of the build #1306 was: SUCCESS. The Pull Request #1868 was integrated: "22533-WelcomeHelp-should-not-have-hardcoded-version" Pull request url: https://github.com/pharo-project/pharo/pull/1868 Issue Url: https://pharo.fogbugz.com/f/cases/22533 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0