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

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

by stepharo

So you found a bug :) Le 30/1/15 15:32, Ben Coman a Ã©crit : > 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: . > > cheers -ben > > On Fri, Jan 30, 2015 at 9:23 PM, Nicolai Hess <nicolaihess(a)web.de > <mailto:nicolaihess@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 > <mailto:nicolaihess@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 > <mailto:btc@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 > > > >

Jan. 31, 2015

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

by stepharo

> > > On Fri, Jan 30, 2015 at 6:32 AM, Ben Coman <btc(a)openinworld.com > <mailto:btc@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) and now normally isSelfEvaluating should return true because {{1@2} . #(1@2) } isSelfEvaluating -> true because 1@2 while not being a literal is still a cool object whose representation represents it fully. In pharo {(1@2). (1 @ 2)} printString ->{(1@2). (1@2)} and not #(....# > > > cheers -ben > > On Fri, Jan 30, 2015 at 9:23 PM, Nicolai Hess <nicolaihess(a)web.de > <mailto:nicolaihess@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 > <mailto:nicolaihess@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 > <mailto:btc@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. 31, 2015

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

by stepharo

Roel Wuyts PhD was exactly this topic and it was in 1998. This is why he built SOUL. Le 31/1/15 13:05, Atlas a Ã©crit : > stepharo wrote >> 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. > It's not a question of how, but when, really. > > There are many answers to this question and one of them is > Chimera: https://www.ics.uci.edu/~taylor/ics228/chimera.pdf > > <http://forum.world.st/file/n4802920/chimera.png> > > There are no perfect solutions of course, but a lot could be done to improve > the current situation, for example, executable flow charts (Grail is a great > example) would be also a great start. Visual arrangement of concepts such as > classes and annotations (in the form of mind maps) would be also great. > > The concepts are there, they just have to be rediscovered and integrated > into Pharo. What your system needs is a hypermedia system and the liveliness > would make it a perfect candidate. > > I have written about future directions, but nobody seemed interested which > was quite a surprise to me. > > > > > > -- > 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. 31, 2015

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

by Atlas

stepharo wrote > 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. It's not a question of how, but when, really. There are many answers to this question and one of them is Chimera: https://www.ics.uci.edu/~taylor/ics228/chimera.pdf <http://forum.world.st/file/n4802920/chimera.png> There are no perfect solutions of course, but a lot could be done to improve the current situation, for example, executable flow charts (Grail is a great example) would be also a great start. Visual arrangement of concepts such as classes and annotations (in the form of mind maps) would be also great. The concepts are there, they just have to be rediscovered and integrated into Pharo. What your system needs is a hypermedia system and the liveliness would make it a perfect candidate. I have written about future directions, but nobody seemed interested which was quite a surprise to me. -- 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. 31, 2015

Re: [Pharo-dev] Athens/Morphic

by Alain Plantec

> > Yes the HandMorph is handled like any other Morph, it draws itself and > after that it draws all its submorphs. (And actually it does not use any caching, and it is still quite fast) the same in Bloc, no caching and it works just fine :) > But yes, it needs a special drawOnAthens method. > > Do you plane to make a package for it ? > I would like to integrate it in Bloc. > > What would like to integrate? In fact I do not see any change when in Bloc. So I guess I will have to adapt Bloc to your changes. > I will upload the changes in Athens-Morphic package to > the Athens repository. cool. thanks Alain

Jan. 31, 2015

Re: [Pharo-dev] SciSmalltalk -> SciTalk

by Serge Stinckwich

On Sat, Jan 31, 2015 at 11:26 AM, stepharo <stepharo(a)free.fr> wrote: > Hi serge Hi Stef, > do we migrate the code to another repo with a nicer name? > Then DHB ->Sci Yes the idea is to find a better name for SciSmalltalk and after that move the repo ;-) Any ideas ? Better to discuss on sci-smalltalk mailing-list : https://groups.google.com/forum/#!forum/scismalltalk -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Jan. 31, 2015

SciSmalltalk -> SciTalk

by stepharo

Hi serge do we migrate the code to another repo with a nicer name? Then DHB ->Sci Stef

Jan. 31, 2015

Re: [Pharo-dev] Athens/Morphic

by Nicolai Hess

Thank you for your feedback @Marcus I spend hours doing experiments with the font rendering, I think there must be a way to make it look better, because AFAIK there are other cairo based applications and the font rendering looks better. (maybe only linux?) Yes, the AthensTestDisplay is initialized with the current screen extent. We can reset that after the window changed (AthensTestDisplay reset). But this is only a test envionment, if we *ever* change the default morphic rendering backend to Athens, we have to develop a real athens world display workflow. (reinit athens on startup, provide a fallback if we move the image to a system without cairo...) 2015-01-31 10:33 GMT+01:00 Alain Plantec <alain.plantec(a)yahoo.com>: > super! > it just works fine, except the font. > Iâve also noticed that the mouse pointer is not drawn while dragging a > morph. > @Alain Yes the HandMorph is handled like any other Morph, it draws itself and after that it draws all its submorphs. (And actually it does not use any caching, and it is still quite fast) But yes, it needs a special drawOnAthens method. > Do you plane to make a package for it ? > I would like to integrate it in Bloc. > What would like to integrate? I will upload the changes in Athens-Morphic package to the Athens repository. But there are actually 5 different kinds of changes and I will group them as: athens morphic support (missing implementation for borderstyles, fillstyles, ) athens text support (athens based display scanner and some changes to the TextMorphs) athens drawOn (some more drawOnAthensCanvas methods (based on the two above) athens canvas wrapper ( the Athens based wrapper for (Morphic-)Canvas) athens drawOn with canvas wrapper ( other missing drawOnAthensCanvas methods, but those that use the CanvasWrapper for its implementation) And the AthensTestDisplay? I don't know, it is just for the testing, but we need something better. nicolai > thanks > Alain > > > Le 31 janv. 2015 Ã 09:48, Marcus Denker <marcus.denker(a)inria.fr> a Ã©crit : > > 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>: > >> >> 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] Athens/Morphic

by Alain Plantec

super! it just works fine, except the font. Iâve also noticed that the mouse pointer is not drawn while dragging a morph. Do you plane to make a package for it ? I would like to integrate it in Bloc. thanks Alain > Le 31 janv. 2015 Ã 09:48, Marcus Denker <marcus.denker(a)inria.fr> a Ã©crit : > > 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 <mailto:nicolaihess@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] athens font rendering and subpixel antialiasing

by stepharo

> In athens, there are "hints" you can set. > (CairoFontOptions/hintMetricsOff/hintMetricsOn/hintStyleFull ....) > I played a bit with different settings. Changing this settings change > the output, but I can not get it to look > like with the freetype plugin. I understand that this can not look > equally, because the FreeTypePlugin and caire work differently, > but the athens result looks bad compared with the other one. > > - Pixel fitting. (The aliasing going on at the top of characters) > Put Hinting: None in FreeType advanced features, and you will > probably see something similar to the Athens rendering. > > > Yes, we can change the freetypeplugin setting and cairofontoption > setting to make the output look equally - ugly :) > Nicolai Igor explained to me that FreeType offers a degenerated mode that when the font does have the information for bold, kerning,.... computes a "guessed and approximated" default. Cairo does not offer this api else Athens would use it. So what would be interesting is to test using font having all the information to see if Cairo display well the fonts. Stef

Jan. 31, 2015