May 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Mocketry names again

by Tudor Girba

Yuppee! Thanks :) Doru > On May 23, 2016, at 12:18 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > And done. Version 3.4 deprecates "should got" and introduces "should receive". > All docs are updated. > > Prebuilt PDF can found here https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre… > > 2016-05-18 11:59 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > So at the end of week I will rename "should got" into "should receive" > > 2016-04-27 23:39 GMT+02:00 Carlos Lombardi <carlombardi(a)gmail.com>: > Hi again, > > ok, just to have coherence between the names for the two possible outcomes of a method, you could use #beReturnedBy instead of #beReturnedFrom: . You would have #beReturnedBy: and #beRaisedBy: > > On Wed, Apr 27, 2016 at 10:00 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2016-04-27 0:33 GMT+02:00 Carlos Lombardi <carlombardi(a)gmail.com>: > ... maybe > > #result should beTheResultOf: [mock someMessage]. > #result should not beTheResultOf: [mock anotherMessage]. > > It's nice.I think "The" can be omitted: > > #result should beResultOf: [mock someMessage]. > > But anyway I use word #return because there are different types of result: value return and error signal. There is no expression for last case but it would be like: > > anError should beRaisedBy: [mock someMessage] > > > -- www.tudorgirba.com www.feenk.com "Speaking louder won't make the point worthier."

May 23, 2016

Re: [Pharo-dev] Mocketry names again

by Denis Kudriashov

And done. Version 3.4 deprecates "should got" and introduces "should receive". All docs are updated. Prebuilt PDF can found here https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre… 2016-05-18 11:59 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > So at the end of week I will rename "should got" into "should receive" > > 2016-04-27 23:39 GMT+02:00 Carlos Lombardi <carlombardi(a)gmail.com>: > >> Hi again, >> >> ok, just to have coherence between the names for the two possible >> outcomes of a method, you could use #beReturnedBy instead of >> #beReturnedFrom: . You would have #beReturnedBy: and #beRaisedBy: >> >> On Wed, Apr 27, 2016 at 10:00 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >>> >>> 2016-04-27 0:33 GMT+02:00 Carlos Lombardi <carlombardi(a)gmail.com>: >>> >>>> ... maybe >>>> >>>> #result should beTheResultOf: [mock someMessage]. >>>> #result should not beTheResultOf: [mock anotherMessage]. >>>> >>> >>> It's nice.I think "The" can be omitted: >>> >>> #result should beResultOf: [mock someMessage]. >>> >>> >>> But anyway I use word #return because there are different types of >>> result: value return and error signal. There is no expression for last case >>> but it would be like: >>> >>> anError should beRaisedBy: [mock someMessage] >>> >>> >> >

May 23, 2016

Re: [Pharo-dev] cleaning the Pharo Catalog

by Cyril Ferlicot Delbecque

On 23/05/2016 10:00, Stephan Eggermont wrote: > Split into two categories? Those with full descriptions likely to load > and those probably needing some updates? > I like this option. Two tabs. A tab "PharoX" and a tab "Legacy" could be an idea. > Stephan > > > -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

May 23, 2016

[pharo-project/pharo-core]

by GitHub

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

May 23, 2016

[pharo-project/pharo-core] e22bb5: 60028

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: e22bb56e311438134062dea8f1c80822f144c27c https://github.com/pharo-project/pharo-core/commit/e22bb56e311438134062dea8… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-05-23 (Mon, 23 May 2016) Changed paths: M Collections-Abstract.package/Collection.class/instance/math functions/stdev.st R Kernel.package/Object.class/instance/updating/noteSelectionIndex_for_.st M Morphic-Widgets-Pluggable.package/PluggableListMorph.class/instance/updating/verifyContents.st M Refactoring-Core.package/RBAbstractClassVariableRefactoring.class/README.md M Refactoring-Core.package/RBAbstractInstanceVariableRefactoring.class/README.md M Refactoring-Core.package/RBAbstractVariablesRefactoring.class/README.md M Refactoring-Core.package/RBAccessorClassRefactoring.class/README.md M Refactoring-Core.package/RBAddClassRefactoring.class/README.md M Refactoring-Core.package/RBAddClassVariableRefactoring.class/README.md M Refactoring-Core.package/RBAddInstanceVariableRefactoring.class/README.md M Refactoring-Core.package/RBAddMethodRefactoring.class/README.md M Refactoring-Core.package/RBAddParameterRefactoring.class/README.md M Refactoring-Core.package/RBCategoryRegexRefactoring.class/README.md M Refactoring-Core.package/RBChangeMethodNameRefactoring.class/README.md M Refactoring-Core.package/RBChildrenToSiblingsRefactoring.class/README.md M Refactoring-Core.package/RBClassRefactoring.class/README.md M Refactoring-Core.package/RBClassRegexRefactoring.class/README.md M Refactoring-Core.package/RBCreateAccessorsForVariableRefactoring.class/README.md M Refactoring-Core.package/RBExpandReferencedPoolsRefactoring.class/README.md M Refactoring-Core.package/RBExtractMethodRefactoring.class/README.md M Refactoring-Core.package/RBExtractMethodToComponentRefactoring.class/README.md M Refactoring-Core.package/RBExtractToTemporaryRefactoring.class/README.md M Refactoring-Core.package/RBGenerateEqualHashRefactoring.class/README.md M Refactoring-Core.package/RBGeneratePrintStringRefactoring.class/README.md M Refactoring-Core.package/RBInlineAllSendersRefactoring.class/README.md M Refactoring-Core.package/RBInlineMethodFromComponentRefactoring.class/README.md M Refactoring-Core.package/RBInlineMethodRefactoring.class/README.md M Refactoring-Core.package/RBInlineParameterRefactoring.class/README.md M Refactoring-Core.package/RBInlineTemporaryRefactoring.class/README.md M Refactoring-Core.package/RBMethodName.class/README.md M Refactoring-Core.package/RBMethodRefactoring.class/README.md M Refactoring-Core.package/RBMoveMethodRefactoring.class/README.md M Refactoring-Core.package/RBMoveVariableDefinitionRefactoring.class/README.md M Refactoring-Core.package/RBPrettyPrintCodeRefactoring.class/README.md M Refactoring-Core.package/RBProtectInstanceVariableRefactoring.class/README.md M Refactoring-Core.package/RBProtocolRegexRefactoring.class/README.md M Refactoring-Core.package/RBPullUpClassVariableRefactoring.class/README.md M Refactoring-Core.package/RBPullUpInstanceVariableRefactoring.class/README.md M Refactoring-Core.package/RBPullUpMethodRefactoring.class/README.md M Refactoring-Core.package/RBPushDownClassVariableRefactoring.class/README.md M Refactoring-Core.package/RBPushDownInstanceVariableRefactoring.class/README.md M Refactoring-Core.package/RBPushDownMethodRefactoring.class/README.md M Refactoring-Core.package/RBRefactoring.class/README.md M Refactoring-Core.package/RBRefactoringManager.class/README.md M Refactoring-Core.package/RBRefactoryTyper.class/README.md M Refactoring-Core.package/RBRegexRefactoring.class/README.md M Refactoring-Core.package/RBRemoveClassRefactoring.class/README.md M Refactoring-Core.package/RBRemoveClassVariableRefactoring.class/README.md M Refactoring-Core.package/RBRemoveInstanceVariableRefactoring.class/README.md M Refactoring-Core.package/RBRemoveMethodRefactoring.class/README.md M Refactoring-Core.package/RBRemoveParameterRefactoring.class/README.md M Refactoring-Core.package/RBRenameClassRefactoring.class/README.md M Refactoring-Core.package/RBRenameClassVariableRefactoring.class/README.md M Refactoring-Core.package/RBRenameInstanceVariableRefactoring.class/README.md M Refactoring-Core.package/RBRenameMethodRefactoring.class/README.md M Refactoring-Core.package/RBRenameTemporaryRefactoring.class/README.md M Refactoring-Core.package/RBSourceRegexRefactoring.class/README.md M Refactoring-Core.package/RBSplitCascadeRefactoring.class/README.md M Refactoring-Core.package/RBSplitCascadeRefactoring.class/instance/preconditions/findMessageNodes.st A Refactoring-Core.package/RBSplitCascadeRefactoring.class/instance/printing/storeOn_.st M Refactoring-Core.package/RBSplitClassRefactoring.class/README.md M Refactoring-Core.package/RBTemporaryToInstanceVariableRefactoring.class/README.md M Refactoring-Core.package/RBVariableRefactoring.class/README.md A Refactoring-Tests-Core.package/RBSplitCascadeRefactoringTest.class/README.md A Refactoring-Tests-Core.package/RBSplitCascadeRefactoringTest.class/definition.st A Refactoring-Tests-Core.package/RBSplitCascadeRefactoringTest.class/instance/data/methodWithCascades.st A Refactoring-Tests-Core.package/RBSplitCascadeRefactoringTest.class/instance/tests/testSplitCascadeRefactoring.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60027.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60028.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60027.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60028.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60028 18297 RBSplitCascadeRefactoring broken https://pharo.fogbugz.com/f/cases/18297 18277 Add Class comments to Refactoring-Core-Refactorings classes https://pharo.fogbugz.com/f/cases/18277 18299 Add Class comments to Refactoring-Core-Supportclasses https://pharo.fogbugz.com/f/cases/18299 18293 Add a comment to Collection>>#stdev https://pharo.fogbugz.com/f/cases/18293 18294 Remove Object >> #noteSelectionIndex:for: https://pharo.fogbugz.com/f/cases/18294 http://files.pharo.org/image/60/60028.zip

May 23, 2016

Re: [Pharo-dev] cleaning the Pharo Catalog

by Stephan Eggermont

On 23/05/16 09:53, Esteban Lorenzano wrote: > Hi guys, > > I will update the Catalog for Pharo 6 and I was wondering if we should keep the âUnsortedâ categoryâ¦ this corresponds with projects present in old MetacelloRepository repo, I added it at the beginning because I did not want those project to be lost, but in fact they are more or less abandonware and definitively, they were not very well kept (no descriptions, no tags and even worst, many of them will not load fine). > So what do you think? should I keep them? Split into two categories? Those with full descriptions likely to load and those probably needing some updates? Stephan

May 23, 2016

cleaning the Pharo Catalog

by Esteban Lorenzano

Hi guys, I will update the Catalog for Pharo 6 and I was wondering if we should keep the âUnsortedâ categoryâ¦ this corresponds with projects present in old MetacelloRepository repo, I added it at the beginning because I did not want those project to be lost, but in fact they are more or less abandonware and definitively, they were not very well kept (no descriptions, no tags and even worst, many of them will not load fine). So what do you think? should I keep them? Esteban

May 23, 2016

Re: [Pharo-dev] [squeak-dev] Re: From a mooc user: method source with it' take so long in Pharo 5

by Martin Dias

Hi all, On Sun, May 22, 2016 at 12:26 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Henrik, > > cc'ing squeak-dev cuz this is relevant to both communities (if and > until Pharo takes the unwise decision to double the size of the image by > keeping sources in the image). > > On May 22, 2016, at 5:01 AM, Henrik Nergaard <henrik.nergaard(a)uia.no> > wrote: > > There is a method in SourceFileArray > #localProcessReadStreamAtFileIndex:atPosition:ifPresent:ifAbsent: which > uses a ProccessLocalVariable called ProccessAndSessionLocalSourcesFileArray > (see #localProcessReadOnlyCopy). Changing the last line in > #readStreamAt:ifPresent:ifAbsent: to use this local process one makes the > time to run this snippet: > > > > [ 1 systemNavigation browseMethodsWithSourceString: 'Morph' matchCase: > false ] timeProfile > > > > From ~ 10 seconds to ~ 3 seconds (Windows). > > > > However I cannot see that the file handles created by this > processLocalVariable to ever be closed, so I suspect those are leaked? In > that case there might be the need to implement some âclean upâ mechanism > for ProccessLocalVariables before they are changed/nilled when a process > changes. > > > > Another approach could be to not use a ProccessLocalVariabe at all, but > extend the SourceFilesArray class to also hold one read only handle for > each of its files, and use these in readStreamAtFileIndex:::â¦ . I guess > that it is also necessary then to have semaphore protecting the two last > lines such that setting the position in the stream and reading from it > cannot be changed by other threads. > > > I like this approach, but it has a fatal flaw. If one is debugging file > access, then as the debugger causes the source of methods to be fetched as > the debugger displays them, so the file pointer in the read-only file the > access of which one is trying to debug will change under one's feet, and > the results will be completely wrong. > > An approach which uses a special copy for the debugger doesn't work; one > can't debug access to that file for the same reason. > > An approach that /should/ work is for the debugger to install its own copy > around file-access. This should be recursive. So around every file access > in the debugger there would need to be something like > > SourceFiles substituteFreshReadOnlyCopiesDuring: [...file access...] > > which would remember the current read-only files, evaluate the block using > ensure: and have the ensure: block reinstall the previous file. > > Does this make sense? > > Interesting discussion. We could give a new try on the "local process read-only copy". It was me who started with it last year in a Pharo sprint, but disabled it due to some errors... and didn't spend more time on it afterwards. it was reported here: https://pharo.fogbugz.com/f/cases/15782 the reason to disable it: https://pharo.fogbugz.com/f/cases/15781/ none of them is very clear as documentation of the problem. > > readStreamAtFileIndex: index atPosition: position ifPresent: presentBlock > ifAbsent: absentBlock > > > > | stream result| > > stream := self readOnlyFileAt: index. > > stream ifNil: [ ^ absentBlock value ]. "sources file > not available" > > > > position > stream size ifTrue: [ ^ absentBlock value ]. > > > > readSema critical: [ > > stream position: position. > > result := presentBlock value: stream > > ]. > > > > ^ result > > > > > > Best regards, > > Henrik > > > > > > *From:* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org > <pharo-dev-bounces(a)lists.pharo.org>] *On Behalf Of *Nicolai Hess > *Sent:* Thursday, May 19, 2016 9:31 AM > *To:* Pharo Development List <pharo-dev(a)lists.pharo.org> > *Subject:* Re: [Pharo-dev] From a mooc user: method source with it' take > so long in Pharo 5 > > > > Squeak caches the opened readonly file(handle). It does not have to reopen > the file on every call for reading (readonly). > > > > 2016-05-18 19:12 GMT+02:00 stepharo <stepharo(a)free.fr>: > > I am wondering why does the search 'method source with it' take so long in > Pharo 5? On my PC, When I select the text 'menu' and search for all 'method > source with it', in Squeak 5 it takes 3 seconds. In Pharo 5 it takes 21 > seconds. > > > > > > >

May 23, 2016

Re: [Pharo-dev] Random is not random at startup

by Martin McClure

On 05/21/2016 01:56 PM, stepharo wrote: > I checked and CMWC Marsaglia is part of polymath > > > PMNumberGenerator allSubclasses an > OrderedCollection(PMBernoulliGenerator PMBinomialGenerator > PMConstantGenerator PMExponentialGenerator PMGaussianGenerator > PMPoissonGenerator) > > PMRandomGenerator allSubclasses an > OrderedCollection(PMMarsagliaKissRandom PMLehmerRandomGenerator > PMLinearCongruentialRandomGenerator PMMersenneTwisterRandomGenerator > PMParkMillerMinimumRandomGenerator) > > So we could pick one of them for Pharo. > Stef > I don't see CMWC in PolyMath. The only Marsaglia algorithm I see there is KISS (which from my reading of the literature is both more complex than and inferior to CMWC). But the Mersenne Twister is there, and though complex (possibly unnecessarily so) it is good, AFAICT. Regards, -Martin

May 23, 2016

Re: [Pharo-dev] compiledcode ?

by ClÃ©ment Bera

I will do a slice today. On Mon, May 23, 2016 at 12:49 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > Would it be possible to add some comments, please. > > CompiledMethod is now a subclass of the new class CompiledCode (and there > is another > class CompiledBlock). > > Can we please don't add new classes at this system level without *any* > comment. > > nicolai >

May 23, 2016