- Pharo-dev - lists.pharo.org

[Pharo-project] Debug and testing in a system code browser
by Alexandre Bergel Dec. 26, 2008

Dec. 26, 2008

ISSUE #427 Added a debug facility when testing (Cmd-T) from within a system browser. Waiting in PharoInbox Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

1 1

[Pharo-project] Code coverage in PharoInbox
by Alexandre Bergel Dec. 25, 2008

Dec. 25, 2008

I just realized that I saved using my initials and not my name. I can resave it if necessary. The MC comment: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ISSUE #426: The class TestCase is extended with few methods that enables a simple code coverage. It essentially checks for method calls in the test, and compare them with the set of defined methods. For example, OrderedCollectionTest coverageAsString ==> 'OrderedCollectionTest covers 60% of OrderedCollection' to get these results for all collections: (((Smalltalk allClasses select: [:cls | cls category beginsWith: 'CollectionsTests-']) copyWithoutAll: {TextAndTextStreamTest . TextLineEndingsTest}) collect: [:cls | cls coverageAsString]) do: [:str | Transcript show: str; cr] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= The printout of the last statement given in the comment is: ArrayTest covers 26% of Array AssociationTest covers 27% of Association BagTest covers 72% of Bag Base64MimeConverterTest covers 0% of Base64MimeConverter CharacterSetTest covers 13% of CharacterSet CharacterTest covers 3% of Character CollectionTest covers 14% of Collection DictionaryTest covers 33% of Dictionary FloatArrayTest covers 22% of FloatArray HeapTest covers 43% of Heap IdentityBagTest covers 0% of IdentityBag IntervalTest covers 59% of Interval LinkedListTest covers 71% of LinkedList MatrixTest covers 10% of Matrix OrderedCollectionTest covers 60% of OrderedCollection ReadStreamTest covers 18% of ReadStream ReadWriteStreamTest covers 13% of ReadWriteStream RunArrayTest covers 25% of RunArray SetTest covers 41% of Set SharedQueue2Test covers 44% of SharedQueue2 SkipListTest covers 48% of SkipList SortedCollectionTest covers 58% of SortedCollection StackTest covers 73% of Stack StringTest covers 10% of String SymbolTest covers 25% of Symbol TextAlignmentTest covers 0% of TextAlignment TextEmphasisTest covers 9% of TextEmphasis TextFontChangeTest covers 33% of TextFontChange TextFontReferenceTest covers 11% of TextFontReference TextKernTest covers 8% of TextKern TranscriptTest covers 9% of Transcript WeakIdentityKeyDictionaryTest covers 0% of WeakIdentityKeyDictionary WideCharacterSetTest covers 38% of WideCharacterSet WideStringTest covers 6% of WideString WriteStreamTest covers 14% of WriteStream The champions are StackTest, BagTest, and OrderedCollectionTest. Good job! Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

1 0

[Pharo-project] Pharo image builds (was Re: Notifiers)
by Michael Roberts Dec. 25, 2008

Dec. 25, 2008

If i'm right in thinking Damien's Pharo-Dev images are early release candidates going forwards for the Pharo image, without the one-click, would it make sense to start naming them Pharo. i.e. drop the -Dev. That way we could start to get consistent with our naming, get the web documentation consistent etc. thoughts? cheers, Mike On Sun, Dec 21, 2008 at 10:31 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Here is an answer for "what is Pharo?" > > There will be two images: > "Pharo-Core": the image in which the development of Pharo takes place > "Pharo": the image to develop your application with (= "Pharo-Core" + > IDE tools [1]) > > "Pharo" is the image that will be officially shipped (packaged as a > one-click image). "Pharo-Core" on the other hand will be important for > deployment as it has a low memory footprint. > > Cheers, > Adrian > > [1] http://code.google.com/p/pharo/wiki/Packages >

3 2

Re: [Pharo-project] Fwd: A little question --- merry christmas
by Bill Schwab Dec. 25, 2008

Dec. 25, 2008

Stef, It was not until I re-read this that I took note of just who had all this great insight into computing. I fully agree about the debugging benefits of immutable arguments. The same argument leads me to want to avoid name collisions between temporary and instance variables. Please tell Dan that from where I sit, he knows a LOT :) Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> stephane.ducasse(a)inria.fr 12/24/08 2:56 PM >>> just to share that with you Begin forwarded message: > From: Daniel Ingalls <Dan.Ingalls(a)Sun.com> > Date: December 24, 2008 8:48:09 PM CEST > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: Re: A little question --- merry christmas > > Hi, Stef - > > >Merry chrismas for you and your family. > > and Merry Christmas to you and yours as well! > > >I have a question for you. > >What is the reason why method arguments are readonly? > >Was there an optimisation? > > In the context of debugging (which is to say, any time you are > looking at the code and thinking about what it does), there is > something nicely declarative about having the arguments preserved in > the state they were at the time of the call. You can refer to them > to see if they make sense, whereas if they have been written over, > you cannot do this, and you may not even be able to look in the > caller if the value comes from an inline expression. So it affords > some of the clarity of the functional programming style. Also, of > course, it makes it simpler to implement, and to think about using, > the ability of a debugger to restart a method after a change. And > finally, if you think about call by reference, overwriting arguments > introduces a bit of gray area in the theory -- one might be led to > think that this would affect a variable in the caller as well. Of > course that's easy to explain, but it's clearer still if there's a > general functional principle that references "upstream" are > immutable -- they are simply a "view" of the calling process. > > But what do I know? > > - Dan > > PS: And yes, there are various optimization aspects such as ways in > which it might be more complicated to maintain two versions of the > stack in a JIT implementation, etc, but this was not a driving force > in the design. > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

[Pharo-project] About inline: and var: varSymbol declareC: declString
by StÃ©phane Ducasse Dec. 25, 2008

Dec. 25, 2008

Hi I'm trying to learn something while reading Object methods. I was wondering whether var: varSymbol declareC: declString and inline: should not be put as Object extension in VMMaker instead of been kept in Object. Now I saw that these methods have senders in the image. Does it mean that part of the code of these senders can be executed when we consider that these two methods are doing nothing? This could be used to debug the code before generating C from it. are my hypotheses correct? Stef

4 4

[Pharo-project] Fwd: A little question --- merry christmas
by StÃ©phane Ducasse Dec. 24, 2008

Dec. 24, 2008

just to share that with you Begin forwarded message: > From: Daniel Ingalls <Dan.Ingalls(a)Sun.com> > Date: December 24, 2008 8:48:09 PM CEST > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: Re: A little question --- merry christmas > > Hi, Stef - > > >Merry chrismas for you and your family. > > and Merry Christmas to you and yours as well! > > >I have a question for you. > >What is the reason why method arguments are readonly? > >Was there an optimisation? > > In the context of debugging (which is to say, any time you are > looking at the code and thinking about what it does), there is > something nicely declarative about having the arguments preserved in > the state they were at the time of the call. You can refer to them > to see if they make sense, whereas if they have been written over, > you cannot do this, and you may not even be able to look in the > caller if the value comes from an inline expression. So it affords > some of the clarity of the functional programming style. Also, of > course, it makes it simpler to implement, and to think about using, > the ability of a debugger to restart a method after a change. And > finally, if you think about call by reference, overwriting arguments > introduces a bit of gray area in the theory -- one might be led to > think that this would affect a variable in the caller as well. Of > course that's easy to explain, but it's clearer still if there's a > general functional principle that references "upstream" are > immutable -- they are simply a "view" of the calling process. > > But what do I know? > > - Dan > > PS: And yes, there are various optimization aspects such as ways in > which it might be more complicated to maintain two versions of the > stack in a JIT implementation, etc, but this was not a driving force > in the design. >

1 0

[Pharo-project] Issues 226 and 368
by HernÃ¡n Morales Durand Dec. 24, 2008

Dec. 24, 2008

http://code.google.com/p/pharo/issues/detail?id=226 http://code.google.com/p/pharo/issues/detail?id=368 ( which lead to http://code.google.com/p/pharo/issues/detail?id=173 )

2 1

[Pharo-project] Coverage of Collection test
by Alexandre Bergel Dec. 24, 2008

Dec. 24, 2008

Hi, I was looking for an approximation of the coverage in the Collection tests. I wrote the following scripts. Maybe some of you have ideas to refine on how to refine it. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- =-=-=-=-= | definedMethods testedMethods classCategory testCategory suffix classes untestedMethods testClasses | suffix := 'Abstract'. classCategory := 'Collections-', suffix. testCategory := 'CollectionsTests-', suffix. classes := Smalltalk allClasses select: [:cls | cls category = classCategory]. testClasses := Smalltalk allClasses select: [:cls | cls category = testCategory]. definedMethods := classes inject: Set new into: [:sum :cls | sum union: cls methodDictionary keys]. testedMethods := testClasses inject: Set new into: [:sum :cls | sum union: (cls methodDictionary values inject: Set new into: [:sums :cm | sums union: cm messages])]. "testedMethods contains all the methods send in test methods, which probably contains methods that have nothign to do with collection" testedMethods := testedMethods reject: [:sel | (definedMethods includes: sel) not]. untestedMethods := definedMethods select: [:selector | (testedMethods includes: selector) not]. { testedMethods . definedMethods . 'coverage =', (testedMethods size * 100 / definedMethods size) asFloat printString } -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- =-=-=-=-= Here are the results so far CollectionsTests- Abstract = 7 % Arrayed = 15% Sequenceable = 54% SkipLists = 47% Stack = 61% Streams = 10% Support = 24% Text = 25% Unordered = 27% Weak = 11% I tried to make Christo run, but it seems that Reflectivity behaves strangely under Pharo. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

1 0

Dec. 24, 2008

Hi I would like to get your point of view on the following: In Object there is the method updateThresholdForGraphicInViewerTab "When a Viewer is open on the receiver, its tab needs some graphic to show to the user. Computing this graphic can take quite some time so we want to make the update frequency depending on how long it takes to compute the thumbnail. The threshold returned by this method defines that the viewer will update at most every 'threshold * timeItTakesToDraw' milliseconds. Thus, if the time for computing the receiver's thumbnail is 200 msecs and the the threshold is 10, the viewer will update at most every two seconds." ^20 "seems to be a pretty good general choice" which is only defined on Object. and only called by ThumbnailMorph>>stepTime "Adjust my step time to the time it takes drawing my referent" drawTime ifNil:[^ 250]. ^(objectToView updateThresholdForGraphicInViewerTab * drawTime) max: 250. and I was thinking ok this a nice hook and may be it should be a morphic extension on Object. On the other hand it seems that this is a feature that is only use by one class that is not even core. So may be we could put the magic number inside the step time. Stef

3 4

[Pharo-project] Gepetto2 and Pharo
by Alexandre Bergel Dec. 24, 2008

Dec. 24, 2008

Hi Marcus, Do you know whether Gepetto2 is know to work on Pharo? I am trying to make Christo (the code coverage tool) run on Pharo. (I ask for it publicly since someone else than Marcus may know). Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

4 9