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

Re: [Pharo-dev] [Moose-dev] Re: Searching for a Roassal2 version

by Yuriy Tymchuk

I donât get this. I do a project and I have version 4.3. Then I make a major changes i.e. change API without backwards compatibility and create version 5.0. Now 5.0 is stable, but if someone depends on my packageâs stable version, he has to rewrite his code, otherwise his package is insta-broken. I think this has to be also discussed with Pharo developers, who missed the main conversation, here it is: http://forum.world.st/Searching-for-a-Roassal2-version-td4833461.html <http://forum.world.st/Searching-for-a-Roassal2-version-td4833461.html> In short: we are arguing on depending on numbered versions vs symbolic. Uko > On 23 Jun 2015, at 14:40, stephan <stephan(a)stack.nl> wrote: > > > > On 23-06-15 14:27, Yuriy Tymchuk wrote: >> Thatâs the point, Iâm fine using Pharo 4 in 2 years as long as the projects works. Because 1) I can use it for my reasons 2) I can migrate it if I need to. But if everyone depends on symbolic, in 2 years I open a project, it doesnât work because too much changed, I have no idea what changed, I throw it to trash. Uko > > If everyone would correctly use symbolic, the only thing you'd need > to do is change your own packages to make it work in the latest version of Pharo 4. > That is what we have with Seaside and it works. To make it work with your code, > Roassal, Glamour and GT need to switch to symbolic versions too. > > Stephan > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

June 23, 2015

Re: [Pharo-dev] Pharo versioning

by Peter UhnÃ¡k

Well as far as image goes, you can download whatever version you want here http://files.pharo.org/image/40/ So each "release" does have a different version number, only it is not usually advertised. If you are interested in the reason of the change, usually searching the version in issue tracker will give an issue https://pharo.fogbugz.com/f/cases/15797/Backport-4-0-New-PackageManifests-s… Peter On Tue, Jun 23, 2015 at 12:26 PM, Daniel Milde <daniel(a)milde.cz> wrote: > Hi everybody, > I am a maintainer of Pharo package in Arch Linux distribution and would > like to ask you if there is some way how to get Pharo release in some > specific (non-changing) version. > > I am now using link to official stable release [1], but the archive is > changing quite often without giving any notice (version number change), > which breaks the package building due to hash sums changes. > > Thanks > > Best regards > Daniel > > [1] http://files.pharo.org/platform/Pharo4.0-linux.zip > >

June 23, 2015

Pharo versioning

by Daniel Milde

Hi everybody, I am a maintainer of Pharo package in Arch Linux distribution and would like to ask you if there is some way how to get Pharo release in some specific (non-changing) version. I am now using link to official stable release [1], but the archive is changing quite often without giving any notice (version number change), which breaks the package building due to hash sums changes. Thanks Best regards Daniel [1] http://files.pharo.org/platform/Pharo4.0-linux.zip

June 23, 2015

Re: [Pharo-dev] Collecting user data

by Yuriy Tymchuk

Hi, As Moose 5.1 was released already, can we move on with unification of data collection strategies? Cheers, Uko > On 30 Apr 2015, at 16:18, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > Of course :) > Just right now we are too busy with releasing moose 5.1 and moving development to Pharo 5. > After it's done we can sync more on this. > > Cheers, > Andrei > > On Thu, Apr 30, 2015 at 4:15 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: > Ok, then an important question: is any author of a reporting tool ready to help other 2 authors to migrate to his tool? > > Uko > > > >> On 30 Apr 2015, at 16:10, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: >> >> >> One is also easier to improve/maintain. >> Stef >> >> >> Le 28/4/15 14:31, Andrei Chis a Ã©crit : >>> Yes, some level of unification would be nice, especially for the part about users agreeing to send usage data and persisting that setting. >>> Also at least two general levels of details about what data is being send that tools should follow would help (full anonymous vs. include class names/method names ?). >>> Last but not least, a single entry point for sending that data over the network would help. >>> >>> How data is collected/stored will differ from tool to tool, but agreeing on the previous aspects would make it much easier to collect data. >>> >>> Cheers, >>> Andrei >>> >>> On Tue, Apr 28, 2015 at 1:18 PM, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >>> >>> > On 28 Apr 2015, at 11:42, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >>> > >>> > Hi guys, >>> > >>> > from time to time we have to collect a usage data in order to improve our tools. For example Iâd like to collect data in future about how do you treat code critics: do they occur, do you outfox them, do you mark them as false positives? If we had answers to these questions, we could really make good and helpful critics. >>> > >>> > For now I know that there are 3 projects which collect data: >>> > - GTSpotter >>> > - Shoreline >>> > - DFlow (not in image by default). >>> > >>> > Should I make 4th data collection for QualityAssistant? Or maybe we can do some unification? >>> > >>> >>> I would love unification! >>> >>> Itâs not only good for the researchers, but even for the user: I do not want to decide 5 times to give data to research, >>> but I want to decide it onceâ¦ >>> >>> Marcus >>> >>> >>> >> > >

June 23, 2015

[pharo-project/pharo-core]

by GitHub

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

June 23, 2015

[pharo-project/pharo-core] 447ccc: 40615

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 447cccfcefa23cbaa5502392d7c2d8d55f829d0c https://github.com/pharo-project/pharo-core/commit/447cccfcefa23cbaa5502392… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-06-23 (Tue, 23 Jun 2015) Changed paths: A Kernel.package/PackageManifest.class/class/-- all --/rejectClasses.st A Kernel.package/PackageManifest.class/class/-- all --/rejectRules.st A Kernel.package/PackageManifest.class/class/code-critics/rejectClasses.st A Kernel.package/PackageManifest.class/class/code-critics/rejectRules.st R Kernel.package/PackageManifest.class/instance/-- all --/=.st R Kernel.package/PackageManifest.class/instance/-- all --/hash.st R Kernel.package/PackageManifest.class/instance/-- all --/rejectClasses.st R Kernel.package/PackageManifest.class/instance/-- all --/rejectRules.st R Kernel.package/PackageManifest.class/instance/code-critics/rejectClasses.st R Kernel.package/PackageManifest.class/instance/code-critics/rejectRules.st R Kernel.package/PackageManifest.class/instance/comparing/=.st R Kernel.package/PackageManifest.class/instance/comparing/hash.st M Manifest-Core.package/TheManifestBuilder.class/definition.st M Manifest-Core.package/TheManifestBuilder.class/instance/-- all --/compileSelector_returnValue_.st M Manifest-Core.package/TheManifestBuilder.class/instance/-- all --/manifest.st M Manifest-Core.package/TheManifestBuilder.class/instance/accessing/manifest.st M Manifest-Core.package/TheManifestBuilder.class/instance/private/compileSelector_returnValue_.st M Manifest-Core.package/extension/RPackage/instance/packageManifest.st M Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/-- all --/testPackagePatternStringRootPackageTag.st M Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/tests/testPackagePatternStringRootPackageTag.st M RPackage-Core.package/RPackage.class/instance/-- all --/packageManifest.st M ScriptLoader40.package/ScriptLoader.class/instance/-- all --/commentForCurrentUpdate.st R ScriptLoader40.package/ScriptLoader.class/instance/-- all --/script614.st A ScriptLoader40.package/ScriptLoader.class/instance/-- all --/script615.st R ScriptLoader40.package/ScriptLoader.class/instance/-- all --/update40614.st A ScriptLoader40.package/ScriptLoader.class/instance/-- all --/update40615.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script614.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script615.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40614.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40615.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40615 15797 Backport 4.0: New PackageManifests should be classes, not instances https://pharo.fogbugz.com/f/cases/15797 http://files.pharo.org/image/40/40615.zip

June 23, 2015

[pharo-project/pharo-core] 98152b: 50129

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 98152bf9da1d9fba1abddb4a2829a96b6c9ad22e https://github.com/pharo-project/pharo-core/commit/98152bf9da1d9fba1abddb4a… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-06-23 (Tue, 23 Jun 2015) Changed paths: R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50128.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50129.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50128.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50129.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R System-Sources.package/SourceFileArray.class/class/initialize-release/install.st M System-Sources.package/SourceFileArray.class/class/instance creation/new_.st A System-Sources.package/SourceFileArray.class/instance/accessing/changesFileStream_.st M System-Sources.package/SourceFileArray.class/instance/accessing/readOnlyCopy.st R System-Sources.package/SourceFileArray.class/instance/accessing/size.st A System-Sources.package/SourceFileArray.class/instance/accessing/sourcesFileStream_.st M System-Sources.package/SourceFileArray.class/instance/initialization/initialize.st R System-Sources.package/SourceFileArray.class/instance/initialization/initialize_.st R System-Sources.package/SourceFileArray.class/instance/to remove/collect_.st A System-Sources.package/SourceFileArray.class/instance/to remove/size.st Log Message: ----------- 50129 15823 Clean up discouraged uses of SourceFiles and friends (8) https://pharo.fogbugz.com/f/cases/15823 http://files.pharo.org/image/50/50129.zip

June 23, 2015

[pharo-project/pharo-core]

by GitHub

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

June 23, 2015

Re: [Pharo-dev] RBEnvironments allClasses/Traits/Meta ...

by Yuriy Tymchuk

I would say, that besides #checkClass: and #checkMethod: rules should also have #checkMetaClass: this will allow rule developers to be more flexible, and will add a bit more certainty. Because sometimes you need to check both, then you implement a method and call it from #checkClass: and #checkMetaClass:. Sometimes you only need to check one of them. And you will always know that metaclass will not sendup in your method. Uko > On 23 Jun 2015, at 08:40, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > What if rules that need metaclasses ask for them explicitly to the class? > > environment allClasses do: [ :theInstanceSide | > self doSomethingWith: theInstanceSide. > self doSomethingWith: theInstanceSide classSide. ] > > Just putting another possibility on the table... > > El lun., 22 de jun. de 2015 a la(s) 10:40 p. m., Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> escribiÃ³: > > 2014-12-18 22:32 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>>: > Iâm ready to help with this issue, but as far as I can tell, itâs not hard to implement the mentors. Here we should decide on the meaning of the phrases. What are "all behaviorsâ and so on. The reason of the refactoring that Iâve done was that there were two methods with similar names that were doing different things. > > Uko > >> On 18 Dec 2014, at 21:19, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: >> >> Hi, >> >> some time ago Yuriy cleaned up the RBBrowserEnvironment methods for >> allClassesAndTraits(Do), classesDo, .... >> >> The fix was good and necessary (I think). But they had an impact >> on some SmallLint-rules (they arent applied on the class side) and the behavior >> for the different Environments changed (compared with Pharo3 >> (-> 14621 <https://pharo.fogbugz.com/default.asp?14621> Some RBBrowserEnvironments don't work well with Metaclasses)) >> >> As some SmallLint-rules need to iterate over the metaclasses as well and >> I don't want to revert Yuriys change, I 'll add another method that >> collect classes and metaclasses. >> >> So, I need some help, how to name this methods: >> >> all classes (Object, Integer, ....) -> allClasses, ok >> all classes and metaclasses (Object, Object class, Integer class ) -> ? allBehaviors? >> all classes and traits -> allClassesAndTraits, ok >> all classes and meta classes and traits and class traits -> ? no idea! >> all metaclasses and class traits -> allMeta(ClassesAndTraits) ? I don't know if we need this >> >> One problem with "allBehaviors" is, SystemNavigation uses allBehaviors to iterate >> over classes, metaclasses, traits and class traits, >> allthough a Trait is not a Behavior. (TClass isBehavior -> false) >> >> feedback is welcome >> >> >> nicolai >> >> > > > > > Pharo 3.0: > SystemNavigation default allClasses size. 4024 > Smalltalk allClasses size. 4024. > RBBrowserEnvironment default allClasses size. 4024 > RBBrowserEnvironment default classes size. 8048 > > Pharo 4.0: > > SystemNavigation default allClasses size. 5012 > Smalltalk allClasses size. 5012 > RBBrowserEnvironment default allClasses size. 5012 > RBBrowserEnvironment default classes size. 5012 > > -> I "define" the Pharo 4.0 behavior as the correct one. RBEnvironment>>#classes should not contain meta classes. > > Some other RBEnvironments and/or RBRules rely on the "classes = classes and metaclasses" (-> see issue > 14621 <https://pharo.fogbugz.com/default.asp?14621> > Some RBBrowserEnvironments don't work well with Metaclasses > 14230 <https://pharo.fogbugz.com/default.asp?14230> > Some rules aren't applied on the classside anymore > 15302 <https://pharo.fogbugz.com/default.asp?15302> > a RBEnvironment from #referencesTo: does not list meta classes > > I will change them, and if appropiate, add a new > classesAndMetaclasses resp. classesAndMetaclassesDo: > > I don't know about classesAndMetaclassesTraits. And I skip "behaviors" for now. > #allBehaviors is suspicious to me, I still don't > know what they are: > > Smalltalk globals allBehaviors includes:TBehavior. -> true (1) > TBehavior isBehavior. -> false (!) > > >

June 23, 2015

Re: [Pharo-dev] RBEnvironments allClasses/Traits/Meta ...

by Guillermo Polito

What if rules that need metaclasses ask for them explicitly to the class? environment allClasses do: [ :theInstanceSide | self doSomethingWith: theInstanceSide. self doSomethingWith: theInstanceSide classSide. ] Just putting another possibility on the table... El lun., 22 de jun. de 2015 a la(s) 10:40 p. m., Nicolai Hess < nicolaihess(a)web.de> escribiÃ³: > > 2014-12-18 22:32 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > >> Iâm ready to help with this issue, but as far as I can tell, itâs not >> hard to implement the mentors. Here we should decide on the meaning of the >> phrases. What are "all behaviorsâ and so on. The reason of the refactoring >> that Iâve done was that there were two methods with similar names that were >> doing different things. >> >> Uko >> >> On 18 Dec 2014, at 21:19, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >> Hi, >> >> some time ago Yuriy cleaned up the RBBrowserEnvironment methods for >> allClassesAndTraits(Do), classesDo, .... >> >> The fix was good and necessary (I think). But they had an impact >> on some SmallLint-rules (they arent applied on the class side) and the >> behavior >> for the different Environments changed (compared with Pharo3 >> (-> 14621 <https://pharo.fogbugz.com/default.asp?14621> Some >> RBBrowserEnvironments don't work well with Metaclasses)) >> >> As some SmallLint-rules need to iterate over the metaclasses as well and >> I don't want to revert Yuriys change, I 'll add another method that >> collect classes and metaclasses. >> >> So, I need some help, how to name this methods: >> >> all classes (Object, Integer, ....) -> allClasses, ok >> all classes and metaclasses (Object, Object class, Integer class ) -> ? >> allBehaviors? >> all classes and traits -> allClassesAndTraits, ok >> all classes and meta classes and traits and class traits -> ? no idea! >> all metaclasses and class traits -> allMeta(ClassesAndTraits) ? I don't >> know if we need this >> >> One problem with "allBehaviors" is, SystemNavigation uses allBehaviors to >> iterate >> over classes, metaclasses, traits and class traits, >> allthough a Trait is not a Behavior. (TClass isBehavior -> false) >> >> feedback is welcome >> >> >> nicolai >> >> >> >> > > > Pharo 3.0: > SystemNavigation default allClasses size. 4024 > Smalltalk allClasses size. 4024. > RBBrowserEnvironment default allClasses size. 4024 > RBBrowserEnvironment default classes size. 8048 > > Pharo 4.0: > > SystemNavigation default allClasses size. 5012 > Smalltalk allClasses size. 5012 > RBBrowserEnvironment default allClasses size. 5012 > RBBrowserEnvironment default classes size. 5012 > > -> I "define" the Pharo 4.0 behavior as the correct one. > RBEnvironment>>#classes should not contain meta classes. > > Some other RBEnvironments and/or RBRules rely on the "classes = classes > and metaclasses" (-> see issue > 14621 <https://pharo.fogbugz.com/default.asp?14621> > Some RBBrowserEnvironments don't work well with Metaclasses > 14230 <https://pharo.fogbugz.com/default.asp?14230> > Some rules aren't applied on the classside anymore > 15302 <https://pharo.fogbugz.com/default.asp?15302> > a RBEnvironment from #referencesTo: does not list meta classes > > I will change them, and if appropiate, add a new > classesAndMetaclasses resp. classesAndMetaclassesDo: > > I don't know about classesAndMetaclassesTraits. And I skip "behaviors" for > now. > #allBehaviors is suspicious to me, I still don't > know what they are: > > Smalltalk globals allBehaviors includes:TBehavior. -> true (1) > TBehavior isBehavior. -> false (!) > > > >

June 23, 2015