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

Re: [Pharo-dev] Old inspector and explorer

by Tudor Girba

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 <kilon.alios(a)gmail.com> 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 <sven(a)stfx.eu> > wrote: > >> >> > On 26 Dec 2014, at 17:42, stepharo <stepharo(a)free.fr> 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 <tudor(a)tudorgirba.com>: >> >>> >> >>> 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 <stepharo(a)free.fr> 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"

Dec. 26, 2014

Re: [Pharo-dev] Old inspector and explorer

by kilon alios

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 <sven(a)stfx.eu> wrote: > > > On 26 Dec 2014, at 17:42, stepharo <stepharo(a)free.fr> 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 <tudor(a)tudorgirba.com>: > >>> > >>> 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 <stepharo(a)free.fr> 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" > >> > > > > >

Dec. 26, 2014

Re: [Pharo-dev] Old inspector and explorer

by Nicolai Hess

2014-12-26 13:18 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > 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? > I think this is pretty clear and we have already many examples on how to extend the inspector (marcus made some great addition for the compiled method view (source code / bytecde / block scope trees) I don't think "inspector as a black box tool" is the problem, eye inspector has this possibility and there were already some "special" views used. But sometimes I just want one tool to inspect or explore an object, without multiple scrolling pages, maybe I am just used to it. > > 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 > > >

Dec. 26, 2014

Re: [Pharo-dev] Old inspector and explorer

by Sven Van Caekenberghe

> On 26 Dec 2014, at 17:42, stepharo <stepharo(a)free.fr> 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 <tudor(a)tudorgirba.com>: >>> >>> 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 <stepharo(a)free.fr> 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" >> >

Dec. 26, 2014

Re: [Pharo-dev] Fwd: regression of NaN comparison

by ClÃ©ment Bera

Hello, It does not happen with the Cog VM nor with older Pharo VM. It's a VM bug and it's specific to the Pharo-VM fork. Most probably it's because of the float refactoring for Smallfloat some stuff got incorrectly merged. Please consider writing a test for that in FloatTest and make a slice for Pharo if you have some time. 2014-12-26 18:35 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > > ---------- Forwarded message ---------- > From: Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > Date: 2014-12-26 16:52 GMT+01:00 > Subject: regression of NaN comparison > To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> > > > I downloaded latest Pharo4.0-mac.zip from https://ci.inria.fr/pharo/ > and I experienced a resurgence of this old bug: > > 2<Float nan. > > This is not one of the errors reported in the CI server. > Any clue? > >

Dec. 26, 2014

Re: [Pharo-dev] trouble with latest PharoLauncher on windows

by Nicolai Hess

try to copy a pharov30.sources into the installation directory and of course, you can run the pharolauncher.image with every other vm (installing from Installing from http://files.pharo.org/platform/Pharo3.0-win.zip for example). nicolai 2014-12-26 17:41 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > > I am on a new computer for the xmas period and trying to install > PharoLauncher > > On Windows 7 Home Premium SP1 64bit, I downloaded > > https://ci.inria.fr/pharo-contribution/job/PharoLauncher-Win-Package/lastSu… > > and ran the installer. First as a numal user escalating to Administative > privileges, then again after logging in as an Administrator and running the > installer. > > When I start "Pharo" from the menu bar, I see "pharo.exe" in the task list > running at 13%, but nothing shows on the screen. > > The following shows in stderr file... > > [31m==== Startup Error: Error: Can't find the requested origin > [0mWindowsResolver(PlatformResolver)>>cantFindOriginError > WindowsResolver(PlatformResolver)>>directoryFromEnvVariableNamed: in > Block: directoryFromEnvVariableNamed: var1... > WindowsResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: in > Block: [31mMessageNotUnderstood: receiver of "doSemanticAnalysisIn:" is nil > [0mUndefinedObject(Object)>>doesNotUnderstand: #doSemanticAnalysisIn: > ASTCache>>at: in Block: at: var1... > ASTCache(Dictionary)>>at:ifAbsentPut: in Block: [31mMessageNotUnderstood: > receiver of "doSemanticAnalysisIn:" is nil > [0mUndefinedObject(Object)>>doesNotUnderstand: #doSemanticAnalysisIn: > ASTCache>>at: in Block: at: var1... > ASTCache(Dictionary)>>at:ifAbsentPut: in Block: [31mMessageNotUnderstood: > receiver of "doSemanticAnalysisIn:" is nil > [0mUndefinedObject(Object)>>doesNotUnderstand: #doSemanticAnalysisIn: > > with the last couple of lines repeating many times. > > Installing from http://files.pharo.org/platform/Pharo3.0-win.zip > does work okay, but I can't live without PharoLauncher. > > Its too late to investigate further on it now and it may be a few days > before I get back to it. Any pointers appreciated. > > cheers -ben >

Dec. 26, 2014

Fwd: regression of NaN comparison

by Nicolas Cellier

---------- Forwarded message ---------- From: Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> Date: 2014-12-26 16:52 GMT+01:00 Subject: regression of NaN comparison To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> I downloaded latest Pharo4.0-mac.zip from https://ci.inria.fr/pharo/ and I experienced a resurgence of this old bug: 2<Float nan. This is not one of the errors reported in the CI server. Any clue?

Dec. 26, 2014

Re: [Pharo-dev] [Ann] a short Bloc demo

by stepharo

Le 25/12/14 15:46, Peter Uhnak a Ã©crit : > This look really interesting! However is there any diagram showing how > all the components (morphic, athens, spec, bloc, or even glamour and > roassal) work together? At least to me it feels that there is some > sort of overlapping. Is bloc replacing morphic? Bloc is a core graphical frameworks. it rethinks - rendering - event handling - view composition Bloc is composed about a low-level: - morphs + event + views Then on top of it we will have Bloc-Widgets valueModel + (spec unsure but we want the same composibility/reuse) + bloc-core Bloc uses Athens. The goal is to replace Morphic (a framework) Glamour is on top. Roassal could reuse bloc-core. Stef > > Peter > ------------------------------------------------------------------------ > From: stepharo <mailto:stepharo@free.fr> > Sent: â12/â25/â2014 11:51 AM > To: Pharo Development List <mailto:pharo-dev@lists.pharo.org> > Subject: Re: [Pharo-dev] [Ann] a short Bloc demo > > > > On some point, you will need to have some functional widgets. > Exact and since there is no magic we will start to write them. We > started to write a radio button and this led to a redesin of the core > and now we should be ready to try again. > > If you are not afraid about strange/bad/circumvoluted code have a look > at the code of PluggableButtonMorph (not talking about tableLayout > intrincaties). > So we will not copy Morphic! It will take time and if people want to > help they will be able to improve their future. > > Stef > > > > Can we start to build our own UI using Bloc? > > > > Cheers, > > Alexandre > > > > > >> On Dec 25, 2014, at 11:33 AM, Alain Plantec > <alain.plantec(a)yahoo.com> wrote: > >> > >> > >>> On 25 Dec 2014, at 10:31, stepharo <stepharo(a)free.fr> wrote: > >>> > >>> > >>> Le 25/12/14 03:04, Ben Coman a Ã©crit : > >>>> Really nice to see your progress. Now do you have some sketches > that show how it relates to the components of the existing Morphic? > What is being disposed of, what reimplemented, what ported? > >> yes, almost everything is new or rewritten and you are right, its > time to write documentation. > >> Now, there is one well identified issue. > >> Athens is used to render everything except > >> the Morphic world. > >> This is cool but at the end of the rendering, the vm Form based > display is used by wrappers : > >> see in TBlAthensWrapper>>unprotectedFullDrawOn: > >> ---- > >> self surface displayOnMorphicCanvas: aCanvas at: self position > >> ââ > >> It slows down the rendering very much. > >> what would be cool would be to have a native Athens/Cairo vm > display to really > >> benefit from Athens. > >> > >> Cheers > >> Alain > >> > >> > >>> I'm writing class comments and soon a chapter. But it takes time > because I have to also do a bit of reverse engineering. > >>> Now Bloc does not relate to Morphic :) Everything is rewritten > from scratch and we will rewrite everything. > >>> We will try to reuse Spec. > >>> Now for default Morphic, rewritting all the morphs to use Athens > >>> is a huge tasks considered the current logic of certain morphic > elements > >>> Since Bloc is fully athens-based, it may be better to only work on > Bloc. > >>> Now the trick is that we can use the morphic elements. > >>>> This would really help to understand where contributions might be > useful. > >>>> > >>>> > >>>> btw, with Build 40419, "ConfigurationOfBloc load" warns that > >>>> it depends on BlEllipseShape which must be resolved before > #drawOn: and #drawOnAthensCanvas: can be resolved. > >>> Yes this is normal, you should load bleedingEdge. > >>>> "ConfigurationOfBlock loadDevelopment" works fine. > >>>> > >>>> cheer -ben > >>>> > >>>> Sven Van Caekenberghe wrote: > >>>>> Yes, a nice X-Mas present ! > >>>>> > >>>>>> On 24 Dec 2014, at 15:41, Alexandre Bergel > <alexandre.bergel(a)me.com> wrote: > >>>>>> > >>>>>> Wow! Impressive!!! > >>>>>> > >>>>>> Alexandre > >>>>>> > >>>>>> > >>>>>>> On Dec 24, 2014, at 3:19 PM, Alain Plantec > <alain.plantec(a)yahoo.com> wrote: > >>>>>>> > >>>>>>> Hello all, > >>>>>>> > >>>>>>> Iâve just uploaded a small demo of Bloc. > >>>>>>> http://vimeo.com/115336678 > >>>>>>> > >>>>>>> > >>>>>>> Cheers > >>>>>>> Alain > >>>>>>> > >>>>>> -- > >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >>>>>> Alexandre Bergel http://www.bergel.eu > >>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>>> > >>> > >> > >

Dec. 26, 2014

Re: [Pharo-dev] Old inspector and explorer

by stepharo

+ 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. 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 <tudor(a)tudorgirba.com >> <mailto:tudor@tudorgirba.com>>: >> >> 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 <stepharo(a)free.fr >> <mailto:stepharo@free.fr>> 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 <http://www.tudorgirba.com/> >> >> "Every thing has its own flow" >

Dec. 26, 2014

trouble with latest PharoLauncher on windows

by Ben Coman

I am on a new computer for the xmas period and trying to install PharoLauncher On Windows 7 Home Premium SP1 64bit, I downloaded https://ci.inria.fr/pharo-contribution/job/PharoLauncher-Win-Package/lastSu… and ran the installer. First as a numal user escalating to Administative privileges, then again after logging in as an Administrator and running the installer. When I start "Pharo" from the menu bar, I see "pharo.exe" in the task list running at 13%, but nothing shows on the screen. The following shows in stderr file... [31m==== Startup Error: Error: Can't find the requested origin [0mWindowsResolver(PlatformResolver)>>cantFindOriginError WindowsResolver(PlatformResolver)>>directoryFromEnvVariableNamed: in Block: directoryFromEnvVariableNamed: var1... WindowsResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: in Block: [31mMessageNotUnderstood: receiver of "doSemanticAnalysisIn:" is nil [0mUndefinedObject(Object)>>doesNotUnderstand: #doSemanticAnalysisIn: ASTCache>>at: in Block: at: var1... ASTCache(Dictionary)>>at:ifAbsentPut: in Block: [31mMessageNotUnderstood: receiver of "doSemanticAnalysisIn:" is nil [0mUndefinedObject(Object)>>doesNotUnderstand: #doSemanticAnalysisIn: ASTCache>>at: in Block: at: var1... ASTCache(Dictionary)>>at:ifAbsentPut: in Block: [31mMessageNotUnderstood: receiver of "doSemanticAnalysisIn:" is nil [0mUndefinedObject(Object)>>doesNotUnderstand: #doSemanticAnalysisIn: with the last couple of lines repeating many times. Installing from http://files.pharo.org/platform/Pharo3.0-win.zip does work okay, but I can't live without PharoLauncher. Its too late to investigate further on it now and it may be a few days before I get back to it. Any pointers appreciated. cheers -ben

Dec. 26, 2014