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" >> > >
