Hi Nicolas, I agree that this is a problem. I actually would like to not have self at all in the list.
Cheers, Doru On Fri, Dec 26, 2014 at 10:37 PM, Nicolas Cellier < [email protected]> wrote: > One thing that upset me is the recursive opening of the same view again > and again > for example when you do something like 'foo' inspect, with the raw view > self | 'foo' > You must then learn to not click self, what use to this? > > There should be dead ends, when you can't go any deeper, you can't... > > 2014-12-26 21:56 GMT+01:00 kilon alios <[email protected]>: > >> I have acknowledge the fact that after I mentioned things I missed from >> old workspace you were quick to integrate them back to Playground (copy, >> paste, implementors, senders etc). You dont understand my premise. My >> premise that in the end a tool can only satisfy some people but not all of >> them. To deny that is to deny the fabric of our reality. So my belief is >> that the answer to the question that Sven asked and I was replying it to >> ". So what is best, we all together use and make the best tools, or we all >> work with different tools ?" is "both". We as a community help GT tools >> evolve with our contributions (certainly I would love to contribute at some >> point too) and this is definitely the start of a long term evolution but >> also on the other hand individual of groups of pharo coder may create their >> own tools to fill the gaps and satisfy needs the existing tools do not . >> >> Afterall one does not bother to use a fairly unpopular language / IDE >> that is easy to hack if he does not intend to at least do some hacking with >> it. The ease of building custom IDE tools with Pharo is what makes Pharo so >> much fun. >> >> On Fri, Dec 26, 2014 at 10:13 PM, Tudor Girba <[email protected]> >> wrote: >> >>> Hi Kilon, >>> >>> Your premise is incorrect. Since two months we are gathering feedback >>> and actively incorporating it in the tools. Quite some changes happened >>> exactly because of this exercise, and they will continue to happen. Tools >>> do get redesigned when there are enough arguments. >>> >>> You do not have to "suck it up". I have no interest in building >>> something for my own needs only. I can do that by myself without going >>> through all the trouble of asking people. >>> >>> We need to make explicit what does not work and the design emerges out >>> of that. Your points of view matter. Your opinions will not be blindly >>> incorporated and the final decision remains with the team that builds these >>> tools, but the majority of times the design was agreed by everyone. This >>> can work. >>> >>> I understand that it can be slightly inconvenient at times, but we want >>> to get far fast, and for that we need everyone's help at least as feedback. >>> If we keep the other tools around, the incentive to fall back on the >>> existing habit is too great and feedback does not happen. Please put a bit >>> more trust in us and we'll try to live up to your expectations. >>> >>> Cheers, >>> Doru >>> >>> >>> >>> >>> On Fri, Dec 26, 2014 at 7:40 PM, kilon alios <[email protected]> >>> wrote: >>> >>>> Why cant be both ? Why it has to be black and white ? What if we , I, >>>> someone does not like the design of a tool at a fundamental level ? >>>> >>>> If you dont like a tool then you dont like a tool, its not as if the >>>> tool itself will be redesigned to fit your own needs . You have two choices >>>> a) suck it up and compromise with what you have b) suck it up go through >>>> the pain / pleasure of creating your own solution. One thing I learned with >>>> coding is that for other codes its usually "use the right tool for the >>>> right job" but for me is "the right tools for the right coder". >>>> >>>> "Personal Preferences" is the name of the game. Plus I disagree that >>>> without variation of effort we can have high quality tools. Take a look at >>>> the software landscape , there is extremely variation out there, why you >>>> think Pharo is immune to that ? >>>> >>>> On Fri, Dec 26, 2014 at 8:14 PM, Sven Van Caekenberghe <[email protected]> >>>> wrote: >>>> >>>>> >>>>> > On 26 Dec 2014, at 17:42, stepharo <[email protected]> wrote: >>>>> > >>>>> > + 10000 >>>>> > >>>>> > Debugging the rendering loops of Athens was such an example. In Bloc >>>>> I get some race conditions with MC forked process... another fun one. >>>>> > Let people decide!!! >>>>> > >>>>> > Doru I DO NOT WANT TO LEARN WHAT I DO NOT WANT TO LEARN! >>>>> > I WANT to DECIDE WHEN. I control my agenda and my own schedule and >>>>> my list is huge. >>>>> >>>>> OK, I understand, but how is this different from any other radical >>>>> changes that we did ? >>>>> >>>>> When we introduced the Eye inspectors we did not offer two options at >>>>> the same time (and I can give 10s of examples). So what is best, we all >>>>> together use and make the best tools, or we all work with different tools >>>>> ? >>>>> >>>>> > Stef >>>>> >> Doru, >>>>> >> >>>>> >> I think your intention is a good one but slightly misplaced. I >>>>> really like the idea of GTInspector. It surely is a great tool and maybe >>>>> I'll start to build my own inspector on my kind of things. >>>>> >> To me the difference is between "motivated to do" or "forced to >>>>> do". Most of the time we are trying hard to solve our own problems. If in >>>>> that progress other problems are forced upon us we get easily distracted >>>>> and frustrated. The same goes for new tools. If I'm forced to use these it >>>>> just means I have to deal with it first and only then I'm allowed to deal >>>>> with my own problem. As it was in that special case the bug in nautilus >>>>> and >>>>> the new inspector made me shy away from developing something in 4.0 and >>>>> now >>>>> I'm back on 3.0. >>>>> >> >>>>> >> So I think the only possibility is to "offer" a new way of doing >>>>> things and give people time to adjust. >>>>> >> >>>>> >> Norbert >>>>> >> >>>>> >>> Am 26.12.2014 um 13:18 schrieb Tudor Girba <[email protected]>: >>>>> >>> >>>>> >>> Hi, >>>>> >>> >>>>> >>> I think there must be a misunderstanding. >>>>> >>> >>>>> >>> There can be a good reason for having a basic inspector around, >>>>> but I think the reason is not because people cannot choose what to use. >>>>> >>> >>>>> >>> There is a toggle to enable/disable the GTInspector. But, even >>>>> without it, the main feature of the GTInspector is exactly to be extended >>>>> the way people want and not impose a fixed way. This is completely >>>>> different from what existed before. In fact, half a year ago there was no >>>>> problem that people could neither choose nor extend anything. In the >>>>> meantime, we can extend our workflows significantly. Adding the various >>>>> flavors of browsing objects is perhaps a couple of lines long and each of >>>>> us can tweak it because there is no higher entity that should decide >>>>> anymore. >>>>> >>> >>>>> >>> What I cannot quite grasp is that while we pride ourselves with >>>>> working on a reflective language, when we have reflective tools, we seem >>>>> to >>>>> not be able to take half an hour to build the tool that fits our needs. I >>>>> am still wondering what is needed to improve this. I think that it's a >>>>> problem of exercise or of communication, but it seems that just providing >>>>> the examples that I linked before is not enough and most people look at >>>>> the >>>>> inspector still as a black box tool. I will try to work on a tutorial to >>>>> see if it gets better, but do you find the moldability proposition not >>>>> valuable or just unclear? >>>>> >>> >>>>> >>> But, as I said, there can still be a valid reason to enable a >>>>> basic inspector that relies on a minimal of libraries (so, definitely not >>>>> the Spec one) for the same reason we have an emergency debugger. >>>>> >>> >>>>> >>> Cheers, >>>>> >>> Doru >>>>> >>> >>>>> >>> >>>>> >>> On Thu, Dec 25, 2014 at 11:43 AM, stepharo <[email protected]> >>>>> wrote: >>>>> >>> I will add basicInspect in Object so that we can get access to the >>>>> old inspector. >>>>> >>> I like that people can choose their tools! >>>>> >>> I mentioned that 20 times but people do not care apparently. >>>>> >>> >>>>> >>> Stef >>>>> >>> >>>>> >>> Le 23/12/14 11:50, Norbert Hartl a écrit : >>>>> >>> >>>>> >>> Is there a way to get the old tools via shortcut? >>>>> >>> >>>>> >>> I started something new with pharo 4.0 today. I discovered a bug >>>>> in Nautilus where every rename or deletion of a method raises a debugger. >>>>> I >>>>> tried finding the bug but struggled because to me the new inspector is >>>>> really confusing. If I "just" want to unfold a few levels of references to >>>>> get a glimpse of the structure the new tool prevents me from doing that. >>>>> There is just to much information in this window and too much happening to >>>>> me. >>>>> >>> To me it looks like a power tool you need to get used to. So it is >>>>> probably not the best tool for simple tasks and people new to this >>>>> environment might be overwhelmed. At least I would like to be able to use >>>>> the old tools. >>>>> >>> >>>>> >>> Norbert >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> -- >>>>> >>> www.tudorgirba.com >>>>> >>> >>>>> >>> "Every thing has its own flow" >>>>> >> >>>>> > >>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >> >> > -- www.tudorgirba.com "Every thing has its own flow"
