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

[pharo-project/pharo-core] 3e046e: 50768

by GitHub

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

Feb. 3, 2017

[pharo-project/pharo-core]

by GitHub

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

Feb. 3, 2017

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

by Nicolai Hess

Am 03.02.2017 12:35 nachm. schrieb "Peter Uhnak" <i.uhnak(a)gmail.com>: I was also looking at this, but couldn't figure out how to change it back, Do you know in what specific commit this happened? PharoLauncher-Core-ChristopheDemarey.100 (I prefer the old naming, since it included context and I knew whether the image was Pharo or Moose). Thanks, Peter On Wed, Feb 01, 2017 at 08:23:33PM +0100, Cyril Ferlicot D. wrote: > 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. 3, 2017

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

by Peter Uhnak

I was also looking at this, but couldn't figure out how to change it back, Do you know in what specific commit this happened? (I prefer the old naming, since it included context and I knew whether the image was Pharo or Moose). Thanks, Peter On Wed, Feb 01, 2017 at 08:23:33PM +0100, Cyril Ferlicot D. wrote: > 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. 3, 2017

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

by Christophe Demarey

> 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 -

Feb. 3, 2017

Re: [Pharo-dev] GTDebugger variables table

by Ben Coman

On Fri, Feb 3, 2017 at 10:21 AM, Ben Coman <btc(a)openinworld.com> wrote: > On Fri, Feb 3, 2017 at 12:28 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > > > 2017-02-02 17:16 GMT+01:00 John Brant <brant(a)refactoryworkers.com>: > >> > >> I think my preference would be to have several tabs for the variables. > In > >> addition to the one tab that we have now that shows all variables, I can > >> think of tabs for locals, inst vars, interesting variables, watched > >> variables/expressions, and stack variables. Locals would show just the > >> method/block arguments and any temps defined in the method. > >> Inst vars would > >> show the object's inst vars (and maybe class vars, however these would > only > >> appear after the inst vars). > >> > >> Interesting variables would show locals and inst vars used by the > method. > >> The locals would be limited to the ones that are still active at the > current > >> location in the method. For example, if you are in a block, it would > only > >> show variables used in the block. > > >> Also, if you are before(/after) the first(/final) use of the variable, > >> it wouldn't show in the interesting list. > > I'm not sure I'd like variables slipping in and out and rearranging > the middle of the list I'm looking at. Perhaps scope could be > indicated another way like greying out variables. It would be okay > for block variables to be added at the bottom. > > >> Interesting variables should also do some analysis to see what accessor > >> methods are used and show their corresponding variables. > > This is a nice idea. It need not only be for interesting variables. > Ideally it would be a tab in the next pane to the right of the [Meta] > tab, but I guess its difficult since that pane is concerned with the > object, and linking back to the variable holding could be difficult. > > >> > >> Watched variables/expressions would be user controlled. The user could > >> add/remove variables or expressions. These variables/expressions would > >> remain across different methods. If a variable didn't exist in the other > >> method, "Invalid" could be displayed. > > I really miss this from my TurboPascal days. > The difficulty of course is avoiding side effects. > > >> > >> Finally, stack variables would display the whole stack and not just the > >> top item. I like the ability to see the stack top, but it really doesn't > >> work if you want to see the first argument of a two argument message > send. > >> For example, if you debug "Array with: OrderedCollection new with: Set > new", > >> stepping over the "OrderedCollection new" immediately pushes the "Set" > class > >> on the stack so you can't see the "OrderedCollection new" object. > > Perhaps the stack could be another tab next to [Variables] ? > Or maybe it [Stack] would be better as a tab of thisContext's next pane. > > Actually you can try... Context>>stackValueMap | stackValues stackDepth| stackValues := OrderedCollection new. stackDepth := self basicSize min: 21. (stackDepth to: 1 by: -1) do: [ :index | |key| key := (index = stackDepth) ifTrue: ['Top'] ifFalse: [(stackDepth - index + 1) asString]. stackValues add: (key -> (self basicAt: index)) ]. ^stackValues Context>>gtInspectorStackValuesIn: composite <gtInspectorPresentationOrder: 40> | stackValues | stackValues := self stackValues. ^ (composite table) title: 'Stack'; display: [ self stackValueMap ]; column: 'Depth' evaluated: [ :assoc | assoc key ] width: 50; column: 'Item' evaluated: [ :assoc | GTObjectPrinter new asTruncatedTextFrom: assoc value ] I'm not sure whether the #stackValueMap is an appropriate name. Perhaps it should be #methodStackValueMap or something else? Similar for the tab name. And I don't know what the magic number 21 is, as I queried here... http://forum.world.st/magic-numbers-in-gtInspectorVariableValuePairs-tp4932… cheers -ben

Feb. 3, 2017

Re: [Pharo-dev] GTDebugger variables table

by Ben Coman

On Fri, Feb 3, 2017 at 12:28 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2017-02-02 17:16 GMT+01:00 John Brant <brant(a)refactoryworkers.com>: >> >> I think my preference would be to have several tabs for the variables. In >> addition to the one tab that we have now that shows all variables, I can >> think of tabs for locals, inst vars, interesting variables, watched >> variables/expressions, and stack variables. Locals would show just the >> method/block arguments and any temps defined in the method. >> Inst vars would >> show the object's inst vars (and maybe class vars, however these would only >> appear after the inst vars). >> >> Interesting variables would show locals and inst vars used by the method. >> The locals would be limited to the ones that are still active at the current >> location in the method. For example, if you are in a block, it would only >> show variables used in the block. >> Also, if you are before(/after) the first(/final) use of the variable, >> it wouldn't show in the interesting list. I'm not sure I'd like variables slipping in and out and rearranging the middle of the list I'm looking at. Perhaps scope could be indicated another way like greying out variables. It would be okay for block variables to be added at the bottom. >> Interesting variables should also do some analysis to see what accessor >> methods are used and show their corresponding variables. This is a nice idea. It need not only be for interesting variables. Ideally it would be a tab in the next pane to the right of the [Meta] tab, but I guess its difficult since that pane is concerned with the object, and linking back to the variable holding could be difficult. >> >> Watched variables/expressions would be user controlled. The user could >> add/remove variables or expressions. These variables/expressions would >> remain across different methods. If a variable didn't exist in the other >> method, "Invalid" could be displayed. I really miss this from my TurboPascal days. The difficulty of course is avoiding side effects. >> >> Finally, stack variables would display the whole stack and not just the >> top item. I like the ability to see the stack top, but it really doesn't >> work if you want to see the first argument of a two argument message send. >> For example, if you debug "Array with: OrderedCollection new with: Set new", >> stepping over the "OrderedCollection new" immediately pushes the "Set" class >> on the stack so you can't see the "OrderedCollection new" object. Perhaps the stack could be another tab next to [Variables] ? Or maybe it [Stack] would be better as a tab of thisContext's next pane. >> >> >> BTW, the current variable list sometimes shows 'error obtaining field >> value' for temporaries when stepping through a method. I'm not sure why it >> occurs, but it should always be able to display the temp variables. > > > I want everything you suggest :) So we should try in Pharo 7. cheers -ben

Feb. 3, 2017

Re: [Pharo-dev] magic numbers in gtInspectorVariableValuePairs

by Ben Coman

On Fri, Feb 3, 2017 at 10:13 AM, Ben Coman <btc(a)openinworld.com> wrote: > Just curious what the magic numbers here relate to... > and can they be factored out to a meaningful method name? > > Context>>gtInspectorVariableValuePairs > Whoops, this is... Object>>gtInspectorVariableValuePairs > "This is a helper method that returns a collection of > variable_name -> value > for the current object. > Subclasses can override it to specialize what appears in the variables > presentation" > | bindings | > bindings := OrderedCollection new. > 1 to: (self basicSize min: 21) do: [ :index | > bindings add: (index "asString""asTwoCharacterString" -> (self basicAt: > index)) ]. > ((self basicSize - 20) max: 22) to: (self basicSize) do: [ :index | "self > haltIf: [ index = 99 ]." > bindings add: (index "asString" -> (self basicAt: index)) ]. > bindings > addAll: ((self class allSlots > collect: [ :slot | slot name -> (slot read: self) ]) sort > asOrderedCollection). > ^ bindings > > > cheers -ben >

Feb. 3, 2017

magic numbers in gtInspectorVariableValuePairs

by Ben Coman

Just curious what the magic numbers here relate to... and can they be factored out to a meaningful method name? Context>>gtInspectorVariableValuePairs "This is a helper method that returns a collection of variable_name -> value for the current object. Subclasses can override it to specialize what appears in the variables presentation" | bindings | bindings := OrderedCollection new. 1 to: (self basicSize min: 21) do: [ :index | bindings add: (index "asString""asTwoCharacterString" -> (self basicAt: index)) ]. ((self basicSize - 20) max: 22) to: (self basicSize) do: [ :index | "self haltIf: [ index = 99 ]." bindings add: (index "asString" -> (self basicAt: index)) ]. bindings addAll: ((self class allSlots collect: [ :slot | slot name -> (slot read: self) ]) sort asOrderedCollection). ^ bindings cheers -ben

Feb. 3, 2017

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

by Igor Stasenko

On 31 January 2017 at 11:12, Christophe Demarey <christophe.demarey(a)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. > > Christophe. > IIRC in Pharo, we purposedly decided to support only single screen depth internally for Display. It is then the headache of VM driver to convert 32bpp to anything that suitable to deliver it on screen. The problem with this prim, is that it doesn't really tells you anything, especially since Pharo started using SDL. Also IIRC Squeak/Pharo doesn't forcing you to use native bitmaps (or only those that supported on platform it runs). -- Best regards, Igor Stasenko.

Feb. 2, 2017