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

[pharo-project/pharo-core]

by GitHub

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

Sept. 17, 2015

[pharo-project/pharo-core] 7586c2: 50330

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 7586c211f6842acc22a041ac7df29bc8fffbb659 https://github.com/pharo-project/pharo-core/commit/7586c211f6842acc22a041ac… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-17 (Thu, 17 Sep 2015) Changed paths: A Deprecated50.package/extension/SmalltalkImage/instance/logChange_.st R Monticello.package/MCVersionReader.class/class/System-FileRegistry/fileReaderServicesForFile_suffix_.st R Monticello.package/MCVersionReader.class/class/System-FileRegistry/loadVersionFile_.st R Monticello.package/MCVersionReader.class/class/System-FileRegistry/mergeVersionFile_.st R Monticello.package/MCVersionReader.class/class/System-FileRegistry/openVersionFile_.st R Monticello.package/MCVersionReader.class/class/System-FileRegistry/services.st A Monticello.package/MCVersionReader.class/class/actions - file/loadVersionFile_.st A Monticello.package/MCVersionReader.class/class/actions - file/mergeVersionFile_.st A Monticello.package/MCVersionReader.class/class/actions - file/openVersionFile_.st A MonticelloFileServices.package/extension/MCVersionReader/class/fileReaderServicesForFile_suffix_.st A MonticelloFileServices.package/extension/MCVersionReader/class/loadVersionStream_fromDirectory_.st A MonticelloFileServices.package/extension/MCVersionReader/class/mergeVersionStream_.st A MonticelloFileServices.package/extension/MCVersionReader/class/openVersionFromStream_.st A MonticelloFileServices.package/extension/MCVersionReader/class/serviceLoadVersion.st A MonticelloFileServices.package/extension/MCVersionReader/class/serviceMergeVersion.st A MonticelloFileServices.package/extension/MCVersionReader/class/serviceOpenVersion.st A MonticelloFileServices.package/extension/MCVersionReader/class/services.st M Nautilus.package/PackageTreeNautilusUI.class/instance/package filter/package_matchPackagePattern_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50329.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50330.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50329.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50330.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R System-Support.package/SmalltalkImage.class/instance/sources%2C change log/logChange_.st Log Message: ----------- 50330 16523 Nautilus Regex Search Box borken https://pharo.fogbugz.com/f/cases/16523 16587 Deprecate SmalltalkImage>>#logChange: https://pharo.fogbugz.com/f/cases/16587 16573 Monticello should not depend on System-FileRegistry https://pharo.fogbugz.com/f/cases/16573 http://files.pharo.org/image/50/50330.zip

Sept. 17, 2015

Re: [Pharo-dev] Remove rule "References an abstract class"

by Yuriy Tymchuk

Well, for me itâs ok. Then I donât have to create a new version in conf :). > On 17 Sep 2015, at 14:17, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 17 Sep 2015, at 14:08, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> Because people can choose in critic browser what they want to see. At least this is my opinion. As a sneak peek to the survey results I can say that there are people who find the removed of âmissing yourselfâ rule as a negative change > > When I learned something than this: Whatever you do, someone will think it is wrong. The largest mistake that you can do is to only do things that nobody objects toâ¦ because the only thing that fulfils that is to do nothing. > > Marcus

Sept. 17, 2015

Re: [Pharo-dev] Remove rule "References an abstract class"

by Marcus Denker

> On 17 Sep 2015, at 14:08, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Because people can choose in critic browser what they want to see. At least this is my opinion. As a sneak peek to the survey results I can say that there are people who find the removed of âmissing yourselfâ rule as a negative change When I learned something than this: Whatever you do, someone will think it is wrong. The largest mistake that you can do is to only do things that nobody objects toâ¦ because the only thing that fulfils that is to do nothing. Marcus

Sept. 17, 2015

Re: [Pharo-dev] Remove rule "References an abstract class"

by Yuriy Tymchuk

Because people can choose in critic browser what they want to see. At least this is my opinion. As a sneak peek to the survey results I can say that there are people who find the removed of âmissing yourselfâ rule as a negative change. Of course they are only a few of them, but as you are not able to set up what rules you want to have in QualityAssistant, it makes sense to remove ones that the majority does not like. But in critics browser we can specify which rules you want to run. So I donât see a need in a complete removal. Yes, maybe form UX perspective critic browser should have some button like: âRun only the important onesââ¦ Uko > On 17 Sep 2015, at 13:43, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 17 Sep 2015, at 12:50, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> Well, what I am saying is that I agree that people should not be bothered with this rule by QualityAssistant. But why we should remove the rule from the image? >> > Because it is wrong? If we keep it, people will see it when they use the Critic Browserâ¦ what would be the reason to keep a rule that everyone things is not good? > > Marcus > > >

Sept. 17, 2015

Re: [Pharo-dev] Contribution scheme confusing ...

by Marcus Denker

> On 16 Sep 2015, at 22:17, Torsten Bergmann <astares(a)gmx.de> wrote: > > We are in a transition to use more and more ConfigurationOfxxxx > to manage packages included in Pharo 5. > Yes, and it is a mess. > But neither the new help topic "How to contribute to Pharo base code" > nor the link it points to http://pharo.org/contribute-propose-fix reflects this. > Yes, I will put it on my TODO to update it. > Also - how do I know which code has to be managed by a Configuration > and where is the original repo if so. > > How will I submit a fix that includes code to change both: somthing that is managed > vai config and something that is a change on a regular slice managed package... > > Also: > I did a simple fix on NautilusGroupAutoBuilder package - there is > a ConfigurationOfNautilusGroupAutoBuilder. But is it managed internally > or externally now? > Even I can not tell you. Marcus

Sept. 17, 2015

Re: [Pharo-dev] Rubric/Event handling issue?

by Ben Coman

On Tue, Sep 15, 2015 at 11:49 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > There is an interesting bad interaction between my drag-and-drop code and > Rubric. It kills all Rubric editors at the same time, so it looks > to me like a problem with the Rubric background thread interacting with > mouseMove or mouseEnter/Leave. > > https://vimeo.com/139353992 It looks like there was meant to be sound, but I didn't hear any (could just be me) cheers -ben > > To reproduce, > Load DragPanels from StephanEggermont/DragPanels > and NewUI from StephanEggermont/Documentation > > In a Playground open a panel > CodePanel new openInWindowLabeled:'Code Panel' > > add a few cards (drop them in the panel) > (CodeCard class: CodeCard selector: #initialize) openInHand > and expand them by clicking on the arrow > > Right click on the empty area in the CodePanel and open the > colors. A fast drag from the color panel to the rubric area of the > code card sometimes results in the rubric editors losing their content. > > Stephan > >

Sept. 17, 2015

Re: [Pharo-dev] Pedantic on Random>>nextValue method name

by Henrik Nergaard

-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Ben Coman Sent: Wednesday, September 16, 2015 6:39 PM To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] Pedantic on Random>>nextValue method name On Wed, Sep 16, 2015 at 11:22 PM, Henrik Nergaard <henrin10(a)uia.no> wrote: >> The method #nextValue actually calculates the next value the seed >> should be, the current value can be accessed by sending #seed. >> I do agree that #nextValue might not be the clearest method name for >> its use; perhaps #nextSeed would be a better name? >Yes. Thats better again. Now its a private method, so there should be >problem changing it ;) ??anyone Continuing on another Random topic related to.. https://pharo.fogbugz.com/default.asp?16577 I notice that Collection>>atRandom is protected by a mutex but Collection>>atRandom: is not. This makes me believe the protection is for the Random generator and not for the actual picking of the element from the collection. So it seems that #atRandom holds the mutex too long - for both random generation and element picking. (> Is there a specific use for the mutex in this case? I tried to use a shared random without the mutex, and forking a few block closures, worked fine.. If the mutex could be removed we could just add a method in the class side of Random like this: globalGenerator ^Generator ifNil: [ Generator := Random new] <) Thus I wonder if rather than copying the existing pattern of Collection>>atRandom to GlobalSharedRandom>>generateFor: it might be better to make a more generic SharedRandom as follows... (> Maybe :P I had a look at the Random Superclass in SciSmalltalk; here #next is used to create and give the next random value. #seed for seed, and #peek for checking what the next value would be without changing the current state. The peek method could be a good addition in Random -> Random>>#Peak Self nextValue / m I would keep the way the #nextValue method behaves since this gives the option to "peek" at the next value the Ivar seed will have without changing it (could be useful?), but the name could be improved to be more clear. Perhaps the method name #nextSeed might not be so good after all, it might imply that the method creates a new seed, but what it actually does is to go to the next state in the random generation? ( so a better name could be #nextState ?), (perhaps the Ivar seed would also be better called state or internalState? ) <) "Old calls to #next changed to private #nextValue" Random>>nextValue | lo hi aLoRHi answer | hi := (seed quo: q) asFloat. lo := seed - (hi * q). " = seed rem: q" aLoRHi := (a * lo) - (r * hi). seed := (aLoRHi > 0.0) ifTrue: [aLoRHi] ifFalse: [aLoRHi + m]. ^ seed / m "this line moved here from old #next" Random>>next ^ self nextValue Random>>next: anInteger into: anArray 1 to: anInteger do: [:index | anArray at: index put: self nextValue]. ^ anArray Random>>nextInt: anInteger anInteger strictlyPositive ifFalse: [ self error: 'Range must be positive' ]. anInteger asFloat isInfinite ifTrue: [^(self nextValue asFraction * anInteger) truncated + 1]. ^ (self nextValue * anInteger) truncated + 1 "SharedRandom protects all calls to private #nextValue" Random subclass: SharedRandom instanceVariableNames: 'mutex' SharedRandom>>initialize mutex := Semaphore forMutualExclusion. SharedRandom>>next ^ mutex critical: [ self nextValue ] SharedRandom>>next: anInteger into: anArray ^ mutex critical: [ super next: anInteger into: anArray ]. SharedRandom>>nextInt: anInteger ^ mutex critical: [ nextInt: anInteger ]. Then... Object subclass: GlobalSharedRandom classVariables: 'sharedRandom' GlobalSharedRandom class>>initialize sharedRandom := SharedRandom new. GlobalSharedRandom class>>generator ^ sharedRandom And finally... Collection>>atRandom ^ self randomAt: GlobalSharedRandom generator. (> +1 <) What do you think? cheers, Ben What do you think? Best regards, Henrik -- View this message in context: http://forum.world.st/Pedantic-on-Random-nextValue-method-name-tp4850582p48… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 17, 2015

Re: [Pharo-dev] Remove rule "References an abstract class"

by Marcus Denker

> On 17 Sep 2015, at 12:50, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Well, what I am saying is that I agree that people should not be bothered with this rule by QualityAssistant. But why we should remove the rule from the image? > Because it is wrong? If we keep it, people will see it when they use the Critic Browserâ¦ what would be the reason to keep a rule that everyone things is not good? Marcus

Sept. 17, 2015

Re: [Pharo-dev] Remove rule "References an abstract class"

by Yuriy Tymchuk

Well, what I am saying is that I agree that people should not be bothered with this rule by QualityAssistant. But why we should remove the rule from the image? Uko > On 17 Sep 2015, at 12:11, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > > yes the problem with rules comes when the rule add more noise than is helpful. > If you do not want to remove this rule because it is useful in some cases, maybe the rule could check only these specific situations to do not add noise in others. > > Le 17 sept. 2015 Ã 10:37, Yuriy Tymchuk a Ã©crit : > >> Ok, it can be removed from Pharoâ¦ I still find it useful as well as missing yourself, but I can keep track of then individually :) >> >> >>> On 17 Sep 2015, at 09:39, Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: >>> >>> You can probably remove it directly from Pharo instead >>> https://pharo.fogbugz.com/f/cases/15858/review-rule-RBAbstractClassRule <https://pharo.fogbugz.com/f/cases/15858/review-rule-RBAbstractClassRule> >>> >>> Peter >>> >>> On Thu, Sep 17, 2015 at 9:09 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >>> Hi. >>> >>> First of all: thank you for the feedback Damien! >>> It makes sense, the rule also has higher amount of negative feedback. I will remove it from QA, let it stay in the image, it actually can be useful. >>> >>> Uko >>> >>> >>> > On 17 Sep 2015, at 06:49, Damien Cassou <damien.cassou(a)inria.fr <mailto:damien.cassou@inria.fr>> wrote: >>> > >>> > This lint rule pops up all the times and my code is always ok. I >>> > typically have to reference an abstract class when: >>> > >>> > - the abstract class takes care of choosing the concrete class to >>> > instantiate >>> > >>> > - the abstract class takes care of some shared variable for its >>> > subclasses (e.g., a cache or an shared external object) >>> > >>> > I propose to remove this rule which has never been useful for me. >>> > >>> > -- >>> > Damien Cassou >>> > http://damiencassou.seasidehosting.st <http://damiencassou.seasidehosting.st/> >>> > >>> > "Success is the ability to go from one failure to another without >>> > losing enthusiasm." --Winston Churchill >>> > >>> >>> >>> >> >

Sept. 17, 2015