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

Re: [Pharo-dev] Komitter in 30852?

by Stephan Eggermont

Marcus wrote >https://pharo.fogbugz.com/f/cases/13539/receiver-of-NodeModel-is-Nil > >There is even a fix, but it needs to be reviewed and back ported. Thanks, I somehow missed that. I was a bit annoyed that I had just yesterday answered a question about closing lots of inspectors and then ran into the situation myself... Thierry wrote: >can you describe how you get it? I immediately had errors on 4.0 >when writing this fix (https://pharo.fogbugz.com/f/cases/13539/receiver-of-NodeModel-is-Nil) but it wasn't reproduced on 3.0. Open a fresh 30852 with 355 (Mac Mavericks 10.9.4). Open a Nautilus browser, create class Bla in category Bla. Open Komitter, 6 MNUs Close MNUs and Komitter add a class Blah in category Bla Open Komitter, 10 MNUs I tried it originally on an image that took over a minute to produce the MNUs... Stephan

July 24, 2014

Re: [Pharo-dev] Komitter in 30852?

by Thierry Goubier

Stephan, can you describe how you get it? I immediately had errors on 4.0 when writing this fix ( https://pharo.fogbugz.com/f/cases/13539/receiver-of-NodeModel-is-Nil) but it wasn't reproduced on 3.0. Thierry 2014-07-24 11:43 GMT+02:00 Stephan Eggermont <stephan(a)stack.nl>: > Anyone tried Komitter recently in Pharo 3? I get about 4 to 6 debugger > windows per change. > Don't try on an image with lots of open changes... > > Stephan > > > >

July 24, 2014

Re: [Pharo-dev] Komitter in 30852?

by Marcus Denker

On 24 Jul 2014, at 11:43, Stephan Eggermont <stephan(a)stack.nl> wrote: > Anyone tried Komitter recently in Pharo 3? I get about 4 to 6 debugger windows per change. > Don't try on an image with lots of open changesâ¦ > https://pharo.fogbugz.com/f/cases/13539/receiver-of-NodeModel-is-Nil There is even a fix, but it needs to be reviewed and back ported.

July 24, 2014

Re: [Pharo-dev] Refactor Nautilus

by Nicolai Hess

2014-07-24 10:28 GMT+02:00 Baptiste Quide <baptiste.quide(a)inria.fr>: > Good luck for that. > I will have a look because the tool which allows to watch package > dependencies embeds the Nautilus Browser, and i'm one of the maintainer at > this time. > Good to know! > > Baptiste > > ------------------------------ > > *De: *"Nicolai Hess" <nicolaihess(a)web.de> > *Ã: *"Pharo Development List" <pharo-dev(a)lists.pharo.org> > *EnvoyÃ©: *Jeudi 24 Juillet 2014 10:23:15 > *Objet: *[Pharo-dev] Refactor Nautilus > > > If no one raises objections, I would like to start on refactor / cleanup > nautilus code. > > This includes: > > renaming / recategorizing > solve code critics shown in Critics Browser > split classes (AbstractNautilusUI has 427 methods 24 instvars ) > stronger separation between the browser model, browser state > and browser UI. > > review event handling and UI updating > (sometimes there is a difference between what the UI shows > as selected and the selection the model(s) holds > > maybe: > create one package pane widget for package and groups > (therefore move all that package vs groups handling from > nautilus ui to that widget) > merge Nautilus and PackageTreeNautilus > > (I don't consider all of Nautilus bad code, it has well > designed parts, it just has grown meanwhile...) > > How to update the code? > > Working with slices makes it easier to find changes > that introduces new bugs. > Otherwise it takes time to do it in such small steps and I don't > know if those changes are reviewed at all. > > So, I would try to group the changes. > 1. code critics > 2. renameing/ simple refactoring > 3. .... > > > nicolai > > > > >

July 24, 2014

Re: [Pharo-dev] Komitter in 30852?

by stepharo

I just tried and I got some problems in 40 too. No time to look deeper into it. Now in 30 this is strange because I used it when working on moose. Stef On 24/7/14 11:43, Stephan Eggermont wrote: > Anyone tried Komitter recently in Pharo 3? I get about 4 to 6 debugger windows per change. > Don't try on an image with lots of open changes... > > Stephan > > > > >

July 24, 2014

[pharo-project/pharo-core]

by GitHub

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

July 24, 2014

[pharo-project/pharo-core] 66a818: 40122

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 66a8182c2a1b6f8de3417956bcf73e50e86fe2e6 https://github.com/pharo-project/pharo-core/commit/66a8182c2a1b6f8de3417956… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-07-24 (Thu, 24 Jul 2014) Changed paths: A Morphic-Base.package/TransformationMorph.class/instance/accessing/embeddedWindowOrNil.st R Morphic-Base.package/extension/PasteUpMorph/instance/windowsSatisfying_.st M Morphic-Core.package/HandMorph.class/instance/private events/generateMouseEvent_.st A Morphic-Core.package/Morph.class/instance/accessing/embeddedWindowOrNil.st A Morphic-Core.package/PasteUpMorph.class/instance/accessing/currentWindow.st A Morphic-Core.package/PasteUpMorph.class/instance/accessing/windowsSatisfying_.st A Morphic-Widgets-Windows.package/SystemWindow.class/instance/accessing/embeddedWindowOrNil.st M OpalCompiler-Core.package/OpalCompiler.class/instance/public access/compile.st R Polymorph-Widgets.package/extension/PasteUpMorph/instance/currentWindow.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script122.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40122.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40122 13675 safer windows enumeration https://pharo.fogbugz.com/f/cases/13675 13676 safer usage of KMBuffer in HandMorph >> #generateMouseEvent: https://pharo.fogbugz.com/f/cases/13676 13669 CompilerNotifying test failing on main build https://pharo.fogbugz.com/f/cases/13669 13674 safer access to top current window https://pharo.fogbugz.com/f/cases/13674 13667 Delete empty package System-Tools https://pharo.fogbugz.com/f/cases/13667 http://files.pharo.org/image/40/40122.zip

July 24, 2014

Komitter in 30852?

by Stephan Eggermont

Anyone tried Komitter recently in Pharo 3? I get about 4 to 6 debugger windows per change. Don't try on an image with lots of open changes... Stephan

July 24, 2014

Re: [Pharo-dev] [Pharo4] Weekend Project 1: Cleanup Low-Level animation code

by stepharo

Yes marcus may be we should add that description to pharo roadmaps on github. I like to document design problems that I encounter but cannot fix fast. Stef On 24/7/14 10:28, Marcus Denker wrote: > Hi, > > Now with holidays comingâ¦ maybe someone wants to do a small Pharo related Project with impact on the future? > > Here is suggestion 1. > > Context: cleanup graphics. (so e.g. one could replace the canvas later). > > Details > ====== > Morphic has some very arcane code for animating moving morphs around that bypasses layers. > > DisplayObject has these methods: > > follow:while: > follow:while:bitsBehind:startingLoc: > slideFrom:to:nSteps:delay: > slideWithFirstFrom:to:nSteps:delay: > displayOnPort:at:rule: > > They are used by morphic for some not really important animation that for sure > can be directly done by moving the morphs as morphs around. Bypassing > and directly using low level (not even Canvas level) functionality is for sure not needed. > > On the Morph level the users are: > > slideBackToFormerSituation: > vanishAfterSlidingTo:event: > animationForMoveSuccess: > > What to do? > > -> rewrite the morphic level code to just move the morphs around. > -> delete all the code from DisplayObject > -> review âGrafPortâ usage, as this might have been the last client. > > > Marcus >

July 24, 2014

Re: [Pharo-dev] Refactor Nautilus

by stepharo

On 24/7/14 10:23, Nicolai Hess wrote: > If no one raises objections, I would like to start on refactor / cleanup > nautilus code. Wonderful! I can review your changes if this helps you (I really like when other people do it for me). > This includes: > > renaming / recategorizing > solve code critics shown in Critics Browser > split classes (AbstractNautilusUI has 427 methods 24 instvars ) > stronger separation between the browser model, browser state > and browser UI. > > review event handling and UI updating > (sometimes there is a difference between what the UI shows > as selected and the selection the model(s) holds > > maybe: > create one package pane widget for package and groups > (therefore move all that package vs groups handling from > nautilus ui to that widget) > merge Nautilus and PackageTreeNautilus > > (I don't consider all of Nautilus bad code, it has well > designed parts, it just has grown meanwhile...) Sure improving does not mean that previous code is bad. Iterations are the way to learn. > How to update the code? > > Working with slices makes it easier to find changes > that introduces new bugs. > Otherwise it takes time to do it in such small steps and I don't > know if those changes are reviewed at all. do the best that can help you and what we can try is to give priority to the integration stream. Like that you avoid to have dependencies between the changes. This is what I try to do when I work on polymorph. I try to work on two unrelated topics (tools and widgets) so that the changes can be pushed to the stream and I can always work with the latest update > > So, I would try to group the changes. > 1. code critics > 2. renameing/ simple refactoring > 3. .... one simple change at a time but steadily. stef > > > nicolai > > >

July 24, 2014