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

Re: [Pharo-project] Issue 940: (13/10) = 1.3 returns false

by Igor Stasenko

2009/7/8 Hernan Wilkinson <hernan.wilkinson(a)gmail.com>: > >> >> >> > [...] and if you write 1.3, the object that represents that number >> > is not going to be an instance of float but of scaledecimal or >> > fraction or whatever, but not float... >> >> That only solves the issue of representing literals because: >> >> >> > and all operations are made with exact representation. >> >> >> >> cannot be done for all operations: obvious ones like square root, log, >> sin, etc and less obvious ones like #squared where you run out of >> enough bits to maintain precision (in fixed-width implementations). > > not really... root, log, sin, etc could be messages that only inexact > numbers know how to answer , so you want "2 sqrt",Â do "2 asFloat sqrt", but > for +, *, /, etc. they work as expected. > We can also have better representations for number like pi. Why pi is > instance of Float and not Pi? If pi is instance of Pi, then cos(pi/2) = 0 > could be true... just a quick hack: > Pi>>/ aNumber > > Â ^ Fraction numerator: self denominator: aNumberÂ "Or maybe an object > representing that Pi has been divided/multiplied, etc > > Fraction>>cos > > Â ^ numerator cosDividedWith: denominator > > Pi>>cosDividedWith: denominator > > Â ^denominator = 2 ifTrue: [ 0 ] ifFalse: [ ... ] > > and so on > don't forget to add Pi>>mantisOfLength: numBits to compute the Pi up to given precision. :) But your examples is not about computing a result, but rather predicting it. So why bother writing so much stuff , while you can just implement : Number>>cosPiHalved ^ 0 :) >> >> >> >> R >> - >> >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

July 8, 2009

Re: [Pharo-project] Annoying bug: UndefinedObject(Object)>>doesNotUnderstand: #mimeTypes

by Michael Rueger

Mariano Martinez Peck wrote: > But I think that's not the real problem, just a fix. I am right? Right. > but I wonder why Sensor nextEvent is returning me that in and "alt + tab". Somehow that event gets either received from Windows or is generated by the VM for some reason. I'd rather suspect Windows, knowing some of the fun stuff it is doing with events... Michael

July 8, 2009

Re: [Pharo-project] Issue 940: (13/10) = 1.3 returns false

by Hernan Wilkinson

> > > > [...] and if you write 1.3, the object that represents that number > > is not going to be an instance of float but of scaledecimal or > > fraction or whatever, but not float... > > That only solves the issue of representing literals because: > > > > and all operations are made with exact representation. > > > > cannot be done for all operations: obvious ones like square root, log, > sin, etc and less obvious ones like #squared where you run out of > enough bits to maintain precision (in fixed-width implementations). not really... root, log, sin, etc could be messages that only inexact numbers know how to answer , so you want "2 sqrt", do "2 asFloat sqrt", but for +, *, /, etc. they work as expected. We can also have better representations for number like pi. Why pi is instance of Float and not Pi? If pi is instance of Pi, then cos(pi/2) = 0 could be true... just a quick hack: Pi>>/ aNumber ^ Fraction numerator: self denominator: aNumber "Or maybe an object representing that Pi has been divided/multiplied, etc Fraction>>cos ^ numerator cosDividedWith: denominator Pi>>cosDividedWith: denominator ^denominator = 2 ifTrue: [ 0 ] ifFalse: [ ... ] and so on > > > R > - > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 8, 2009

[Pharo-project] byte codes, parse-tree walking, etc.

by Cameron Sanders

1) What classes should I look at to learn about the byte-code generation? 2) What are good examples of code that handles/manipulates/processes the byte-code? e.g. like the code used for searching for symbol references in the byte-code, what is that called? (Is that MethodFinder stuff?) 2.b) And what is the name (& path) of the C module that actually implements the VM case statement (or whatever dispatch is used)? 3. Once upon a time there was some code that processed Slang ... but I have no idea whether that code is in Pharo, or completely antiquated in all versions. (And if gone from Pharo, what should I look for and in which version of Squeak?) A list of a few classes (in current use) would be greatly appreciated. Thanks in advance, Cam PS: reading through list archives can be painful, as they often either build on known information, or if you back up too far, the material - you later learn- is completely antiquated.

July 8, 2009

Re: [Pharo-project] Browser>>copyClass missing issue

by Adrian Lienhard

thanks, I tagged it and set the status to fixed. Adrian On Jul 8, 2009, at 19:29 , Alain Plantec wrote: > Hi all, > I think that this issue is a good candidat for 1.0 > http://code.google.com/p/pharo/issues/detail?id=894 > Cheers > Alain > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 8, 2009

Re: [Pharo-project] Annoying bug: UndefinedObject(Object)>>doesNotUnderstand: #mimeTypes

by Mariano Martinez Peck

On Wed, Jul 8, 2009 at 3:04 PM, Michael Rueger <m.rueger(a)acm.org> wrote: > Mariano Martinez Peck wrote: > > This is strange because it is interpreted as if it were a DropFilesEvent! > > > > But this is just a alt + tab. I don't see the relation between and alt + > > tab and a DropFilesEvent > > could be some oddness in the Windows event generation/handling. > A fix would be to check for a nil file entry in the drop event in > ExternalDropHandler class>>lookupExternalDropHandler: But I think that's not the real problem, just a fix. I am right? What I can see debugging is that HandMorph>>processEvents when it does: Sensor nextEvent that returns: #(3 11623748 4 0 0 0 1 1) which 3 means type EventTypeDragDropFiles... but I wonder why Sensor nextEvent is returning me that in and "alt + tab". best, Mariano > > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 8, 2009

Re: [Pharo-project] doing bad things to Dictionaries.

by David Goehrig

On Wed, Jul 8, 2009 at 1:06 PM, Michael Roberts <mike(a)mjr104.co.uk> wrote: > Why do you assume all keys of dictionarys understand beginsWith: ? > I don't. Someone else did. I just added a nil check to the code. There's probably bigger issues with this code. Dave -- -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/

July 8, 2009

Re: [Pharo-project] Issue 940: (13/10) = 1.3 returns false

by David Goehrig

I love these sorts of ridiculous arguments, because the problem is fundamentally a question of design.Do you design accounting for the expectations of reasonable people, or do you design for programmers :) Seriously, there's a bigger question here than should you or should you not compare fractions and reals. The question is "for whom is Pharo written?" IEEE754 run contrary to all of my 18 years of sudying math and using rational numbers. I expect the semantics 1/10 = 10/100 = 100/1000 = 1/2*1/5 = 0.5 * 0.2 based on math in Q. This is no different from expecting 0.1 + 0.2 = 0.3 and not 0.29999999.... If you're building software intended for ordinary people, programmers who rarely do computational mathematics, and for educational use, then defaulting to arbitrary precision scaled math is the right way to go, as it matches the expectations of the audience. If you're defining the default behavior of numbers in the system, the principle of "thou shall not commit premature optimization" should come into play. If you're that desperately in need of floating point speed, you're also probably capable of applying that and other optimization techniques accordingly, as befits your problem. Consider IEEE754 floats as optimization for a specific class of application, but a de-optimization for all other uses. Now if you're only designing Pharo for people who program IEEE754 float intensive applications, then by all means, go right ahead and make them the default. Dave -- -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/

July 8, 2009

[Pharo-project] Browser>>copyClass missing issue

by Alain Plantec

Hi all, I think that this issue is a good candidat for 1.0 http://code.google.com/p/pharo/issues/detail?id=894 Cheers Alain

July 8, 2009

Re: [Pharo-project] doing bad things to Dictionaries.

by Michael Roberts

Why do you assume all keys of dictionarys understand beginsWith: ? Thanks mike On Wednesday, July 8, 2009, David Goehrig <dave(a)nexttolast.com> wrote: > So I've been doing some very bad things to dictionaries, and I've had to make a small change: > 'From Pharo0.1 of 16 May 2008 [Latest update: #10342] on 8 July 2009 at 12:28:04 pm'! > > !Dictionary methodsFor: 'testing' stamp: 'djg 7/8/2009 11:53'!hasBindingThatBeginsWith: aString "Answer true if the receiver has a key that begins with aString, false otherwise" > self keysDo:[:each |Â each ifNotNil: [ > (each beginsWith: aString) ifTrue:[^true]]]. ^false! ! > > I'm occasionally had code blow up and was left with nil keys in my SystemDictionary (which may be a red herring),Â andÂ SHParserST80Â resolvePartial:Â wasÂ throwingÂ fitsÂ asÂ aÂ resultÂ ofÂ whatÂ IÂ believeÂ wasÂ anÂ environmentÂ keyÂ beingÂ nil. > > I doubt this is a suitable fix, but if someone know why that might happen I'd love to hear it. > Dave > -- > -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/ > >

July 8, 2009