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

Re: [Pharo-dev] printString and asString

by Esteban A. Maringolo

Hi Otto, 2014/1/3 Otto Behrens <otto(a)finworks.biz>: >> #printString is used for debugging, that's why the default >> implementation shows the class name. It's implemented using #printOn: > > Makes sense. So unless there's a nice symbol that one can add to show > what it is (eg #foo printString = '#foo'), implementors of printOn: > should call super printOn:, yes? In Pharo, this seems to be the > general idea. In my opinion it is not mandatory to call super. Every object is responsible for the implementation. Ej... numbers, dates, and other "scalar like" objects. > But then printString should not be used (generally) as the mechanism > to display something to for a user, right? As this would show > something like 'a Person Otto' to the user. > > Some implementors of printOn: could be renamed to storeOn: > In GemStone, the default implementation of asString is to show the class name. The #storeOn: approach is obsolete, IMHO. It assumes a predefined serialization scheme, which is basically an smalltalk expression to build the object, but as soon as the object graph gets complex, it becomes unusable. It is useful only for magnitudes and other "standalone" objects. >> #displayString (deprecated in Pharo*) is used to display the object in >> the UI. It is implemented by means of #displayOn: (Dolphin used this >> pattern) > > So we don't have this in Pharo anymore. Looks like it is mostly > asString now. But then, really, > > Object asString > ^ self printString > > does not make sense? I never fully understood the "intention" of #asString other than to convert the object to the String "protocol". But I don't use its answer for anything UI-dependant. That's why I have my own #displayOn: and #displayString methods. >> #asString is the toString() equivalent of other languages. In some >> cases `anObject asString asObject` should give the same object back >> (e.g. in Date, Numbers, etc.). Most of the times it is the same string >> as #printString, but it is not consistent. > > The intention of #storeString implemented via #storeOn: is to do that: > (Compiler evaluate: anObject storeString) = anObject. Probably not > completely true for really complex objects... > Which means that by default, both printString and storeString can call > asString, and asString is the 'lowest level'? Any "store" (serialization) should have it's own selector. And most of the times it is implemented using a visitor pattern with double dispatch instead of a simple text append to a Stream. Nowadays it is more common/useful to serialize to JSON than to a smalltalk expression. Regards,

Jan. 3, 2014

Re: [Pharo-dev] out of scope for two weeks

by olivier auverlot

Look after yourself Olivier :-) Le 3 janv. 2014 17:10, "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> a Ã©crit : > hi guys > > my doc stopped me because Iâm exhausted so see you in two weeks. > > Stef >

Jan. 3, 2014

Re: [Pharo-dev] out of scope for two weeks

by Serge Stinckwich

Take care StÃ©phane. Hope to see soon here in good health. On Fri, Jan 3, 2014 at 5:10 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > hi guys > > my doc stopped me because Iâm exhausted so see you in two weeks. > > Stef -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Jan. 3, 2014

out of scope for two weeks

by StÃ©phane Ducasse

hi guys my doc stopped me because Iâm exhausted so see you in two weeks. Stef

Jan. 3, 2014

Re: [Pharo-dev] stroke width in Athens

by Igor Stasenko

Right: scaling scales everything not just geometry. this is intentionally done so, that you have a uniform way to scale up/down whole scenery i.e. if you want to render same scene but 2 times bigger , just put 'scaleBy: 2' before and you done, and it will be exactly 2 times bigger (as if you zoomed-in the image in your graphics editor, except from losing picture quality and having aliasing effects ;) . On 3 January 2014 16:11, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Very true! > looks like to be the thing. Thanks! > > Alexandre > > > On Jan 3, 2014, at 11:12 AM, Henrik Johansen <henrik.s.johansen(a)veloxit.no> > wrote: > > > > > On 03 Jan 2014, at 1:58 , Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > > > >> Hi! > >> > >> Apparently, the width (in pixels) of a stroke in athens seems to vary > with the size of the path. Am I right? > >> > >> For example, I have the following rendering: > >> > >> <Screen Shot 2014-01-03 at 9.54.29 AM.png> > >> > >> There is just one code to draw a box, which is: > >> > >> athensCanvas pathTransform restoreAfter: [ > >> athensCanvas pathTransform > >> translateBy: rectangle center; > >> scaleBy: rectangle extent / 2. > >> > >> athensCanvas > >> setPaint: color; > >> drawShape: self path. > >> > >> strokePaint ifNotNil: > >> [ (athensCanvas > >> setStrokePaint: strokePaint) width: 0.1. > >> athensCanvas drawShape: path ] > >> ] > >> > >> Having a width of 1 makes a very large border. > >> Do I miss something? > >> > >> Cheers, > >> Alexandre > >> -- > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> Alexandre Bergel http://www.bergel.eu > >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >> > >> > >> > > Well yes, you are using scaleBy:. > > That scaling applies to the stroke width of the path as well, Iâd > imagine... > > > > Cheers, > > Henry > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- Best regards, Igor Stasenko.

Jan. 3, 2014

Re: [Pharo-dev] Lost changes recovery

by StÃ©phane Ducasse

hi lorenzo this is strange. Did you succeed to have the following steps? On 03 Jan 2014, at 15:34, Lorenzo Schiavina <lorenzo(a)edor.it> wrote: > Hi, > > I tried to recover lost changes but I failed. > > I used the item in tools menu and I followed the expected actions, but I was not able to find the lost changes in my image; where do they go? > > Is there any place where I can find details about the expected results and understand what I missed? > > Thanks > > Lorenzo >

Jan. 3, 2014

Re: [Pharo-dev] [Issue tracker] Help needed for reviews

by Marcus Denker

On 03 Jan 2014, at 12:04, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > Le 03/01/2014 10:31, Marcus Denker a Ã©crit : >> From then the change was made *other* changes have been done. >> >> âChangeâ will show *all* differences, both the ones other integrations >> did to the package as well as the changes of the slice. >> >> In addition, there is still some bug that when e.g moving classes >> the *extending* packages are bot dirty and there might be some >> inconsistencies. > > Got it. So this is simply an usability concern with misleading button > text and button tooltips, or am I the only one to fell misguided? > > Anyway should be easily fixable, if it should be. yesâ¦ Marcus

Jan. 3, 2014

Re: [Pharo-dev] Lost changes recovery

by Marcus Denker

On 03 Jan 2014, at 15:34, Lorenzo Schiavina <lorenzo(a)edor.it> wrote: > Hi, > > I tried to recover lost changes but I failed. > > I used the item in tools menu and I followed the expected actions, but I was not able to find the lost changes in my image; where do they go? > > Where do they go? they are all in the .changes file. The tools is just a âviewerâ for the stuff pasted at the end of the .changes I just edited a method, quite the image (no save) ârecover lost changesâ, select the last snapshot: > Is there any place where I can find details about the expected results and understand what I missed? > > The tools is far from easy to useâ¦ Martin has a replacement ready, but sadly for Pharo4 ;-) Marcus

Jan. 3, 2014

Re: [Pharo-dev] Nautilus and Traits

by Marcus Denker

On 03 Jan 2014, at 16:48, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi, > > in Nautilus there is a menu "Analyze" -> "Class refs..." to see where a class is used. > > When I select a trait it is not displayed in the menu, but CMD+N is also working when I select > a Traits name in the code pane. Is it by intention to not browse refs for traits or a bug in the menu? > No, else you can not see any place where the user types TBehaviorâ¦ references should stay references. > How can one browse the classes that "use" a trait? Looks like there is no option for that yet. > (for instance to browse and see that "TBehavior" is used in "Behavior") There is a âbrowse usersâ n the main menu (not the âAnalyzeâ submenu), when you browse a Trait. (yes, the menus are not perfect). Marcus

Jan. 3, 2014

Re: [Pharo-dev] Weird Athens Artifact

by Igor Stasenko

On 3 January 2014 12:38, J.F. Rick <self(a)je77.com> wrote: > OK. Here's some code to demonstrate the bug: > > wrap := AthensWrapMorph new > extent: 100 @ 100; > yourself. > black := Morph new > extent: 100 @ 100; > color: Color black; > yourself. > red := Morph new > extent: 100 @ 50; > color: Color red; > yourself. > transparent := Morph new > extent: 50 @ 50; > position: 25 @ -25; > color: Color transparent; > yourself. > wrap > addMorph: black; > addMorph: red; > addMorph: transparent; > openInWorld > > Please note that for this to work, you have to remove the "initialize" > method in AthensWrapMorph that makes it use a TableLayout, which is a silly > choice. Though adding transparent should not make a difference in the > rendering, it does. > > Ah, ok, that's the whole reason why :) Because i AthensWrapMorph mainly , as you said very silly and works for simplest layouts for example: wrap := AthensWrapMorph new extent: 100 @ 100; yourself. black := Morph new extent: 100 @ 100; color: Color black; yourself. red := Morph new extent: 100 @ 50; color: Color red; yourself. transparent := Morph new extent: 50 @ 50; position: 25 @ -25; color: Color transparent; yourself. wrap addMorph: black; addMorph: red; addMorph: transparent; fullBounds (0@ -25) corner: (100@100) it is obvious, that it has to clip submorphs, and fullBounds should be (0@ 0) corner: (100@100) but not (0@ -25) corner: (100@100) because then it is causing 'clipping' because surface's 0@0 corresponds to fullbounds zero , which is 0@-25 and if you draw it this way, then of course the bottom 25 pixels will be clipped. But it really depends on usage.. because in fact maybe it should not clip. (ehh.. morphic has too many features to support them properly :) (btw, i think i found why there's extra 1 pixel , because in #initialize there is: layoutInset: 0@1; :) don't ask me how it appeared there.. i don't remember. The logic should be rewritten in a way that: - the surface extent should be same as wrap morph's fullBounds, not bounds then it won't clip the morphs which outside.. and also it should take into account the negative offset (either x or y) when copying output from athens surface to morphic. i added the issue.. Please feel free to provide a better "fixed" version of wrapper, which is less intrusive than existing one (if i won't do it before) https://pharo.fogbugz.com/f/cases/12555/Improve-AthensWrapMorph Cheers, > > Jeff > > > On Thu, Jan 2, 2014 at 5:29 PM, J.F. Rick <self(a)je77.com> wrote: > >> I'm aware of the default Morphic behavior. I've hacked it so that a >> transparent 1x1 pixel bit is in the hand and its movement causes the brown >> morph to move and remain a submorph of the AthensWrapMorph application. >> >> Yes, this is some kind of weird clipping thing. Specifically, it looks >> like clipping is not happening. The brown morph (and the area behind it) >> renders correctly but it is not rendered at the correct location. Instead, >> the starting location of the rendering seems to be forced into the bounds >> of the surface. That's why it looks like the background things have shifted >> downwards. >> >> Cheers, >> >> Jeff >> >> >> On Thu, Jan 2, 2014 at 5:10 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> >>> >>> >>> On 2 January 2014 16:54, J.F. Rick <self(a)je77.com> wrote: >>> >>>> I've been converting DigiTile over to Athens with general success but I >>>> have found an odd rendering bug. In this scenario, I am moving the brown >>>> square around with a hand. As I am using AthensWrapMorph, I have made it so >>>> that the brown square is a submorph of the application (an AthensWrapMorph) >>>> and not in the hand. The brown square is actually twice the extent that it >>>> appears (i.e., it has a 50 pixel transparent border). This has to be done >>>> to allow rotation handles to be added. Anyway, when it moves so that its >>>> top would go beyond the top of the application, some crazy rendering effect >>>> happens, as illustrated in the included screenshots. This same behavior >>>> happens when moving the square to the left side of the screen. It does not >>>> happen on either the right or the bottom of the screen. It seems like >>>> Athens does not like for submorphs of AthensWrapMorph to extend to the left >>>> or above their parent. This seems like a problem and something that can >>>> easily happen as somebody moves some morph to be partially offscreen. >>>> >>>> >>> Sounds like clipping issue. But it is hard to tell anything by looking >>> at screenshots.. >>> Usually all things outside of visible area should be clipped. >>> Also, note that dragging, like it is done in Morphic, the dragged morph >>> changes its owner to hand (handmorph).. >>> and since it is only within AthensWrapMorph it is where it uses >>> rendering by Athens, it could be simply the case that it don't renders at >>> all (or just uses morhic rendering while held by hand). >>> >>> >>>> Cheers, >>>> >>>> Jeff >>>> >>>> -- >>>> Jochen "Jeff" Rick, Ph.D. >>>> http://www.je77.com/ >>>> Skype ID: jochenrick >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> >> >> -- >> Jochen "Jeff" Rick, Ph.D. >> http://www.je77.com/ >> Skype ID: jochenrick >> > > > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick > -- Best regards, Igor Stasenko.

Jan. 3, 2014