December 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] SmalltalkHub bugs & hangs :-(

by Esteban A. Maringolo

El Mon Dec 01 2014 at 12:19:53 PM, Andreas Wacknitz <A.Wacknitz(a)gmx.de> escribiÃ³: > > Am 01.12.14 12:34, schrieb kilon alios: > > No of course not. That would have been a deal braker. > > Personally I prefer using Sourcetree to browser history of commits than > using the pharo on board tools. Pharo is good on that respect, but > sourcetree is better > > Alas Sourcetree is only available for Windows and Mac OSX. > Non-portable programs die with their system. > Closed source programs die with their company. > It's not a matter of SourceTree or other program, it's about your git GUI app of preference. You can use plain git from the command line if you prefer. The git repo is portable, the client is up to you.

Dec. 1, 2014

Re: [Pharo-dev] Video Tutorial - Github for Pharo using Sourcetree

by Eliot Miranda

Hi Dale, On Sun, Nov 30, 2014 at 10:52 AM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > Eliot, > > If we remove the meta data from the FileTree repo, then it will be > necessary to use the `adopt` command to restore the proper version history > before interchanging copying to an mcz repo or trying to merge with an mcz > package ... > > `adopt` is not an ideal solution, which is exactly why I've (stubbornly) > maintained the monticello meta data ... > So *please* continue to be stubborn :-) My statement about "as the community begins to use git-based repos as their > primary repository" includes a broad definition of community, in my mind:) > +1 Cross-platform package portability has always been one of my primary > concerns and I do share your concern that it's a big step to remove the > monticello meta data from FileTree (again it's why I haven't done so yet) > ... > > So far this is a bridge that doesn't need to be crossed, but when it > becomes time to cross it, there might be other options that can be applied > (perhaps an ancestry can be synthesized from the git meta data?) > Which would be reasonable, but it needs to be there. And thanks. Dale > > > > > On Sun, Nov 30, 2014 at 9:31 AM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> Hi Dale, >> >> On Nov 30, 2014, at 8:14 AM, Dale Henrichs < >> dale.henrichs(a)gemtalksystems.com> wrote: >> >> >> >> On Sun, Nov 30, 2014 at 7:51 AM, kilon alios <kilon.alios(a)gmail.com> >> wrote: >> >>> So far all I knew that using git for binary files was a no go, doable >>> but not recommended. Thus I found strange that filetree uses binary files. >>> >>> >> Well the files are text files, but because the text represents structured >> data, the line-based auto-merge used by git is not correct ... >> >> The monticello version files have been included in FileTree to make it >> possible to move the packages seamlessly between Filetree-based >> repositories and mcz based repositories ... without that meta data, once >> you move a package to FileTree it could not be moved back into an mcz >> repository without losing all of the package history. >> >> When I was first introducing FileTree, I thought it was important that >> folks be able to test out the git waters without making an "irreversible >> commitment to git." Even today I find myself needing to move packages back >> and forth between git and mcz repositories, so Thierry's merge-tools has >> made it possible for me to have my cake and eat it too. >> >> I have been threatening to remove the monticello meta data from FileTree >> (or at least make it optional), but I just haven't had the time or >> motivation to do so ... again Thierry's merge-tool means that I never have >> to deal with a manual merge of the version file, so for me I never have to >> think about it ... >> >> As the tool sets for supporting git improve and as the community begins >> to use git-based repos as their primary repository, it will make sense to >> remove the monticello meta data from FileTree ... >> >> >> Will that mean that packages will still be able to be interchanged with >> Monticello? If yes, will that mean that packages will still be able to >> be merged with Monticello? >> >> Dale >> >> > -- best, Eliot

Dec. 1, 2014

Re: [Pharo-dev] Duration year

by Chris Cunningham

Hi. I was working on a GenericYear that was intended to be used for DateAndTime calculus - to be able to add and subtract an arbitrary number of years. The class by itself would not know the days - it is an arbitrary (generic) Year. It would only know the number of days when it is added (or subtracted) from an actual date (or timespan). The idea was that it would have a very specific and limited scope of responsibility. -cbc On Sat, Nov 22, 2014 at 3:03 AM, Hilaire <hilaire(a)drgeo.eu> wrote: > I saw some discussion about Duration and year calculus in the list > > Given that it is impossible to determine the number of days in a year > without the calendar years, should not 365.25 be used in place of 365 to > minimize the error ? > > So it could look like: > > Duration class >> years: aNumber > ^ self days: (aNumber * 365.25) truncated seconds: 0 > > > Hilaire > > -- > Dr. Geo - http://drgeo.eu > iStoa - http://istoa.drgeo.eu > > >

Dec. 1, 2014

Re: [Pharo-dev] WhatsUp from: 2014-12-01 until: 2014-12-14

by Tudor Girba

On Mon, Dec 1, 2014 at 5:51 PM, Ben Coman <btc(a)openinworld.com> wrote: > seaside(a)rmod.lille.inria.fr wrote: > >> Hi! We're sending this automatic email twice a month, to give the >> community an opportunity to easily know what's happening and to coordinate >> efforts. Just answer informally, and feel free to spawn discussions >> thereafter! >> >> ### Here's what I've been up to since the last WhatsUp: >> >> > * Made my first contribution to the VM, adding <modifier> keypress events > for OSX. > Thanks a lot for that! :) Doru -- www.tudorgirba.com "Every thing has its own flow"

Dec. 1, 2014

Re: [Pharo-dev] [pharo-project/pharo-core]

by Esteban Lorenzano

but it didnât work so we will need to insist :( Esteban > On 01 Dec 2014, at 18:13, GitHub <noreply(a)github.com> wrote: > > Branch: refs/heads/4.0 > Home: https://github.com/pharo-project/pharo-core > Commit: 6f6c06023fa6406371a1e66a33159f03ea6427a2 > https://github.com/pharo-project/pharo-core/commit/6f6c06023fa6406371a1e66a… > Author: Jenkins Build Server <board(a)pharo-project.org> > Date: 2014-12-01 (Mon, 01 Dec 2014) > > Changed paths: > M EmbeddedFreeType.package/EmbeddedFreeTypeFontFontDescription.class/class/accessing/fontContents.st > M EmbeddedFreeType.package/EmbeddedFreeTypeFontFontDescription.class/class/accessing/installAllFontsIn_.st > M EmbeddedFreeType.package/EmbeddedFreeTypeFontFontDescription.class/class/accessing/installFontsIn_.st > M EmbeddedFreeType.package/EmbeddedFreeTypeFontFontDescription.class/class/accessing/originalFileName.st > M EmbeddedFreeType.package/EmbeddedFreeTypeFontInstaller.class/class/accessing/current.st > M EmbeddedFreeType.package/EmbeddedFreeTypeFontInstaller.class/class/extra fonts registration/registerFont_.st > R EmbeddedFreeType.package/OpenSansRegular.class/README.md > R EmbeddedFreeType.package/OpenSansRegular.class/class/accessing/fontContents.st > R EmbeddedFreeType.package/OpenSansRegular.class/class/accessing/originalFileName.st > R EmbeddedFreeType.package/OpenSansRegular.class/class/class initialization/initialize.st > R EmbeddedFreeType.package/OpenSansRegular.class/definition.st > M EmbeddedFreeType.package/SourceCodeFonts.class/class/accessing/defaultFontName.st > A EmbeddedFreeType.package/SourceCodeFonts.class/class/accessing/setSourceCodeFontsDefault.st > M EmbeddedFreeType.package/SourceCodeFonts.class/class/font registration/registerFonts_.st > A EmbeddedFreeType.package/SourceSansProRegular.class/README.md > A EmbeddedFreeType.package/SourceSansProRegular.class/class/accessing/fontContents.st > A EmbeddedFreeType.package/SourceSansProRegular.class/class/accessing/originalFileName.st > A EmbeddedFreeType.package/SourceSansProRegular.class/class/class initialization/initialize.st > A EmbeddedFreeType.package/SourceSansProRegular.class/definition.st > M FreeType.package/FreeTypeFontProvider.class/instance/loading and updating/updateEmbeddedFreeTypeFonts.st > M FreeType.package/FreeTypeFontProvider.class/instance/loading and updating/updateFromSystem.st > M FreeType.package/FreeTypeSettings.class/class/startup/startUp_.st > A FreeType.package/FreeTypeSettings.class/class/startup/updateFreeType.st > A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script393.st > A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40393.st > M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st > > Log Message: > ----------- > 40393 > 14553 FreeType default fonts not correctly loaded when image initializes > https://pharo.fogbugz.com/f/cases/14553 > > http://files.pharo.org/image/40/40393.zip > >

Dec. 1, 2014

[pharo-project/pharo-core]

by GitHub

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

Dec. 1, 2014

[pharo-project/pharo-core] 6f6c06: 40393

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 6f6c06023fa6406371a1e66a33159f03ea6427a2 https://github.com/pharo-project/pharo-core/commit/6f6c06023fa6406371a1e66a… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-12-01 (Mon, 01 Dec 2014) Changed paths: M EmbeddedFreeType.package/EmbeddedFreeTypeFontFontDescription.class/class/accessing/fontContents.st M EmbeddedFreeType.package/EmbeddedFreeTypeFontFontDescription.class/class/accessing/installAllFontsIn_.st M EmbeddedFreeType.package/EmbeddedFreeTypeFontFontDescription.class/class/accessing/installFontsIn_.st M EmbeddedFreeType.package/EmbeddedFreeTypeFontFontDescription.class/class/accessing/originalFileName.st M EmbeddedFreeType.package/EmbeddedFreeTypeFontInstaller.class/class/accessing/current.st M EmbeddedFreeType.package/EmbeddedFreeTypeFontInstaller.class/class/extra fonts registration/registerFont_.st R EmbeddedFreeType.package/OpenSansRegular.class/README.md R EmbeddedFreeType.package/OpenSansRegular.class/class/accessing/fontContents.st R EmbeddedFreeType.package/OpenSansRegular.class/class/accessing/originalFileName.st R EmbeddedFreeType.package/OpenSansRegular.class/class/class initialization/initialize.st R EmbeddedFreeType.package/OpenSansRegular.class/definition.st M EmbeddedFreeType.package/SourceCodeFonts.class/class/accessing/defaultFontName.st A EmbeddedFreeType.package/SourceCodeFonts.class/class/accessing/setSourceCodeFontsDefault.st M EmbeddedFreeType.package/SourceCodeFonts.class/class/font registration/registerFonts_.st A EmbeddedFreeType.package/SourceSansProRegular.class/README.md A EmbeddedFreeType.package/SourceSansProRegular.class/class/accessing/fontContents.st A EmbeddedFreeType.package/SourceSansProRegular.class/class/accessing/originalFileName.st A EmbeddedFreeType.package/SourceSansProRegular.class/class/class initialization/initialize.st A EmbeddedFreeType.package/SourceSansProRegular.class/definition.st M FreeType.package/FreeTypeFontProvider.class/instance/loading and updating/updateEmbeddedFreeTypeFonts.st M FreeType.package/FreeTypeFontProvider.class/instance/loading and updating/updateFromSystem.st M FreeType.package/FreeTypeSettings.class/class/startup/startUp_.st A FreeType.package/FreeTypeSettings.class/class/startup/updateFreeType.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script393.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40393.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40393 14553 FreeType default fonts not correctly loaded when image initializes https://pharo.fogbugz.com/f/cases/14553 http://files.pharo.org/image/40/40393.zip

Dec. 1, 2014

Re: [Pharo-dev] WhatsUp from: 2014-12-01 until: 2014-12-14

by Ben Coman

seaside(a)rmod.lille.inria.fr wrote: > Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! > > ### Here's what I've been up to since the last WhatsUp: > * Made my first contribution to the VM, adding <modifier> keypress events for OSX. * Refactored class variables and class-side methods of Delay to instance side of new DelayScheduler. > > ### What's next, until 2014-12-14 (*): > * Change Delays/DelayScheduler base from milliseconds to microseconds, to fix the commandline issue with "super fast delay" * Factor out the mutex interthread synchronisation code and provide some alternatives (e.g. Semaphore & Spinlock) > > (*) we'll be expecting results by then ;) > >

Dec. 1, 2014

14353 Delay refactoring (part 2) - change from milliseconds to microseconds

by Ben Coman

The change of Delay from milliseconds to microseconds is ready for human review. (https://pharo.fogbugz.com/default.asp?14353) With this change from milliseconds to microseconds, clock rollover is eliminated, but it seems Delays run at reduced performance. newCodeEnabled FALSE TRUE 128507 101227 delays scheduled per second 100% 79% relative performance 7.8 9.9 microseconds per scheduled delay 100% 127% relative performance I "guess" this is due to the move from 32bit millisecond immediate SmallIntegers to 64bit microsecond boxed LargePositiveIntegers. It would be interesting to check this on Spur64, but for now, is this performance penalty a reasonable trade for eliminating delay clock rollover? The Delay class comment warns of the critical performance its high priority event loop, and on paper a 21% drop in performance seems significant, but actually the main Morph interCyclePause is 50 milliseconds. So... (9.9 - 7.8) / 50000 = 0.004% difference in performance. (Did I get that right?) Comments? P.S. DelayBenchmark results... =============== DelayBenchmark withNewCodeEnabled: true... #ConcurrentDelays: 1000 . Count: 39018 per second #ConcurrentDelays: 2000 . Count: 71906 per second #ConcurrentDelays: 3000 . Count: 98010 per second #ConcurrentDelays: 4000 . Count: 101227 per second #ConcurrentDelays: 5000 . Count: 64728 per second #ConcurrentDelays: 6000 . Count: 90495 per second #ConcurrentDelays: 7000 . Count: 89220 per second #ConcurrentDelays: 8000 . Count: 89585 per second #ConcurrentDelays: 9000 . Count: 88393 per second #ConcurrentDelays: 10000 . Count: 89073 per second DelayBenchmark withNewCodeEnabled: false... #ConcurrentDelays: 1000 . Count: 39498 per second #ConcurrentDelays: 2000 . Count: 77808 per second #ConcurrentDelays: 3000 . Count: 99889 per second #ConcurrentDelays: 4000 . Count: 117632 per second #ConcurrentDelays: 5000 . Count: 128507 per second #ConcurrentDelays: 6000 . Count: 118729 per second #ConcurrentDelays: 7000 . Count: 114437 per second #ConcurrentDelays: 8000 . Count: 114792 per second #ConcurrentDelays: 9000 . Count: 115137 per second #ConcurrentDelays: 10000 . Count: 113973 per second

Dec. 1, 2014

Re: [Pharo-dev] [squeak-dev] IdentitySet>>collect:

by Eliot Miranda

On Fri, Nov 28, 2014 at 7:42 PM, Ben Coman <btc(a)openinworld.com> wrote: > Levente Uzonyi wrote: > >> The problem with changing #species is that it's overused. There are at >> least three different things it's used for in the Collection hierarchy: >> - the class of the object returned by #collect: (Set's subclasses are the >> exception since 2000 or so, except for WeakSet, but that's really strange, >> and should revisited) >> - the class of the object returned by #select: and friends >> - the class used for comparison of collections >> > > So should there be #collectSpecies ? > No. That's what species was invented for in the first place. > Which defaults to "^self species" and is overidden as required. > > In the case of Sets, you start with an "unordered collection without > duplicates", but since #collect can introduce duplicates, you end up with > "an unordered collection with duplicates" --> Bag (per Dave's suggestion) > > So I think its reasonable that the following two snippets should produce > the same result. > > oc := OrderedCollection newFrom: #( 1 2 3 4 5 ). > (oc collect: [ :e | e even ]) occurrencesOf: true. "--> 2" > > s := Set newFrom: #( 1 2 3 4 5 ). > (s collect: [ :e | e even ]) occurrencesOf: true. "--> 2" > > > which you get with the following change... > > Set>>collectSpecies > ^Bag > > Set>>collect: aBlock > | result | > result := self collectSpecies new: self size. > array do: [:each | each ifNotNil: [result add: (aBlock value: each > enclosedSetElement)]]. > ^ result > > > > >> HashedCollection >> #select: uses #species. Changing IdentitySet >> >>> #species to return a Set would break #select:, because a ~~ b doesn't >>>> >>> imply a ~= b. IdentitySet is the optimal class for the return value of >> IdentitySet >> #select:, because it's guaranteed to be able to hold all >> selected values. I think the same applies to all other kind of sets (and >> collections, because #select: is simply reducing the number of elements). >> >> This is not the first time this discussion comes up. There was one in >> 2003[1], but the thread is hard to follow. And there was one in 2009[2]. >> I think the conclusion was that it's better to leave the method as it is, >> because there's no better way to do it. >> Sure, we could use #species in #collect:, but it would break quite a lot >> of stuff. For example: >> >> | k | >> k := KeyedSet keyBlock: [ :each | each first ]. >> k add: #[1]; add: #[2]. >> k collect: [ :each | each size ] >> > > > That works with the above change to produce --> a Bag(1 1) > > >> Currently this snippet returns "a Set(1)". Using #species in #collect: >> (via #copyEmpty) one would get an error, because SmallInteger does not >> understand #first. Changing the #species of KeyedSet would break #select:. >> >> So IMHO when you #collect: from a set, you should always use >> #collect:as:. Here is a (partial) list of methods which send #collect: to a >> Set: >> >> Categorizer >> #changeFromCategorySpecs: >> ClassFactoryForTestCase >> #createdClassNames >> Dictionary >> #unreferencedKeys >> MCDependencySorterTest >> #assertItems:orderAs:withRequired:toLoad: >> extraProvisions: >> MessageNode >> #analyseTempsWithin:rootNode:assignmentPools: >> MethodNode >> #referencedValuesWithinBlockExtent: >> SetTest >> #testCollect >> SetWithNilTest >> #runSetWithNilTestOf: >> >> There are probably many more, but we should fix all of them. A static >> analyzer could help a lot. >> >> Levente >> >> [1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2003- >> February/052659.html >> [2] http://lists.squeakfoundation.org/pipermail/squeak-dev/2009- >> November/141016.html >> >> >> >> On Wed, 26 Nov 2014, David T. Lewis wrote: >> >> It seems to me that Object>>species is intended to handle this sort of >>> issue. >>> >>> For IdentitySet, it answers what Eliot was expecting: >>> >>> IdentitySet new species ==> IdentitySet >>> Set new species ==> Set >>> >>> However, IdentitySet>>collect: does not make use of this, and it answers >>> a Set for the reasons that Levente explained. >>> >>> Answering an Array or and OrderedCollection would not really make sense, >>> because sets are unordered collections (but Bag might be better). >>> >> > Bag is better. > > >>> Shouldn't we have an implementation of IdentitySet>>species that answers >>> Set (or Bag), with a method comment explaining why this is the case, and >>> with all of the collection methods using #species to answer the right >>> kind of result? >>> >>> I note that IdentitySet>>collect: answers a Set, but IdentitySet>select: >>> sends #species and therefore answers an IdentitySet. >>> >>> So I think that if we want the #species of an IdentitySet to be a Set, >>> then we should make it so, and give it a method comment to explain the >>> rationale. And the #collect: and #select: methods should both answer a >>> result of that #species. >>> >> > I think the species of #collect: and #select: are intrinsically different. > #collect: is a transformation. > > >>> Dave >>> >>> >>> On Thu, Nov 27, 2014 at 01:14:30AM +0100, Levente Uzonyi wrote: >>> >>>> Your example hides the problem of ordering - what Tobias is asking >>>> about - >>>> so here's another: >>>> >>>> (IdentitySet withAll: #(1 1.0)) collect: [ :each | each class ] >>>> >>>> If IdentitySet >> #collect: were returning an Array, then what would be >>>> the >>>> answer? >>>> >>>> { SmallInteger. Float } or { Float. SmallInteger } ? >>>> >>> > --> a Bag(SmallInteger Float) > > >>>> If you really want to have the resulting collection have the same size, >>>> but avoid the problem with ordering, then what you really need is a Bag. >>>> >>> > To me that makes the most sense. > > >>>> On Thu, 27 Nov 2014, Frank Lesser wrote: >>>> >>>> Hi Tobias, >>>>> agree, a problem of "OrderedCollection" >>>>> not to break a lot of other things we could return an Array. >>>>> but for me collecting has priority. >>>>> Frank >>>>> >>>>> -----Urspr?ngliche Nachricht----- >>>>> Von: squeak-dev-bounces(a)lists.squeakfoundation.org >>>>> [mailto:squeak-dev-bounces@lists.squeakfoundation.org] Im Auftrag von >>>>> Tobias >>>>> Pape >>>>> Gesendet: Donnerstag, 27. November 2014 00:48 >>>>> An: The general-purpose Squeak developers list >>>>> Betreff: Re: [squeak-dev] IdentitySet>>collect: >>>>> >>>>> >>>>> On 27.11.2014, at 00:34, Frank Lesser <frank-lesser@lesser-software. >>>>> com> >>>>> wrote: >>>>> >>>>> hmm, not convinced >>>>>> >>>>>> (IdentitySet withAll: #(1 1.0)) collect: [:e| e asInteger ] >>>>>> OrderedCollection(1 1 ) >>>>>> >>>>>> in LSWVST ( one-to-one ), you collect results of evaluating a block on >>>>>> objects. >>>>>> >>>>>> Frank >>>>>> maybe I am wrong ... >>>>>> >>>>> >>>>> Where would the order come from for that _Ordered_Collection? >>>>> >>>> > An unordered OrderedCollection --> Bag > > cheers -ben > > -- best, Eliot

Dec. 1, 2014