- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Bootstrap dependency, System-Announcements --> PragmaCollector

by stepharo

yes but we are focusing on bootstrap and we cannot do deep first :) Doing a pass on systemnavigation will help. And having the dependencies in the right order would help too. Le 10/9/15 23:01, Tudor Girba a Ã©crit : > I think SystemNavigation should essentially dissolve in the near > future. Moose used to have one of these some 10 years ago, and now all > queries are implemented as fluent APIs distributed throughout the > model classes. I would want the Pharo code model should move in the > same direction. > > Doru > > On Thu, Sep 10, 2015 at 8:29 PM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Pragma should not depend on SystemNavigation. The inverse > > > Le 10/9/15 19:44, Ben Coman a Ã©crit : > > On Fri, Sep 11, 2015 at 12:43 AM, Max Leske > <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > > On 10 Sep 2015, at 17:22, Ben Coman > <btc(a)openInWorld.com> wrote: > > The bootstrap-dependency graph and report [1] mark > dependency > System-Announcements --> PragmaCollector for pruning. > This is due to... > > SystemAnnouncer>>restoreAllNotifications > | collector | > self reset. > collector := PragmaCollector filter: [ :pragma | > pragma keyword = #systemEventRegistration ]. > collector reset. > collector do: [ :pragma | > pragma methodClass theNonMetaClass > perform: pragma selector ] > > Browsing around I came to understand that > PragmaCollector is useful as > a pragma cache, but here the collector is thrown away, > so that > facility is not needed. A key part is "collector > reset" which does... > self class allSystemPragmas > do: [:pragma | self addPragma: pragma] > > where the #addPragma: evaluates the initialize'd > #filter: block. Now > it seems that #allSystemPragmas might fit nicely on > Pragma rather than > PragmaCollector > such that the following should be equivalent... > > SystemAnnouncer>>restoreAllNotifications > | systemPragmas | > self reset. > systemPragmas := Pragma allSystemPragmas > collect: [ :pragma | > pragma keyword = #systemEventRegistration ]. > systemPragmas do: [ :pragma | > pragma methodClass theNonMetaClass > perform: pragma selector > > Cool. I like that better. > > However #allSystemPragmas depends on SystemNavigation, > so is it be > okay for Pragma to depend on SystemNavigation? > > Spontaneously Iâd say that SystemNavigation should depend > on Pragma or PragmaCollector for looking up pragmas, not > the other way around. > > So you mean something like... > > SystemAnnouncer>>restoreAllNotifications > self reset. > SystemNavigation allPragmasNamed: > #systemEventRegistration do: > [ :pragma | > pragma methodClass theNonMetaClass perform: > pragma selector ]. > > where... > > SystemNavigation>>allPragmasNamed: symbol do: aBlock > | systemPragmas | > systemPragmas := > self allSystemPragmas collect: [ :pragma | > pragma keyword > = symbol ]. > systemPragmas do: [ :pragma | > pragma methodClass theNonMetaClass perform: > pragma selector > > SystemNavigation>>allSystemPragmas > ^ (Array > streamContents: [:stream | > self allBehaviorsDo: [:behavior | > Pragma > withPragmasIn: behavior > do: [:pragma | stream nextPut: pragma]]]) > > cheers -ben > > > Actually, class side of Pragma has several #named:in: > like methods, so > something like the following would be neat... > SystemAnnouncer>>restoreAllNotifications > self reset. > Pragma allNamed: #systemEventRegistration do: > [ :pragma | > pragma methodClass theNonMetaClass > perform: pragma selector ]. > > > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

Sept. 11, 2015

[pharo-project/pharo-core]

by GitHub

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

Sept. 11, 2015

[pharo-project/pharo-core] 60d9f9: 50319

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 60d9f9a757251d663c2083e4779a8f62f477576d https://github.com/pharo-project/pharo-core/commit/60d9f9a757251d663c2083e4… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-11 (Fri, 11 Sep 2015) Changed paths: M ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/symbolic versions/stable_.st A ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version1185_.st A ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version1186_.st A ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version1214Moose51_.st M Rubric.package/RubAbstractTextArea.class/instance/initialize/plugFindReplace.st M Rubric.package/RubCursor.class/instance/submorphs-accessing/noteNewOwner_.st M Rubric.package/RubFindReplaceService.class/instance/accessing/textArea_.st M Rubric.package/RubFindReplaceService.class/instance/user-interface/newDialog.st M Rubric.package/RubFloatingEditorBuilder.class/instance/accessing/withEditedContentsDo_.st M Rubric.package/RubFloatingEditorBuilder.class/instance/private/buildEditor.st M Rubric.package/RubGhostTextDisplayer.class/instance/submorphs-accessing/noteNewOwner_.st M Rubric.package/RubHighlightSegmentMorph.class/instance/event handling/registerTextArea.st M Rubric.package/RubPluggableTextMorphExample.class/instance/view creation/open.st M Rubric.package/RubPrimarySelectionMorph.class/instance/event handling/registerTextArea.st M Rubric.package/RubScrolledTextMorph.class/instance/accessing/model_.st A Rubric.package/RubScrolledTextMorph.class/instance/event handling/whenLostFocus_.st R Rubric.package/RubScrolledTextMorph.class/instance/event handling/whenLostForcus_.st M Rubric.package/RubScrolledTextMorph.class/instance/initialize-release/initialize.st M Rubric.package/RubShoutStylerDecorator.class/instance/accessing/next_.st M Rubric.package/RubTextAreaExamples.class/class/examples/textFieldWithCRAction.st M Rubric.package/RubTextFieldMorph.class/instance/initialize-release/initialize.st M Rubric.package/RubTextSegmentMorph.class/instance/event handling/registerTextArea.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50318.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50319.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50318.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50319.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50319 16503 Remove senders of subscribe:send:to: in Rubric https://pharo.fogbugz.com/f/cases/16503 http://files.pharo.org/image/50/50319.zip

Sept. 11, 2015

Re: [Pharo-dev] chunk file format (unrecoverable changes)

by Martin Dias

On Thu, Sep 10, 2015 at 11:17 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > Now that this is fixed, should we (is it possible?) fix the changes file? > A script that replaces the "! !" by "! " in class comments should work. It's important to replace the ! mark by a space, but keep the byte positions of the strings. This is important, because the system recovers a method's source code by fetching it from the .changes (or .sources) file using the byte position where the source code was written (the sourcePointer in the trailer of the CompiledMethods). A concrete example: !OSTouchTwoFingersPinchInMoveEvent commentStamp: 'MerwanOuddane 5/11/2015 15:14' prior: 0! Two fingers are pinching in! ! <--- replace last ! by space I think this can work as a template for a script: fileStream := SourceFiles changesFileStream. fileStream resetToStart. <iterate over the fileStream and replace some !s> SourceFiles forceChangesToDisk. If somebody wants to take it... else I might do it during the weekend. Cheers, MArtin > > 2015-09-06 21:56 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > >> Do we have a documentation about the format of >> - class definitions >> - methods >> - class comments >> for the changes file ? >> >> I am asking because some entries are using two separator >> "! !" >> and some only one >> "!" >> And we have a problem with the "Recover lost changes" browser >> (https://pharo.fogbugz.com/f/cases/16498/unrecoverable-changes) >> and I am not sure if this is a bug on the code importer >> or if it is a bug on how we write changes to the changes file. >> >> >> nicolai >> >> >

Sept. 11, 2015

Re: [Pharo-dev] [Vm-dev] Re: issue with large file path on windows

by Nicolai Hess

2015-09-11 9:44 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > > > 2015-09-11 9:43 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > >> >> >> 2015-09-10 23:07 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >>> >>> Hi Nicolai, >>> >>> On Thu, Sep 10, 2015 at 1:17 PM, Nicolai Hess <nicolaihess(a)web.de> >>> wrote: >>> >>>> >>>> >>>> >>>> 2015-09-10 21:31 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >>>> >>>>> >>>>> Hi Nicolai, >>>>> >>>>> I'm a bit concerned that this is creating drift with the >>>>> "official" Cog source base at >>>>> http://www.squeakvm.org/svn/squeak/branches/Cog. Long filename >>>>> support for win32 was recently added by Marcel Taumel in May of this year. >>>>> Are you tracking that? How can we keep the sources harmonized? >>>>> >>>> >>>> Yes, I know, and I already asked on the ML if we can take that change or >>>> if it is not possible because we have already other changes (pharos >>>> file plugin >>>> provides addition attributes (the file permissions)). >>>> >>> >>> Esteban and I just harmonized this. I'm (almost correctly) generating >>> the plugin source such that one can define either PharoVM or not to chose >>> between the different versions. I say "almost" because I'm currently >>> spitting out >>> >>> #define PharoVM 0 >>> ... >>> #if PharoVM >>> >>> instead of >>> >>> #if !defined(PharoVM) >>> # define PharoVM 0 >>> #endif >>> ... >>> #if PharoVM >>> >>> but I'll fix it v soon. >>> >> >> OK, I'll try to copy marcels solution >> >> >>> >>> But I got no response, so I tried to adopt Marcels change. >>>> >>>> And I only found the change for sqWin32FilePrims.c, but missed the >>>> other change >>>> that is necessary in sqWin32Directory.c (and asked on the ML). In the >>>> meantime Marcel added this but I could not find >>>> the changed source, only an updated vm. >>>> Is this change already comitted? >>>> >>> >>> Yes, see >>> http://www.squeakvm.org/svn/squeak/branches/Cog/platforms/win32/vm/sqWin32D… >>> >> >> Ah, good. Now (I must be blind, but) I can not see the other change, >> shouldn't there >> be a "plugins" folder in Cog/platforms/win32/? >> Where are the changes to sqWin32FilePrims.c now? >> > > Ok, found it. It is in the trunk branch :) > No, wait, now I am confused. The change to sqWin32FilePrims.c is only in the trunk branch and the change to sqWin32Directory.c is only in the Cog branch. What branch includes the solution for both (sqWin32Directory.c and sqWin32FilePrims.c) and should be used for a merge into pharos vm repository? > > > >> >> >> >> >>> >>> I'm sorry I didn't see your message. Did you ask on vm-dev? >>> >> >> I am not sure, maybe I only send it in the squeak-dev list >> >> >>> >>> >>> >>>> I would love if someone else got this working. >>>> >>> >>> :-) I hear you :-) >>> >>> >>> >>>> >>>> nicolai >>>> >>>> >>>> >>>>> >>>>> On Sun, Aug 23, 2015 at 4:44 AM, Nicolai Hess <nicolaihess(a)web.de> >>>>> wrote: >>>>> >>>>>> For those who had problems with pharo on windows and github based >>>>>> repositories, >>>>>> I built a windows vm with support for long paths: >>>>>> >>>>>> >>>>>> https://drive.google.com/file/d/0B8yEahnuIem2bmxwdzJuUXFxVGM/view?usp=shari… >>>>>> >>>>>> >>>>>> For browsing directories with large paths (FileList or Inspect), >>>>>> you may need one additional change in the image (But I am not really >>>>>> sure about that) : >>>>>> >>>>>> DiskStore>>initialize >>>>>> super initialize. >>>>>> maxFileNameLength := Smalltalk vm maxFilenameLength ifNil: [ >>>>>> 32767 ]. >>>>>> >>>>>> >>>>>> please test and give feedback. >>>>>> >>>>>> This wasn't as easy as I thought, and I had to make some more changes >>>>>> for the file permissions (the stat-functions don't work for files >>>>>> with long paths). >>>>>> Please test other file/folder operations. >>>>>> >>>>>> >>>>>> nicolai >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> _,,,^..^,,,_ >>>>> best, Eliot >>>>> >>>>> >>>> >>>> >>> >>> >>> -- >>> _,,,^..^,,,_ >>> best, Eliot >>> >>> >> >

Sept. 11, 2015

Re: [Pharo-dev] [Vm-dev] Re: issue with large file path on windows

by Nicolai Hess

2015-09-11 9:43 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > > > 2015-09-10 23:07 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> >> Hi Nicolai, >> >> On Thu, Sep 10, 2015 at 1:17 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >>> >>> >>> >>> 2015-09-10 21:31 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >>> >>>> >>>> Hi Nicolai, >>>> >>>> I'm a bit concerned that this is creating drift with the "official" >>>> Cog source base at http://www.squeakvm.org/svn/squeak/branches/Cog. >>>> Long filename support for win32 was recently added by Marcel Taumel in May >>>> of this year. Are you tracking that? How can we keep the sources >>>> harmonized? >>>> >>> >>> Yes, I know, and I already asked on the ML if we can take that change or >>> if it is not possible because we have already other changes (pharos file >>> plugin >>> provides addition attributes (the file permissions)). >>> >> >> Esteban and I just harmonized this. I'm (almost correctly) generating >> the plugin source such that one can define either PharoVM or not to chose >> between the different versions. I say "almost" because I'm currently >> spitting out >> >> #define PharoVM 0 >> ... >> #if PharoVM >> >> instead of >> >> #if !defined(PharoVM) >> # define PharoVM 0 >> #endif >> ... >> #if PharoVM >> >> but I'll fix it v soon. >> > > OK, I'll try to copy marcels solution > > >> >> But I got no response, so I tried to adopt Marcels change. >>> >>> And I only found the change for sqWin32FilePrims.c, but missed the other >>> change >>> that is necessary in sqWin32Directory.c (and asked on the ML). In the >>> meantime Marcel added this but I could not find >>> the changed source, only an updated vm. >>> Is this change already comitted? >>> >> >> Yes, see >> http://www.squeakvm.org/svn/squeak/branches/Cog/platforms/win32/vm/sqWin32D… >> > > Ah, good. Now (I must be blind, but) I can not see the other change, > shouldn't there > be a "plugins" folder in Cog/platforms/win32/? > Where are the changes to sqWin32FilePrims.c now? > Ok, found it. It is in the trunk branch :) > > > > >> >> I'm sorry I didn't see your message. Did you ask on vm-dev? >> > > I am not sure, maybe I only send it in the squeak-dev list > > >> >> >> >>> I would love if someone else got this working. >>> >> >> :-) I hear you :-) >> >> >> >>> >>> nicolai >>> >>> >>> >>>> >>>> On Sun, Aug 23, 2015 at 4:44 AM, Nicolai Hess <nicolaihess(a)web.de> >>>> wrote: >>>> >>>>> For those who had problems with pharo on windows and github based >>>>> repositories, >>>>> I built a windows vm with support for long paths: >>>>> >>>>> >>>>> https://drive.google.com/file/d/0B8yEahnuIem2bmxwdzJuUXFxVGM/view?usp=shari… >>>>> >>>>> >>>>> For browsing directories with large paths (FileList or Inspect), >>>>> you may need one additional change in the image (But I am not really >>>>> sure about that) : >>>>> >>>>> DiskStore>>initialize >>>>> super initialize. >>>>> maxFileNameLength := Smalltalk vm maxFilenameLength ifNil: [ 32767 >>>>> ]. >>>>> >>>>> >>>>> please test and give feedback. >>>>> >>>>> This wasn't as easy as I thought, and I had to make some more changes >>>>> for the file permissions (the stat-functions don't work for files with >>>>> long paths). >>>>> Please test other file/folder operations. >>>>> >>>>> >>>>> nicolai >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> _,,,^..^,,,_ >>>> best, Eliot >>>> >>>> >>> >>> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot >> >> >

Sept. 11, 2015

Re: [Pharo-dev] [Vm-dev] Re: issue with large file path on windows

by Nicolai Hess

2015-09-10 23:07 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > Hi Nicolai, > > On Thu, Sep 10, 2015 at 1:17 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> >> >> >> 2015-09-10 21:31 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >>> >>> Hi Nicolai, >>> >>> I'm a bit concerned that this is creating drift with the "official" >>> Cog source base at http://www.squeakvm.org/svn/squeak/branches/Cog. >>> Long filename support for win32 was recently added by Marcel Taumel in May >>> of this year. Are you tracking that? How can we keep the sources >>> harmonized? >>> >> >> Yes, I know, and I already asked on the ML if we can take that change or >> if it is not possible because we have already other changes (pharos file >> plugin >> provides addition attributes (the file permissions)). >> > > Esteban and I just harmonized this. I'm (almost correctly) generating the > plugin source such that one can define either PharoVM or not to chose > between the different versions. I say "almost" because I'm currently > spitting out > > #define PharoVM 0 > ... > #if PharoVM > > instead of > > #if !defined(PharoVM) > # define PharoVM 0 > #endif > ... > #if PharoVM > > but I'll fix it v soon. > OK, I'll try to copy marcels solution > > But I got no response, so I tried to adopt Marcels change. >> >> And I only found the change for sqWin32FilePrims.c, but missed the other >> change >> that is necessary in sqWin32Directory.c (and asked on the ML). In the >> meantime Marcel added this but I could not find >> the changed source, only an updated vm. >> Is this change already comitted? >> > > Yes, see > http://www.squeakvm.org/svn/squeak/branches/Cog/platforms/win32/vm/sqWin32D… > Ah, good. Now (I must be blind, but) I can not see the other change, shouldn't there be a "plugins" folder in Cog/platforms/win32/? Where are the changes to sqWin32FilePrims.c now? > > I'm sorry I didn't see your message. Did you ask on vm-dev? > I am not sure, maybe I only send it in the squeak-dev list > > > >> I would love if someone else got this working. >> > > :-) I hear you :-) > > > >> >> nicolai >> >> >> >>> >>> On Sun, Aug 23, 2015 at 4:44 AM, Nicolai Hess <nicolaihess(a)web.de> >>> wrote: >>> >>>> For those who had problems with pharo on windows and github based >>>> repositories, >>>> I built a windows vm with support for long paths: >>>> >>>> >>>> https://drive.google.com/file/d/0B8yEahnuIem2bmxwdzJuUXFxVGM/view?usp=shari… >>>> >>>> >>>> For browsing directories with large paths (FileList or Inspect), >>>> you may need one additional change in the image (But I am not really >>>> sure about that) : >>>> >>>> DiskStore>>initialize >>>> super initialize. >>>> maxFileNameLength := Smalltalk vm maxFilenameLength ifNil: [ 32767 >>>> ]. >>>> >>>> >>>> please test and give feedback. >>>> >>>> This wasn't as easy as I thought, and I had to make some more changes >>>> for the file permissions (the stat-functions don't work for files with >>>> long paths). >>>> Please test other file/folder operations. >>>> >>>> >>>> nicolai >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> _,,,^..^,,,_ >>> best, Eliot >>> >>> >> >> > > > -- > _,,,^..^,,,_ > best, Eliot > >

Sept. 11, 2015

Re: [Pharo-dev] Bootstrap dependency, System-Announcements --> PragmaCollector

by Max Leske

> On 10 Sep 2015, at 19:44, Ben Coman <btc(a)openInWorld.com> wrote: > > On Fri, Sep 11, 2015 at 12:43 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: >> >>> On 10 Sep 2015, at 17:22, Ben Coman <btc(a)openInWorld.com> wrote: >>> >>> The bootstrap-dependency graph and report [1] mark dependency >>> System-Announcements --> PragmaCollector for pruning. This is due to... >>> >>> SystemAnnouncer>>restoreAllNotifications >>> | collector | >>> self reset. >>> collector := PragmaCollector filter: [ :pragma | >>> pragma keyword = #systemEventRegistration ]. >>> collector reset. >>> collector do: [ :pragma | >>> pragma methodClass theNonMetaClass perform: pragma selector ] >>> >>> Browsing around I came to understand that PragmaCollector is useful as >>> a pragma cache, but here the collector is thrown away, so that >>> facility is not needed. A key part is "collector reset" which does... >>> self class allSystemPragmas >>> do: [:pragma | self addPragma: pragma] >>> >>> where the #addPragma: evaluates the initialize'd #filter: block. Now >>> it seems that #allSystemPragmas might fit nicely on Pragma rather than >>> PragmaCollector >>> such that the following should be equivalent... >>> >>> SystemAnnouncer>>restoreAllNotifications >>> | systemPragmas | >>> self reset. >>> systemPragmas := Pragma allSystemPragmas collect: [ :pragma | >>> pragma keyword = #systemEventRegistration ]. >>> systemPragmas do: [ :pragma | >>> pragma methodClass theNonMetaClass perform: pragma selector >>> >> >> Cool. I like that better. >> >>> However #allSystemPragmas depends on SystemNavigation, so is it be >>> okay for Pragma to depend on SystemNavigation? >> >> Spontaneously Iâd say that SystemNavigation should depend on Pragma or PragmaCollector for looking up pragmas, not the other way around. > > So you mean something like... > > SystemAnnouncer>>restoreAllNotifications > self reset. > SystemNavigation allPragmasNamed: #systemEventRegistration do: > [ :pragma | > pragma methodClass theNonMetaClass perform: pragma selector ]. > > where... > > SystemNavigation>>allPragmasNamed: symbol do: aBlock > | systemPragmas | > systemPragmas := > self allSystemPragmas collect: [ :pragma | pragma keyword > = symbol ]. > systemPragmas do: [ :pragma | > pragma methodClass theNonMetaClass perform: pragma selector > > SystemNavigation>>allSystemPragmas > ^ (Array > streamContents: [:stream | > self allBehaviorsDo: [:behavior | > Pragma > withPragmasIn: behavior > do: [:pragma | stream nextPut: pragma]]]) Yes, exactly. > > cheers -ben > > >>> Actually, class side of Pragma has several #named:in: like methods, so >>> something like the following would be neat... >>> SystemAnnouncer>>restoreAllNotifications >>> self reset. >>> Pragma allNamed: #systemEventRegistration do: [ :pragma | >>> pragma methodClass theNonMetaClass perform: pragma selector ].

Sept. 11, 2015

Re: [Pharo-dev] Bootstrap dependency, System-Announcements --> PragmaCollector

by Marcus Denker

> On 10 Sep 2015, at 23:01, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > I think SystemNavigation should essentially dissolve in the near future. Moose used to have one of these some 10 years ago, and now all queries are implemented as fluent APIs distributed throughout the model classes. I would want the Pharo code model should move in the same direction. > Yes! Marcus

Sept. 11, 2015

Re: [Pharo-dev] Adding custom context to a debugger

by Ben Coman

On Fri, Sep 11, 2015 at 4:31 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Hi, > > is it possible to add custom context to a debugger? > (pic deleted) > I would like to add a reference to the highlighted area. > I am assuming that since SpecDebugger doesn't provide plugin support I > would have to modify the source code? > I'm not sure but you might try observing the execution of SpecDebugger>>updateInspectorsFromContext: aContext. cheers -ben

Sept. 11, 2015