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

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

by stepharo

I forwarded to alain. Now this is the restart of the university... Stef Le 15/9/15 17:49, Stephan Eggermont a Ã©crit : > 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 > > 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] Contribution scheme confusing ...

by stepharo

Yes we know. Now we are full. Sorry I cannot clone ourselves. Else I would do it. Stef Le 16/9/15 22:17, Torsten Bergmann a Ã©crit : > We are in a transition to use more and more ConfigurationOfxxxx > to manage packages included in Pharo 5. > > 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. > > 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? > > Thanks > T. > >

Sept. 17, 2015

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

by Christophe Demarey

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> wrote: >> >> You can probably remove it directly from Pharo instead >> 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> 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> 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 >> > >> > "Success is the ability to go from one failure to another without >> > losing enthusiasm." --Winston Churchill >> > >> >> >> >

Sept. 17, 2015

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

by Yuriy Tymchuk

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> 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

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

by Stephan Eggermont

ping On 15-09-15 17:49, Stephan Eggermont 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 > > 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] SyntaxError: parentheses; cascades and yourself (Opal vs. old compilers parser)

by Sven Van Caekenberghe

> On 17 Sep 2015, at 09:32, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2015-09-17 9:10 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > > > 2015-09-16 15:14 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Argh, sent too early: > > self new color: Color red; yourself > > est bien une cascade, non? > > Yes, but in > > (self new color: Color red); yourself > the expression in parenthesis looks like "this evalulates first, to 'anObject' ", so we send " ; yourself", > a cascaded messages with only one message to "anObject". > > Yes, agreed of course. > > In a way, it looks like an error correction type of thing: the parser knows the parenthesis shouldn't be there or the ; shouldn't be there, so it chooses one interpretation out of the two: here it is the parenthesis are unnecessary. Hmm, I don't agree. We as humans can infer that, from a language/compiler's standpoint it is not clear/possible. someObject message1; message2 is a pure cascade (someObject message1) message2 is not a cascade, message2 being sent to the result the last expression is totally equivalent to someObject message1 message2 However expression message expression ; message could be equivalent, like if it said expression yourself; message but the decision to drop the parenthesis cannot be made automatically, IMHO I would make the spurious ; an error, to avoid confusion > By the way, John found another issue with a fix you did in RBParser (RBPatternParser>>parseUnaryMessage) which fail some refactoring expressions. Can you have a look? > > Thierry > > > > > > > > > Thierry > > > 2015-09-16 15:12 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > > > 2015-09-16 15:05 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > OK, I think Sven is right and a cascade needs at least one message send > > "self ; yourself" > > doesn't work too (both parser don't accept this). > > But > > > > There are currently two methods in Pharo 5.0 with this > syntax: > > DAPackageAnalyzerWindow class>>#onPackagesNamed: > DAPackageCycleDetectionTreeModel class>>#onPackagesNamed: > > @Yuri, can you change that. > > > And I think we should fix RBParser. > > > 2015-09-16 11:30 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Nicolai, > > can you try with the RBParser directly? I believe Opal uses the RBParser. > > RBParser parseMethod: 'createRedMorph > ^ (self new color:Color red); yourself' > > Oh, RBParser sees it as: > > self new > color: Color red; > yourself > > :) > > Thierry > > > 2015-09-16 10:56 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > The following method compiles with Opal: > > createRedMorph > ^ (self new color:Color red); yourself > > but gives a syntax error with the old compilers parser > > createRedMorph > ^ (self new color:Color red)End of block expected -> ; yourself > > > removing the parenthesis of course works for both. > Who is right ? > > > (for those who understand the ParseTreeSearcher syntax, how would > a search expression look, for finding code like: > > "(some expression);yourself" > > > nicolai

Sept. 17, 2015

[pharo-project/pharo-core]

by GitHub

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

Sept. 17, 2015

[pharo-project/pharo-core] feb71a: 50329

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: feb71a8705982cbb829e2678703c07d2131e71d8 https://github.com/pharo-project/pharo-core/commit/feb71a8705982cbb829e2678… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-17 (Thu, 17 Sep 2015) Changed paths: M CodeImport.package/CodeImporter.class/instance/evaluating/flushChangesFile.st A CodeImport.package/ManifestCodeImport.class/README.md A CodeImport.package/ManifestCodeImport.class/class/meta-data - dependency analyser/manuallyResolvedDependencies.st A CodeImport.package/ManifestCodeImport.class/definition.st M ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/symbolic versions/stable_.st A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/versions/version09_.st A ConfigurationOfCodeImporter.package/ConfigurationOfCodeImporter.class/instance/baselines/baseline112_.st A ConfigurationOfCodeImporter.package/ConfigurationOfCodeImporter.class/instance/symbolic versions/development_.st A ConfigurationOfCodeImporter.package/ConfigurationOfCodeImporter.class/instance/symbolic versions/stable_.st A ConfigurationOfCodeImporter.package/ConfigurationOfCodeImporter.class/instance/versions/version112_.st A Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testInsteadBlockSequence.st M Reflectivity.package/RFASTTranslatorForValue.class/instance/visitor-double dispatching/visitSequenceNode_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50328.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50329.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50328.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50329.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tool-Catalog.package/CatalogBrowser.class/instance/actions/installStableVersion_onSuccess_.st M Tool-Catalog.package/CatalogBrowser.class/instance/private - events/onLoadFrom_.st M Tool-Catalog.package/extension/GTSpotter/instance/spotterCatalogProjectsFor_.st Log Message: ----------- 50329 16589 #instead for block sequence https://pharo.fogbugz.com/f/cases/16589 16588 Integrate Catalog 0.9 https://pharo.fogbugz.com/f/cases/16588 16586 Load latest version of CodeImporter https://pharo.fogbugz.com/f/cases/16586 http://files.pharo.org/image/50/50329.zip

Sept. 17, 2015

[Reflectivity] Links on Block creation vs. execution

by Marcus Denker

Hi, For blocks, we now have the correct model to destinguish âblock creationâ from âblock executionâ: 1) put a link on the block node, it will be called when the block definition (creation) is executed. e.g. when you put a before link on the block in this method, it will be called when you execute the method: TT>>method ^[1 + 2]. 2) put a link on the *body* of the block (the sequence of statements), it will be called when the block *executes*. For the example, it would not be called when executing âTT new methodâ, but only when you do âTT new method valueâ. Test: testBeforeBlockSequenceNoValue | sequence link | sequence := (ReflectivityExamples >> #exampleBlockNoValue) ast statements first value body. self assert: sequence isSequence. link := MetaLink new metaObject: self; selector: #tagExec. sequence link: link. self assert: sequence hasMetalinkBefore. self assert: (ReflectivityExamples >> #exampleBlockNoValue) class = ReflectiveMethod. self assert: tag isNil. ReflectivityExamples new exampleBlockNoValue. self assert: tag isNil. ReflectivityExamples new exampleBlockNoValue value. self assert: tag = 'yes'. self assert: (ReflectivityExamples >> #exampleBlockNoValue) class = CompiledMethod. link uninstall. ReflectivityExamples recompile: #exampleBlockNoValue Marcus

Sept. 17, 2015

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

by Peter UhnÃ¡k

You can probably remove it directly from Pharo instead 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> 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> 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 > > > > "Success is the ability to go from one failure to another without > > losing enthusiasm." --Winston Churchill > > > > >

Sept. 17, 2015