July 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Nautilus shortcuts from code pane

by Peter UhnÃ¡k

> > This should not happen. If it does not handle the shortcut, it should be > handled by its owner Hmm, interesting. Apparently this must've been changed or something, because in Pharo 4 when I want to automatically categorize (ctrl+shift+h+c) it shows comparison against clipboard instead. In Pharo 5 that particular seems to work. In either case, if there is a shortcut clash then I have no way to use the Nautilus one. So I would like to have an option, to cancel focus on code pane with a keyboard. Peter

July 24, 2015

Re: [Pharo-dev] Nautilus shortcuts from code pane

by Peter UhnÃ¡k

On Fri, Jul 24, 2015 at 11:05 AM, Franck Warlouzet < franck.warlouzet(a)hotmail.fr> wrote: > What shortcut for example ? > Many Nautilus shortcuts where there is conflict. to pick some.. * open a new nautilus window (cmd + b + f/i) [cmd + b selects the row, cmd + f opens search dialog] * jump to selected class/method/protocol (cmd + g + c/p/..)

July 24, 2015

Re: [Pharo-dev] Is Metacello in Pharo 5.0 up-to-date? and project locking

by Thierry Goubier

Hi Peter, the FileTree part is solved, as far as I could do (i.e. all tests green with Pharo5 on Linux), but there is a failure in the travis CI of the most annoying type: the filetree code isn't even loaded :( I'm going on annual leave later today, and Dale told me he won't be easily available for a few weeks; I'll try to make some progress on it during the holidays, but don't count too much on it ;) In the meantime, if someone would be nice to setup Metacello and FileTree in Pharo5 as external projects with a configuration, it would immensely help. FileTree on the pharo5.0_dev is ready for it (apart for the travis CI), as are the tests. Thierry 2015-07-24 11:00 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > Is there any update on this? > > Thanks, > Peter > > On Mon, Jul 20, 2015 at 10:26 PM, Dale Henrichs < > dale.henrichs(a)gemtalksystems.com> wrote: > >> Wait, the "fix" was on the pharo5.0_dev branch (not clear to me whether >> this was even run against pharo5.0[1]) so it looks like Metacello is >> stalled by FileTree issues at the moment and it looks like Thierry is >> tackling the issues .... >> >> Dale >> >> [1] https://travis-ci.org/dalehenrich/filetree/builds/71656767 >> >> On 07/20/2015 01:13 PM, Dale Henrichs wrote: >> >> Okay ... apparently it isn't enough to fix the FileTree for Pharo 5.0, >> because that nets you a MNU with FileReference>>closed[1]. >> >> This issue looks to have been fixed a day ago[3], so I will see if I can >> kick off a rebuild of PR #351[2] and see where the port stands ... >> >> Dale >> >> [1] >> https://github.com/dalehenrich/metacello-work/pull/351#issuecomment-1225506… >> [2] https://github.com/dalehenrich/metacello-work/pull/351 >> [3] https://travis-ci.org/dalehenrich/filetree/builds/71656767 >> >> On 07/20/2015 12:35 PM, Peter UhnÃ¡k wrote: >> >> Hmm, #onWarningLog doesn't exist either. >> >> I'm assuming this is the issue >> https://pharo.fogbugz.com/f/cases/15456/Load-latest-version-of-metacello >> >> There's linked github issue >> https://github.com/dalehenrich/metacello-work/issues/354 >> >> But running the script (in the github issue) fails, because there's no >> defined spec for FileTree for Pharo 5.0 >> >> I'm not knowledgeable in Monticello so I don't know if I can do >> anything to help besides user testing. >> >> Peter >> >> On Mon, Jul 20, 2015 at 9:22 PM, Marcus Denker <marcus.denker(a)inria.fr> >> wrote: >> >>> No. There is an issue on the issue tracker. >>> >>> If nobody pushes, nothing will happen. >>> >>> Marcus >>> >>> On 20 Jul 2015, at 21:04, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >>> >>> Hi, >>> >>> I was playing around with metacello because I wanted to ignore >>> warnings with locks... >>> >>> currently I am doing something like >>> >>> ~~~~~~~~ >>> Metacello new >>> baseline: 'ProjectAAA'; >>> repository: 'gitfiletree:///path/to/projectAAA'; >>> lock. >>> >>> Metacello new >>> baseline: 'ProjectBBB'; >>> repository: 'gitfiletree:///projectBBB'; >>> onConflict: [ :ex | ex allow ]; >>> load. >>> ~~~~~~~~~ >>> >>> This will load both projects via gitfiletree, however it will also >>> generate a lots of lock warnings which I have to manually confirm - this is >>> bad for scripts. >>> >>> So the docs ( >>> https://github.com/dalehenrich/metacello-work/blob/master/docs/LockCommandR… >>> ) >>> >>> mention onLock: [ :ex | ex honor ], however in Pharo 5.0 there is no >>> such method "honor". >>> >>> Is this bug? >>> Should Metacello be updated on Pharo 5.0? >>> Will this even solve my problems? (Honoring locks while not throwing >>> warnings). >>> >>> Thanks, >>> Peter >>> >>> >>> >> >> >> >

July 24, 2015

Re: [Pharo-dev] Nautilus shortcuts from code pane

by Nicolai Hess

2015-07-24 10:56 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > Hi, > > currently when you are in the method code pane in Nautilus, no Nautilus > shortcuts (at least on Linux) works. > My understanding is that Rubric will eat all the shortcuts since it has > focus. > This should not happen. If it does not handle the shortcut, it should be handled by its owner > > So maybe a solution to this would be to add <Esc> shortcut for the code > pane to remove the focus? > Or is there already a solution in place? > > Peter >

July 24, 2015

Re: [Pharo-dev] Nautilus shortcuts from code pane

by Franck Warlouzet

What shortcut for example ? Franck Date: Fri, 24 Jul 2015 10:56:07 +0200 From: i.uhnak(a)gmail.com To: pharo-dev(a)lists.pharo.org Subject: [Pharo-dev] Nautilus shortcuts from code pane Hi, currently when you are in the method code pane in Nautilus, no Nautilus shortcuts (at least on Linux) works.My understanding is that Rubric will eat all the shortcuts since it has focus. So maybe a solution to this would be to add <Esc> shortcut for the code pane to remove the focus?Or is there already a solution in place? Peter

July 24, 2015

Re: [Pharo-dev] Is Metacello in Pharo 5.0 up-to-date? and project locking

by Peter UhnÃ¡k

Is there any update on this? Thanks, Peter On Mon, Jul 20, 2015 at 10:26 PM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > Wait, the "fix" was on the pharo5.0_dev branch (not clear to me whether > this was even run against pharo5.0[1]) so it looks like Metacello is > stalled by FileTree issues at the moment and it looks like Thierry is > tackling the issues .... > > Dale > > [1] https://travis-ci.org/dalehenrich/filetree/builds/71656767 > > On 07/20/2015 01:13 PM, Dale Henrichs wrote: > > Okay ... apparently it isn't enough to fix the FileTree for Pharo 5.0, > because that nets you a MNU with FileReference>>closed[1]. > > This issue looks to have been fixed a day ago[3], so I will see if I can > kick off a rebuild of PR #351[2] and see where the port stands ... > > Dale > > [1] > https://github.com/dalehenrich/metacello-work/pull/351#issuecomment-1225506… > [2] https://github.com/dalehenrich/metacello-work/pull/351 > [3] https://travis-ci.org/dalehenrich/filetree/builds/71656767 > > On 07/20/2015 12:35 PM, Peter UhnÃ¡k wrote: > > Hmm, #onWarningLog doesn't exist either. > > I'm assuming this is the issue > https://pharo.fogbugz.com/f/cases/15456/Load-latest-version-of-metacello > > There's linked github issue > https://github.com/dalehenrich/metacello-work/issues/354 > > But running the script (in the github issue) fails, because there's no > defined spec for FileTree for Pharo 5.0 > > I'm not knowledgeable in Monticello so I don't know if I can do anything > to help besides user testing. > > Peter > > On Mon, Jul 20, 2015 at 9:22 PM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > >> No. There is an issue on the issue tracker. >> >> If nobody pushes, nothing will happen. >> >> Marcus >> >> On 20 Jul 2015, at 21:04, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >> Hi, >> >> I was playing around with metacello because I wanted to ignore warnings >> with locks... >> >> currently I am doing something like >> >> ~~~~~~~~ >> Metacello new >> baseline: 'ProjectAAA'; >> repository: 'gitfiletree:///path/to/projectAAA'; >> lock. >> >> Metacello new >> baseline: 'ProjectBBB'; >> repository: 'gitfiletree:///projectBBB'; >> onConflict: [ :ex | ex allow ]; >> load. >> ~~~~~~~~~ >> >> This will load both projects via gitfiletree, however it will also >> generate a lots of lock warnings which I have to manually confirm - this is >> bad for scripts. >> >> So the docs ( >> https://github.com/dalehenrich/metacello-work/blob/master/docs/LockCommandR… >> ) >> >> mention onLock: [ :ex | ex honor ], however in Pharo 5.0 there is no >> such method "honor". >> >> Is this bug? >> Should Metacello be updated on Pharo 5.0? >> Will this even solve my problems? (Honoring locks while not throwing >> warnings). >> >> Thanks, >> Peter >> >> >> > > >

July 24, 2015

Nautilus shortcuts from code pane

by Peter UhnÃ¡k

Hi, currently when you are in the method code pane in Nautilus, no Nautilus shortcuts (at least on Linux) works. My understanding is that Rubric will eat all the shortcuts since it has focus. So maybe a solution to this would be to add <Esc> shortcut for the code pane to remove the focus? Or is there already a solution in place? Peter

July 24, 2015

Re: [Pharo-dev] Buttons in Nautilus

by Peter UhnÃ¡k

> > Is there something you always do and you would like to have without > opening a menu ? I very often use scoped selection. Currently I either do <alt>+b+s to open nautilus only on selected package, or <alt>+b+r+r to select several packages by regex.. Peter

July 24, 2015

Buttons in Nautilus

by Franck Warlouzet

Hello, Working on groups, I am removing the group button in Nautilus because no one uses it (Correct me if I am wrong). So there will be an extra slot for another button instead of this one. We could put a direct access to class refs but maybe we are the only ones to use it a lot. Is there something you always do and you would like to have without opening a menu ? Cheers, Franck

July 24, 2015

Re: [Pharo-dev] [Reflectivity] ... and Roassal

by Thierry Goubier

Hi Marcus, what is interesting is when you show the control flow graph overlaid over the AST, inter procedural analysis (i.e. follow the call graph) and thread or process-based decomposition if the code is run in parallel. This is some of the things I've done for a demo, and, yes, it doesn't take much time. Roassal is very cool for doing that :) Thierry 2015-07-24 8:57 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > Hi, > > Yesterday Alex and me played with using Roassal in combination with > reflectivity. > > Very quickly (within half an hour, even shorter) we had a view per class > that shows coverage for ASTs as trees > like this: > > > > > > this is > > | t | > t := false. > t ifTrue: [ self bar ] ifFalse: [ 'hello' ]. > ^ 5 > > > and you directly see that I have not yet added support for annotating > optimized blocksâ¦ will come soon. > (These views are nice for debugging reflectivityâ¦) > > > The code: > > 1) node-by-node coverage: > > getCoverageOf: aPharoClass whileExecuting: aBlock > " > self new getCoverageOf: CoverageDemoTest whileExecuting: [ > CoverageDemoTest new simpleAst ] > " > > | link | > link := MetaLink new > metaObject: #node; > selector: #tagExecuted. > aPharoClass methods do: [ :cm | cm ast nodesDo: [ :node | node link: link > ] ]. > aBlock value. > ^ aPharoClass > and the code for visalization: > > renderCoverage > | b | > b := RTMondrian new. > > b shape rectangle withTextAbove: #selector. > b nodes: self methods forEach: [ :aMethod | > b shape label > text: [ :astNode | > | aName | > aName := astNode class name copyFrom: 3 to: astNode class name size. > (aName endsWith: 'Node') > ifTrue: [ aName copyFrom: 1 to: aName size - 'Node' size ] > ifFalse: [ aName ] > ] ; > color: Color red; > if: #hasBeenExecuted color: Color green. > b nodes: aMethod ast allChildren. > b edges connectFrom: #parent. > b layout tree. > ]. > > b layout flow. > b build. > ^ b view > > > A second example shows often executed nodes larger (shows another bugâ¦ the > one largest should have the same size as the other large ones): > > > Code: > > > > renderNodeExecutions > | b | > b := RTMondrian new. > > b shape rectangle withTextAbove: #selector. > b nodes: self methods forEach: [ :aMethod | > b shape rectangle > size: [ :astNode | astNode propertyAt: #nbExecutions ifAbsent: [ 0 ] ]. > b nodes: aMethod ast allChildren. > b edges connectFrom: #parent. > b layout tree. > ]. > > b layout flow. > b build. > ^ b view > > > getNodeExecution: aPharoClass whileExecuting: aBlock > " > self new getNodeExecution: CoverageDemoTest whileExecuting: [ > 30 timesRepeat: [ CoverageDemoTest new simpleAst ] ] > " > > | link | > link := MetaLink new > metaObject: [ :node | > | v | > v := node propertyAt: #nbExecutions ifAbsentPut: [ 0 ]. > node propertyAt: #nbExecutions put: v + 1 ]; > selector: #value:; > arguments: #(#node). > aPharoClass methods do: [ :cm | cm ast nodesDo: [ :node | node link: link > ] ]. > aBlock value. > ^ aPharoClass > > > These are just very quick and raw experimentsâ¦ but they got us excited > about the possibilities when this is all > debugged and readyâ¦ > > Marcus > > > >

July 24, 2015