February 2017 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] 3e046e: 50768
by GitHub Feb. 3, 2017

Feb. 3, 2017

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 3e046ef0045f650761884511f756c714e65a31a4 https://github.com/pharo-project/pharo-core/commit/3e046ef0045f650761884511… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-02-03 (Fri, 03 Feb 2017) Changed paths: R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50767.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50768.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50767.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50768.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Settings-Polymorph.package/PolymorphSystemSettings.class/class/morphic/morphicMenuSettingsOn_.st Log Message: ----------- 50768 19623 System Settings has "Menues" instead of "Menu" https://pharo.fogbugz.com/f/cases/19623 http://files.pharo.org/image/50/50768.zip

1 0

Re: [Pharo-dev] [Vm-dev] pb with primitive #primitiveScreenDepth on Linux ?
by Christophe Demarey Feb. 3, 2017

Feb. 3, 2017

> Le 2 fÃ©vr. 2017 Ã 21:31, Bert Freudenberg <bert(a)freudenbergs.de> a Ã©crit : > > I was thinking about if it's safe to ignore endianness in this VM primitive. And I think it's safe in 32 bpp, but not in lower bit depths. > > #(1 -1 16 -16 32 -32) collect: [:d | ((Form extent: 1@1 depth: d) colorAt: 0@0 put: Color red; bits) first hex] > > ==> #('16r80000000' '16r1' '16r7C000000' '16r7C00' '16rFFFF0000' '16rFFFF0000â) #('16r80000000' '16r1' '16r7C000000' '16r7C00' '16rFFFF0000' '16rFFFF0000â) same result in Pharo > So from the image's perspective, there is no difference for little endian / big endian forms in the raw bitmap values in 32 bpp. > > And to the VM it looks the same. It just needs to know that on a little endian architecture it's BGRA while on big endian it's ARGB. Neither helps SqueakJS, because Javascript's Canvas.putImageData() uses RGBA. May be I should add a WebGL rendering path ... the swizzling would be easy in a fragment shader. > > - Bert -

1 0

pb with primitive #primitiveScreenDepth on Linux ?
by Christophe Demarey Feb. 2, 2017

Feb. 2, 2017

Hello, With Pavel, we discovered a strange behavior of the primitive #primitiveScreenDepth on Linux. It returns a value of 24 bits per pixel (True colors) that looks valid but not supported (at least by Pharo). DisplayScreen actualScreenDepth "(calling the primitive screenDepth)" => 32 on OS X [OK] => 24 on Linux [KO] Also, it is not consistent with the primitive 91 DisplayScreen new supportsDisplayDepth: DisplayScreen actualScreenDepth => true on OS X => false on Linux There are some safeguard image-side but it would be great if someone could check that vm side. Christophe.

2 1

athens dead code?
by stepharong Feb. 2, 2017

Feb. 2, 2017

accept: aVisitor ^ aVisitor lineSegment: self accept: aVisitor ^ aVisitor closeSegment: self accept: aVisitor ^ aVisitor moveSegment: self seems to invoke methods that do not exit I check AthensLIneSegment is used so I do not understand why the methods are broken. -- Using Opera's mail client: http://www.opera.com/mail/

4 11

Re: [Pharo-dev] [Vm-dev] pb with primitive #primitiveScreenDepth on Linux ?
by Christophe Demarey Feb. 2, 2017

Feb. 2, 2017

Hello Bert, > Le 31 janv. 2017 Ã 18:18, Bert Freudenberg <bert(a)freudenbergs.de> a Ã©crit : > > On Tue, Jan 31, 2017 at 10:44 AM, Christophe Demarey <christophe.demarey(a)inria.fr <mailto:christophe.demarey@inria.fr>> wrote: > > Hello, > > With Pavel, we discovered a strange behavior of the primitive #primitiveScreenDepth on Linux. It returns a value of 24 bits per pixel (True colors) that looks valid but not supported (at least by Pharo). > > DisplayScreen actualScreenDepth "(calling the primitive screenDepth)" > => 32 on OS X [OK] > => 24 on Linux [KO] > > Also, it is not consistent with the primitive 91 > > DisplayScreen new supportsDisplayDepth: DisplayScreen actualScreenDepth > => true on OS X > => false on Linux > > There are some safeguard image-side but it would be great if someone could check that vm side. > > That seems wrong indeed, since BitBlt can only handle power-of-two depths currently. It should answer 32 or -32 in this case. > > Actually ... is there a difference in pixel layout for 32 bit MSB vs LSB forms? A quick test in SqueakJS suggests there isnât. I do not get what you mean by 32 bits MSB vs LSB form. Could you give an example of what to test? If you mean a difference between depth 32 or -32, I do not see any difference. Christophe

1 0

[Ann] Calypso update: method browser and better UI
by Denis Kudriashov Feb. 2, 2017

Feb. 2, 2017

Hi. I glad release new version of Calypso: - white toolbar (according to theme background color) - separators between radio button groups - clickable labels instead of buttons - method browser - view modes - scopes - window tabs for following navigation requests Read details with pictures here http://dionisiydk.blogspot.fr/2017/01/calypso-update-methodbrowser-and-bett… Best regards, Denis

10 25

[Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely
by Denis Kudriashov Feb. 1, 2017

Feb. 1, 2017

Hi. I am glad announce first version of PharmIDE project which is complete toolset for remote development of Pharo images. It includes: - remote debugger - remote inspector - remote playground - remote browser Old project RemoteDebuggingTools is deprecated. But it could be used for Pharo 5 images. PharmIDE targets Pharo 6 or later and provides everything which was done in original project. For details and live demo look at my blog http://dionisiydk.blogspot.fr/2017/01/pharmide-pharo-remote-ide-to-develop.… . Best regards, Denis

13 33

Re: [Pharo-dev] Memory leaks
by Torsten Bergmann Feb. 1, 2017

Feb. 1, 2017

3 2

[pharo-project/pharo-core]
by GitHub Feb. 1, 2017

Feb. 1, 2017

Branch: refs/tags/60371 Home: https://github.com/pharo-project/pharo-core

1 0

[pharo-project/pharo-core] b5cfdf: 60371
by GitHub Feb. 1, 2017

Feb. 1, 2017

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: b5cfdfb1fbc8fb2d0ffa15750f7dc84d1d3c9e24 https://github.com/pharo-project/pharo-core/commit/b5cfdfb1fbc8fb2d0ffa1575… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-02-01 (Wed, 01 Feb 2017) Changed paths: M CodeImportCommandLineHandlers.package/EvaluateCommandLineHandler.class/instance/activation/argumentString.st M GT-Playground.package/GTPlayPage.class/instance/accessing/content_.st A Polymorph-Widgets.package/Pharo3Theme.class/instance/accessing colors/balloonBackgroundColor.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60370.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60371.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60370.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60371.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60371 19631 GTPlayBook is producing memory leaks https://pharo.fogbugz.com/f/cases/19631 19633 EvaluateCommandLineHandler cannot process --evaluate https://pharo.fogbugz.com/f/cases/19633 19627 More contrast for default tooltip https://pharo.fogbugz.com/f/cases/19627 http://files.pharo.org/image/60/60371.zip

1 0