August 2009 - Pharo-dev - lists.pharo.org

[Pharo-project] could somebody comment on

by StÃ©phane Ducasse

Issue 1065: WriteStream nextPut: has unnecessary coupling to/ performance decrease with ByteStrings http://code.google.com/p/pharo/issues/detail?id=1065

Aug. 30, 2009

Re: [Pharo-project] Process>>#'environmentAt:put:'

by StÃ©phane Ducasse

Good point http://code.google.com/p/pharo/issues/list?thanks=1117 On Aug 30, 2009, at 12:43 PM, James Foster wrote: > The typical Dictionary protocol is to return the added value rather > than self. I suggest that Process>>#'environmentAt:put:' follow the > same convention. > > Dictionary new at: #'James' put: 1. "returns 1" > Processor activeProcess environmentAt: #'James' put: 1. "returns > aProcess" > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 30, 2009

[Pharo-project] Process>>#'environmentAt:put:'

by James Foster

The typical Dictionary protocol is to return the added value rather than self. I suggest that Process>>#'environmentAt:put:' follow the same convention. Dictionary new at: #'James' put: 1. "returns 1" Processor activeProcess environmentAt: #'James' put: 1. "returns aProcess"

Aug. 30, 2009

Re: [Pharo-project] Clipboard Problem on Mac build 10424

by StÃ©phane Ducasse

James Thanks what is the magic initialize that we typed in your workspace. Stef On Aug 30, 2009, at 12:21 PM, James Foster wrote: > On #10424 my image became confused with clipboard problems. Somehow, > MacOSClipboard.clipboard became false when it appears that the correct > value is zero (0). When attempting to fix this I found that > ExternalClipboard>>#'initialize' contains the following line, which > probably causes the problem: > > clipboard := [self createClipboard] on: Error do: [:ex | clipboard > = 0] > > I suspect that the correct code should be: > > clipboard := [self createClipboard] on: Error do: [:ex | clipboard := > 0] > or > clipboard := [self createClipboard] on: Error do: [:ex | 0] > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 30, 2009

[Pharo-project] Clipboard Problem on Mac build 10424

by James Foster

On #10424 my image became confused with clipboard problems. Somehow, MacOSClipboard.clipboard became false when it appears that the correct value is zero (0). When attempting to fix this I found that ExternalClipboard>>#'initialize' contains the following line, which probably causes the problem: clipboard := [self createClipboard] on: Error do: [:ex | clipboard = 0] I suspect that the correct code should be: clipboard := [self createClipboard] on: Error do: [:ex | clipboard := 0] or clipboard := [self createClipboard] on: Error do: [:ex | 0]

Aug. 30, 2009

[Pharo-project] Complex Solutions

by Ken Dickey

>From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> ... >I have not been over all of it, but I have found that Real>>arcCosH and > #arcTanH can answer a Complex. I would rather not have to say it, but I do > not get the sense that you have taken our concerns seriously. We want the > errors from Float when the domains are violated. A mere #asComplex can be > dividing line that puts the programmer in conrol. Thanks. I had not caught these. >On this next minor point I can be talked out of it, but I would much prefer > #cosh etc. to #cosH; it's easier to type and matches all conventional > notation that I have seen. I am trying to follow camelCase as I understand it. One rubric from user interfaces is that things which are distinct should *look* distinct. I personally perfer cosH to cosh because I know it is not a typo. That I really mean cosH not cos. Let me know the proper thing to do here. >Number>>angle should probably be called #argument, though I would argue that > it should not exist as it is another example of implicit (however benign) > coercion to complex numbers. I am trying to follow conventions here for other languages which support Complex data types [primarily Common Lisp and, Scheme]. An angle in radians is what is returned. Wny not call the function returning an angle to be #angle ? Again, let me know the proper thing to do in Smalltalk. >Complex>>angle looks like it will answer zero for a value of zero?? AFAIK, > there should be no direction for a zero vector. In a way, it is splitting > hairs because exact comparisons of floats are dubious, but it probably > should raise an error for zero. I am following ANSI X3J13 (they had a formal vote which declared the angle of zero to be zero). Let me know of a better refrerence. [The problem with standards is that there are so many to chose from ;^]. >Object Arts has long looked down on #as* and #is* methods. With my bias > toward their views confessed, #isComplex and #isNumberOrComplex realy > should not exist, and even if they do, what are they doing in Object? > #isNumberOrComplex raises concerns that there is too much blending of > Complex into floats. According to my recollection of _Squeak by Example_, #isFoo is a standard ideom for a class #Foo. #isNumberOrComplex is used to make double dispatch work in #=, now that Complex instances answer false to isNumber. Do you have a better solution here? #isNumberOrComplex was added to Object to make the test relatively cheap (#= is used a lot, yes?). If Complex does not interoperate, at least to some extent, with Floats how would it be useful for anything? Smalltalk without polymorphism ??? Better solutions? >There are various uses of Taylor series corrections and some things that are > computed directly in terms of exponentials. My hunch is that robust > scientific libraries will (hopefully) do these things well, and most of the > transcendental functions, especially over complex numbers, should come from > them when possible and reasonable. The results will likely be faster and > probably more accurate than what we can do in Smalltalk. I agree that a better global solution for numbers is desired. This is an attempt for a small tweak to simply fix the problems I outlined. These problems exist in the current code base. Thank you again for taking the time to look at this, -KenD

Aug. 29, 2009

Re: [Pharo-project] Complex Solutions

by Schwab,Wilhelm K

Ken, I have not been over all of it, but I have found that Real>>arcCosH and #arcTanH can answer a Complex. I would rather not have to say it, but I do not get the sense that you have taken our concerns seriously. We want the errors from Float when the domains are violated. A mere #asComplex can be dividing line that puts the programmer in conrol. On this next minor point I can be talked out of it, but I would much prefer #cosh etc. to #cosH; it's easier to type and matches all conventional notation that I have seen. Number>>angle should probably be called #argument, though I would argue that it should not exist as it is another example of implicit (however benign) coercion to complex numbers. Complex>>angle looks like it will answer zero for a value of zero?? AFAIK, there should be no direction for a zero vector. In a way, it is splitting hairs because exact comparisons of floats are dubious, but it probably should raise an error for zero. Object Arts has long looked down on #as* and #is* methods. With my bias toward their views confessed, #isComplex and #isNumberOrComplex realy should not exist, and even if they do, what are they doing in Object? #isNumberOrComplex raises concerns that there is too much blending of Complex into floats. There are various uses of Taylor series corrections and some things that are computed directly in terms of exponentials. My hunch is that robust scientific libraries will (hopefully) do these things well, and most of the transcendental functions, especially over complex numbers, should come from them when possible and reasonable. The results will likely be faster and probably more accurate than what we can do in Smalltalk. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Ken Dickey Sent: Saturday, August 29, 2009 11:08 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Complex Solutions Greetings, I have released SLICE-basic-Complex to PharoInbox and created added ISSUE # 1097. I believe this proposal addresses most of the concerns I have seen. Thanks again for your review and helpful comments! A brief discussion follows. -KenD ===================================== The SLICE-basic-Complex package (re)adds Complex objects to the Pharo Beta 1 image. YOU MUST LOAD the SLICE-remove-Complex package BEFORE LOADING THIS PACKAGE !! ==PROBLEMS== In mathematics, type Complex is a superset of type Real, but in Pharo the class Complex is unrelated to subclasses of Number. This causes some common expectations to be disappointed. In particular, the following patterns break down: [1] If (A=a) and (B=b) and (A<B) then (a<b) [2] A squared sqrt = A [3] A isNumber => (A class) isKindOf: Number [4] Pharo users and code have expectations that (-1 sqrt) causes an exception. [1] | A a B b | A := 0. a := A + 0i. B := 1. b := B asComplex. A = a. "true" B = b. "true" A < B. "true" a < b. "ERROR" [2] 1i squared. "-1 + 0i" 1i squared sqrt. "ERROR" 1i squared real sqrt. "ERROR" [3] (1.2 + (1/2)i) isNumber. "true" (1.2 + (1/2)i) class isKindOf: Number. "false" In particular, isNumber is used in a number of low-level methods which would not deal well with complex numbers. E.g. FloatArray>> *= anObject ^anObject isNumber ifTrue:[self primMulScalar: anObject asFloat] ifFalse:[self primMulArray: anObject] ==SOLUTIONS== [A] SLICE-remove-Complex Removing the Complex code gives more traditional Smalltalk expectations. In particular this conservative approach yields the best code backward compatability because Complex is a relatively recent addition to Squeak and was not present in many older Smalltalk implementations. In particular, problems [1][2][3] cannot arise. [B] SLICE-basic-Complex [1] is fixed by adding a "formal" method to Complex with selector #< which only compares real numbers (those whose imaginary component is zero). [2] is addressed by keeping Complex objects disjoint from Numbers. Explicit coercion is required 1i squared asComplex sqrt -> 1i -4 asComplex sqrt -> 2i The examples shown above continue to yield exceptions. [3] Complex objects are NOT numbers, but objects with number-like behavior. Complex instances answer false to isNumber. There is a isNumberOrComplex predicate which is used in the Number>>= methods in place of isNumber so that the double dispatch coercions work as expected with Numbers and Complex instances. Note that the basicComplex package also adds the hyperbolic trig functions to Numbers. -KenDickey [Ken dot Dickey at Whidbey dot Com] _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 29, 2009

Re: [Pharo-project] Events, announcements, etc.

by Schwab,Wilhelm K

Stef, Thanks for your input/reassurance. Vassili Bykov has a nice blog enty (Nov 2005) on announcements, and after skimming that, I have a much better sense (hopefully a correct one<g>) for announcements. Given that #trigger:with: can carry arbitrary information, it seems that announcements are a smaller change relative to events than events were to depencies of the MVC era - I'm still trying to forget about the latter. Thanks! Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Saturday, August 29, 2009 10:58 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Events, announcements, etc. On Aug 28, 2009, at 11:08 PM, Schwab,Wilhelm K wrote: > Hello all, > > I know there has been a fair amount of discussion of event mechanisms; > I have not been able to follow all of it, and have probably forgotten > most of what I did manage to absorb. That said, I _think_ I am fairly > flexible as long as there is some way to trigger events and get > messages sent to interested parties. > > Dolphin calls uses selectors such as #trigger: and #trigger:with:. > Pharo has methods called #triggerEvent:, etc. Is that done for a > specific reason? Am I walking into any traps by forwarding them to > #trigger: and friends? I do not think so. Announcement is nice because you manipulate objects. Stef > > Bill > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 29, 2009

[Pharo-project] [ANN] 10424

by Damien Cassou

- Issue 1094: Notification in compiler by Colin StÃ©phane & Damien -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Aug. 29, 2009

[Pharo-project] Complex Solutions

by Ken Dickey

Greetings, I have released SLICE-basic-Complex to PharoInbox and created added ISSUE # 1097. I believe this proposal addresses most of the concerns I have seen. Thanks again for your review and helpful comments! A brief discussion follows. -KenD ===================================== The SLICE-basic-Complex package (re)adds Complex objects to the Pharo Beta 1 image. YOU MUST LOAD the SLICE-remove-Complex package BEFORE LOADING THIS PACKAGE !! ==PROBLEMS== In mathematics, type Complex is a superset of type Real, but in Pharo the class Complex is unrelated to subclasses of Number. This causes some common expectations to be disappointed. In particular, the following patterns break down: [1] If (A=a) and (B=b) and (A<B) then (a<b) [2] A squared sqrt = A [3] A isNumber => (A class) isKindOf: Number [4] Pharo users and code have expectations that (-1 sqrt) causes an exception. [1] | A a B b | A := 0. a := A + 0i. B := 1. b := B asComplex. A = a. "true" B = b. "true" A < B. "true" a < b. "ERROR" [2] 1i squared. "-1 + 0i" 1i squared sqrt. "ERROR" 1i squared real sqrt. "ERROR" [3] (1.2 + (1/2)i) isNumber. "true" (1.2 + (1/2)i) class isKindOf: Number. "false" In particular, isNumber is used in a number of low-level methods which would not deal well with complex numbers. E.g. FloatArray>> *= anObject ^anObject isNumber ifTrue:[self primMulScalar: anObject asFloat] ifFalse:[self primMulArray: anObject] ==SOLUTIONS== [A] SLICE-remove-Complex Removing the Complex code gives more traditional Smalltalk expectations. In particular this conservative approach yields the best code backward compatability because Complex is a relatively recent addition to Squeak and was not present in many older Smalltalk implementations. In particular, problems [1][2][3] cannot arise. [B] SLICE-basic-Complex [1] is fixed by adding a "formal" method to Complex with selector #< which only compares real numbers (those whose imaginary component is zero). [2] is addressed by keeping Complex objects disjoint from Numbers. Explicit coercion is required 1i squared asComplex sqrt -> 1i -4 asComplex sqrt -> 2i The examples shown above continue to yield exceptions. [3] Complex objects are NOT numbers, but objects with number-like behavior. Complex instances answer false to isNumber. There is a isNumberOrComplex predicate which is used in the Number>>= methods in place of isNumber so that the double dispatch coercions work as expected with Numbers and Complex instances. Note that the basicComplex package also adds the hyperbolic trig functions to Numbers. -KenDickey [Ken dot Dickey at Whidbey dot Com]

Aug. 29, 2009