October 2014 - Pharo-dev - lists.pharo.org

PharoNOS

by Torsten Bergmann

Hi, I just found http://pillarhub.pharocloud.com/hub/mikefilonov/pharonos Mike: can you comment a little bit on it here on the pharo lists? Thx T.

Oct. 16, 2014

Re: [Pharo-dev] Playground and its current usability in Pharo4.0 Latest update: #40307

by phil＠highoctane.be

I'd like to have the old workspace as it is for quick commands and as a kind of CLI where I do not need all the noise of the right part of the playground. And the playground for what it is meant to do. These two things are *not* for the same use case. âPhil

Oct. 16, 2014

Re: [Pharo-dev] Playground and its current usability in Pharo4.0 Latest update: #40307

by kilon alios

>> > Indeed. This was a discussion I wanted to spawn as well. I would prefer to > change the name from Workspace to Playground in the World Menu. The reason > is that the Playground is such a distinct departure from the Workspace that > it deserves a different name. > > >> >> I agree, it should not be named Workspace but on the other hand I feel also that "Playground" does not quite represent the raw power of the tool. But it definitely should not be named Workspace.

Oct. 16, 2014

Re: [Pharo-dev] Mysteries of the compiler

by Marcus Denker

>> >> While in the write we need to mark: >> >> lookupVariableForWrite: aVariableNode >> >> | var | >> >> var := scope lookupVar: aVariableNode name. >> >> var ifNil: [^var]. >> var isSpecialVariable ifTrue: [ self storeIntoSpecialVariable: aVariableNode ]. >> var isWritable ifFalse: [ self storeIntoReadOnlyVariable: aVariableNode ]. >> >> var isTemp ifTrue: [ >> "when in a loop, all writes escape" >> scope outerScope isInsideOptimizedLoop ifTrue: [ var markEscapingWrite ]. >> "else only escaping when they will end up in different closures" >> (var scope outerNotOptimizedScope ~= scope outerNotOptimizedScope) >> ifTrue: [ var markEscapingWrite]]. >> ^var >> >> >> I checked that all Opal tests that are failing are actually testing wrong, and I double checked >> that all those methods are now compiled like with the old old compilerâ¦ >> Now recompilng the image. > > Hmmâ¦ nopeâ¦. something wrong. > the âouterScopeâ was wrong. So without that, I can recompile the image and your example is compiled without temp vectorsâ¦ Marcus

Oct. 16, 2014

Re: [Pharo-dev] Playground and its current usability in Pharo4.0 Latest update: #40307

by Tudor Girba

Hi Torsten, Thanks for the feedback. On Thu, Oct 16, 2014 at 11:22 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > While I like that GTTools are in Pharo 4 now (thanks!!!) and allow all > kind of neat > things I basically ask myself if we forgot to remember usability on a few > places: > > 1. the world menu item "Workspace" opens a window "Playground" including > also > a tab with the same name "Playground". > => CONFUSING > > I would suggest that we rename the window "Workspace" and keep > "Playground" > for the initial tab. This is easy to fix and would also fulfill the > expectation > when a beginner grabbed an existing Smalltalk or Pharo book. > Indeed. This was a discussion I wanted to spawn as well. I would prefer to change the name from Workspace to Playground in the World Menu. The reason is that the Playground is such a distinct departure from the Workspace that it deserves a different name. > 2. While in all UI interfaces (Windows, Linux, Mac) the order in the > context menu > is "Cut", "Copy", "Paste" the playground menu uses a different order > "Copy", "Cut" "Paste". > => CONFUSING again > > I would suggest to use the well known order "Cut","Copy","Paste". > Thanks for noticing. This will be fixed. > 3. When one uses "Inspect it" from the context menu it means > - to run the code > - and the resulting object is then "inspectable" in a new window > > On the other side "Do it and go" from the context menu means > - to run the code > - and the resulting object is then "inspectable" in a new pane > (but same window) > > > The intention of both menu items and also the result is the same, but > the naming > is different ("go" vs. "inspect"). But the only notable difference is > that in one case the > inspectable object is opening right to the existing pane in the other > case a new > window is opened. > > => CONFUSING and inconsistent > This is harder to solve. Possible solutions are: > > 3a. We keep the "inspect" concept and name the menu items "Do > and Inspect it" and "Inspect in new window" > > 3b. We keep "Do it" as before to run the code, also "Inspect > it" which opens the new pane to the > left in the same window. If someone wants to open a new > inspector window he should keep SHIFT key pressed > while running "Inspect it". This is a concept known from > web browsers and other tools today, clicking on > a link while pressing SHIFT opens a new window. > Indeed, we had a debate about the name. I proposed the solution 3b you mention, but it was decided that it would be too confusing to change the Cmd+i action at this time, and we chose "Go" to be the name of the action that is mapped on Cmd+g. I proposed "gInspect it", but that is perhaps less fortunate :). You say that the intention is the same, but is is not. Having it opened to the right has the intention of keeping track of the path of inspection (we call it the inspection session). That is different from spawning an unrelated window. What other proposal would you have? > 4. The icons in the context menu of Playground are not the same as the > ones in the Pharo browsers. > > => CONFUSING and inconsistent > > They are just black and if one switches to the Pharo dark theme they > stay black and therefore > looking ugly and make nearly no sense on the dark grey menu background. > > For now we should use the known icons that we already have. Maybe > currently they are hardcoded and may > conflict with Moose vs. Pharo icons - but this could be solved with > the Icon Theming. > This is a known issue and we will look at it soon. > (In the long term I would like to see scalable icons in Pharo menues > (instead of bitmaps) similar to > "Fontawesome" in web browsers (two colors) or SVG based ones (more > colors) as currently the icon does > not scale when changing the menue font size). > Me too! > Sorry if it sound like a rant - but the intention of this mail is that we > discuss > (and hopefully fix) in order to improve. > It's not a rant at all. > Maybe it is written too early after the initial integration, but I think > the mentioned > points should be easy to address. Unfortunately I'm additionally confused > with the changed > contribution process that has exceptions for specific packages like GT to > fix it > myself with the usualy bugs/slice cycle. > At the moment, GT is an external project and the contributions should happen directly in its repository. Cheers, Doru > Thanks > T. > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 16, 2014

Re: [Pharo-dev] Mysteries of the compiler

by Marcus Denker

> On 16 Oct 2014, at 17:26, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 16 Oct 2014, at 16:43, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> >> >> >> >> 1. sometimes the debugger can not inspect a single tempvar (list of all temps is working) >> 2. number of temp vars (in method header) is wrong: >> >> | a b c | >> a := 1. >> b := 2. >> c := 3. >> [[a asString] >> on: Error >> do: [:ex | a >> value: a >> value: b >> value: c]. >> c < 0] whileTrue. >> >> method header numtemps 1 >> >> | a b c | >> a := 1. >> b := 2. >> c := 3. >> c < 0 >> ifTrue: [ >> [ a asString ] >> on: Error >> do: [ :ex | a value: a value: b value: c ]. >> c < 0 ]. >> ^ a >> >> method header numtemps 3 >> >> both methods define a block with a nested block. >> In the first method it is the receiver of #whileTrue: >> the second method it is the argument to #ifTrue: >> I think both blocks are optimized, but somehow the >> block receiving the whileTrue: message makes the computation >> for the number of tempvars wronng >> >> >> What is happening is that the variables are wrongly put in a temp vector... in the case >> of loops. >> >> the one temp is this vector. >> >> this should be fixed. >> > > I think the problem is that what we did is to mark a variables as escaping when it > as *read* in an optimised block. > > But what we should do is to mark only all *writes* to a variable that happens in a loop as > escaping vars even in the case when they happen in the same scope. > > this means the read is simpler: > > visitVariableNode: aVariableNode > | var | > var := (self lookupVariableForRead: aVariableNode) ifNil: [(self undeclaredVariable: aVariableNode)]. > aVariableNode binding: var. > var isUninitialized ifTrue: [self uninitializedVariable: aVariableNode]. > > > While in the write we need to mark: > > lookupVariableForWrite: aVariableNode > > | var | > > var := scope lookupVar: aVariableNode name. > > var ifNil: [^var]. > var isSpecialVariable ifTrue: [ self storeIntoSpecialVariable: aVariableNode ]. > var isWritable ifFalse: [ self storeIntoReadOnlyVariable: aVariableNode ]. > > var isTemp ifTrue: [ > "when in a loop, all writes escape" > scope outerScope isInsideOptimizedLoop ifTrue: [ var markEscapingWrite ]. > "else only escaping when they will end up in different closures" > (var scope outerNotOptimizedScope ~= scope outerNotOptimizedScope) > ifTrue: [ var markEscapingWrite]]. > ^var > > > I checked that all Opal tests that are failing are actually testing wrong, and I double checked > that all those methods are now compiled like with the old old compilerâ¦ > Now recompilng the image. Hmmâ¦ nopeâ¦. something wrong. Marcus

Oct. 16, 2014

Re: [Pharo-dev] [Pharo4] Inspector View for Opal Scopes

by Sven Van Caekenberghe

You should add #gtInspectorItemsIn: as well (look in Dictionary), to get the key/value view, maybe changed a bit to keep the order. On 16 Oct 2014, at 16:59, phil(a)highoctane.be wrote: > These things are wicked cool. > > GTInspector rocks (even more when it will have **full* menus!). > > Some little updates in OrderPreservingDictionary and bingo, I get the data. > > e.g. > > gtInspectorVariableValuePairs > ^ Set new > add: ( 'tally' -> self size ); > add: ( 'dictionary' -> self dictionary ); > add: ( 'orderedKeys' -> self orderedKeys ); > yourself > > Indeed, this is really powerful and has the potential of giving terrific boosts to the development speed. It does for me! > > Phil > > > > > On Thu, Oct 16, 2014 at 4:21 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Keep the goodies coming :) > > Doru > > On Thu, Oct 16, 2014 at 4:04 PM, Clara Allende <clari.allende(a)gmail.com> wrote: > I love it :) Thanks ^^ > > 2014-10-16 15:39 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > Hi, > > There is now a special view for semantic scopes in Opal: > > <scopes.png> > > > And these tools work outside of the Inspector, too: > e.g. > > GTBytecodeBrowser openOn: (OrderedCollection>>#do:) > > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Oct. 16, 2014

Re: [Pharo-dev] Mysteries of the compiler

by Marcus Denker

> On 16 Oct 2014, at 16:43, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > > 1. sometimes the debugger can not inspect a single tempvar (list of all temps is working) > 2. number of temp vars (in method header) is wrong: > > | a b c | > a := 1. > b := 2. > c := 3. > [[a asString] > on: Error > do: [:ex | a > value: a > value: b > value: c]. > c < 0] whileTrue. > > method header numtemps 1 > > | a b c | > a := 1. > b := 2. > c := 3. > c < 0 > ifTrue: [ > [ a asString ] > on: Error > do: [ :ex | a value: a value: b value: c ]. > c < 0 ]. > ^ a > > method header numtemps 3 > > both methods define a block with a nested block. > In the first method it is the receiver of #whileTrue: > the second method it is the argument to #ifTrue: > I think both blocks are optimized, but somehow the > block receiving the whileTrue: message makes the computation > for the number of tempvars wronng > > > What is happening is that the variables are wrongly put in a temp vector... in the case > of loops. > > the one temp is this vector. > > this should be fixed. > I think the problem is that what we did is to mark a variables as escaping when it as *read* in an optimised block. But what we should do is to mark only all *writes* to a variable that happens in a loop as escaping vars even in the case when they happen in the same scope. this means the read is simpler: visitVariableNode: aVariableNode | var | var := (self lookupVariableForRead: aVariableNode) ifNil: [(self undeclaredVariable: aVariableNode)]. aVariableNode binding: var. var isUninitialized ifTrue: [self uninitializedVariable: aVariableNode]. While in the write we need to mark: lookupVariableForWrite: aVariableNode | var | var := scope lookupVar: aVariableNode name. var ifNil: [^var]. var isSpecialVariable ifTrue: [ self storeIntoSpecialVariable: aVariableNode ]. var isWritable ifFalse: [ self storeIntoReadOnlyVariable: aVariableNode ]. var isTemp ifTrue: [ "when in a loop, all writes escape" scope outerScope isInsideOptimizedLoop ifTrue: [ var markEscapingWrite ]. "else only escaping when they will end up in different closures" (var scope outerNotOptimizedScope ~= scope outerNotOptimizedScope) ifTrue: [ var markEscapingWrite]]. ^var I checked that all Opal tests that are failing are actually testing wrong, and I double checked that all those methods are now compiled like with the old old compilerâ¦ Now recompilng the image. Marcus

Oct. 16, 2014

Re: [Pharo-dev] [Pharo4] Inspector View for Opal Scopes

by Tudor Girba

Hi, On Thu, Oct 16, 2014 at 4:59 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > These things are wicked cool. > > GTInspector rocks (even more when it will have **full* menus!). > The menu was enhanced with the entries that were reported as being missing. Which entries are still missing for you? > Some little updates in OrderPreservingDictionary and bingo, I get the data. > > e.g. > > gtInspectorVariableValuePairs > ^ Set new > add: ( 'tally' -> self size ); > add: ( 'dictionary' -> self dictionary ); > add: ( 'orderedKeys' -> self orderedKeys ); > yourself > > Indeed, this is really powerful and has the potential of giving terrific > boosts to the development speed. It does for me! > Indeed :) Doru > Phil > > > > > On Thu, Oct 16, 2014 at 4:21 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Keep the goodies coming :) >> >> Doru >> >> On Thu, Oct 16, 2014 at 4:04 PM, Clara Allende <clari.allende(a)gmail.com> >> wrote: >> >>> I love it :) Thanks ^^ >>> >>> 2014-10-16 15:39 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: >>> >>>> Hi, >>>> >>>> There is now a special view for semantic scopes in Opal: >>>> >>>> >>>> >>>> And these tools work outside of the Inspector, too: >>>> e.g. >>>> >>>> GTBytecodeBrowser openOn: (OrderedCollection>>#do:) >>>> >>>> >>>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 16, 2014

Re: [Pharo-dev] [Pharo4] Inspector View for Opal Scopes

by phil＠highoctane.be

These things are wicked cool. GTInspector rocks (even more when it will have **full* menus!). Some little updates in OrderPreservingDictionary and bingo, I get the data. e.g. gtInspectorVariableValuePairs ^ Set new add: ( 'tally' -> self size ); add: ( 'dictionary' -> self dictionary ); add: ( 'orderedKeys' -> self orderedKeys ); yourself Indeed, this is really powerful and has the potential of giving terrific boosts to the development speed. It does for me! Phil On Thu, Oct 16, 2014 at 4:21 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Keep the goodies coming :) > > Doru > > On Thu, Oct 16, 2014 at 4:04 PM, Clara Allende <clari.allende(a)gmail.com> > wrote: > >> I love it :) Thanks ^^ >> >> 2014-10-16 15:39 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: >> >>> Hi, >>> >>> There is now a special view for semantic scopes in Opal: >>> >>> >>> >>> And these tools work outside of the Inspector, too: >>> e.g. >>> >>> GTBytecodeBrowser openOn: (OrderedCollection>>#do:) >>> >>> >>> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Oct. 16, 2014