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

Re: [Pharo-dev] [ANN] No-Metadata mode for GitFileTree

by Dale Henrichs

Submitted a FileTree bug[1] for this ... I think this is more a function of FileTree than Metacello ... but I have to uncover the "cypress fix" and then think about the best place to make the fix .... Dale [1] https://github.com/dalehenrich/filetree/issues/166 On 11/9/15 5:27 PM, Dale Henrichs wrote: > > > On 11/9/15 5:08 PM, Thierry Goubier wrote: >> Hi Dale, >> >> I'm back at that again. >> >> And I think that Metacello is already failing with repositories that >> have true branches (git + filetree). Metacello delegates to >> Monticello which rely on full ordering to establish upgrades or >> loading preferences. And on repositories with branches, each branch >> has its own ordering, making upgrades a possible problem (such as >> switching to a new branch with a new version and discover there that >> the top of that branch has a lower version number than the previous >> version == no load). > Hmmm ... I can see that this could happen ... >> >> Granted, this is less probable, but could surprise... > I don't like surprises:) >> >> Now, if Metacello could use the semantic versionning present in the >> Configurations and Baselines... > Semantic versioning is only used in ConfigurationOf subclasses ... the > notion with git is that the branch should be loaded whether or not it > is an "Monticello package upgrade" or not... I'll have to think on > this one a bit .... I'm in Buenos Aires for Smalltalks this week ... > but I consider this to be somewhat of a major bug, given that folks > are moving more and more to git .... it may be as "simple" as turning > on the "cypress url" for all FileTree repos .... but I want to think > through this one a bit more ... > > Dale >

Nov. 9, 2015

Re: [Pharo-dev] [ANN] No-Metadata mode for GitFileTree

by Dale Henrichs

On 11/9/15 5:08 PM, Thierry Goubier wrote: > Hi Dale, > > I'm back at that again. > > And I think that Metacello is already failing with repositories that > have true branches (git + filetree). Metacello delegates to Monticello > which rely on full ordering to establish upgrades or loading > preferences. And on repositories with branches, each branch has its > own ordering, making upgrades a possible problem (such as switching to > a new branch with a new version and discover there that the top of > that branch has a lower version number than the previous version == no > load). Hmmm ... I can see that this could happen ... > > Granted, this is less probable, but could surprise... I don't like surprises:) > > Now, if Metacello could use the semantic versionning present in the > Configurations and Baselines... Semantic versioning is only used in ConfigurationOf subclasses ... the notion with git is that the branch should be loaded whether or not it is an "Monticello package upgrade" or not... I'll have to think on this one a bit .... I'm in Buenos Aires for Smalltalks this week ... but I consider this to be somewhat of a major bug, given that folks are moving more and more to git .... it may be as "simple" as turning on the "cypress url" for all FileTree repos .... but I want to think through this one a bit more ... Dale

Nov. 9, 2015

Re: [Pharo-dev] [ANN] No-Metadata mode for GitFileTree

by Dale Henrichs

On 11/8/15 2:04 PM, Thierry Goubier wrote: > Le 08/11/2015 17:41, Dale Henrichs a Ã©crit : >> >> >> On 11/7/15 10:00 AM, Thierry Goubier wrote: >>> Oh yes, >>> >>> I can announce that from now on, the development version of >>> GitFileTree for Pharo 5 handles FileTree repositories without most of >>> the metadata (precisely version and methodProperties). >>> >>> This makes the format a lot more DVCS friendly (Git, Fossil, Hg, SVN, >>> all...) by cutting the noise on diffs and conflicts on merge and >>> cherry picking. >>> >>> Note: it only apply to brand new repositories; nothing is changed for >>> pre-existing ones. >>> >>> Note2: reading those Metadata-less repositories with FileTree does >>> give you packages without metadata: no version history, no author, no >>> author nor timestamp on methods. >>> >>> Note3: it is possible to hack a repo from metadata to non-metadata >>> mode, but I won't explain it. >>> >>> Enjoy and tell me how it works for you. I'm especially interested by >>> heavy branchers/mergers reports :) >>> >>> Thierry >>> >> Thierry, >> >> You want to double check that Metacello works correctly with these >> metadata-less packages ... if you are continuing to increment the >> "package version" there shouldn't be a problem, but when I did a similar >> experiment a year or so ago, I found that I had to teach Metacello to >> ignore the "package version" and load the package anyway ... the normal >> procedure for Monticello packages and Metacello is not load a package if >> the "package version" is less than or equal to the package already >> loaded .... I did make an extension to Metacello to make this work .... >> I can hunt it up if needed and make it part of the standard release (I >> may have kept it as part of tODE) ... > > Hi Dale, > > GitFileTree without metadata on disk does not mean no metadata for > Monticello/Metacello to work with; as long as you reach the git log > info, then it will work exactly as usual (incrementing version > numbers, etc...), with the usual caveats (i.e., if you limit depth > when cloning with git, version numbers do change). > > However, when accessing via FileTree (for example github:// urls), > then, yes, version numbers become 1. > > It will only matter when updating an already loaded project via a > github:// or bitbucket:// url. And there, simply allowing Metacello to > load if repository version is >= to existing version should take care > of it. This is the sticky wicket ... what I did to "solve the problem" was to define a Cypress url (I think) that would arrange for the proper loading to take place (ignore monticello meta data and load unconditionally) .... this sounds bad, but Monticello is smart enough to only load the changed definitions, so loading the same package over and over will not load anything ... you do get the overhead of ccreating definitions from disk ... but that might not be as big a deal these days ... > > I have an idea of possible solutions. We'll see how it goes and solve > that when we'll have a serious push around git ;) Agreed ... I just wanted to point out this potentially surprising tidbit:) Dale

Nov. 9, 2015

[pharo-project/pharo-core]

by GitHub

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

Nov. 9, 2015

[pharo-project/pharo-core] 006851: 50430

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 006851356e13cd0d0e4741193ff611e868d38305 https://github.com/pharo-project/pharo-core/commit/006851356e13cd0d0e474119… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-11-09 (Mon, 09 Nov 2015) Changed paths: M Kernel.package/Point.class/README.md M Kernel.package/Point.class/instance/arithmetic/abs.st M Kernel.package/Point.class/instance/arithmetic/max.st M Kernel.package/Point.class/instance/arithmetic/min.st M Kernel.package/Point.class/instance/arithmetic/reciprocal.st A Kernel.package/Point.class/instance/testing/isIntegerPoint.st A Kernel.package/Point.class/instance/truncation and round off/ceiling.st A Kernel.package/Point.class/instance/truncation and round off/floor.st A Kernel.package/Point.class/instance/truncation and round off/roundDownTo_.st A Kernel.package/Point.class/instance/truncation and round off/roundUpTo_.st R Kernel.package/Point.class/instance/truncation and roundoff/ceiling.st R Kernel.package/Point.class/instance/truncation and roundoff/floor.st R Kernel.package/Point.class/instance/truncation and roundoff/isIntegerPoint.st R Kernel.package/Point.class/instance/truncation and roundoff/roundDownTo_.st R Kernel.package/Point.class/instance/truncation and roundoff/roundUpTo_.st M OpalTools.package/GTOpalScopeBrowser.class/instance/building/treeIn_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50429.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50430.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50429.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50430.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M SmartSuggestions.package/extension/OCLiteralVariable/instance/specialCommands.st Log Message: ----------- 50430 16967 Inspecting the Scopes presentation of some ProgramNodes results in an exception https://pharo.fogbugz.com/f/cases/16967 16963 Smalltalk globals not needed for smart suggestions of OCLiteralValiable https://pharo.fogbugz.com/f/cases/16963 16953 Clean Point Reciprocal comment and improving class comment! https://pharo.fogbugz.com/f/cases/16953 http://files.pharo.org/image/50/50430.zip

Nov. 9, 2015

Re: [Pharo-dev] [ANN] No-Metadata mode for GitFileTree

by Thierry Goubier

Hi Dale, I'm back at that again. And I think that Metacello is already failing with repositories that have true branches (git + filetree). Metacello delegates to Monticello which rely on full ordering to establish upgrades or loading preferences. And on repositories with branches, each branch has its own ordering, making upgrades a possible problem (such as switching to a new branch with a new version and discover there that the top of that branch has a lower version number than the previous version == no load). Granted, this is less probable, but could surprise... Now, if Metacello could use the semantic versionning present in the Configurations and Baselines... Thierry Le 08/11/2015 17:41, Dale Henrichs a Ã©crit : > > > On 11/7/15 10:00 AM, Thierry Goubier wrote: >> Oh yes, >> >> I can announce that from now on, the development version of >> GitFileTree for Pharo 5 handles FileTree repositories without most of >> the metadata (precisely version and methodProperties). >> >> This makes the format a lot more DVCS friendly (Git, Fossil, Hg, SVN, >> all...) by cutting the noise on diffs and conflicts on merge and >> cherry picking. >> >> Note: it only apply to brand new repositories; nothing is changed for >> pre-existing ones. >> >> Note2: reading those Metadata-less repositories with FileTree does >> give you packages without metadata: no version history, no author, no >> author nor timestamp on methods. >> >> Note3: it is possible to hack a repo from metadata to non-metadata >> mode, but I won't explain it. >> >> Enjoy and tell me how it works for you. I'm especially interested by >> heavy branchers/mergers reports :) >> >> Thierry >> > Thierry, > > You want to double check that Metacello works correctly with these > metadata-less packages ... if you are continuing to increment the > "package version" there shouldn't be a problem, but when I did a similar > experiment a year or so ago, I found that I had to teach Metacello to > ignore the "package version" and load the package anyway ... the normal > procedure for Monticello packages and Metacello is not load a package if > the "package version" is less than or equal to the package already > loaded .... I did make an extension to Metacello to make this work .... > I can hunt it up if needed and make it part of the standard release (I > may have kept it as part of tODE) ... > > Dale > >

Nov. 9, 2015

Re: [Pharo-dev] Woe unto thee who assigns to class-side #name!

by Gabriel Cotelli

Yes please!! . I hate Object>>#name. Let me know if you need help. On Nov 9, 2015 15:22, "stepharo" <stepharo(a)free.fr> wrote: > I would start to remove for real name from Object :) > > Stef > > > > Le 9/11/15 13:05, Sean P. DeNigris a Ã©crit : > >> Ben Coman wrote >> >>> But Class has an instance variable 'name', >>> and Class subclasses --> {ProtoObject class} >>> >> He he, of course. Thanks for the clarification! >> >> >> Ben Coman wrote >> >>> should that instance variable and accessors be renamed to 'classname'? >>> >> YES to a rename! Let's remove all mysterious gotchas for newbies (and me >> ha >> ha). This is an obscure and scary bug, because it prevents all operations >> on >> the package, so one can not even commit or file out the package. >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: >> http://forum.world.st/Woe-unto-thee-who-assigns-to-class-side-name-tp485973… >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> >> > >

Nov. 9, 2015

Re: [Pharo-dev] [Reflectivity] Object invalidate now works

by Marcus Denker

> On 13 Oct 2015, at 17:01, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 09 Oct 2015, at 13:47, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> Hi, >> >> The mechanism that is behind the MetaLinks is now working for Object 50378: >> >> Object methods do: #createTwin. >> Object methods do: #invalidate. >> >> This means we are very close on having that working on the whole image. >> >> Next steps: >> >> -> invalidate the whole kernel. > > Done. in 50384: > > Object package methods do: [ :method | > method createTwin. method invalidate]. > As of 50#429, this is now working for the complete systemâ¦ (silly bug in the end, like alwaysâ¦). Marcus

Nov. 9, 2015

[pharo-project/pharo-core]

by GitHub

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

Nov. 9, 2015

[pharo-project/pharo-core] 6f8953: 50429

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 6f89538ac4ef0b7fcf474b305f9bbd1be0f4c204 https://github.com/pharo-project/pharo-core/commit/6f89538ac4ef0b7fcf474b30… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-11-09 (Mon, 09 Nov 2015) Changed paths: M CodeExport.package/extension/SystemOrganizer/instance/fileOutCategory_on_initializing_.st M Reflectivity.package/ReflectiveMethod.class/instance/forwarding/flushCache.st A Reflectivity.package/extension/VirtualMachine/instance/metaLinkOptions.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50428.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50429.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50428.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50429.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R Slot.package/extension/ByteString/instance/asClassVariable.st R Slot.package/extension/ByteString/instance/asSlot.st A Slot.package/extension/String/instance/asClassVariable.st A Slot.package/extension/String/instance/asSlot.st M System-Support.package/SystemNavigation.class/instance/query/allMethodsWithSourceString_matchCase_.st M Traits.package/TClass.class/class/inquiries/rootsOfTheWorld.st M Traits.package/TClass.class/instance/copying/duplicateClassWithNewName_.st Log Message: ----------- 50429 16941 Slots can not have non-latin names https://pharo.fogbugz.com/f/cases/16941 16965 Smalltalk globals cleaned in system navigator and organiser and TClass https://pharo.fogbugz.com/f/cases/16965 16966 Invalidate whole image: more fixes https://pharo.fogbugz.com/f/cases/16966 http://files.pharo.org/image/50/50429.zip

Nov. 9, 2015