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

Re: [Pharo-dev] GTDebugger variables table

by Nicolas Anquetil

for what it is worth, Eclipse behaves more or less as described by Denis: you see only local variables (self being one) and if a variable contains an object (such as self), it expands in a three to show the attributes of this object. I sometimes find it a pain to have to expand "self" to see the attributes, but it is true that when there are many attributes/local variables, one gets easily annoyed too. nicolas On 02/02/2017 11:22, Denis Kudriashov wrote: > Hi. > > Finally I force myself to report my bad feeling of merged variable > table in GTDebugger. > By "merged" I mean that debugger join temps and receiver state in one > table. > Sometimes I really not like it because it is difficult to find > concrete variable. > > Now I think I realized main reason of my confusion. Temps and receiver > vars are not just in single table but they are also sorted by name all > together. > > For example try debug #expandBy: method: > > (1@2 corner: 3@4) expandBy: 10 > > You will see rows: self, corner, delta, origin, thisContext, stackTop > Maybe in this example it is not really bad. But it shows problem. > And imaging that there are much more inst vars in receiver object like > in morph or Spec. It is really difficult to find desired temp. > Actually it is also difficult to find inst var which are really used > in selected method. And usually methods use only few variables and few > temps. And the rest variables in table are just waste. > > I think we can improve this part of debugger. My idea that variable > table should show only used temp and variables. And "self" should be > selected by default. > With this main table will show only important information. And on the > right pane we will see receiver state like in the old debuggers. > > What you think? > -- Nicolas Anquetil -- MCF (HDR) Project-Team RMod

Feb. 2, 2017

GTDebugger variables table

by Denis Kudriashov

Hi. Finally I force myself to report my bad feeling of merged variable table in GTDebugger. By "merged" I mean that debugger join temps and receiver state in one table. Sometimes I really not like it because it is difficult to find concrete variable. Now I think I realized main reason of my confusion. Temps and receiver vars are not just in single table but they are also sorted by name all together. For example try debug #expandBy: method: (1@2 corner: 3@4) expandBy: 10 You will see rows: self, corner, delta, origin, thisContext, stackTop Maybe in this example it is not really bad. But it shows problem. And imaging that there are much more inst vars in receiver object like in morph or Spec. It is really difficult to find desired temp. Actually it is also difficult to find inst var which are really used in selected method. And usually methods use only few variables and few temps. And the rest variables in table are just waste. I think we can improve this part of debugger. My idea that variable table should show only used temp and variables. And "self" should be selected by default. With this main table will show only important information. And on the right pane we will see receiver state like in the old debuggers. What you think?

Feb. 2, 2017

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