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

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