- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Vm-dev] pb with primitive #primitiveScreenDepth on Linux ?

by Christophe Demarey

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

Feb. 2, 2017

Re: [Pharo-dev] [Ann] Calypso update: method browser and better UI

by Stephan Eggermont

On 31/01/17 21:10, Denis Kudriashov wrote: > I always said that UI needs much more work. But my question was to your > "don't mix styles". > Do you think it looks worse than before? I like the toolbar in the middle, and the separators. > I am not designer and would be very appreciate if somebody paint how it > should be. I'll take a look at it, but am a bit slow at the moment. Attached is current painting state of a morph that might be useful. Stephan

Feb. 2, 2017

Re: [Pharo-dev] PharoLauncher create image / default image name

by Cyril Ferlicot D.

Le 01/02/2017 Ã 20:18, Nicolai Hess a Ã©crit : > 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 Hi, This change was made by Christophe I think and was in purpose. Template name before: Name of the "location" (ex: Common Tools, Pharo Contribution Jenkins, Pharo 6.0â¦) - Name of the build Now: Name of the build -- Cyril Ferlicot http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Feb. 1, 2017

PharoLauncher create image / default image name

by Nicolai Hess

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

Feb. 1, 2017

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

by Norbert Hartl

> Am 01.02.2017 um 11:56 schrieb Denis Kudriashov <dionisiydk(a)gmail.com>: > > > 2017-02-01 9:41 GMT+01:00 Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>>: > I think in the future we need to work out how we can inspect a remote object while using GT features. A lot of stuff in GT inspector is pretty useful. But then I assume it is really chatty at the same time making the remote usage less useful. > > I know what needs to be done from my point of view. But what exactly missing from your perspective? I'm not sure, yet. But what I do is inspecting SeamlessProxy objects which won't enable extra tabs and views for the object. And if it does I don't know if the communication overhead is not too hardcore. In my dreams there is a remote image without GTTools and a GTenabled image on my laptop and still I can use GT features on remote objects. I know but â¦ hey you asked! ;) Norbert

Feb. 1, 2017

Re: [Pharo-dev] Memory leaks

by Pavel Krivanek

The catalog is updated once per day or so... -- Pavel 2017-02-01 16:01 GMT+01:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > I cannot find ReferenceFinder in the catalog. > Any idea? > > Alexandre > > > > On Jan 31, 2017, at 8:17 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > > > > I created a config (in original repo and MetaRepoForPharo60) so it > should be available > > In the morning in catalog already. > > > > Thanks to John for the nice tool and giving me access to the repo on > sthub. > > > > Thx > > T. > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

Feb. 1, 2017

Re: [Pharo-dev] Memory leaks

by Alexandre Bergel

I cannot find ReferenceFinder in the catalog. Any idea? Alexandre > On Jan 31, 2017, at 8:17 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > > I created a config (in original repo and MetaRepoForPharo60) so it should be available > In the morning in catalog already. > > Thanks to John for the nice tool and giving me access to the repo on sthub. > > Thx > T. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 1, 2017

[pharo-project/pharo-core]

by GitHub

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

Feb. 1, 2017

[pharo-project/pharo-core] b5cfdf: 60371

by GitHub

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

Feb. 1, 2017

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

by Norbert Hartl

> Am 01.02.2017 um 13:44 schrieb Torsten Bergmann <astares(a)gmx.de>: > >>> Great job!!! A dream comes true. >>> If there is a working UFFI for ARM then we have a pretty decent stack for IoT times. >> Thank's. UFFI works in my simple tests like "LibC system: 'ls'" > > Did you check out my OSRaspbian project loadable from the catalog? It uses > UFFI and is working on Pi. > Ok, thanks. As the next attempt is using an Raspberry pi it seems to be a perfect fit Norbert

Feb. 1, 2017