- Pharo-dev - lists.pharo.org

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