- Pharo-dev - lists.pharo.org

[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

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

by stepharo

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] Kind of RBRenameMethodRefactoring but for closures?

by Thierry Goubier

Le 09/11/2015 17:38, Mariano Martinez Peck a Ã©crit : > Thierry, I have a last question. My last requirement will basically be > to find ANY node that would match the regex *oldSelector* and rename it > to *newSelector* being that.. a literal string, a literal symbol, a > message send, a tempVar name, a comment, etc... I guess there is a > simpler way that defining rewrite for each type of node right? > I can always do a "(methodSource substrings detect: [:each | each > matches: '*oldSelector'] ifNone: [#()] ) each2: [:each2 | copReplace. > .... ] I think that if it is really everywhere, then it may works better to just do text replace (methodSource copyReplaceAll: 'oldSelector' with: 'newSelector'). But remember that it will touch everything (pragmas, varNames, comments, etc.) > but RB is probably better. It gives you more control to what you will change. But then you will have to write rewrites for all types of nodes (around 6 or 7?). > Any clues in this last requirement? Well, one thing which may be interesting would be to consider encapsulating the rewrites in refactoring commands, and bring them as a composite change, so that you could launch a rewrite, recover all those method changes, apply (execute) them, check the result with the possibility of undoing them. But I'm not familiar with that part of RB. I do consider it could become significant with EPICEA. It has been a long term project to have AltBrowser make all coding actions as refactoring commands so that EPICEA could log them properly, but its only partly there (and has been for years now)... and EPICEA is not yet here as well (but could be soon). Thierry

Nov. 9, 2015

Re: [Pharo-dev] How to integrate change on class Point

by Marcus Denker

I think it would be enough to do it when the shape of the class changes (adding/removing variables). Marcus > On 09 Nov 2015, at 12:07, stepharo <stepharo(a)free.fr> wrote: > > so when does it report it? When we redefine a method? > > > Le 9/11/15 12:05, Marcus Denker a Ã©crit : >>> On 08 Nov 2015, at 18:23, stepharo <stepharo(a)free.fr> wrote: >>> >>> There is a trick >>> Tx henrik >>> DangerousClassNotifier disable :) >>> >> Yes, but we should actually fix the class builder to not raise the error when just changing a commentâ¦ >> but then, this happens not often so I did not yet even report an issue for it. >> >> Marcus >> > >

Nov. 9, 2015