- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Spotter

by stepharo

aliaksei what would be nice is that each time we click on a button or press a command key you emit a growl notification with the description. Stef Le 5/4/15 03:03, Aliaksei Syrel a Ã©crit : > Hi Ben, > > > This is quite a hidden and implicit key stroke. Regardless that I > know I've used it before follow a tutorial, I forgot it. Since > Spotter has a <Settings Icon> (which I like and think it could be > pushed as a standard throughout the system in Pharo 5), it might > be useful for Pharo 4 if the Spotter Settings page contains a "How > To" or "Keyboard shortcuts" item that just contains descriptive > text. Or if there is no facility for that, perhaps a few of the > keyboard shortcuts listed as individual items with descriptions, > even if you can't change them. I think this will be useful for > people presented with Spotter for the first time, particularly > since first use already prompts users to go to settings to send > usage data. > > > > Yes, you right, shortcuts were quite hidden. However, after we > received a lot of similar feedback we improved the situation with > shortcuts. Now all actions in Spotter have explicit action buttons: > Inline image 1 > > As soon as you press "shift" (you can't not to press shift during > usage of spotter) all action buttons are highlighted explicitly: > Inline image 2 > > If you hover action button for a few second a hint appears that tells > which shortcut is assigned to an action. If you hover the button while > pressing shift a hint appears immediately: > > Inline image 3 > > Also, in Pharo help there is a good tutorial listing all Spotter > shortcuts and assigned actions: > Inline image 4 > > How else can we improve discoverability of Spotter features? > > Cheers, > Alex > > > Cheers, > Alex > > On Sun, Apr 5, 2015 at 2:35 AM, Ben Coman <btc(a)openinworld.com > <mailto:btc@openinworld.com>> wrote: > > Thanks Aliaksei. > > This is quite a hidden and implicit key stroke. Regardless that I > know I've used it before follow a tutorial, I forgot it. Since > Spotter has a <Settings Icon> (which I like and think it could be > pushed as a standard throughout the system in Pharo 5), it might > be useful for Pharo 4 if the Spotter Settings page contains a "How > To" or "Keyboard shortcuts" item that just contains descriptive > text. Or if there is no facility for that, perhaps a few of the > keyboard shortcuts listed as individual items with descriptions, > even if you can't change them. I think this will be useful for > people presented with Spotter for the first time, particularly > since first use already prompts users to go to settings to send > usage data. > > cheers -ben > > On Sun, Apr 5, 2015 at 8:25 AM, Aliaksei Syrel > <alex.syrel(a)gmail.com <mailto:alex.syrel@gmail.com>> wrote: > > Hi Ben, > > It's CMD+Shift+Right > > On Apr 5, 2015 2:23 AM, "Ben Coman" <btc(a)openinworld.com > <mailto:btc@openinworld.com>> wrote: > > Just a note, I went back to an old image and really miss > the Spotter workflow. > > One thing, can you remind me how when it shows 5/30 > implementors I get a list of all 30? I'm sure I've done > this before but can't remember. Perhaps this means its not > obvious and maybe should appear in a "How To Use" section > in the Release Notes. > > cheers -ben > > >

April 5, 2015

Re: [Pharo-dev] Xtreams Now in MetaRepoForPharo40

by Ben Coman

Thanks Sean. On Sun, Apr 5, 2015 at 10:07 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Sean P. DeNigris wrote > > It was a bit ugly... I asked a question on the MetaC list about cleaning > > it up. > > Okay, Dale explained how to do it properly > ( > http://forum.world.st/Xtreams-Pharo-4-0-Other-FileSystem-Images-tp4816537p4… > ). > New version published. > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Xtreams-Now-in-MetaRepoForPharo40-tp4816538p4817681.h… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

April 5, 2015

Metacello: Resolving Conflicting Attributes

by Sean P. DeNigris

Dale taught me something helpful (and maybe a little obscure) while fixing ConfigurationOfXtreams... Problem: Say you have a platform attribute #pharo4.x, and a #customProjectAttribute #FileSystem. The problem is that the FileSystem-related packages required for #pharo4.x are different than those for the default cases. spec for: #'pharo4.x' do: [ spec package: 'Xtreams-TerminalsFileSystem' with: 'Xtreams-TerminalsFileSystem.pharo40-SeanDeNigris.4' ]. ... spec for: #FileSystem do: [ spec package: 'Xtreams-TerminalsFileSystem' with: 'Xtreams-TerminalsFileSystem-nice.1'. ] Solution: Nest a "spec for: #FileSystem do:" inside the "spec for: #pharo4.x do:" declaring the #pharo4.x-specifics spec for: #'pharo4.x' do: [ spec for: #'FileSystem' do: [ spec package: 'Xtreams-TerminalsFileSystem' with: 'Xtreams-TerminalsFileSystem.pharo40-SeanDeNigris.4' ]. Why it works: Per Dale, "The spec:for:do: blocks are evaluated in attribute order (ConfigurationOfX project attributes) with top-level blocks evaluated before nested blocks ... second level blocks are evaluated in top-level block order after the first level block evaluation ... so having #FileSystem nested inside of #pharo4.x and given that #FileSystem follows #pharo4.x in attribute order means that the nested #FileSystem block inside of #pharo4.x is evaluated after to top-level #FileSystem block allowing you to do #pharo4.x specific overrides" ----- Cheers, Sean -- View this message in context: http://forum.world.st/Metacello-Resolving-Conflicting-Attributes-tp4817683.… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 5, 2015

Re: [Pharo-dev] Xtreams Now in MetaRepoForPharo40

by Sean P. DeNigris

Sean P. DeNigris wrote > It was a bit ugly... I asked a question on the MetaC list about cleaning > it up. Okay, Dale explained how to do it properly (http://forum.world.st/Xtreams-Pharo-4-0-Other-FileSystem-Images-tp4816537p4…) New version published. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Xtreams-Now-in-MetaRepoForPharo40-tp4816538p4817681.h… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 5, 2015

New Pull Request for UpdatedPharoByExample

by Gaurav Singh

I have made a few corrections in the chapter Syntax in a Nutshell. Link to the pull request: https://github.com/SquareBracketAssociates/UpdatedPharoByExample/pull/30 Kindly review the pull request.

April 5, 2015

Re: [Pharo-dev] 14606 Really Important bug - Can't see some variables values while debugging closure

by Sven Van Caekenberghe

Yes, incredible work, well done. Thank you. > On 05 Apr 2015, at 14:59, stepharo <stepharo(a)free.fr> wrote: > > > Thanks both of you for the energy you put into Pharo. > The tam really appreciates. > This is because there are guys like you that Pharo is worth being done. > Thanks for the tests. > Esteban has apparently found the bug on the VM. > > Stef >> >> >> On Sun, Apr 5, 2015 at 1:23 PM, Ben Coman <btc(a)openinworld.com> wrote: >> I got annoyed since a few times I thought I'd solved everything just the issue looking at the manual examples of one issue, only to find I'd caused the other case to fail. Also keeping track of all cases as I threw away images with partial solutions was awkward. So I turned the examples from all these Cases into tests and uploaded AdditionalTests-14606-13260-15174-BenComan.1 - so solutions can consistently test all cases. These can be integrated once we have a solution for all of them. Can you think of anymore to add? >> >> >> >> >> And of course, please advise if you think the tests are correct. >> cheers -ben >> >> >> They look good. >> >> Just for reference, in the slice for fixing issue 13260, I added two testcases >> MethodMapTest>>#testCopiedVarFromDeadContext >> and >> MethodMapTest>>#testExampleTempNamedTempVectorInlinedLoop >> >> >

April 5, 2015

Re: [Pharo-dev] 14606 Really Important bug - Can't see some variables values while debugging closure

by stepharo

Thanks both of you for the energy you put into Pharo. The tam really appreciates. This is because there are guys like you that Pharo is worth being done. Thanks for the tests. Esteban has apparently found the bug on the VM. Stef > > > > On Sun, Apr 5, 2015 at 1:23 PM, Ben Coman <btc(a)openinworld.com > <mailto:btc@openinworld.com>> wrote: > > I got annoyed since a few times I thought I'd solved > everything just the issue looking at the manual examples of > one issue, only to find I'd caused the other case to fail. > Also keeping track of all cases as I threw away images with > partial solutions was awkward. So I turned the examples from > all these Cases into tests and uploaded > AdditionalTests-14606-13260-15174-BenComan.1 - so solutions > can consistently test all cases. These can be integrated once > we have a solution for all of them. Can you think of anymore > to add? > > > > > And of course, please advise if you think the tests are correct. > cheers -ben > > > > They look good. > > Just for reference, in the slice for fixing issue 13260, I added two > testcases > MethodMapTest>>#testCopiedVarFromDeadContext > and > MethodMapTest>>#testExampleTempNamedTempVectorInlinedLoop > >

April 5, 2015

Re: [Pharo-dev] 14606 Really Important bug - Can't see some variables values while debugging closure

by Nicolai Hess

2015-04-05 7:25 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > > > On Sun, Apr 5, 2015 at 1:23 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> I got annoyed since a few times I thought I'd solved everything just the >> issue looking at the manual examples of one issue, only to find I'd caused >> the other case to fail. Also keeping track of all cases as I threw away >> images with partial solutions was awkward. So I turned the examples from >> all these Cases into tests and uploaded >> AdditionalTests-14606-13260-15174-BenComan.1 - so solutions can >> consistently test all cases. These can be integrated once we have a >> solution for all of them. Can you think of anymore to add? >> >> >> >> > And of course, please advise if you think the tests are correct. > cheers -ben > They look good. Just for reference, in the slice for fixing issue 13260, I added two testcases MethodMapTest>>#testCopiedVarFromDeadContext and MethodMapTest>>#testExampleTempNamedTempVectorInlinedLoop

April 5, 2015

Re: [Pharo-dev] 14606 Really Important bug - Can't see some variables values while debugging closure

by Ben Coman

On Sun, Apr 5, 2015 at 1:23 PM, Ben Coman <btc(a)openinworld.com> wrote: > I got annoyed since a few times I thought I'd solved everything just the > issue looking at the manual examples of one issue, only to find I'd caused > the other case to fail. Also keeping track of all cases as I threw away > images with partial solutions was awkward. So I turned the examples from > all these Cases into tests and uploaded > AdditionalTests-14606-13260-15174-BenComan.1 - so solutions can > consistently test all cases. These can be integrated once we have a > solution for all of them. Can you think of anymore to add? > > > > And of course, please advise if you think the tests are correct. cheers -ben

April 5, 2015

Re: [Pharo-dev] 14606 Really Important bug - Can't see some variables values while debugging closure

by Ben Coman

I got annoyed since a few times I thought I'd solved everything just the issue looking at the manual examples of one issue, only to find I'd caused the other case to fail. Also keeping track of all cases as I threw away images with partial solutions was awkward. So I turned the examples from all these Cases into tests and uploaded AdditionalTests-14606-13260-15174-BenComan.1 - so solutions can consistently test all cases. These can be integrated once we have a solution for all of them. Can you think of anymore to add? On Sun, Apr 5, 2015 at 8:27 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > 2015-04-01 18:56 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > >> Issue 14606 [1] is tagged "Really Important" where evaluating.... >> >> | t1 t2 t3 t4 t5 t6 | >> t1 := 1. >> t2 := 2. >> t3 := 3. >> t4 := 4. >> t5 := 5 . >> t6 := 6. >> [ t5 := 50. >> t6 := 60. >> t3 + t4. >> 1 halt. >> ] value >> >> => can't see the value of t4, t5, t6. >> >> I've just submitted a possible solution for this, but its a bit late >> before release for such a change - so I'm asking for "all hands in" to help >> stress test it. You don't need to review code, just please merge latest >> slice 14606 into your normal working image and report your experience. >> >> cheers -ben >> >> [1] https://pharo.fogbugz.com/default.asp?14606#124466 >> >> > > > Origins of issue "14606 Can't see some variables values while debugging > closure" > It starts with issue: > 14079 Inconsistent information in debugger (pharo 4) > (fixed in 40258) > The thisContext inspector in the debugger (sometimes) shows the wrong > values for the thisContext temp vars. > This was first seen in Method FreeTypeFontProvider>>#updateFromFile: > I extracted a minimal example to reproduce this behavior: > [ :x | > | d c b a | > a := 1. > b := 2. > c := 3. > d := 4. > [ c:=3. c=0 ] on:Error do:[:ex|]. > d halt. > [ c:=3. c=0 ] whileTrue:[]] value:23 > If you execute this method, it stops at "d halt". Look at the "all temp > vars" and the > individual temp var entries in the context inspector. It shows the temp > vars with the correct > values. Now do a step over, int the whileTrue block the temp var name list > is unchanged but > the values changed their order, now the list of individual temp vars shows > the wrong values! > Why did this happen? > There are two problems, > 1. The order of temp vars changes between the method context and the block > closure > 2. The EyeDebuggerContextInspector compares ContextTempEyeElements > without their inst vars (tempName AND tempIndex). > In EyeInspector>>#updateList: > We step into a new block and the debugger calls updateList, here > we check the current list (self list getItems) with the new list (elements) > and check if they are equal, they aren't, because the lists contain > ContextTempEyeElements with > the same tempName but different tempIndex, but the #= selector in > AbstractEyeElement doesn't check this. > EyeInspector>>#updateList > "update the list of elements displayed according to the new object" > > | elements | > " self haltOnce." > elements := self generateElements. > self list getItems = elements ifTrue: [ ^ self ]. "<<<--- returns > event if the elements aren't equal" > .... > > Possible solutions: > - Don't reorder tempvars in inner scopes. This needs some deeper knowlegde > of opals AST Translator. > - Fix the #= for AbstractEyeElement resp. ContextTempEyeElement > - in ContextTempEyeElement, access the temp values not by index (they > changed) but by name > I choosed the latter, because I could not get a working fix for the other, > this raised some > new issues. Not really new, they exists already, but weren't visible > because they were only > used in special cases: > > 13260 inspecting variables in the debugger fails in some cases > (fixed in 40354) > Minimal example: > x := [ :k || b a | b:=[ a:=1. a:=k+1.a]] value:7. > x value > > *Execute* the first line, then debug the second. > In the debugger, in the thisContext inspector, you can select the var > "k", it shows 7, you can select the var "b" it shows nil (because it *is* > nil), > you can not show the value for "a", although it should show "1". > Why did this happens? > With the fix for issue 14079, we now use #tempNamed:aName instead of > #namedTempAt: anIndex > but in the end, the context only stores the temp vars by index, so we (the > debugger) > needs to find the index for the named temp. This is done through > DebuggerMethodMapOpal > namedTempAt:in: resp. tempNamed:in: > It looks up the temp index by the variable binding for the *Method* scope > (and finally the method context). > This is wrong, because in this case, the method context is already dead. > I fixed this by changing OCVectorTempVariable>>#readFromContext:scope: > to start from the inner scope instead of the scope that defined the method > (because it can > be already dead). (This wasn't straight forward, I need to change some > more because the > way the IR class for constructing the closures bytecodes, only searched in > its "block sequence" > but the copyied tempvector is defined in its "sequence" (I don't really > remember what is what). > Even if I had choosed a different fix for issue 14079, this still had to > be fixed, because > indirect variable access through namedTempAt: is used, if we select the > temp var in the *code view* > and do a inspectIt. > Even with this fix, the issue is not fully solved: > > Unsolved issues: > 14606 Can't see some variables values while debugging closure > Minimal example: > |a b c| > a := [ Transcript show: 'test' ]. > [ b :=4. > c := 5. > 1 halt] on: Error do: a. > select the b or c value in the thisContext inspector shows "nil" although > they actually have a value. > And > > 15174 error when inspecting/printing variables in the debugger > > this is a minimal example, reproducing this case, the assignment on "a" is > alreaday > done, after that accessing the value with DebuggerMethodMapOpal should > work, but > it raises an error > | a b | > [ ] value. > a := 1. > b := [ > a := 4. > (DebuggerMethodMapOpal forMethod: thisContext method) tempNamed: 'a' > in: thisContext ] value. > ^ a + b > > -> MessageNotUnderstood: receiver of "indexForVarNamed:" is nil > in OCCopyingTempVariable>>indexInTempVectorFromIR: > > Both issues has to be solved and they have actually two causes: > 1. There is a guarding clause in Context>>tempNamed: anIndex > If the context stackpointer is below temp index, it returns nil. This is > for the case > the block closure vars aren't yet fully initialized (context tempvars are > pushed > on the stack with pushNil, if the stack pointer is below the index, it > looks like we > access a temp var, for which there isn't yet a place on the stack). > But this is wrong! > If the closure uses a closure copied or closure indirect tempvars, then > multiple > vars may be in *one* array that only takes one place on the stack. > 2. (This is the reason for the MNU). Reading the temp vector index for > "copied" temp > vars fails. My proposed solution in "15174 error when inspecting/printing > variables in the debugger" > Looks like fixing this bug at the wrong place. I think it has something to > do with 12887 Fix pc->AST maping. > > There was another issue, something with optimized blocks and reading and > or writing closure temp > vars, but I don't remember that, one. Don't know if it had something to do > with this issues. > > Hope this was understandable and it helps (but I doubt we can solve any of > this for this release. > I was working on them the last 6 month, and issues 12887 is there since > one year, still exists). > > > nicolai > > >

April 5, 2015