- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Low traffic [ANN] only list

by Marcus Denker

> On 06 Sep 2015, at 16:43, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Subscribing is quite cumbersome. > > 1. subscribe > 2. confirm my subscription > 3. confirm my humanity > > why not just the first? This could discourage people easily midway. > Ok, I have turned 3) off. Marcus

Sept. 6, 2015

Re: [Pharo-dev] Low traffic [ANN] only list

by Peter UhnÃ¡k

Subscribing is quite cumbersome. 1. subscribe 2. confirm my subscription 3. confirm my humanity why not just the first? This could discourage people easily midway. Peter On Sun, Sep 6, 2015 at 4:32 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hello, > > We have set up a low traffic announce-only list: > > http://eepurl.com/byhgL9 > > > The idea is that this is max one mail per month. > > Marcus >

Sept. 6, 2015

Low traffic [ANN] only list

by Marcus Denker

Hello, We have set up a low traffic announce-only list: http://eepurl.com/byhgL9 <http://eepurl.com/byhgL9> The idea is that this is max one mail per month. Marcus

Sept. 6, 2015

Re: [Pharo-dev] Rubric #mouseDown, #mouseUp and #click

by Stephan Eggermont

On 06/09/15 11:11, Nicolai Hess wrote: > Does the mouseUp on JobProgressMorph work ? > I always wondered how I can stop a long running task. I don't know. Not when running tests from the TestRunner. Stephan

Sept. 6, 2015

Re: [Pharo-dev] ***important*** cannot remove a class anymore...

by Peter UhnÃ¡k

But this is all implementation details, I'm still not sure what exactly we (Stef) want to send. * change diff after each successful CI build for an issue? * diff after the change has been integrated? Peter

Sept. 6, 2015

Re: [Pharo-dev] ***important*** cannot remove a class anymore...

by Peter UhnÃ¡k

> > You are right, Peter. But the way the rest of the world (and many people > using git from Pharo or other Smalltalk implementations) is that you > propose patches which I believe are quite similar to commits. That would be > the equivalent of our slice, I guess. I don't think that slice has equivalence in git, because we have changes much more fine-grained. Git patch is simply a diff between two different versions. And even though github (or bitbucket) offer things like "pull requests", they are only a nicer way of presenting a diff. But this doesn't really matter, because the result will be still the same. Now what might be an interesting work flow would be when an issue is tagged > Fix Review Needed and the CI monkey validates the issue it pushes the slice > to a new IssueNNNNN branch in github and branch diff emailed from there. Unless we want to migrate from fogzbugz to github and do code-reviews there in pull requests there's really no reason to create new branches. You can just create detached commits. (But then again, creating branches is dirt cheap). Actually for a diff you don't need to even commit, because you can compare your current code to the commited one (just like in Monticello). Peter

Sept. 6, 2015

[pharo-project/pharo-core]

by GitHub

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

Sept. 6, 2015

[pharo-project/pharo-core] 56e3cc: 50308

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 56e3cce6d903a8bdca1427aad2d90eb15627d7e6 https://github.com/pharo-project/pharo-core/commit/56e3cce6d903a8bdca1427aa… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-06 (Sun, 06 Sep 2015) Changed paths: A Reflectivity-Tests.package/ReflectiveMethodTest.class/instance/tests - links/testSetLinkInPrimitive.st M Reflectivity-Tests.package/ReflectiveMethodTest.class/instance/tests - links/testSetLinkOnPrimitive.st A Reflectivity-Tests.package/ReflectivityLinkTest.class/instance/tests - primitives/testPrimitiveWithLinkExecuteWrapper.st M Reflectivity.package/RFASTTranslator.class/instance/visitor-double dispatching/visitMethodNode_.st M Reflectivity.package/ReflectiveMethod.class/instance/evaluation/compileAndInstallCompiledMethod.st A Reflectivity.package/ReflectiveMethod.class/instance/evaluation/generatePrimitiveWrapper.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50307.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50308.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50307.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50308.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Settings-System.package/SystemSystemSettings.class/class/settings/systemSettingOn_.st Log Message: ----------- 50308 16495 Reflectivity: Wrap primitive methods https://pharo.fogbugz.com/f/cases/16495 16039 put a space between numbers and units https://pharo.fogbugz.com/f/cases/16039 http://files.pharo.org/image/50/50308.zip

Sept. 6, 2015

Re: [Pharo-dev] ***important*** cannot remove a class anymore...

by Ben Coman

On 6 Sep 2015 7:42 am, "Peter UhnÃ¡k" <i.uhnak(a)gmail.com> wrote: >> >> git clone https://github.com/pharo-project/pharo-core.git >> cd pharo-core/ >> git show 2536752ecdd88e15b00c6d3e29cb055d108731c8 > > > But this is post-integration, we want to review things before they break something, not after. > So ideally monkey reviews code on CI and if it passes the diff is sent from CI to the mailing list. > > Also these commits combine several unrelated issues, which is not good for review. > > Isn't what Squeak uses open-source and available somewhere? Can't we just reuse it? I thought the Squeak email diffs were post-commit?? Now what might be an interesting work flow would be when an issue is tagged Fix Review Needed and the CI monkey validates the issue it pushes the slice to a new IssueNNNNN branch in github and branch diff emailed from there. Cheers ben

Sept. 6, 2015

Re: [Pharo-dev] Rubric #mouseDown, #mouseUp and #click

by Nicolai Hess

Does the mouseUp on JobProgressMorph work ? I always wondered how I can stop a long running task. 2015-09-02 12:25 GMT+02:00 Stephan Eggermont <stephan(a)stack.nl>: > We have a few morphs where #on:#mouseDown send: aMessage to: aTarget is > used where I'd expected that to be on #click. Mostly in Rubric and the > Nautilus annotations > > If a morph is supposed to behave as a button, the action should happen > on the #mouseUp, but only if the mouse pointer hasn't moved away from > the morph. That is what #click does. > > And > ExpanderTitleMorph > GrowlMorph > JobProgressMorph > react on #mouseUp instead of #click > > Stephan > > >

Sept. 6, 2015