April 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Better debugging...

by Camillo Bruni

I think a nice way to have a decent debugger is to run the program on top of a changeable interpreter. Since a classical debugger is nothing else but an interpreter with slightly changed semantics. The object flow VM does a great job at tracing back stuff.. however it might pose a massive overhead since it collects tons and tons of data. In Pinocchio[1] we implemented very nice and simple debuggers by "just" changing the current interpreter to take a user-action into account on each message send. Since this is implemented on top of a metacircular interpreter this was quite simple to achieve. So the whole implementation of the known debugger functionality (step, over...) maybe took an afternoon. Since you have access to the full interpreter protocol it is very easy to intercept different sorts of actions. As described in the linked paper, it was very easy to implement the object-flow behavior in Pinocchio. So for me there is only one real way to have a decent debugger. And that means that it is a first-class interpreter whose semantics I can change at will. Thus I can create a specific debugger for my applications. But I guess that making the first-class interpreters work right away in Pharo will take a while to do, hence I propose the following additions to the current interpreter to make it partly useable: - interception of message sends - per thread [ok] - of specific classes [missing] - of specific instances [missing] - interception of instance variable access, read/write - per thread [missing] - of specific classes [missing] - of specific instances [missing] - of specific instance variables [missing] Furthermore I really want to be able to script all of that stuff, eg. provide a simple test block that gets invoked on each message send. Returning true => halt, Returning false => continue execution. [1] http://scg.unibe.ch/archive/papers/Verw10aPinocchio.pdf

April 25, 2011

Re: [Pharo-project] What is a well documented class?

by Alexandre Bergel

Ok, focusing on the instance variables. I think there is two kind of documentation, one for the casual user, and another for the developers. Alexandre On 25 Apr 2011, at 16:09, DougEdmunds wrote: > 2cents about "what is a well-documented class?": > > Information about the state variables (instance variables): what goes in the > slot, and what it's for. > > Good examples (the layout gets skewed doing copy/paste) > > in RxsPredicate > > Instance Variables: > > predicate <BlockClosure> A one-argument block. If it evaluates to the value > defined by > <negated> when it is passed a character, the predicate is considered to > match. > > negation <BlockClosure> A one-argument block that is a negation of > <predicate>. > > > SMxMorph > > Structure: > instance var Type Description > bounds Rectangle A Rectangle indicating my position and a size that will > enclose me. > > owner SMxMorph My parent SMxMorph, or nil for the top-level SMxMorph, > which is a > or nil world, typically a SMxPasteUpMorph. > > submorphs Array My child Morphs. > > fullBounds Rectangle A Rectangle minimally enclosing me and my > submorphs. > > color Color My primary color. Subclasses can use this in different > ways. > > extension SMxMorphExtension Allows extra properties to be stored without > adding a > or nil storage burden to all morphs. > > > -- > View this message in context: http://forum.world.st/What-is-a-well-documented-class-tp3470956p3474024.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 25, 2011

Re: [Pharo-project] Error with latest ProfStef in Pharo 1.3

by Alexandre Bergel

Ok, tomorrow at 13:20 - 13:30 (GMT+1) on skype Alexandre On 25 Apr 2011, at 15:26, laurent laffont wrote: > > On Mon, Apr 25, 2011 at 8:30 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > May be I can check this with my local developer group on Tuesday (we meet from 12:30 -> 13h30. If you wake up early :) > > 13:30 in france is 8:30 in Chile. I usually arrive at 8:20 at work. So, we meet on tomorrow? > Using IRC? > > No problem. We can use skype. > > Laurent. > > > > Cheers, > Alexandre > > > Laurent > > > > We could then write new tests, make sure ProfStef works for Pharo 1.3 and fix the bug found by Mariano. > > > > Cheers, > > Alexandre > > > > > > On 24 Apr 2011, at 12:33, laurent laffont wrote: > > > > > > > > On Sun, Apr 24, 2011 at 6:43 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > > ah ah! This is what we have changed during the pharo cast. > > > Laurent, do you want that we have a look at it together? > > > > > > haha I won't be able to look at it until Tuesday. > > > > > > Laurent. > > > > > > > > > Cheers, > > > Alexandre > > > > > > > > > On 24 Apr 2011, at 11:30, Mariano Martinez Peck wrote: > > > > > > > "Error 'Please use buildTutorialTopicFor: instead'" > > > > > > > > when I try to open it from the menu. > > > > > > > > ProfStefHelpTutorialBuilder >> buildHelpTopicFrom: aHelpTopicDescription > > > > "Start building from the given help topic description" > > > > > > > > ^(self new) > > > > rootToBuildFrom: aHelpTopicDescription; > > > > build; > > > > topicToBuild > > > > > > > > the rpoblem is that #new > > > > > > > > I am using last versions of Pharo1.3 > > > > > > > > -- > > > > Mariano > > > > http://marianopeck.wordpress.com > > > > > > > > > > -- > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > Alexandre Bergel http://www.bergel.eu > > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > > > > > > > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 25, 2011

Re: [Pharo-project] What is a well documented class?

by Alexandre Bergel

> The tool is a text editor ;-) Woooaaa... That can't be :-) please check the email I just sent. Alexandre > > If we agree on my suggestions, we can compose a set of guidelines to arrive at deliverables that comply with them. > > One tool could be a template and a checklist to help the writer of the documentation. > > -- > Cesar Rabak > > Em 25/04/2011 14:59, Alexandre Bergel < alexandre.bergel(a)me.com > escreveu: > Ok, but what would be a tool that help you write comment? This cannot be the system browser. > > Alexandre > > > On 25 Apr 2011, at 12:37, csrabak(a)bol.com.br wrote: > >> I think a well documented class is a class which can be understood by reading its documentation without having to resort to anything else, be it running the test only to see something not obvious, reading the code to understand the working which the document fell short; and without having to assemble a mini encyclopedia of references in order to grasp the contents of the documentation. >> >> my 0.019999 >> >> -- >> Cesar Rabak >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 25, 2011

Re: [Pharo-project] new template for class empty comments for OB

by Alexandre Bergel

Hi! I worked on a small prototype to help me write code documentation. As an example, here is a template that is automatically given for MOShape, an abstract class in Mondrian that does not have any class variables. MOShape has just one instance variable, isCached. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 'MOShape is PLEASE FILL MOShape is an abstract class. The following methods needs to be implemented #absoluteBoundsFor: #containsPoint:for: #display:on: #heightFor: #widthFor: Class collaborations MOFilledShape MORoundedRectangleShape MOEvent MOLineShape MOAbstractLineLayout MOHorizontalLineLayout MOShape MOVerticalLineLayout MONode MOMouseEvent MOFormsShape MOImageShape MOEasel MOViewRenderer MOShapeAdaptor MOGraphElement MOFormsBuilder MOBoundedShape MOChildrenShape MONodeShape Testing classes MOViewRendererTest MondrianTest MOFormsBuilderTest MONewFormsBuilderTest Class public API #absoluteBoundsFor: #apply:bounds: #boundsFor: #canHandleChildren #collectAllShapes #computeBoundsFor: #computeExtentFor: #containsPoint:for: #disableCache #display:on: #enableCache #heightFor: #isCached #isChildShape #isFormsShape #isLineShape #isNodeShape #isShape #scaleElement:by: Implementation notes Instance Variables: isCached -- PLEASE FILL Comments written by AlexandreBergel on 25 April 2011 ' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= I plan to use this template for each class of Mondrian. The template can be easily automatically processed to detect inconsistency. A collaboration class is a class for which I sent to or received a message from. Unit tests are excluded. A public method is a method that is invoked by an instance of a different class. This is very Java specific, I know. We could scope it to an object instead of a class. What is your opinion on this template? Cheers, Alexandre On 25 Apr 2011, at 11:59, Alexandre Bergel wrote: > I see your point. We need to iterate on what a good template can be. > > In general, I believe a lot can be extracted from unit test execution that can serve as a good basis for documentation: public, private methods, collaboration, ... > > Alexandre > > > On 25 Apr 2011, at 03:15, Lukas Renggli wrote: > >> Hi Alexandre, >> >>> But this is not incompatible. The IVs may still be listed, >>> the template can be adjusted for that >> >> Yes, this is true and the proposed change takes the IVs into account. >> The only problem is that I have to scroll to the bottom in 90% of the >> cases as the variables are a couple of pages below the template text. >> 90% of the time I am looking for information and then something like >> the variable types is at least useful, a two page template is only >> "useful" the few times I actually write a comment. >> >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 25, 2011

Re: [Pharo-project] What is a well documented class?

by DougEdmunds

2cents about "what is a well-documented class?": Information about the state variables (instance variables): what goes in the slot, and what it's for. Good examples (the layout gets skewed doing copy/paste) in RxsPredicate Instance Variables: predicate <BlockClosure> A one-argument block. If it evaluates to the value defined by <negated> when it is passed a character, the predicate is considered to match. negation <BlockClosure> A one-argument block that is a negation of <predicate>. SMxMorph Structure: instance var Type Description bounds Rectangle A Rectangle indicating my position and a size that will enclose me. owner SMxMorph My parent SMxMorph, or nil for the top-level SMxMorph, which is a or nil world, typically a SMxPasteUpMorph. submorphs Array My child Morphs. fullBounds Rectangle A Rectangle minimally enclosing me and my submorphs. color Color My primary color. Subclasses can use this in different ways. extension SMxMorphExtension Allows extra properties to be stored without adding a or nil storage burden to all morphs. -- View this message in context: http://forum.world.st/What-is-a-well-documented-class-tp3470956p3474024.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 25, 2011

Re: [Pharo-project] Memory profiling

by Adrian Lienhard

Hi Alex, I assume that your test run always creates the same number objects with the same size. Given that, there doesn't appear to be any reason why the amount of allocated memory for the given run should vary. So its rather the way you measure that makes the difference. I don't know how you get your profiles, but if you use the VM GC stats, they are global and hence other processes may influence the outcome. Incremental GC is triggered depending on allocation count. There's a r/w VM param to configure this. So iGC is rather a crude way to measure memory usage as it doesn't consider object size (and it is a global counter)... As a solution I suggest to take a look at my DTrace provider for the Squeak/Pharo VM [1]. It allows you to take statistics on questions like: how many instances of which size and of which class were created by which process in which methods? In the blog post I give an example that illustrates the use of DTrace for exactly such a question. HTH, Adrian [1] http://www.adrian-lienhard.ch/blog?dialog=smalltak-meets-dtrace On Apr 24, 2011, at 05:32 , Alexandre Bergel wrote: > Hi! > > I have been working on a memory profiler for Pharo. People who attended Smalltalks'10 may remember Mariano Coca's presentation. > > Unfortunately, I am not satisfied with what we can obtain from the execution of a piece of code in Pharo. The amount of memory consumed by a method _significantly varies_ across execution. I have the impression that memory consumption is a less stable metric than execution time. > > For example, I used this as a benchmark: > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > 7 timesRepeat: [ > 5 timesRepeat: [ Smalltalk garbageCollect]. > MemoryProfiler > viewProfiling: [ > 20 timesRepeat: [| view | > 5 timesRepeat: [ Smalltalk garbageCollect]. > Object new. Object new. > 5 timesRepeat: [ Smalltalk garbageCollect]. > > view := MOViewRenderer new. > view nodes: (1 to: 5000). > view root applyLayout] ] > inPackagesMatching: 'Mondrian-*' > ] > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > It opens a simple visualization in Mondrian. I tried to clean as much as I can before executing the code with multiple garbage collect. > > This piece of code return 7 profiles. > In a profile I have for the method MOBoundedShape>>heightFor: : > Number of Young Allocated Bytes: 42,879,008 bytes > Number of Old Allocated Bytes: 6,000,660 bytes > Total Allocated Bytes: 48,879,668 bytes > Number of Increased Memory Bytes: 0 bytes > Number of Incremental GC's: 1,415 > Number of Full GC's: 0 > Number of Tenures of Surving Objects: 164 > > In another profile I have: > Number of Young Allocated Bytes: -7,857,156 bytes > Number of Old Allocated Bytes: 6,008,872 bytes > Total Allocated Bytes: -1,848,284 bytes > Number of Increased Memory Bytes: 0 bytes > Number of Incremental GC's: 1,373 > Number of Full GC's: 0 > Number of Tenures of Surving Objects: 165 > > In another: > Number of Young Allocated Bytes: -11,956,720 bytes > Number of Old Allocated Bytes: 5,315,216 bytes > Total Allocated Bytes: -6,641,504 bytes > Number of Increased Memory Bytes: 0 bytes > Number of Incremental GC's: 1,354 > Number of Full GC's: 0 > Number of Tenures of Surving Objects: 145 > > And another: > Number of Young Allocated Bytes: 59,132,472 bytes > Number of Old Allocated Bytes: 6,177,772 bytes > Total Allocated Bytes: 65,310,244 bytes > Number of Increased Memory Bytes: 0 bytes > Number of Incremental GC's: 1,361 > Number of Full GC's: 0 > Number of Tenures of Surving Objects: 167 > > The metric "Number of Young Allocated Bytes", "Number of Old Allocated Bytes", "Total Allocated Bytes" are highly unpredictable: i.e., two profiles are likely to be completely different. I am not sure why is this so. I use the standard Pharo1.2 One click, without additional parameter to the VM. Do you think that other platforms and languages behave the same? > > However, the positive point is that it seems that the amount of incremental GC and the number of tenured objects may play an important role in estimating the memory consumption. These metrics are much more stable. > What do you think on this? Does it make sense to say that more a method triggers incremental GC, more it consumes memory? > > What exactly triggers an incremental GC? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

April 25, 2011

Re: [Pharo-project] What is a well documented class?

by csrabak＠bol.com.br

The tool is a text editor ;-) If we agree on my suggestions, we can compose a set of guidelines to arrive at deliverables that comply with them. One tool could be a template and a checklist to help the writer of the documentation. -- Cesar Rabak Em 25/04/2011 14:59, Alexandre Bergel < alexandre.bergel(a)me.com > escreveu: Ok, but what would be a tool that help you write comment? This cannot be the system browser. Alexandre On 25 Apr 2011, at 12:37, csrabak(a)bol.com.br wrote: > I think a well documented class is a class which can be understood by reading its documentation without having to resort to anything else, be it running the test only to see something not obvious, reading the code to understand the working which the document fell short; and without having to assemble a mini encyclopedia of references in order to grasp the contents of the documentation. > > my 0.019999 > > -- > Cesar Rabak > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 25, 2011

Re: [Pharo-project] Error with latest ProfStef in Pharo 1.3

by laurent laffont

On Mon, Apr 25, 2011 at 8:30 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > > May be I can check this with my local developer group on Tuesday (we meet > from 12:30 -> 13h30. If you wake up early :) > > 13:30 in france is 8:30 in Chile. I usually arrive at 8:20 at work. So, we > meet on tomorrow? > Using IRC? > No problem. We can use skype. Laurent. > > Cheers, > Alexandre > > > Laurent > > > > We could then write new tests, make sure ProfStef works for Pharo 1.3 and > fix the bug found by Mariano. > > > > Cheers, > > Alexandre > > > > > > On 24 Apr 2011, at 12:33, laurent laffont wrote: > > > > > > > > On Sun, Apr 24, 2011 at 6:43 PM, Alexandre Bergel < > alexandre.bergel(a)me.com> wrote: > > > ah ah! This is what we have changed during the pharo cast. > > > Laurent, do you want that we have a look at it together? > > > > > > haha I won't be able to look at it until Tuesday. > > > > > > Laurent. > > > > > > > > > Cheers, > > > Alexandre > > > > > > > > > On 24 Apr 2011, at 11:30, Mariano Martinez Peck wrote: > > > > > > > "Error 'Please use buildTutorialTopicFor: instead'" > > > > > > > > when I try to open it from the menu. > > > > > > > > ProfStefHelpTutorialBuilder >> buildHelpTopicFrom: > aHelpTopicDescription > > > > "Start building from the given help topic description" > > > > > > > > ^(self new) > > > > rootToBuildFrom: aHelpTopicDescription; > > > > build; > > > > topicToBuild > > > > > > > > the rpoblem is that #new > > > > > > > > I am using last versions of Pharo1.3 > > > > > > > > -- > > > > Mariano > > > > http://marianopeck.wordpress.com > > > > > > > > > > -- > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > Alexandre Bergel http://www.bergel.eu > > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > > > > > > > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > >

April 25, 2011

Re: [Pharo-project] Glamour theme

by Alexandre Bergel

>> Just wondering whether you have tried to remove the black border of each windows. > The border is not black, it is only slightly darker and it is basically there to distinguish overlapping windows from one another. Ah ok. >> I indeed like to not have it around button, scrollbar. Why not windows? > > You have a border around buttons, because you want to distinguish them from the background. But the button has a different color from the background. > The scrollbar does not have a border because you can already distinguish it against the white. yes >> I have the impression what the window color has to slightly change when not in foreground. > > This is a terrible mechanism that I cannot make to work consistently. At least not yet. In any case, you would probably still want a small border. I was just wondering. >> I like the theme, even if I am more rounded than squared :-) > > The main reason for the square look is that rounded borders look terrible. If this would change, I would definitely play with it :). Ok Thanks, Alexandre > > Cheers, > Doru > > >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> > > -- > www.tudorgirba.com > > "Beauty is where we see it." > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 25, 2011