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

Re: [Pharo-dev] Cmd+click in Rubric

by Yuriy Tymchuk

Well, if you cmd+click in nautilus, or other default text areas, it goes to definition. Uko > On 09 Nov 2014, at 18:58, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > Do you mean like in eclipse? I did not know it was possible, but for sure, I find it is a must have! > > 2014-11-09 18:12 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>>: > Dear all. > > Iâve already reported this issue but didnât make it clear. > > When I cmd+click some text in nautilus, I can âbrowseâ it. This means browse class implementation, browse method implementors. When I cmd+click something in rubric it opens a context menu. > > I anybody using cmd+click besides of me? > Can this be solved? > > Uko >

Nov. 9, 2014

Re: [Pharo-dev] Cmd+click in Rubric

by Nicolas Cellier

Do you mean like in eclipse? I did not know it was possible, but for sure, I find it is a must have! 2014-11-09 18:12 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > Dear all. > > Iâve already reported this issue but didnât make it clear. > > When I cmd+click some text in nautilus, I can âbrowseâ it. This means > browse class implementation, browse method implementors. When I cmd+click > something in rubric it opens a context menu. > > I anybody using cmd+click besides of me? > Can this be solved? > > Uko >

Nov. 9, 2014

Cmd+click in Rubric

by Yuriy Tymchuk

Dear all. Iâve already reported this issue but didnât make it clear. When I cmd+click some text in nautilus, I can âbrowseâ it. This means browse class implementation, browse method implementors. When I cmd+click something in rubric it opens a context menu. I anybody using cmd+click besides of me? Can this be solved? Uko

Nov. 9, 2014

Re: [Pharo-dev] Gofer loadDevelopment Bug?

by phil＠highoctane.be

Speaking of Gofer, I've had some issues with loading headless from a script. It complained about MC stuff with an interactive prompt. This error haw to do with the package cache location even if I disabled that on load. I'll make a better report but we need to get these things ironed out to have Pharo as a really good citizen in the command line ecosystem. Phil Le 9 nov. 2014 16:16, "Max Leske" <maxleske(a)gmail.com> a Ã©crit : > > > On 07.11.2014, at 20:02, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > > > The following, although seemingly equivalent, produce different > results... > > > > #1: > > Gofer it > > smalltalkhubUser: 'SeanDeNigris' project: 'SeansPlayground'; > > configurationOf: 'LivingCode'; > > load. > > #ConfigurationOfLivingCode asClass project development load. > > > > VS. > > > > #2: > > Gofer it > > smalltalkhubUser: 'SeanDeNigris' project: 'SeansPlayground'; > > configurationOf: 'LivingCode'; > > loadDevelopment > > > > #1 correctly loads package dependencies which #2 fails to load. > > I tried to reproduce you problem. That package breaks GT stuff in Pharo 4, > so Iâm not quite sure about the result, but I can say that #2 took > noticeably less time to run than #1. > > > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: > http://forum.world.st/Gofer-loadDevelopment-Bug-tp4788987.html > > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > >

Nov. 9, 2014

Re: [Pharo-dev] Gofer loadDevelopment Bug?

by Max Leske

> On 07.11.2014, at 20:02, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > The following, although seemingly equivalent, produce different results... > > #1: > Gofer it > smalltalkhubUser: 'SeanDeNigris' project: 'SeansPlayground'; > configurationOf: 'LivingCode'; > load. > #ConfigurationOfLivingCode asClass project development load. > > VS. > > #2: > Gofer it > smalltalkhubUser: 'SeanDeNigris' project: 'SeansPlayground'; > configurationOf: 'LivingCode'; > loadDevelopment > > #1 correctly loads package dependencies which #2 fails to load. I tried to reproduce you problem. That package breaks GT stuff in Pharo 4, so Iâm not quite sure about the result, but I can say that #2 took noticeably less time to run than #1. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Gofer-loadDevelopment-Bug-tp4788987.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Nov. 9, 2014

Re: [Pharo-dev] edit values in GTInspector

by Marcus Denker

>> > > Ah.. and we need not full object centric reflection for this: > > -> the inspector need to refresh if a variable changes > -> this means we need to hook into all assignment to an ivar > -> which is just a #before reflectivity link on a Slot, the same that breakpoints use. > (reflective change needs more care (#instVarAt: and friends) -> scope to the object by testing for it (with a condition on the link). (would slow down all other users of the same class a little) Marcus

Nov. 9, 2014

Re: [Pharo-dev] edit values in GTInspector

by Marcus Denker

> On 09 Nov 2014, at 07:45, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 08 Nov 2014, at 21:11, stepharo <stepharo(a)free.fr> wrote: >> >> What would be nice is to have the bifrost infrastructure and add a metaobject to an inspected object and removing when the inspector get closed. >> It would be quite nice and fully dynamic. >> > > Yes, in the longer term we should is like thatâ¦ of course we need to be a bit careful as this would mean that we change (on some level) > as soon as we inspect. But if we make the underlying framework really good (working with e.g. objects being passed to primitives), > it would be great. > Ah.. and we need not full object centric reflection for this: -> the inspector need to refresh if a variable changes -> this means we need to hook into all assignment to an ivar -> which is just a #before reflectivity link on a Slot, the same that breakpoints use. (reflective change needs more care (#instVarAt: and friends) So this should be working very very soonâ¦ Marcus

Nov. 9, 2014

Re: [Pharo-dev] edit values in GTInspector

by Marcus Denker

> On 08 Nov 2014, at 21:11, stepharo <stepharo(a)free.fr> wrote: > > What would be nice is to have the bifrost infrastructure and add a metaobject to an inspected object and removing when the inspector get closed. > It would be quite nice and fully dynamic. > Yes, in the longer term we should is like thatâ¦ of course we need to be a bit careful as this would mean that we change (on some level) as soon as we inspect. But if we make the underlying framework really good (working with e.g. objects being passed to primitives), it would be great. >From the planning -> Finish Reflecticity -> add proxies to the system -> combine the two -> then add a higher level layer (in the style of bifrost) So this will be funâ¦ but will take a while. Marcus

Nov. 9, 2014

Re: [Pharo-dev] edit values in GTInspector

by Tudor Girba

This would be indeed fantastic. Cheers, Doru On Sat, Nov 8, 2014 at 9:11 PM, stepharo <stepharo(a)free.fr> wrote: > What would be nice is to have the bifrost infrastructure and add a > metaobject to an inspected object and removing when the inspector get > closed. > It would be quite nice and fully dynamic. > > On 8/11/14 08:28, Tudor Girba wrote: > > What Alex was saying is that he only trusts an inspector that he just > opened. This is clearly not ideal. > > Is there a way to get reliably notified when an object changes its state? > > Cheers, > Doru > > > > On Sat, Nov 8, 2014 at 7:37 AM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > >> >> > On 07 Nov 2014, at 19:24, Alexandre Bergel <alexandre.bergel(a)me.com> >> wrote: >> > >> > This is strange, I do not remember to have use this when I was using >> the old inspector. I usually trust what the inspector tells me only having >> open one. >> > >> >> But thatâs the point: if the value changes, the inspector shows the old >> one. So you can *not* trust it. >> (and all the cool demos do not work anymore: adding an ivar to a class >> and the inspector on the object shows >> it, inspecting the world and showing how the mouse course position >> changesâ¦) >> >> Marcus >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 8, 2014

Re: [Pharo-dev] edit values in GTInspector

by stepharo

What would be nice is to have the bifrost infrastructure and add a metaobject to an inspected object and removing when the inspector get closed. It would be quite nice and fully dynamic. On 8/11/14 08:28, Tudor Girba wrote: > What Alex was saying is that he only trusts an inspector that he just > opened. This is clearly not ideal. > > Is there a way to get reliably notified when an object changes its state? > > Cheers, > Doru > > > > On Sat, Nov 8, 2014 at 7:37 AM, Marcus Denker <marcus.denker(a)inria.fr > <mailto:marcus.denker@inria.fr>> wrote: > > > > On 07 Nov 2014, at 19:24, Alexandre Bergel > <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: > > > > This is strange, I do not remember to have use this when I was using the old inspector. I > usually trust what the inspector tells me only having open one. > > > > But thatâs the point: if the value changes, the inspector shows > the old one. So you can *not* trust it. > (and all the cool demos do not work anymore: adding an ivar to a > class and the inspector on the object shows > it, inspecting the world and showing how the mouse course position > changesâ¦) > > Marcus > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

Nov. 8, 2014