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

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40428 Home: https://github.com/pharo-project/pharo-core

Jan. 1, 2015

[pharo-project/pharo-core] b4d557: 40428

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: b4d557e84786cdf79fb362b73b4d92193b5f4385 https://github.com/pharo-project/pharo-core/commit/b4d557e84786cdf79fb362b7… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-01-01 (Thu, 01 Jan 2015) Changed paths: R SUnit-Core.package/EqualityTester.class/instance/as yet unclassified/resultFor_.st A SUnit-Core.package/EqualityTester.class/instance/operation/resultFor_.st R SUnit-Core.package/HashTester.class/instance/as yet unclassified/resultFor_.st A SUnit-Core.package/HashTester.class/instance/operation/resultFor_.st M SUnit-Core.package/PrototypeTester.class/README.md R SUnit-Core.package/PrototypeTester.class/class/as yet unclassified/defaultRuns.st R SUnit-Core.package/PrototypeTester.class/class/as yet unclassified/with_.st A SUnit-Core.package/PrototypeTester.class/class/default/defaultRuns.st A SUnit-Core.package/PrototypeTester.class/class/instance creation/with_.st A SUnit-Core.package/PrototypeTester.class/instance/accessing/prototype.st A SUnit-Core.package/PrototypeTester.class/instance/accessing/prototype_.st R SUnit-Core.package/PrototypeTester.class/instance/as yet unclassified/prototype.st R SUnit-Core.package/PrototypeTester.class/instance/as yet unclassified/prototype_.st R SUnit-Core.package/PrototypeTester.class/instance/as yet unclassified/result.st A SUnit-Core.package/PrototypeTester.class/instance/operation/result.st A SUnit-Core.package/PrototypeTester.class/instance/operation/resultFor_.st M SUnit-Core.package/TestResource.class/instance/accessing/description.st M SUnit-Core.package/TestResource.class/instance/accessing/name.st M SUnit-Core.package/TestResource.class/instance/accessing/name_.st M SUnit-Core.package/TestResource.class/instance/testing/isUnavailable.st M SUnit-Core.package/TestSuite.class/instance/running/resourceClass.st M SUnit-Core.package/TestSuite.class/instance/running/run_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script428.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40428.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40428 14658 cleaning/commenting SUnit classes https://pharo.fogbugz.com/f/cases/14658 http://files.pharo.org/image/40/40428.zip

Jan. 1, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40427 Home: https://github.com/pharo-project/pharo-core

Jan. 1, 2015

[pharo-project/pharo-core] b35f60: 40427

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: b35f60be751d5b1dace7238a4a17b25f7c5d1415 https://github.com/pharo-project/pharo-core/commit/b35f60be751d5b1dace7238a… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-01-01 (Thu, 01 Jan 2015) Changed paths: M Files.package/SourceFileArray.class/instance/source code management/changeRecordsFrom_className_isMeta_do_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script427.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40427.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Tool-Base.package/PharoCommonTools.class/README.md A Tool-Base.package/PharoCommonTools.class/class/cleanUp/shutDown_.st A Tool-Base.package/PharoCommonTools.class/class/initialization/initialize.st A Tool-Base.package/PharoCommonTools.class/class/settings/settingsOn_.st A Tool-Base.package/PharoCommonTools.class/definition.st A Tool-Base.package/PharoCommonTools.class/instance/cleanup/cleanUp.st A Tool-Base.package/PharoCommonTools.class/instance/initialization/initialize.st A Tool-Base.package/PharoCommonTools.class/instance/registration/recentBrowserTools.st A Tool-Base.package/PharoCommonTools.class/instance/registration/recentChangeSorterTools.st A Tool-Base.package/PharoCommonTools.class/instance/registration/recentDebuggerTools.st A Tool-Base.package/PharoCommonTools.class/instance/registration/recentFileListTools.st A Tool-Base.package/PharoCommonTools.class/instance/registration/recentInspectorTools.st A Tool-Base.package/PharoCommonTools.class/instance/registration/recentMessageListTools.st A Tool-Base.package/PharoCommonTools.class/instance/registration/recentToolsFor_.st A Tool-Base.package/PharoCommonTools.class/instance/registration/recentVersionBrowserTools.st A Tool-Base.package/PharoCommonTools.class/instance/registration/recentWorkspaceTools.st A Tool-Base.package/PharoCommonTools.class/instance/registration/register_as_.st A Tool-Base.package/PharoCommonTools.class/instance/registration/remove_.st A Tool-Base.package/PharoCommonTools.class/instance/tools/browserTool.st A Tool-Base.package/PharoCommonTools.class/instance/tools/browserTool_.st A Tool-Base.package/PharoCommonTools.class/instance/tools/changeSorterTool.st A Tool-Base.package/PharoCommonTools.class/instance/tools/changeSorterTool_.st A Tool-Base.package/PharoCommonTools.class/instance/tools/debuggerTool.st A Tool-Base.package/PharoCommonTools.class/instance/tools/debuggerTool_.st A Tool-Base.package/PharoCommonTools.class/instance/tools/fileListTool.st A Tool-Base.package/PharoCommonTools.class/instance/tools/fileListTool_.st A Tool-Base.package/PharoCommonTools.class/instance/tools/inspectorTool.st A Tool-Base.package/PharoCommonTools.class/instance/tools/inspectorTool_.st A Tool-Base.package/PharoCommonTools.class/instance/tools/messageListTool.st A Tool-Base.package/PharoCommonTools.class/instance/tools/messageListTool_.st A Tool-Base.package/PharoCommonTools.class/instance/tools/versionBrowserTool.st A Tool-Base.package/PharoCommonTools.class/instance/tools/versionBrowserTool_.st A Tool-Base.package/PharoCommonTools.class/instance/tools/workspaceTool.st A Tool-Base.package/PharoCommonTools.class/instance/tools/workspaceTool_.st M Tool-Base.package/extension/SmalltalkImage/instance/tools.st Log Message: ----------- 40427 14643 find records for classcomment changes in SourceFileArray https://pharo.fogbugz.com/f/cases/14643 10529 ToolRegistry need to support multiple registrations per tool https://pharo.fogbugz.com/f/cases/10529 http://files.pharo.org/image/40/40427.zip

Jan. 1, 2015

Re: [Pharo-dev] GLMGaussianBlurBrickRenderer

by Alexandre Bergel

Wow, impressive!!! Alexandre > On Dec 31, 2014, at 6:13 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > I saw this > GLMGaussianBlurBrickRenderer class #example > nice! > > And once I did something similiar, a Morph that blurres the underlaying display. > > But instead of doing a convolution (convolve image with kernel) by hand, > I convolve the kernel with the image by using copyBits from the BitBlt: > > | form temp dest from to | > form := Display contentsOfArea: self bounds. > temp := Form extent: self extent depth: 32. > temp getCanvas fillColor: Color white darker. > dest := Form extent: self extent depth: 32. > dest getCanvas fillColor: Color white darker. > to := kernel size // 2. > from := -1 * to. > (from to: to) do: [ :i | temp copyBits: form at: i @ 0 translucent: (kernel at: i + to + 1) ]. > (from to: to) do: [ :i | dest copyBits: temp at: 0 @ i translucent: (kernel at: i + to + 1) ]. > aCanvas drawImage: dest at: self bounds topLeft. > > > <PharoScreenshot.4.png><BlurringMorph.st> -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 1, 2015

Re: [Pharo-dev] Old inspector and explorer

by Tudor Girba

Hi ClÃ©ment, Thanks for reviewing. I'm glad it fits your needs. Indeed, my implementation is naive and was intended to enable quick review. We will iterate over it. Cheers, Doru On Thu, Jan 1, 2015 at 10:52 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hello Doru, > > Yes this works for me. > > There are still little details like when you inspect an object with > instance variable and variable fields, the variable fields are shown before > the instance variables as 01 is before any string in alphabetical order but > that's minor. > > Thank you very much. I won't have to switch anymore to the old inspector > for closures and contexts. > > Best, > > Clement > > > 2015-01-01 9:57 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > >> Hi ClÃ©ment, >> >> Thanks for the extra pointers. I tried to dig a little and I now added >> dynamic variables into the Raw view. >> >> Take a look at the latest version (GT-Inspector-TudorGirba.277) and let >> me know if it fits your needs. >> >> Cheers, >> Doru >> >> >> >> On Wed, Dec 24, 2014 at 12:22 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> >> wrote: >> >>> On Dec 23, 2014 9:36 PM, "Tudor Girba" <tudor(a)tudorgirba.com> wrote: >>> >>>> Hi Clement, >>>> >>>> Thanks for the detailed feedback. This is useful. Btw, did you try to >>>> extend this view yourself? >>>> >>> >>> Well I added other views (mostly roassal views) but not this one. >>> >>>> >>>> It would actually be more useful to come from you given that you know >>>> what you want to see and then we iterate. Here is a starting point: >>>> >>>> http://www.humane-assessment.com/blog/extending-variables-shown-in-gtinspec… >>>> >>>> If not, then could you advise me as to how to get the internal state >>>> independent of the layout? >>>> >>> >>> I think the issue is that #gtInspectorItemsIn: is in Collection whereas >>> it should be on all objects that answers true to: "object class layout >>> isVariable". >>> >>> One needs to check this method works on all variable objects (WordArray, >>> ByteArray, CompiledMethod and WeakArray). >>> >>> But I don't know how to change that in gtInspector. >>> >>> >>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> >>>> On Tue, Dec 23, 2014 at 8:09 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> >>>> wrote: >>>> >>>>> >>>>> >>>>> 2014-12-23 19:37 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>>>> >>>>>> >>>>>> > On 23 Dec 2014, at 19:13, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>>>> > >>>>>> > Hi, >>>>>> > >>>>>> > What does a basic inspector mean for you? It's not a rhetorical >>>>>> question. I am actually interested in what you miss. >>>>>> >>>>>> What took you so long, Doru ? Haha ;-) >>>>>> >>>>>> Seriously, I think that the 'Raw' tab of GT-Inspector actually covers >>>>>> the key old inspector *and* inspector behaviour quite well. I guess that >>>>>> was/is also the design goal. >>>>>> >>>>> >>>>> No it covers only part of it. See below. >>>>> >>>>>> >>>>>> The rest is mostly a reaction to something new and unfamiliar. GT >>>>>> takes some getting used to. >>>>>> >>>>>> But we need concrete use cases that give people trouble to be able to >>>>>> improve. >>>>>> >>>>> >>>>> My use case is simple, I have variable objects such as Context or >>>>> BlockClosure, and when I inspect them I cannot see their variable fields >>>>> with GTInspector. The old basicInspector allows me to see these fields. >>>>> >>>>> Example: >>>>> >>>>> | t | >>>>> t := 1. >>>>> [ t ] inspect >>>>> >>>>> GT visualisation: >>>>> >>>>> [image: Images intÃ©grÃ©es 1] >>>>> >>>>> Old visualisation: >>>>> >>>>> [image: Images intÃ©grÃ©es 2] >>>>> >>>>> In the old visualisation I could see the 1 with its value. >>>>> >>>>> Same problem with contexts. In the old basicInspector I could see all >>>>> the stack fields, I can't see them anymore. >>>>> >>>>> Example: >>>>> >>>>> [image: Images intÃ©grÃ©es 3] >>>>> >>>>> [image: Images intÃ©grÃ©es 4] >>>>> >>>>> Therefore I need the old inspector to inspect Context and >>>>> BlockClosure. I talk about Context and BlockClosure because they are the >>>>> most annoying in my workflows, but the problem is more generic. GTInspector >>>>> does not automatically detect the object's layout, on the contrary to the >>>>> old inspector. Therefore when I do: >>>>> >>>>> Object variableSubclass: #MyVariableObject >>>>> instanceVariableNames: '' >>>>> classVariableNames: '' >>>>> category: 'Banana' >>>>> >>>>> (MyVariableObject new: 3) inspect >>>>> >>>>> => I can't see any of the fields. >>>>> >>>>> Same issue with variableByteSubclass and co. And Context and >>>>> BlockClosure falls into this category of objects (they're >>>>> variableSubclasses). >>>>> >>>>> To me a basicInspector is an inspector that allows you to see the ALL >>>>> the internal state of an object without hiding or changing the names of >>>>> fields, and I do not have that (right now) with GTInspector on the contrary >>>>> to the old inspectors. >>>>> >>>>> Note: don't mistake me, I use GTInspector for most of my daily work, I >>>>> like it and it improved my productivity. There are just a few cases that do >>>>> not work where I need to switch to the old inspector, mostly the ones I've >>>>> just described. >>>>> >>>>> In addition, a visualization of tempName -> tempValue for inspectors >>>>> on context is missing but that's a detail. >>>>> >>>>> > Doru >>>>>> > >>>>>> > On Tue, Dec 23, 2014 at 6:06 PM, ClÃ©ment Bera < >>>>>> bera.clement(a)gmail.com> wrote: >>>>>> > Yes. >>>>>> > >>>>>> > World Menu >> Settings >> Glamourous toolkit >>>>>> > >>>>>> > then you can uncheck GTInspector and GTPlayground. >>>>>> > >>>>>> > I also need to do that very often as GTInspector does not have a >>>>>> basic inspector. >>>>>> > >>>>>> > 2014-12-23 11:50 GMT+01:00 Norbert Hartl <norbert(a)hartl.name>: >>>>>> > 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" >> > > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 1, 2015

Re: [Pharo-dev] Smalltalk Reflections Podcast

by Marcus Denker

> On 31 Dec 2014, at 16:05, davidbuck <david(a)simberon.com> wrote: > > Thanks Stef. One possibility is to get a few Pharo developers together to > have a short round-table talking about Pharo and we'd insert that as a > segment into the podcast. We're open to all sorts of possibilities. > > I am interested in helping with this, too. Marcus

Jan. 1, 2015

Re: [Pharo-dev] Old inspector and explorer

by ClÃ©ment Bera

Hello Doru, Yes this works for me. There are still little details like when you inspect an object with instance variable and variable fields, the variable fields are shown before the instance variables as 01 is before any string in alphabetical order but that's minor. Thank you very much. I won't have to switch anymore to the old inspector for closures and contexts. Best, Clement 2015-01-01 9:57 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi ClÃ©ment, > > Thanks for the extra pointers. I tried to dig a little and I now added > dynamic variables into the Raw view. > > Take a look at the latest version (GT-Inspector-TudorGirba.277) and let me > know if it fits your needs. > > Cheers, > Doru > > > > On Wed, Dec 24, 2014 at 12:22 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> > wrote: > >> On Dec 23, 2014 9:36 PM, "Tudor Girba" <tudor(a)tudorgirba.com> wrote: >> >>> Hi Clement, >>> >>> Thanks for the detailed feedback. This is useful. Btw, did you try to >>> extend this view yourself? >>> >> >> Well I added other views (mostly roassal views) but not this one. >> >>> >>> It would actually be more useful to come from you given that you know >>> what you want to see and then we iterate. Here is a starting point: >>> >>> http://www.humane-assessment.com/blog/extending-variables-shown-in-gtinspec… >>> >>> If not, then could you advise me as to how to get the internal state >>> independent of the layout? >>> >> >> I think the issue is that #gtInspectorItemsIn: is in Collection whereas >> it should be on all objects that answers true to: "object class layout >> isVariable". >> >> One needs to check this method works on all variable objects (WordArray, >> ByteArray, CompiledMethod and WeakArray). >> >> But I don't know how to change that in gtInspector. >> >> >> >>> Cheers, >>> Doru >>> >>> >>> >>> On Tue, Dec 23, 2014 at 8:09 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> >>> wrote: >>> >>>> >>>> >>>> 2014-12-23 19:37 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>>> >>>>> >>>>> > On 23 Dec 2014, at 19:13, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>>> > >>>>> > Hi, >>>>> > >>>>> > What does a basic inspector mean for you? It's not a rhetorical >>>>> question. I am actually interested in what you miss. >>>>> >>>>> What took you so long, Doru ? Haha ;-) >>>>> >>>>> Seriously, I think that the 'Raw' tab of GT-Inspector actually covers >>>>> the key old inspector *and* inspector behaviour quite well. I guess that >>>>> was/is also the design goal. >>>>> >>>> >>>> No it covers only part of it. See below. >>>> >>>>> >>>>> The rest is mostly a reaction to something new and unfamiliar. GT >>>>> takes some getting used to. >>>>> >>>>> But we need concrete use cases that give people trouble to be able to >>>>> improve. >>>>> >>>> >>>> My use case is simple, I have variable objects such as Context or >>>> BlockClosure, and when I inspect them I cannot see their variable fields >>>> with GTInspector. The old basicInspector allows me to see these fields. >>>> >>>> Example: >>>> >>>> | t | >>>> t := 1. >>>> [ t ] inspect >>>> >>>> GT visualisation: >>>> >>>> [image: Images intÃ©grÃ©es 1] >>>> >>>> Old visualisation: >>>> >>>> [image: Images intÃ©grÃ©es 2] >>>> >>>> In the old visualisation I could see the 1 with its value. >>>> >>>> Same problem with contexts. In the old basicInspector I could see all >>>> the stack fields, I can't see them anymore. >>>> >>>> Example: >>>> >>>> [image: Images intÃ©grÃ©es 3] >>>> >>>> [image: Images intÃ©grÃ©es 4] >>>> >>>> Therefore I need the old inspector to inspect Context and BlockClosure. >>>> I talk about Context and BlockClosure because they are the most annoying in >>>> my workflows, but the problem is more generic. GTInspector does not >>>> automatically detect the object's layout, on the contrary to the old >>>> inspector. Therefore when I do: >>>> >>>> Object variableSubclass: #MyVariableObject >>>> instanceVariableNames: '' >>>> classVariableNames: '' >>>> category: 'Banana' >>>> >>>> (MyVariableObject new: 3) inspect >>>> >>>> => I can't see any of the fields. >>>> >>>> Same issue with variableByteSubclass and co. And Context and >>>> BlockClosure falls into this category of objects (they're >>>> variableSubclasses). >>>> >>>> To me a basicInspector is an inspector that allows you to see the ALL >>>> the internal state of an object without hiding or changing the names of >>>> fields, and I do not have that (right now) with GTInspector on the contrary >>>> to the old inspectors. >>>> >>>> Note: don't mistake me, I use GTInspector for most of my daily work, I >>>> like it and it improved my productivity. There are just a few cases that do >>>> not work where I need to switch to the old inspector, mostly the ones I've >>>> just described. >>>> >>>> In addition, a visualization of tempName -> tempValue for inspectors on >>>> context is missing but that's a detail. >>>> >>>> > Doru >>>>> > >>>>> > On Tue, Dec 23, 2014 at 6:06 PM, ClÃ©ment Bera < >>>>> bera.clement(a)gmail.com> wrote: >>>>> > Yes. >>>>> > >>>>> > World Menu >> Settings >> Glamourous toolkit >>>>> > >>>>> > then you can uncheck GTInspector and GTPlayground. >>>>> > >>>>> > I also need to do that very often as GTInspector does not have a >>>>> basic inspector. >>>>> > >>>>> > 2014-12-23 11:50 GMT+01:00 Norbert Hartl <norbert(a)hartl.name>: >>>>> > 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" >

Jan. 1, 2015

Re: [Pharo-dev] Old inspector and explorer

by phil＠highoctane.be

yes yes yes! Le 25 dÃ©c. 2014 11:43, "stepharo" <stepharo(a)free.fr> a Ã©crit : > 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 >> >> >> >> >> > >

Jan. 1, 2015

Re: [Pharo-dev] Old inspector and explorer

by Tudor Girba

Hi ClÃ©ment, Thanks for the extra pointers. I tried to dig a little and I now added dynamic variables into the Raw view. Take a look at the latest version (GT-Inspector-TudorGirba.277) and let me know if it fits your needs. Cheers, Doru On Wed, Dec 24, 2014 at 12:22 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > On Dec 23, 2014 9:36 PM, "Tudor Girba" <tudor(a)tudorgirba.com> wrote: > >> Hi Clement, >> >> Thanks for the detailed feedback. This is useful. Btw, did you try to >> extend this view yourself? >> > > Well I added other views (mostly roassal views) but not this one. > >> >> It would actually be more useful to come from you given that you know >> what you want to see and then we iterate. Here is a starting point: >> >> http://www.humane-assessment.com/blog/extending-variables-shown-in-gtinspec… >> >> If not, then could you advise me as to how to get the internal state >> independent of the layout? >> > > I think the issue is that #gtInspectorItemsIn: is in Collection whereas it > should be on all objects that answers true to: "object class layout > isVariable". > > One needs to check this method works on all variable objects (WordArray, > ByteArray, CompiledMethod and WeakArray). > > But I don't know how to change that in gtInspector. > > > >> Cheers, >> Doru >> >> >> >> On Tue, Dec 23, 2014 at 8:09 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> >> wrote: >> >>> >>> >>> 2014-12-23 19:37 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>> >>>> >>>> > On 23 Dec 2014, at 19:13, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>> > >>>> > Hi, >>>> > >>>> > What does a basic inspector mean for you? It's not a rhetorical >>>> question. I am actually interested in what you miss. >>>> >>>> What took you so long, Doru ? Haha ;-) >>>> >>>> Seriously, I think that the 'Raw' tab of GT-Inspector actually covers >>>> the key old inspector *and* inspector behaviour quite well. I guess that >>>> was/is also the design goal. >>>> >>> >>> No it covers only part of it. See below. >>> >>>> >>>> The rest is mostly a reaction to something new and unfamiliar. GT takes >>>> some getting used to. >>>> >>>> But we need concrete use cases that give people trouble to be able to >>>> improve. >>>> >>> >>> My use case is simple, I have variable objects such as Context or >>> BlockClosure, and when I inspect them I cannot see their variable fields >>> with GTInspector. The old basicInspector allows me to see these fields. >>> >>> Example: >>> >>> | t | >>> t := 1. >>> [ t ] inspect >>> >>> GT visualisation: >>> >>> [image: Images intÃ©grÃ©es 1] >>> >>> Old visualisation: >>> >>> [image: Images intÃ©grÃ©es 2] >>> >>> In the old visualisation I could see the 1 with its value. >>> >>> Same problem with contexts. In the old basicInspector I could see all >>> the stack fields, I can't see them anymore. >>> >>> Example: >>> >>> [image: Images intÃ©grÃ©es 3] >>> >>> [image: Images intÃ©grÃ©es 4] >>> >>> Therefore I need the old inspector to inspect Context and BlockClosure. >>> I talk about Context and BlockClosure because they are the most annoying in >>> my workflows, but the problem is more generic. GTInspector does not >>> automatically detect the object's layout, on the contrary to the old >>> inspector. Therefore when I do: >>> >>> Object variableSubclass: #MyVariableObject >>> instanceVariableNames: '' >>> classVariableNames: '' >>> category: 'Banana' >>> >>> (MyVariableObject new: 3) inspect >>> >>> => I can't see any of the fields. >>> >>> Same issue with variableByteSubclass and co. And Context and >>> BlockClosure falls into this category of objects (they're >>> variableSubclasses). >>> >>> To me a basicInspector is an inspector that allows you to see the ALL >>> the internal state of an object without hiding or changing the names of >>> fields, and I do not have that (right now) with GTInspector on the contrary >>> to the old inspectors. >>> >>> Note: don't mistake me, I use GTInspector for most of my daily work, I >>> like it and it improved my productivity. There are just a few cases that do >>> not work where I need to switch to the old inspector, mostly the ones I've >>> just described. >>> >>> In addition, a visualization of tempName -> tempValue for inspectors on >>> context is missing but that's a detail. >>> >>> > Doru >>>> > >>>> > On Tue, Dec 23, 2014 at 6:06 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> >>>> wrote: >>>> > Yes. >>>> > >>>> > World Menu >> Settings >> Glamourous toolkit >>>> > >>>> > then you can uncheck GTInspector and GTPlayground. >>>> > >>>> > I also need to do that very often as GTInspector does not have a >>>> basic inspector. >>>> > >>>> > 2014-12-23 11:50 GMT+01:00 Norbert Hartl <norbert(a)hartl.name>: >>>> > 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"

Jan. 1, 2015