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

[pharo-project/pharo-core] 285fe7: 50305

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 285fe7de759eb90547a2a31d541166d176bb5a20 https://github.com/pharo-project/pharo-core/commit/285fe7de759eb90547a2a31d… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-04 (Fri, 04 Sep 2015) Changed paths: M CodeExport.package/extension/RPackage/instance/fileOut.st M MonticelloGUI.package/MCWorkingCopyBrowser.class/instance/morphic ui/initialExtent.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50304.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50305.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50304.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50305.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A System-Model.package/Model.class/README.md A System-Model.package/Model.class/definition.st A System-Model.package/Model.class/instance/as yet unclassified/announcer.st A System-Model.package/Model.class/instance/backstops/arrowKey_from_.st A System-Model.package/Model.class/instance/backstops/selectedClass.st A System-Model.package/Model.class/instance/copying/veryDeepFixupWith_.st A System-Model.package/Model.class/instance/dependents-private/actAsExecutor.st A System-Model.package/Model.class/instance/dependents-private/myDependents.st A System-Model.package/Model.class/instance/dependents-private/myDependents_.st A System-Model.package/Model.class/instance/dependents/addDependent_.st A System-Model.package/Model.class/instance/dependents/dependents.st A System-Model.package/Model.class/instance/dependents/removeDependent_.st A System-Model.package/Model.class/instance/edits/canDiscardEdits.st A System-Model.package/Model.class/instance/edits/hasUnacceptedEdits.st A System-Model.package/Model.class/instance/updating/step.st A System-Model.package/Model.class/instance/updating/update_.st R System-Support.package/Model.class/README.md R System-Support.package/Model.class/definition.st R System-Support.package/Model.class/instance/as yet unclassified/announcer.st R System-Support.package/Model.class/instance/backstops/arrowKey_from_.st R System-Support.package/Model.class/instance/backstops/selectedClass.st R System-Support.package/Model.class/instance/copying/veryDeepFixupWith_.st R System-Support.package/Model.class/instance/dependents-private/actAsExecutor.st R System-Support.package/Model.class/instance/dependents-private/myDependents.st R System-Support.package/Model.class/instance/dependents-private/myDependents_.st R System-Support.package/Model.class/instance/dependents/addDependent_.st R System-Support.package/Model.class/instance/dependents/dependents.st R System-Support.package/Model.class/instance/dependents/removeDependent_.st R System-Support.package/Model.class/instance/edits/canDiscardEdits.st R System-Support.package/Model.class/instance/edits/hasUnacceptedEdits.st R System-Support.package/Model.class/instance/updating/step.st R System-Support.package/Model.class/instance/updating/update_.st Log Message: ----------- 50305 16413 Model should be packaged outside System-Support https://pharo.fogbugz.com/f/cases/16413 16482 Better default size for MCBrowser https://pharo.fogbugz.com/f/cases/16482 16460 I fileout a package does not fileout metaclass extension https://pharo.fogbugz.com/f/cases/16460 http://files.pharo.org/image/50/50305.zip

Sept. 4, 2015

Re: [Pharo-dev] Announcements in Nautilus

by stepharo

Le 4/9/15 21:08, Yuriy Tymchuk a Ã©crit : > Iâve opened an issue about double announcing method selection change > https://pharo.fogbugz.com/f/cases/16480/NethodSelectionChanged-announcement…. > I think that it should be easier to track down 2 announcement than 7 :). :) Stef > > Uko > >> On 04 Sep 2015, at 19:50, stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>> wrote: >> >> Thanks we should continue to do a pass. >> I'm sad that I did not have a the time to sit with ben as I did it >> with franck. >> But I cannot redo the past so let us invest in the future. >> Stef >> >> >> >> Le 4/9/15 14:38, Yuriy Tymchuk a Ã©crit : >>> Iâve seen that there is a method #package:class:category:method: >>> which is called sometimes with nil values and the method sends 4 >>> messages, and in each message if the arg is not nil it announces the >>> selection. >>> >>> What Iâve done was to break in into 4 methods: #package:, >>> #package:class: and so on. Then Iâve changes all the messages that >>> contained hardcoded nil, to use only the method they need. And each >>> method fires only one announcement. >>> >>> This is not perfect, but at least we donât have to send >>> >>> model package: aPackage class: aClass category: nil method: nil >>> >>> if we only want to select a class. Maybe in the future this can be >>> reduced to a simple "class: aClassâ, because Iâve seen that many of >>> parameters some from âself selectedPackageâ, âself selectedClassâ >>> and so on. >>> >>> Uko >>> >>> >>>> On 04 Sep 2015, at 14:02, Franck Warlouzet >>>> <franck.warlouzet(a)hotmail.fr> wrote: >>>> >>>> I will take a look at it, thanks to continue this effort. >>>> I agree with Nicolai, there is too many announcements raised but >>>> the way to manage selection complicates a deep change. But I trust >>>> us, step by step we can simplify all of this. >>>> >>>> Franck >>>> >>>> ------------------------------------------------------------------------ >>>> From: yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com> >>>> Date: Fri, 4 Sep 2015 12:08:55 +0200 >>>> To: pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> >>>> Subject: Re: [Pharo-dev] Announcements in Nautilus >>>> >>>> Iâve made a prototype, and it seems to work well, though Iâd really >>>> like if Franck or Esteban can take a look. >>>> https://pharo.fogbugz.com/f/cases/16475/Nautilus-sends-too-many-announcemen… >>>> >>>> >>>> Cheers. >>>> Uko >>>> >>>> >>>> On 04 Sep 2015, at 10:25, stepharo <stepharo(a)free.fr >>>> <mailto:stepharo@free.fr>> wrote: >>>> >>>> I will not reply publicly on the true reason of that situation :) >>>> Now what we should do is to continue to simplify the code of >>>> Nautilus (we made great steps with Franck). >>>> And yuriy if you have some fixes please let us know. >>>> >>>> Stef >>>> >>>> Le 4/9/15 09:22, Yuriy Tymchuk a Ã©crit : >>>> >>>> Hi, >>>> >>>> I find announcements in Nautilus a bit strange. I guess you >>>> are familiar with QualityAssistant. To display the critics >>>> about the currently selected entity I need to know which >>>> one is selected. There is NautilusMethodSelected and >>>> NautilusClassSelected announcements. But here is a small >>>> detail, if you select a method, both of them are fired i.e. >>>> for the methodâs class and the method itself. For me it >>>> does not make any sense because I need to show critics only >>>> for currently selected source code. >>>> >>>> Moreover if I need to show something about the class while >>>> a method is selected, I can just ask the method for its >>>> class, right? >>>> >>>> Does anybody need this double announcing? (Maybe it is >>>> quadruple, I havenât checked for a package and protocol) >>>> >>>> Cheers! >>>> Uko >>>> >>> >> >

Sept. 4, 2015

Re: [Pharo-dev] Image and bootstrap dependencies

by Christophe Demarey

Hi Nicolai, Le 4 sept. 2015 Ã 21:12, Nicolai Hess a Ã©crit : > Hi Christophe, > > the tool The tool was originally created by Baptiste QuidÃ© and I enhanced it with message send analysis. > and this depedency report is great. Thanks. > But how are the dependencies categories "Ignored dependency" , Yes, it is a manual step. You find them in the package manifest class, in #ignoredDependencies. > "Dependency to remove" created, > is this a manual step? This one also. There is a special manifest ManifestBootstrap holding this dependenciesToRemove. > For examlpe, I don't understand why > Graphics-Display Objects Graphics-Primitives > are "Dependency to remove" for package Athens-Balloon. > Aren't these low level packages? Yes, it is not clear. Dependencies to remove are packages we do NOT want in the bootstrap. They appear in red everywhere. It is not the dependency we want to remove from the bootstrap but the package itself. I will update that.

Sept. 4, 2015

Re: [Pharo-dev] Image and bootstrap dependencies

by Christophe Demarey

Le 4 sept. 2015 Ã 18:23, Ben Coman a Ã©crit : > On Fri, Sep 4, 2015 at 11:18 PM, Christophe Demarey > <Christophe.Demarey(a)inria.fr> wrote: >> Hi Ben, >> >> Le 4 sept. 2015 Ã 17:04, Ben Coman a Ã©crit : >>> >>> I tried the Dependency Analyzer. First a minor point, it wasn't >>> obvious how to invoke it. I expected to see "Dependency Analyzer" in >>> the tools but its not there. I think I correctly guessed it was >>> "Package Dependencies Browser", but it would be better to match the >>> catalog name. >> >> ok, I will fix that. >> I will also add the analyzer in the system. > > Sorry I'm (easily) confused - when you say "also" makes me think you > are referring to "Package Dependencies Analysis". I only meant that > if "Package Dependencies Browser" is the entry point, it would be > better named "Dependency Analyzer". You were clear. Maybe I was not. I meant I will open an issue to add the dependency anlayzer packages as part of the default Pharo image. > I did not have an opinion on > whether "Package Dependencies Analysis" should be added to the menu > (but maybe thats not what you meant.) > >> In a second step, I will introduce rules to check dependencies. > > btw, I'm not sure how much gloss you'd like to put on the Package > Dependencies Browser, but just some immediate thoughts: > * It feels awkward having the <Add package> button at the top and the > <Add all> button at the bottom. It would be nicer if the first was > also at the bottom on the same line (i.e. half the width). Same with > the <remove...> buttons. > * The opposite of the green-plus icon would be a red-minus icon rather > than the trash-can icon. I never used this UI because I find easier to just right-click on a selected package in Nautilus and select 'browse dependencies ...'. I will take a look at this UI to enhance it a bit. > In Package Dependencies Analysis, taking for example "(AST-Core --> > Dependent packages : 15 | Dependencies : 134 (+ 14 extension > dependencies)" > I see method Traits > TBehavior >> #parseTreeFor: > whose extension protocol is *ast-core. > This to me doesn't seem a dependency. It is seen as a dependency because if you want to load AST-Core, containing an extension method on TBehavior class packaged in Traits, and Traits is not in the system, it will fail. We could imagine optional extension methods, i.e. only loaded in the system if the class extended is present but it is not like that now. >> >>> The sample dependency I looked at from bootstrap-dependency-report.html >>> was Collections-Streams --> Tool-Transcript >>> which seems to be due to only single method "Generator class>>examplePrimes". >>> So should this be coloured orange by marking it in #ignoredDependencies ? >> >> The clean solution is to have a package Collections-Streams-Example with this method. >> It depends how we want to be strict with that. I can live with no additional package and the dependency added in #ignoredDependencies. >> There are so many wrong dependencies in the system that I will prefer at a first step to put dependencies introduced by example methods or settings by example as ignored dependencies because they will not be called. > > Are examples the only (or majority) kind of ignoredDependencies ? If > there is a significant number of other kinds, it might be useful to > split the examples out At this time, not a lot. It is mostly when you know that a code will not be executed. >> We could fix that in a second step if we want and let us focus on stronger dependencies. >> >> Thanks for helping. >> >> PS: Even for people not having time to clean the system, when you contribute code to the image, pleas check that you do not introduce a dependency from a low-level package to a higher level package. It is not obvious to catch but for example, check that you do not introduce a dependency to UI packages when the package could work without UI. > > Even with my best intentions, I think the long term reality is that > the workflow delay of installing Dependency Analyzer to do this will > inhibit me doing this. When working on issues I always start with a > fresh/latest build. As a tool to facilitate one of Pharo's goals, > perhaps it could be integrated into the Image and be prominently > displayed on the top level World menu to encourage its use. Yes, that will be done very soon. > Now I guess it will be hard to identify an introduced dependency just > by looking at a one shot report after a modification. It would help if > this could be compared to a prior snapshot stored in the image > produced during the CI builds. it will be the first step to check regressions from the dependency point of view. It can be done with a CI job if dependency analysis is published for each image. > Perhaps even it could provide live > advice through integration with Quality Assistant. It is what I want at the end. When you update a method or a class, run a dependency check against the current version and the version about to be saved. To reach this point, each package needs to have its dependencies specified. It will come ... Thanks for the feedback

Sept. 4, 2015

Re: [Pharo-dev] TextAttributes in source code or class comment?

by Eliot Miranda

Hi Martin, On Fri, Sep 4, 2015 at 8:13 AM, Martin Dias <tinchodias(a)gmail.com> wrote: > Hi all, > > The source code of a method could be a Text, with TextAttributes. In such > case, it will be written down to a stream with a "]style[" suffix. Through > a special parsing, the system can reconstruct the original Text. I think > the use of Text in source code or class comments is discouraged, but I > understand we kept support for some backward compatibility. Now, may be > it's time to remove this feature. > > With Pablo, we looked for uses of ]style[ in the .sources and .changes > files of a new Pharo 5.0, and there are no real uses. It appears in some > comments only, as examples. > > We tried to find past discussions about this feature, because we're sure > there were, but we couldn't. > > So, the questions is: > > Can we remove support for text in source code or class comments in > Pharo 5.0? > IIUC, ]style[ also supports things like embedding URL links and method references in class comments. So I would request that it /not/ be removed. It is very useful to put clickable links in class comments. > > I think I can propose a slice. > > Regards, > MartÃn > PS: I was trying to cut dependencies of Text-Core with System-Changes and > System-Changes. > -- _,,,^..^,,,_ best, Eliot

Sept. 4, 2015

Re: [Pharo-dev] Image and bootstrap dependencies

by Nicolai Hess

Hi Christophe, the tool and this depedency report is great. But how are the dependencies categories "Ignored dependency" , "Dependency to remove" created, is this a manual step? For examlpe, I don't understand why Graphics-Display Objects <https://ci.inria.fr/pharo/job/Pharo-5.0-DependencyAnalysis/Dependencies_HTM…> Graphics-Primitives <https://ci.inria.fr/pharo/job/Pharo-5.0-DependencyAnalysis/Dependencies_HTM…> are "Dependency to remove" for package Athens-Balloon. Aren't these low level packages? regards Nicolai 2015-09-04 15:13 GMT+02:00 Christophe Demarey <christophe.demarey(a)inria.fr>: > Hi, > > I created a job to automatically generate a report of the Pharo image > dependencies as well as current bootstrap dependencies. > You can find them here: > > - > https://ci.inria.fr/pharo/job/Pharo-5.0-DependencyAnalysis/Dependencies_HTM… > - > https://ci.inria.fr/pharo/job/Pharo-5.0-DependencyAnalysis/Dependencies_HTM… > > > There are a lot (too many) dependencies but you can focus on some of them > with the search field. > Dependencies inside orange boxes are dependencies that are there but that > we ignore (for example, an example method adds an extra-dependency). It > should be fixed later but is not a problem for now. Ignored dependencies > are declared in the package manifest in #ignoredDependencies. > Dependencies inside red boxes are dependencies we want to remove for the > bootstrap. For now, they are listed in the bootstrap dependency report. > > People that are willing to help to have a more modular Pharo could first > take a look at the bootstrap dependency report and check dependencies that > we should cut. > Once we know, we can open issues on fogbugz in the 'bootstrap category' > and update manifests accordingly. > To investigate more deeply dependencies, you can use the > DependencyAnalyzer (in the Pharo Catalog) to actually check dependencies > (inheritance, reference, extension, traits, message send). > > Regards, > Christophe. >

Sept. 4, 2015

Re: [Pharo-dev] Announcements in Nautilus

by Yuriy Tymchuk

Iâve opened an issue about double announcing method selection change https://pharo.fogbugz.com/f/cases/16480/NethodSelectionChanged-announcement… <https://pharo.fogbugz.com/f/cases/16480/NethodSelectionChanged-announcement…>. I think that it should be easier to track down 2 announcement than 7 :). Uko > On 04 Sep 2015, at 19:50, stepharo <stepharo(a)free.fr> wrote: > > Thanks we should continue to do a pass. > I'm sad that I did not have a the time to sit with ben as I did it with franck. > But I cannot redo the past so let us invest in the future. > Stef > > > > Le 4/9/15 14:38, Yuriy Tymchuk a Ã©crit : >> Iâve seen that there is a method #package:class:category:method: which is called sometimes with nil values and the method sends 4 messages, and in each message if the arg is not nil it announces the selection. >> >> What Iâve done was to break in into 4 methods: #package:, #package:class: and so on. Then Iâve changes all the messages that contained hardcoded nil, to use only the method they need. And each method fires only one announcement. >> >> This is not perfect, but at least we donât have to send >> >> model package: aPackage class: aClass category: nil method: nil >> >> if we only want to select a class. Maybe in the future this can be reduced to a simple "class: aClassâ, because Iâve seen that many of parameters some from âself selectedPackageâ, âself selectedClassâ and so on. >> >> Uko >> >> >>> On 04 Sep 2015, at 14:02, Franck Warlouzet < <mailto:franck.warlouzet@hotmail.fr>franck.warlouzet(a)hotmail.fr <mailto:franck.warlouzet@hotmail.fr>> wrote: >>> >>> I will take a look at it, thanks to continue this effort. >>> I agree with Nicolai, there is too many announcements raised but the way to manage selection complicates a deep change. But I trust us, step by step we can simplify all of this. >>> >>> Franck >>> >>> From: yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com> >>> Date: Fri, 4 Sep 2015 12:08:55 +0200 >>> To: pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> >>> Subject: Re: [Pharo-dev] Announcements in Nautilus >>> >>> Iâve made a prototype, and it seems to work well, though Iâd really like if Franck or Esteban can take a look. <https://pharo.fogbugz.com/f/cases/16475/Nautilus-sends-too-many-announcemen…>https://pharo.fogbugz.com/f/cases/16475/Nautilus-sends-too-many-announcemen… <https://pharo.fogbugz.com/f/cases/16475/Nautilus-sends-too-many-announcemen…> >>> >>> Cheers. >>> Uko >>> >>> >>> On 04 Sep 2015, at 10:25, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: >>> >>> I will not reply publicly on the true reason of that situation :) >>> Now what we should do is to continue to simplify the code of Nautilus (we made great steps with Franck). >>> And yuriy if you have some fixes please let us know. >>> >>> Stef >>> >>> Le 4/9/15 09:22, Yuriy Tymchuk a Ã©crit : >>> Hi, >>> >>> I find announcements in Nautilus a bit strange. I guess you are familiar with QualityAssistant. To display the critics about the currently selected entity I need to know which one is selected. There is NautilusMethodSelected and NautilusClassSelected announcements. But here is a small detail, if you select a method, both of them are fired i.e. for the methodâs class and the method itself. For me it does not make any sense because I need to show critics only for currently selected source code. >>> >>> Moreover if I need to show something about the class while a method is selected, I can just ask the method for its class, right? >>> >>> Does anybody need this double announcing? (Maybe it is quadruple, I havenât checked for a package and protocol) >>> >>> Cheers! >>> Uko >> >

Sept. 4, 2015

Re: [Pharo-dev] Image and bootstrap dependencies

by stepharo

> btw, I'm not sure how much gloss you'd like to put on the Package > Dependencies Browser, but just some immediate thoughts: > * It feels awkward having the <Add package> button at the top and the > <Add all> button at the bottom. It would be nicer if the first was > also at the bottom on the same line (i.e. half the width). Same with > the <remove...> buttons. Yes the add button is awkwark. Christophe is often not using it via the tool menu. > * The opposite of the green-plus icon would be a red-minus icon rather > than the trash-can icon. >>> The sample dependency I looked at from bootstrap-dependency-report.html >>> was Collections-Streams --> Tool-Transcript >>> which seems to be due to only single method "Generator class>>examplePrimes". >>> So should this be coloured orange by marking it in #ignoredDependencies ? >> The clean solution is to have a package Collections-Streams-Example with this method. >> It depends how we want to be strict with that. I can live with no additional package and the dependency added in #ignoredDependencies. >> There are so many wrong dependencies in the system that I will prefer at a first step to put dependencies introduced by example methods or settings by example as ignored dependencies because they will not be called. > Are examples the only (or majority) kind of ignoredDependencies ? If > there is a significant number of other kinds, it might be useful to > split the examples out > > Even with my best intentions, I think the long term reality is that > the workflow delay of installing Dependency Analyzer to do this will > inhibit me doing this. When working on issues I always start with a > fresh/latest build. As a tool to facilitate one of Pharo's goals, > perhaps it could be integrated into the Image and be prominently > displayed on the top level World menu to encourage its use. agree we should add the tool in the system so that we can use it as fast as possible. > > Now I guess it will be hard to identify an introduced dependency just > by looking at a one shot report after a modification. It would help if > this could be compared to a prior snapshot stored in the image > produced during the CI builds. Perhaps even it could provide live > advice through integration with Quality Assistant. No you can really get a good understanding of the dependency. We should continue to address them. Often the system is not thought with layer and modularity in mind (for example all the inform: and cursorWhile: everywhere. I think that we should remove as much as possible as cursorWhile:. for example. Stef > > cheers -ben > >

Sept. 4, 2015

Voyage Mongo and Serialization anomalies?

by Holger Freyther

Hi all, it is the first time I notice this and I am not sure that this has been written down somewhere and if it is known to others (and then what to do about it). I had an Object with a ByteArray and then tried to find this object using the ByteArray and it wasnât found. It looks like the ByteArray will be converted to an âarrayâ. When searching the ByteArray would not match it, an Array matches it. When using anArray to find the object and using a âgetterâ to get the value and comparing it will not lead to equality. I understand that Mongo doesnât have same types (Array, OrderedCollection, ByteArray) as Smalltalk but I wonder if there can be done something to improve the situation? Is this known? Can we improve it? I can of course workaround it by converting it to an array/orderedcollection before comparing it. holger Example: | data repository test res | repository := VOMongoRepository database: 'dbtest'. data := #[1 2 3 4]. test := ZEByteArrayVoyage new. test byteArray: data. repository save: test. res := repository selectOne: ZEByteArrayVoyage where: [:each | each byteArray = data ]. res. "---> UndefinedObject" res := repository selectOne: ZEByteArrayVoyage where: [:each | each byteArray = data asArray]. res. "---> ZEByteArrayVoyage" res byteArray = data. âfalse.. OrderedCollection = ByteArray" res byteArray = data asArray. âOrderedCollection = Array" res byteArray = data asOrderedCollection. "true"

Sept. 4, 2015

Re: [Pharo-dev] Announcements in Nautilus

by stepharo

Thanks we should continue to do a pass. I'm sad that I did not have a the time to sit with ben as I did it with franck. But I cannot redo the past so let us invest in the future. Stef Le 4/9/15 14:38, Yuriy Tymchuk a Ã©crit : > Iâve seen that there is a method #package:class:category:method: which > is called sometimes with nil values and the method sends 4 messages, > and in each message if the arg is not nil it announces the selection. > > What Iâve done was to break in into 4 methods: #package:, > #package:class: and so on. Then Iâve changes all the messages that > contained hardcoded nil, to use only the method they need. And each > method fires only one announcement. > > This is not perfect, but at least we donât have to send > > model package: aPackage class: aClass category: nil method: nil > > if we only want to select a class. Maybe in the future this can be > reduced to a simple "class: aClassâ, because Iâve seen that many of > parameters some from âself selectedPackageâ, âself selectedClassâ and > so on. > > Uko > > >> On 04 Sep 2015, at 14:02, Franck Warlouzet >> <franck.warlouzet(a)hotmail.fr <mailto:franck.warlouzet@hotmail.fr>> wrote: >> >> I will take a look at it, thanks to continue this effort. >> I agree with Nicolai, there is too many announcements raised but the >> way to manage selection complicates a deep change. But I trust us, >> step by step we can simplify all of this. >> >> Franck >> >> ------------------------------------------------------------------------ >> From: yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com> >> Date: Fri, 4 Sep 2015 12:08:55 +0200 >> To: pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> >> Subject: Re: [Pharo-dev] Announcements in Nautilus >> >> Iâve made a prototype, and it seems to work well, though Iâd really >> like if Franck or Esteban can take a look. >> https://pharo.fogbugz.com/f/cases/16475/Nautilus-sends-too-many-announcemen… >> >> >> Cheers. >> Uko >> >> >> On 04 Sep 2015, at 10:25, stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>> wrote: >> >> I will not reply publicly on the true reason of that situation :) >> Now what we should do is to continue to simplify the code of >> Nautilus (we made great steps with Franck). >> And yuriy if you have some fixes please let us know. >> >> Stef >> >> Le 4/9/15 09:22, Yuriy Tymchuk a Ã©crit : >> >> Hi, >> >> I find announcements in Nautilus a bit strange. I guess you >> are familiar with QualityAssistant. To display the critics >> about the currently selected entity I need to know which one >> is selected. There is NautilusMethodSelected and >> NautilusClassSelected announcements. But here is a small >> detail, if you select a method, both of them are fired i.e. >> for the methodâs class and the method itself. For me it does >> not make any sense because I need to show critics only for >> currently selected source code. >> >> Moreover if I need to show something about the class while a >> method is selected, I can just ask the method for its class, >> right? >> >> Does anybody need this double announcing? (Maybe it is >> quadruple, I havenât checked for a package and protocol) >> >> Cheers! >> Uko >> >

Sept. 4, 2015