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

Re: [Pharo-dev] #milliseconds versus #milliSeconds

by Marcus Denker

> On 03 Mar 2015, at 14:52, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 03 Mar 2015, at 14:37, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> Sven Van Caekenberghe-2 wrote >>> Yes, maybe this could be made more consistent in Pharo 5, but it is of >>> course again a case of lots of pain for little gain ;-) >> >> I definitely recall feeling "lots of pain" with the subStringXyz -> >> substringXyz that we're still dealing with in recent updates (I think I >> started that push as a naive newbie), but I'm not sure about the "little >> gain" part. It's hard to quantify the negative effect of inconsistency in >> the system, or the empowering effect of uniformity. There's the practical >> "was /this/ case the milliS or the millis??", as well as the more subtle >> effect of a calm, happy feeling users may get from a system in which the >> little details have been cared for. >> >> IMNSHO: Fix all these little things now while so many changes are swirling >> around the system. The longer we wait, the more mature/widely-used Pharo >> gets, the less practical these changes will become > > I agree, but the recent #subStrings: to #substrings: forced me to add another package with one method to make Zinc work in Pharo 2, 3 and 4 (after I managed to convince others to make a change to pharo 3 too). > > There *is* pain in those external codebases trying to target multiple versions. > I said this already: we can not be backward compatible forever. There needs to be a cutoff. For me is is that we support one version back. We could do 2 versions. But there *has* to be a defined point in the past where we do not care anymore. Marcus

March 3, 2015

Re: [Pharo-dev] #milliseconds versus #milliSeconds

by Sven Van Caekenberghe

> On 03 Mar 2015, at 14:37, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Sven Van Caekenberghe-2 wrote >> Yes, maybe this could be made more consistent in Pharo 5, but it is of >> course again a case of lots of pain for little gain ;-) > > I definitely recall feeling "lots of pain" with the subStringXyz -> > substringXyz that we're still dealing with in recent updates (I think I > started that push as a naive newbie), but I'm not sure about the "little > gain" part. It's hard to quantify the negative effect of inconsistency in > the system, or the empowering effect of uniformity. There's the practical > "was /this/ case the milliS or the millis??", as well as the more subtle > effect of a calm, happy feeling users may get from a system in which the > little details have been cared for. > > IMNSHO: Fix all these little things now while so many changes are swirling > around the system. The longer we wait, the more mature/widely-used Pharo > gets, the less practical these changes will become I agree, but the recent #subStrings: to #substrings: forced me to add another package with one method to make Zinc work in Pharo 2, 3 and 4 (after I managed to convince others to make a change to pharo 3 too). There *is* pain in those external codebases trying to target multiple versions.

March 3, 2015

Re: [Pharo-dev] #milliseconds versus #milliSeconds

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote > Yes, maybe this could be made more consistent in Pharo 5, but it is of > course again a case of lots of pain for little gain ;-) I definitely recall feeling "lots of pain" with the subStringXyz -> substringXyz that we're still dealing with in recent updates (I think I started that push as a naive newbie), but I'm not sure about the "little gain" part. It's hard to quantify the negative effect of inconsistency in the system, or the empowering effect of uniformity. There's the practical "was /this/ case the milliS or the millis??", as well as the more subtle effect of a calm, happy feeling users may get from a system in which the little details have been cared for. IMNSHO: Fix all these little things now while so many changes are swirling around the system. The longer we wait, the more mature/widely-used Pharo gets, the less practical these changes will become ----- Cheers, Sean -- View this message in context: http://forum.world.st/milliseconds-versus-milliSeconds-tp4809142p4809151.ht… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 3, 2015

Re: [Pharo-dev] #milliseconds versus #milliSeconds

by Sven Van Caekenberghe

I last added a couple of methods to Duration (#whole[Micro|Milli|Nano]seconds) and chose the lower case option, which is the normal one in the larger world, as far as I understand it. Yes, maybe this could be made more consistent in Pharo 5, but it is of course again a case of lots of pain for little gain ;-) > On 03 Mar 2015, at 14:31, Ben Coman <btc(a)openInWorld.com> wrote: > > Using Finder, the majority representation in the image appears to be all-lowercase #milliseconds with only a few #milliSeconds. Googling indicates the former is usual. Is it worth logging a ticket for Pharo 5 to make the latter consistent? > > cheers -ben

March 3, 2015

#milliseconds versus #milliSeconds

by Ben Coman

Using Finder, the majority representation in the image appears to be all-lowercase #milliseconds with only a few #milliSeconds. Googling indicates the former is usual. Is it worth logging a ticket for Pharo 5 to make the latter consistent? cheers -ben

March 3, 2015

Re: [Pharo-dev] [Reflectivity] Tiny progress of the day: MetaLink

by Marcus Denker

> On 02 Mar 2015, at 15:39, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 02 Mar 2015, at 13:10, Clara Allende <clari.allende(a)gmail.com <mailto:clari.allende@gmail.com>> wrote: >> >> >> Le 2 mars 2015 05:38, "Marcus Denker" <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> a Ã©crit : >> > >> > Hi, >> > >> > The tiny progress of today: I reviewed the code for the MetaLink from Claraâs Breakpoints >> > and added it to Pharo4. >> >> Yay! There was also one extension method in Slot to make work with those, have you seen it? >> >> > > Ah, the uninstallâ¦ I will add it. > Part of my tiny step forward of today: https://pharo.fogbugz.com/f/cases/15039/Move-Reflectivity-related-methods-a… <https://pharo.fogbugz.com/f/cases/15039/Move-Reflectivity-related-methods-a…> - Move Reflectivity related methods and classes to Reflectivity - LinkWrapper>>#uninstall from breakpoints prototype Marcus

March 3, 2015

1 Dollar recogniser in Pharo

by stepharo

HI does any of you ported the 1Dollar recogniser from Squeak to Pharo? Stef

March 3, 2015

[Slots] tiny improvement of today

by Marcus Denker

-> there is now #allSlotsEverywhere (following #allInstVarNamesEverywhere -> added more cards to Trello: https://trello.com/b/d59lgZFB Marcus

March 3, 2015

Re: [Pharo-dev] [Pharo4] Image size now 23.2MB

by Marcus Denker

> > > Size: 22.9MB (== 21.8 MiB, people obsessed with memory size tend to think binary). > Another ~150KB savings for review: https://pharo.fogbugz.com/f/cases/15032/ScriptLoader-does-not-need-to-log-t… <https://pharo.fogbugz.com/f/cases/15032/ScriptLoader-does-not-need-to-log-t…> Scriptloader has an old mechanism to log all descriptions of updates. These days the discription is a) always just a lost of issue tracker issues b) available in the Monticello history of the ScriptLoader package. ==> the slice removes the ~160Kb String from the image. Marcus

March 3, 2015

[pharo-project/pharo-core]

by GitHub

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

March 3, 2015