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

Re: [Pharo-dev] Image and bootstrap dependencies

by Ben Coman

On Sat, Sep 5, 2015 at 12:23 AM, Ben Coman <btc(a)openinworld.com> wrote: > In Package Dependencies Analysis, taking for example "(AST-Core --> > Dependent packages : 15 | Dependencies : 134 (+ 14 extension > dependencies)" If I select Announcements-Core, then click <Show extension dependencies> to unselect it, I get "MNU DAPotentialDependenciesNode>>containsOnlyExtensionDependency" cheers -ben

Sept. 4, 2015

Re: [Pharo-dev] Image and bootstrap dependencies

by Ben Coman

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". 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. 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. > >> 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 > 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. 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. cheers -ben

Sept. 4, 2015

Re: [Pharo-dev] Image and bootstrap dependencies

by Christophe Demarey

Hi Ben, Le 4 sept. 2015 Ã 17:04, Ben Coman a Ã©crit : > On Fri, Sep 4, 2015 at 9:13 PM, Christophe Demarey > <christophe.demarey(a)inria.fr> wrote: >> 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). > > 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. In a second step, I will introduce rules to check dependencies. > 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. 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.

Sept. 4, 2015

TextAttributes in source code or class comment?

by Martin Dias

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? 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.

Sept. 4, 2015

Re: [Pharo-dev] Image and bootstrap dependencies

by Ben Coman

On Fri, Sep 4, 2015 at 9:13 PM, Christophe Demarey <christophe.demarey(a)inria.fr> wrote: > 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). 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. 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 ? Also, even though Collections-Streams --> Transcript is not highlighted red nor orange, this dependency also seems due only to "Generator class>>examplePrimes" cheers -ben

Sept. 4, 2015

[pharo-project/pharo-core]

by GitHub

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

Sept. 4, 2015

[pharo-project/pharo-core] 253675: 50304

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 2536752ecdd88e15b00c6d3e29cb055d108731c8 https://github.com/pharo-project/pharo-core/commit/2536752ecdd88e15b00c6d3e… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-04 (Fri, 04 Sep 2015) Changed paths: A Kernel.package/CompiledMethod.class/instance/testing/isRealPrimitive.st M Nautilus.package/AbstractNautilusUI.class/instance/accessing/selectedPackageWithoutChangingSelection_.st M Nautilus.package/Nautilus.class/class/opening/openOnCategory_ofClass_inEnvironment_.st M Nautilus.package/Nautilus.class/class/opening/openOnClass_inEnvironment_.st M Nautilus.package/Nautilus.class/class/opening/openOnClass_onGroup_inEnvironment_.st M Nautilus.package/Nautilus.class/class/opening/openOnClass_onProtocol_inEnvironment_.st M Nautilus.package/Nautilus.class/class/opening/openOnMethod_inEnvironment_.st M Nautilus.package/Nautilus.class/class/opening/openOnPackage_class_category_method_group_sortHierarchically_showHierarchy_showComment_showInstance_showCategories_inEnvironment_.st M Nautilus.package/Nautilus.class/instance/accessing/selectedCategory_.st M Nautilus.package/Nautilus.class/instance/accessing/selectedClass_.st M Nautilus.package/Nautilus.class/instance/accessing/selectedMethod_.st M Nautilus.package/Nautilus.class/instance/accessing/selectedPackage_.st A Nautilus.package/Nautilus.class/instance/history/package_.st A Nautilus.package/Nautilus.class/instance/history/package_class_.st R Nautilus.package/Nautilus.class/instance/history/package_class_category_method_.st A Nautilus.package/Nautilus.class/instance/history/package_class_protocol_.st A Nautilus.package/Nautilus.class/instance/history/package_class_protocol_method_.st M Nautilus.package/NautilusUI.class/instance/accessing/selectedClassWithoutChangingSelection_.st M Nautilus.package/NautilusUI.class/instance/menus behavior/findAllMethod.st M Nautilus.package/NautilusUI.class/instance/menus behavior/findMethod.st M Nautilus.package/NautilusUI.class/instance/menus behavior/findProtocol.st M Nautilus.package/NautilusUI.class/instance/private/selectedClass_withSelection_.st M Nautilus.package/NautilusUI.class/instance/private/unselectClass.st M Nautilus.package/NautilusUI.class/instance/widget category/selectedCategory_.st M Nautilus.package/NautilusUI.class/instance/widget method/forceSelectedMethod_.st M Nautilus.package/PackageTreeNautilusUI.class/instance/private dispatch/registerSelectionGroup_.st M Nautilus.package/PackageTreeNautilusUI.class/instance/private dispatch/registerSelectionPackage_.st M NautilusCommon.package/NautilusClassSelected.class/README.md R NautilusCommon.package/NautilusClassSelected.class/class/instance creation/class_.st A NautilusCommon.package/NautilusClassSelected.class/class/instance creation/package_class_.st M NautilusCommon.package/NautilusClassSelected.class/definition.st R NautilusCommon.package/NautilusClassSelected.class/instance/accessing/class_.st R NautilusCommon.package/NautilusClassSelected.class/instance/accessing/itemClass.st A NautilusCommon.package/NautilusClassSelected.class/instance/accessing/selectedClass.st A NautilusCommon.package/NautilusClassSelected.class/instance/accessing/selectedClass_.st A NautilusCommon.package/NautilusClassSelected.class/instance/compatibility/itemClass.st M NautilusCommon.package/NautilusMethodSelected.class/README.md R NautilusCommon.package/NautilusMethodSelected.class/class/instance creation/method_.st A NautilusCommon.package/NautilusMethodSelected.class/class/instance creation/package_class_protocol_method_.st M NautilusCommon.package/NautilusMethodSelected.class/definition.st R NautilusCommon.package/NautilusMethodSelected.class/instance/accessing/method.st R NautilusCommon.package/NautilusMethodSelected.class/instance/accessing/method_.st A NautilusCommon.package/NautilusMethodSelected.class/instance/accessing/selectedMethod.st A NautilusCommon.package/NautilusMethodSelected.class/instance/accessing/selectedMethod_.st A NautilusCommon.package/NautilusMethodSelected.class/instance/compatibility/method.st M NautilusCommon.package/NautilusPackageSelected.class/README.md M NautilusCommon.package/NautilusPackageSelected.class/class/instance creation/package_.st R NautilusCommon.package/NautilusPackageSelected.class/instance/accessing/package.st R NautilusCommon.package/NautilusPackageSelected.class/instance/accessing/package_.st A NautilusCommon.package/NautilusPackageSelected.class/instance/accessing/selectedPackage.st A NautilusCommon.package/NautilusPackageSelected.class/instance/accessing/selectedPackage_.st A NautilusCommon.package/NautilusPackageSelected.class/instance/compatibility/package.st M NautilusCommon.package/NautilusProtocolSelected.class/README.md R NautilusCommon.package/NautilusProtocolSelected.class/class/instance creation/category_.st A NautilusCommon.package/NautilusProtocolSelected.class/class/instance creation/package_class_protocol_.st M NautilusCommon.package/NautilusProtocolSelected.class/definition.st R NautilusCommon.package/NautilusProtocolSelected.class/instance/accessing/category.st R NautilusCommon.package/NautilusProtocolSelected.class/instance/accessing/category_.st A NautilusCommon.package/NautilusProtocolSelected.class/instance/accessing/selectedProtocol.st A NautilusCommon.package/NautilusProtocolSelected.class/instance/accessing/selectedProtocol_.st A NautilusCommon.package/NautilusProtocolSelected.class/instance/compatibility/category.st M NautilusCommon.package/PackageTasksPlugin.class/instance/display/updateMethodSelection_.st R Reflectivity-Tests.package/ReflectivityControlTest.class/instance/running/tearDown.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - after/testAfterArray.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - after/testAfterAssignment.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - after/testAfterBlock.st A Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - after/testAfterBlockSequence.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - after/testAfterLiteral.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - after/testAfterLiteralArray.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - after/testAfterMethod.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - after/testAfterSend.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - after/testAfterSequence.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - after/testAfterVariable.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - before/testBeforeAssignment.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - before/testBeforeBlock.st A Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - before/testBeforeBlockSequence.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - before/testBeforeClassVariable.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - before/testBeforeLiteral.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - before/testBeforeLiteralArray.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - before/testBeforeMethod.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - before/testBeforeReturn.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - before/testBeforeSend.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - before/testBeforeSequence.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - before/testBeforeVariable.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - before/testbeforeArray.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testInsteadArray.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testInsteadAssign.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testInsteadBlock.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testInsteadLiteral.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testInsteadLiteralArray.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testInsteadMethod.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testInsteadReturn.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testInsteadSend.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testInsteadVariableReadGlobal.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testInsteadVariableReadIvar.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testInsteadVariableReadTemp.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testInsteadVariableWrite.st M Reflectivity.package/RFASTTranslator.class/instance/visitor-double dispatching/visitBlockNode_.st M Reflectivity.package/RFASTTranslatorForValue.class/instance/visitor-double dispatching/visitSequenceNode_.st M Reflectivity.package/extension/CompiledMethod/instance/installLink_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50303.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50304.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50303.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50304.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50304 16475 Nautilus sends too many announcements for a single action https://pharo.fogbugz.com/f/cases/16475 16477 Fixes: #before on sequence, after on Block https://pharo.fogbugz.com/f/cases/16477 http://files.pharo.org/image/50/50304.zip

Sept. 4, 2015

Re: [Pharo-dev] Need a decision on subString: vs substring:

by Chris Cunningham

On Fri, Sep 4, 2015 at 6:18 AM, Christophe Demarey < Christophe.Demarey(a)inria.fr> wrote: <snip> > > I agree with that. > To be compatible with these goals, I think my proposition just needs to be > updated a bit. > I'm still in favor of rules to transform ANSI code to Pharo code. The > point is that we should not force the user to update their code base. The > rule-cased approach is compatible with that if you transform ANSI code when > it gets loaded in the image. True to a point. That point being folks who want to write code that could play in other ANSI Smalltalks - with your approach, you have locked those people out, since they CAN'T write ansi code - only Pharo code. any non-Pharo ANSI'ism would be auto-changed back to Pharo - and they'd leave to write and live in a different Smalltalk. Now, if you had the ANSI compatibility layer that either allowed conversion to Pharo OR ignored conversion to Pharo, that wouldn't be a barrier. On a different topic, what would be required to amend the ANSI standard? Maybe a Smalltalk Agreement 2016 that took the standard and amended some parts (like fixing the spelling) so that going forward, all Smalltalks could be standard with good English spellings? Just curious, cbc

Sept. 4, 2015

Re: [Pharo-dev] Need a decision on subString: vs substring:

by Jan Vrany

... > > The corollary being, if you make it simple for people to continue > > maintaining the old dialect, you are more likely to get code ported > > to > > your dialect. > > I agree with that. > To be compatible with these goals, I think my proposition just needs > to be updated a bit. > I'm still in favor of rules to transform ANSI code to Pharo code. The > point is that we should not force the user to update their code base. > The rule-cased approach is compatible with that if you transform ANSI > > code when it gets loaded in the image. No, it's not! Rewriting the code in this case is actually a very bad thing. The problem is that when you port changes done in, say, Pharo back to, say, "The other cool Smalltalk" you have rewrite everything back (or things will break). This is not what you want to spend you time on. So either don't enforce code rewriting in this case or be honest and say openly "I do not care, not my problem" :-) And no, I'm not theorizing, I'm talking out of my every-two-weeks-or=-so-pain I'm suffering last year or so. Best, Jan

Sept. 4, 2015

remove MczInstaller?

by Martin Dias

Hi, Does somebody use MczInstaller to load Monticello files? The only users in the image are it's tests. The class comment states: " An installer for Monticello files with the *.mcz extension. MczInstaller installFileNamed: 'MyKillerApp-Core-Author.1.mcz' " MartÃn

Sept. 4, 2015