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

Re: [Pharo-dev] Anonymous classes should be browseable

by stepharo

Hernan I would really love that you think twice before pressing the button sent mail. Else I will finish to put you on my kill list and I will be sad but so far I see from you often frustration. Could you try to be positive? You will see as a state of mind this is so much more pleasant. There are many aspects of Nautilus that I do not like but there are even more aspect about the old browser and OB that I hate! And as you know doing is difficult. So what is the point. How many anonymous classes did I created over the last five year: none. What do we do with class side? packages? Why do you expect that a tools supporting the Smalltalk metaclass model should suport Anonymous classes? BTW I'm the guy in Squeak that fixed long long long time ago Behavior new new (So I know a bit on anonymous classes). When I used anonymous classes I did it to support instance based programming. So should I expect my hack to work with normal browser? Now may be the anonymous classes you create should return a dummy package. Stef Le 26/1/15 07:44, HernÃ¡n Morales Durand a Ã©crit : > I want to discuss case 14789 > (https://pharo.fogbugz.com/f/cases/14789/Nautilus-assumes-a-class-always-und…) > because a class should be browseable even without a definition. > Anonymous classes are still classes. > > If Nautilus project cannot deal with the whole Smalltalk power then it > is poorly designed and I wonder what's the advantage over the old > OmniBrowser... > > HernÃ¡n >

Jan. 31, 2015

Re: [Pharo-dev] Tools for automatic recognition of Design Patterns

by stepharo

Hi nevena You probably know that Design patterns are about intent, description and names. Their implementation is flexible and do not have to follow the book so I doubt that such a tool can exist in any language. Now if you look in my paper Software Architecture Extraction survey you will find a little section with pointers on such research which was really at the top in 1996-2000. Roel Wuyts and VUB logic meta programming used SOUL (a prolog unifying AST) to identify some DesignPatterns. You can contact andy Kellens and Johan Brichau to get a version of Soul, I'm sure that they have it on their disc somewhere. There was a version for Squeak and VisualWorks. It would be nice to get it running again and I'm sure that they had a lot of tests. Now if you are interested in a topic that is somehow related: one of the key challenge for today software development is how do we document in an executable way frameworks so that during the next 10 ot 15 years they can be maintained an extended even when the main developers left. Architecture Design P Extension point We have many excellent frameworks (Seaside, Athens, Fuel, ...) and we are asking ourselves the questions how to ensure their futures. stef > Hi, > > Can anyone suggest me tool for automatic design patterns detection in Smalltalk? > > Cheers, > Nevena Milojkovic > > > ââââââââ > Nevena Milojkovic > Research assistant > Software Composition Group > Institute of Computer Science and Applied Mathematics > University of Bern > > email: nevena(a)iam.unibe.ch > office phone: +41 (0)31 511 7639 > webpage: http://scg.unibe.ch/staff/Milojkovic > > > > > > >

Jan. 31, 2015

[pharo-project/pharo-core] 6ecd67: 40470

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 6ecd6769c54f243508d223f3c827d5c5c669f8ca https://github.com/pharo-project/pharo-core/commit/6ecd6769c54f243508d223f3… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-01-31 (Sat, 31 Jan 2015) Changed paths: M Announcements-Help.package/AnnouncementsTutorial.class/class/pages/step2.st M Graphics-Primitives.package/Color.class/class/instance creation/colorFromPixelValue_depth_.st A Graphics-Tests.package/ColorTest.class/instance/tests/test32BlackColorTranformation.st A Graphics-Tests.package/FormTest.class/instance/tests/test32BitFormBlackShouldStayBlackAfterSave.st M HelpSystem-Core.package/CustomHelp.class/class/editing/accept_title_contents_.st M HelpSystem-Core.package/CustomHelp.class/class/editing/edit_.st M Kernel.package/Duration.class/instance/converting/asMinutes.st M KernelTests.package/DurationTest.class/instance/tests/testAsMinutes.st M Polymorph-Widgets.package/MorphicUIManager.class/instance/ui requests/openDebuggerOn_context_label_contents_fullView_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script470.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40470.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tests.package/SystemNavigationOnNewlyCreatedEnvironmentTest.class/instance/testing/testEnsureDefaultEnvironmentNotUsed.st Log Message: ----------- 40470 14825 Correct spelling of "orginal" https://pharo.fogbugz.com/f/cases/14825 13215 Duration>>#asMinutes should use full precision https://pharo.fogbugz.com/f/cases/13215 14619 Strange behavior of TestRunner-Icon https://pharo.fogbugz.com/f/cases/14619 14808 Make Help file editing in Pharo 4.0 work again and ease it by using <script> pragma in generated methods https://pharo.fogbugz.com/f/cases/14808 http://files.pharo.org/image/40/40470.zip

Jan. 31, 2015

[pharo-project/pharo-core]

by GitHub

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

Jan. 31, 2015

Re: [Pharo-dev] Athens/Morphic

by Marcus Denker

Nice! It works fine here (font looks strange, yes). The world size seems to be limited to the small window that pharo starts up with? Making it larger seems to still clip at that border. > On 23 Jan 2015, at 17:40, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > 2015-01-10 13:18 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>>: > > I think I got the MorphTreeTransformMorph now working, need to clean up the code > and maybe I 'll upload this to the athens repository. > > nicolai > > > > > I don't know how often I thought "I got this working", but NOW I think I got this morphic transformation working :) > > I give up to use the AthensTextRenderer classes, they aren't implemented fully, to much work for me to do this. > Instead, I just subclass the DisplayScanner and reimplemented all Canvas-draw-methods with athens-drawing-methods. > > Still some morphs aren't "ported", but they use some magic. For example, for some morphs the drawOn:Canvas methods > calls many other methods drawBackroundOn: aCanvas, drawIconOn: aCanvas, drawLinesOn: ... > (for exampe: IndentingListItemMorph, MorphTreeMorph). Porting this morphs means, we have to duplicate all this methods. > (Ok there are other options, but I don't want to change something in the original Morphic/Canvas workflow). > Other Morphs just delegate the drawing call, that delegate the calls further and deep in this call change the > drawing actually happens. This again means I have to duplicate all this methods just to use an AthensCanvas for drawing. > > So, for those Morphs I use a Canvas Wrapper (AthensCanvasWrapper). I already wrote about this one, it implements (most) > of the Morphic/Canvas API on top of Athens, it was an alternative approach for Morphic<->Athens porting. This one is > now a much more advanced version and I can use it in combination with the other drawOnAthensCanvas methods. > > The drawOnAthensCanvas method in MorphTreeNodeMorph for example just calls this > drawOnAthensCanvas: anAthensCanvas > self drawOnCanvasWrapperFor: anAthensCanvas > which in turn creates an AthensCanvasWrapper and then calls > self drawOn: wrapper > The same Morphic/Canvas drawOn method is used! But the rendering is done with Athens. > > Rubric does not work - Itself already duplicates many code, I don't want to look at this now. > Brick does not work - It uses some of Canvas' private api, and it is difficult to provide this with Athens. > > > Many other things are working, > PLEASE try it out. Morphic on Athens looks great (except the font issue ...). > > Just take a fresh image (I use 40442) and load the attached > > morphic_on_athens.cs (<-- all code for Morphic<->Athens porting) > athens_test_display.3.cs (<-- Tests Athens for the whole MorphicWorld) > > Open a Workspace (old workspace preferred) and execute > > AthensTestDisplay testSwitchToAthensFor: 25. > > This will switch the world display rendering for 25 seconds from Morphics Canvas-Api to > Athens. > > > Feedback welcome. > > > > > > > > <athens_test_display.3.cs><morphic_on_athens.cs>

Jan. 31, 2015

Re: [Pharo-dev] Issue 12970 - 16 steps to get through #halt - PROPOSED FIX

by Eliot Miranda

On Fri, Jan 30, 2015 at 2:54 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Ben Coman wrote > > @Sean, In what way will it make halts more annoying? > > Clearly seems to make things better in your use case, but IIRC the purpose > of that test is that you don't want to open the debugger within the halting > system. And indeed, when you remove it, you end up in #halt. But where you > want to be is in UndefinedObject>>DoIt. So, it seems like a hack that, > while > better in this case, may have implications in other cases. The solution > we're looking for is: "debuggers-opened-due-to-halts always open on the > first context totally outside the halt machinery" and we're not quite there > yet. > Nobody responded to my suggestion of inlining the code for haltOnce so that the Halt signal happens in haltOnce itself, just as it does inside halt. This may make the system respond to haltOnce the same as it does to halt. i.e. the debugger can look to the sender of the signalling context. As it is now, the sender of the signalling context of a haltOnce is halt, not the sender of haltOnce as desired. Let me reiterate, I expect haltOnce "Halt unless we have already done it once." (Smalltalk at: #HaltOnce ifAbsent: [false]) ifTrue: [Smalltalk at: #HaltOnce put: false. Halt signal] will behave similarly to halt Halt signal and stop the debugger where desired. If the decomposition into haltOnceEnabled & clearHaltOnce is desired it can still be written haltOnce "Halt unless we have already done it once." self haltOnceEnabled ifTrue: [self clearHaltOnce. Halt signal] but keeping Halt signal in haltOnce instead of invoking through halt is key. > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Issue-12970-16-steps-to-get-through-halt-PROPOSED-FIX… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- best, Eliot

Jan. 31, 2015

Re: [Pharo-dev] Issue 12970 - 16 steps to get through #halt - PROPOSED FIX

by Sean P. DeNigris

Ben Coman wrote > @Sean, In what way will it make halts more annoying? Clearly seems to make things better in your use case, but IIRC the purpose of that test is that you don't want to open the debugger within the halting system. And indeed, when you remove it, you end up in #halt. But where you want to be is in UndefinedObject>>DoIt. So, it seems like a hack that, while better in this case, may have implications in other cases. The solution we're looking for is: "debuggers-opened-due-to-halts always open on the first context totally outside the halt machinery" and we're not quite there yet. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Issue-12970-16-steps-to-get-through-halt-PROPOSED-FIX… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 30, 2015

Re: [Pharo-dev] Fwd: 14827 ProtoObject>>pointersTo failing circular references

by Eliot Miranda

On Fri, Jan 30, 2015 at 6:32 AM, Ben Coman <btc(a)openinworld.com> wrote: > Yes. I just got back to looking at it and noticed the culprit was > printString. Now #printString --> #printStringLimitedTo: --> > #streamContents:limitedTo: which uses LimitedWriteStream that should > protect against such recursion. > > However Array>>printOn: is... > > self shouldBePrintedAsLiteral ifTrue: [self printAsLiteralFormOn: aStream. > ^ self]. > self isSelfEvaluating ifTrue: [self printAsSelfEvaluatingFormOn: aStream. > ^ self]. > super printOn: aStream > > where #shouldBePrintedAsLiteral and #isSelfEvaluating recursively call > themselves - bypassing the protection of LimitedWriteStream. > > As an aside, Array>>shouldBePrintedAsLiteral seems identical to > Array>>isLiteral -- so is it redundant and the former be deprecated? > > Now I don't quite follow the semantics of #isLiteral and #isSelfEvaluating > for Arrays. > > a := #( 1 2 { 3 . 4 } 5). > a isLiteral. "true" > a isSelfEvaluating. "true" > > b := { 1 . 2 . #( 3 4 ) . 5 }. > b isLiteral. "true" > b isSelfEvaluating. "true" > > So can someone provide an example for an Array where #isLiteral or > #isSelfEvaluating are false ? Otherwise it seems it will always take > the first condition of Array>>printOn: . > An Array that contains anything that isn't literal. e.g. {1@2} {1@2} isLiteral => false {{1@2} size. #(1@2) size} => #(1 3) > cheers -ben > > On Fri, Jan 30, 2015 at 9:23 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> Quick and Dirty, >> replace Array>>#printOn: >> with >> >> printOn: aStream >> self class = Array ifTrue: [self printAsSelfEvaluatingFormOn: >> aStream. ^ self]. >> super printOn: aStream >> >> testObject := 'TEST'. >> ref1 := { testObject. nil }. >> ref2 := { ref1 }. >> ref3 := { ref2 }. >> ref1 at: 2 put: ref3. "note the reference loop this creates" >> testObject pointersTo asString >> >> works >> >> >> 2015-01-30 14:15 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: >> >>> Hi Ben, >>> >>> i don't know exactly what is happening here, but (size vs. inpsect) >>> >>> testObject := 'TEST'. >>> ref1 := { testObject. nil }. >>> ref2 := { ref1 }. >>> ref3 := { ref2 }. >>> ref1 at: 2 put: ref3. "note the reference loop this creates" >>> testObject pointersTo size >>> -> 5 >>> >>> >>> >>> works. So, the problem is not in #pointersTo but inspecting the result >>> array has one or more recursive self calls >>> to its elements. >>> >>> >>> >>> >>> 2015-01-30 3:59 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >>> >>>> >>>> I am revisiting my PointerDetective tool, which relies heavily on >>>> ProtoObject>>pointersTo. >>>> >>>> The example I recorded at the repository home page is currently locking >>>> & crashing the image due to #pointersTo being unable to handle the circular >>>> reference. This "must" have been working on Windows at least around August >>>> 2014, but I've been unable to reproduce a working case since my Windows >>>> laptop died and I've since moved to OSX. >>>> >>>> On OSX, in a fresh image 40467 and latest vm 402, the following crashes >>>> the image... >>>> >>>> testObject := 'TEST'. >>>> ref1 := { testObject. nil }. >>>> ref2 := { ref1 }. >>>> ref3 := { ref2 }. >>>> ref1 at: 2 put: ref3. "note the reference loop this creates" >>>> testObject pointersTo inspect. >>>> >>>> OSX Memory Monitor shows memory usage shoot from 50MB to >500MB in a >>>> few seconds, then usually the image crashes, but sometimes just hangs. >>>> >>>> I've logged... >>>> https://pharo.fogbugz.com/default.asp?14827 >>>> >>>> cheers -ben >>>> >>>> >>> >> > -- best, Eliot

Jan. 30, 2015

Re: [Pharo-dev] Tools for automatic recognition of Design Patterns

by Atlas

Sounds exciting, I'd be also happy to know if there is any tool I might have missed. You might want to take a look at the ASTInterpreter and write the analyses yourselves, if that is an option. As a matter of fact, I have some experience in doing program analysis and design pattern detection, but that's a long time ago. If you need any help, please let me know. -- View this message in context: http://forum.world.st/Tools-for-automatic-recognition-of-Design-Patterns-tp… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 30, 2015

Re: [Pharo-dev] Tools for automatic recognition of Design Patterns

by Richard Sargent

Nevena Milojkovic wrote > Can anyone suggest me tool for automatic design patterns detection in > Smalltalk? The rewrite tool in the Refactoring Browser has the potential, but I strongly suspect the problem is intractable. By the way, the rewrite tool is powerful but difficult to figure out and use, even when you can find the documentation for it. -- View this message in context: http://forum.world.st/Tools-for-automatic-recognition-of-Design-Patterns-tp… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 30, 2015