- Pharo-dev - lists.pharo.org

PharoLauncher create image / default image name
by Nicolai Hess Feb. 3, 2017

Feb. 3, 2017

I started to use a more recent version of pharo launcher, and somehow it changed how it creates the default image name when creating a new image. For example, select an entry from "Pharo 6.0 (beta)" template, the old behavior sets the default name to Pharo 6.0 (beta) - 60353 but now, the template name is omitted, it only sets 60535 was this change on purpose ? I can not find an issue about this on https://github.com/pharo-project/pharo-launcher/issues (I actually don't care much about which format to use, it is just that all my images I used from the prior version, and the new one now appear on different positions in the images list) nicolai

4 5

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

Feb. 3, 2017

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

1 0

[pharo-project/pharo-core] b13be4: 60372
by GitHub Feb. 3, 2017

Feb. 3, 2017

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: b13be4e6152f99bf840d5973b24a2afb231a9b08 https://github.com/pharo-project/pharo-core/commit/b13be4e6152f99bf840d5973… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-02-03 (Fri, 03 Feb 2017) Changed paths: M Morphic-Widgets-FastTable.package/FTRootItem.class/instance/expanding-collapsing/collapseAll.st M Morphic-Widgets-FastTable.package/FTRootItem.class/instance/expanding-collapsing/expandAll.st M Morphic-Widgets-FastTable.package/FTRootItem.class/instance/expanding-collapsing/expandAllTo_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60371.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60372.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60371.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60372.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60372 19651 showing a progress dialog each time I want to make an expandAll is incorrect https://pharo.fogbugz.com/f/cases/19651 http://files.pharo.org/image/60/60372.zip

1 0

Zinc / REST misunderstanding
by Nicolas Anquetil Feb. 3, 2017

Feb. 3, 2017

Hi, I am trying to create a small Redmine wrapper with Zinc, using Redmine REST API And I am having a problem to update issues in redmine from zinc. In curl, I can do: curl -v -H "Content-Type: application/json" -X PUT --data-binary '{ "issue": { "subject": "Subject different changed", "notes": "The subject was changed changed" } }' -u anquetil:<mypasswd> http://<theserver>/redmine/issues/430.json and this updates issue #430 by changing its subject and notes. For information, the trace given by curl (-v) is: * Trying <theserver>... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to <theserver> (<theserver>) port 80 (#0) * Server auth using Basic with user 'anquetil' > PUT /redmine/issues/430.json HTTP/1.1 > Host: <theserver> > Authorization: Basic YW5xdWV0aWw6UjNkTTFuMy1wYXNz > User-Agent: curl/7.47.0 > Accept: */* > Content-Type: application/json > Content-Length: 110 > } [110 bytes data] * upload completely sent off: 110 out of 110 bytes 100 110 0 0 100 110 0 546 --:--:-- --:--:-- --:--:-- 544< HTTP/1.1 200 OK < Date: Thu, 02 Feb 2017 12:18:41 GMT < Server: Apache/2.2.22 (Ubuntu) < X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 3.0.21 < X-Rack-Cache: invalidate, pass < X-Request-Id: 73f75565... < X-UA-Compatible: IE=Edge,chrome=1 < Cache-Control: no-cache < X-Runtime: 0.994081 < Set-Cookie: _redmine_session=BAh7ByIP...; path=/; HttpOnly < Set-Cookie: autologin=; path=/; expires=Thu, 01-Jan-1970 00:00:00 GMT < Status: 200 < Content-Length: 0 < Content-Type: application/json; charset=utf-8 < 100 110 0 0 100 110 0 105 0:00:01 0:00:01 --:--:-- 105 * Connection #0 to host <theserver> left intact The problem is that I cannot replicate that with Zinc: cont := '{ "issue": { "subject": "Subject different changed", "notes": "The subject was changed changed" } }'. ent := ((ZnHeaders requestHeadersFor: 'http://<theserver>/redmine/' asZnUrl ) contentType: (ZnMimeType main: 'application' sub: 'json')) ; contentLength: cont size. ZnClient new beOneShot ; entity: ent ; username: 'anquetil' password: '<mypasswd>' ; put: 'http://<theserver>/redmine/issues/430.json' contents: cont ; response. if I inspect the ZnHeader constructed, it seems to have all headers that curl traces except the Authorization: Basic one: The response of ZnClient is "200 OK", with again the same headers as reported by curl Yet the issue remains unchanged on the redmine server (contrary to curl evidently) Can anyone explain where the error could be ? Any help will be gladly welcome nicolas -- Nicolas Anquetil -- MCF (HDR) Project-Team RMod

2 4

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

Feb. 3, 2017

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

1 0

[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