December 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Behavior>>basicLocalSelectors

by Alexandre Bergel

Sorry, I missed the lazy initialization. Cheers, Alexandre On 26 Dec 2008, at 18:21, Alexandre Bergel wrote: > Dear List, > > I guess this method returns a collection of selectors that are > locally defined (i.e., not imported by some traits). Why it returns > nil in Behavior then? Should it return #() instead? > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 26, 2008

[Pharo-project] Behavior>>basicLocalSelectors

by Alexandre Bergel

Dear List, I guess this method returns a collection of selectors that are locally defined (i.e., not imported by some traits). Why it returns nil in Behavior then? Should it return #() instead? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 26, 2008

Re: [Pharo-project] Debug and testing in a system code browser

by Alexandre Bergel

Sorry, it is in the source.wiresong.ca/ob, and not where it should not be (inbox) Cheers, Alexandre On 26 Dec 2008, at 11:39, Alexandre Bergel wrote: > 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 26, 2008

[Pharo-project] Debug and testing in a system code browser

by Alexandre Bergel

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 26, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by Yoshiki Ohshima

At Wed, 24 Dec 2008 11:11:16 +0100, Michael Rueger wrote: > > What really is the convenience of modifying an argument? Having not to > think up another name? I never understood this argument especially if > you need to use the original value of the argument in several places. If you can think of an argument as a "temp initialized by the caller" (like C), that kind of unifies the args and temps and would reduce the implementation complexity. In *some cases* it would reduce the lines of code in the user land. > Same for upper/lowercase conventions, let alone uppercase method > names. For this, I would strongly advocate to remove the restriction, as only a small subset of letters (defined in Unicode) have the upper or lower classification. -- Yoshiki

Dec. 26, 2008

[Pharo-project] Code coverage in PharoInbox

by Alexandre Bergel

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 25, 2008

Re: [Pharo-project] Pharo image builds (was Re: Notifiers)

by Damien Cassou

On Tue, Dec 23, 2008 at 6:28 PM, Michael Roberts <mike(a)mjr104.co.uk> wrote: > 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? It's ok for me. Just tell me the way you would like me to version and name my images. -- Damien Cassou http://damiencassou.seasidehosting.st

Dec. 25, 2008

Re: [Pharo-project] Fwd: A little question --- merry christmas

by Bill Schwab

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

Dec. 25, 2008

Re: [Pharo-project] About inline: and var: varSymbol declareC: declString

by John M McIntosh

Ok, well the ugly part of this is that we have some Slang in the base pharo, either as Slang code or doubling as primitive failure recovery code . Normally if we had say: primAddActiveEdgeTableEntryFrom: edgeEntry "Add edge entry to the AET." <primitive: 'primitiveAddActiveEdgeEntry' module: 'B2DPlugin'> (self canProceedAfter: self primGetFailureReason) ifTrue:[ ^self primAddActiveEdgeTableEntryFrom: edgeEntry ]. ^self primitiveFailed It would invoke the primitive 'primitiveAddActiveEdgeEntry' in the named plugin 'B2DPlugin' which is located either as a plugin, or compiled into the VM. If the primitive call fails or the primitive fails the call it would then execute the smalltalk failure code. In the case above it would execute the canProceedAfter: and either do the primAddActiveEdgeTableEntryFrom: or the primitiveFailed which would cause the walkback. So looking at var: varSymbol declareC: an example would be ByteString>>indexOfAscii: anInteger inString: aString startingAt: start | stringSize | <primitive: 'primitiveIndexOfAsciiInString' module: 'MiscPrimitivePlugin'> self var: #aCharacter declareC: 'int anInteger'. self var: #aString declareC: 'unsigned char *aString'. stringSize := aString size. start to: stringSize do: [:pos | (aString at: pos) asciiValue = anInteger ifTrue: [^ pos]]. ^ 0 This and others are in the MiscPrimitivePlugin, BUT BUT it's possible that aString isn't a byte or word array object, but understands size, and at: so the the C code will fail, but the Smalltalk code will run. Being clever here we are using the the method to contain both the smalltalk code and the Slang code because it's the same. So you can't remove the smalltalk code because it likely has a purpose in special cases. {"MiscPrimitivePlugin", "primitiveIndexOfAsciiInString", (void*)primitiveIndexOfAsciiInString}, {"MiscPrimitivePlugin", "primitiveCompareString", (void*)primitiveCompareString}, {"MiscPrimitivePlugin", "primitiveStringHash", (void*)primitiveStringHash}, {"MiscPrimitivePlugin", "primitiveConvert8BitSigned", (void*)primitiveConvert8BitSigned}, {"MiscPrimitivePlugin", "primitiveFindFirstInString", (void*)primitiveFindFirstInString}, {"MiscPrimitivePlugin", "primitiveDecompressFromByteArray", (void*)primitiveDecompressFromByteArray}, {"MiscPrimitivePlugin", "primitiveTranslateStringWithTable", (void*)primitiveTranslateStringWithTable}, {"MiscPrimitivePlugin", "primitiveFindSubstring", (void*)primitiveFindSubstring}, {"MiscPrimitivePlugin", "primitiveCompressToByteArray", (void*)primitiveCompressToByteArray}, Also see {"ADPCMCodecPlugin", "primitiveDecodeStereo", (void*)primitiveDecodeStereo}, {"ADPCMCodecPlugin", "primitiveDecodeMono", (void*)primitiveDecodeMono}, {"ADPCMCodecPlugin", "primitiveEncodeStereo", (void*)primitiveEncodeStereo}, {"ADPCMCodecPlugin", "primitiveEncodeMono", (void*)primitiveEncodeMono}, For inline: It's not quite clear if *all* code is in plugins since WarpBlt>>rgbMap: sourcePixel from: nBitsIn to: nBitsOut called via WarpBlt>>mixPix: pix sourceMap: sourceMap destMap: destMap called via WarpBlt>>warpBitsSmoothing: n sourceMap: sourceMap which might be called as a primitive failure case for primitiveWarpBits so you can't remove it. But maybe this is the only special case and you could put inline: in WarpBlt and remove from Object>> The same might apply to var: varSymbol declareC: but would you put that in the using class or retain in Object? Of course if your goal is to simplify Object you might consider moving it. However VMMaker likely would need to consider if it should extend Object. To fully remove var:declareC: & inline: I think you'd would end up with a method in Pharo, and a slightly different method in VMMaker, which isn't a good choice. On 23-Dec-08, at 2:20 PM, StÃ©phane Ducasse wrote: > 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 > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Dec. 25, 2008

[Pharo-project] Fwd: A little question --- merry christmas

by StÃ©phane Ducasse

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. >

Dec. 24, 2008