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

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

by Ignacio Vivona

The question is why do you want Floats to be the default implementation of reals instead of ScaledDecimals? On Wed, Jul 8, 2009 at 4:29 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 2009/7/8 Hernan Wilkinson <hernan.wilkinson(a)gmail.com>: > > it was just an example where you can "bind" as "late" as possible a > > combination of symbols with its value... I like late binding :-) in this > > example allows you to get rigth results... and of course > > cosPiHalved is not the same as "a/b cos" where a is bound to pi and b to > > 2... it is not only for literals. > > > > If you like the late binding, and if you are using a set of functions > which having no side effects , then > you can, instead of computing the result , store the numerical > operations (in same fashion as Fraction stores division) and compute > the exact value(s) only when you really need them. > Then you can bring in the power of mathematical apparatus/trigonometry > rules and use them at full scale. > > Think, how many things we can add (in parallel to Fraction) > SquaredNumber > SquaredRootNumber > CosFn > SinFn > TanFn > PiFraction > and so on.. limited only by your own limits/knowledge... > > But again, all of this stuff is more related to predicting than exact > computing , which is happens to be inexact because of hardware > limitations :) > > > On Wed, Jul 8, 2009 at 3:59 PM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >> > >> 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. > >> > >> _______________________________________________ > >> 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. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Hope is for sissies (Gregory House, M.D.)

July 8, 2009

[Pharo-project] Quote from Guy Steele

by Alexandre Bergel

"So I think the sole way to win is to plan for growth with help from users" Keynote Speech, OOPSLA'98 Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 8, 2009

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

by Schwab,Wilhelm K

It certainly is not a generally applicable method for Dictionary (not all/most keys will not understand #beginsWith:), but for some senders, it might make sense, as it (I think) does for SystemDictionary. It would bother me less as a loose method packaged as part of something that "needs" it, but I would be inclined to deprecate/clean it if it is intended as part of the collection protocol. Clients/senders could always define something like #dictionary:hasKeyBeginningWith:. One of the great things about Smalltalk is the ability to add methods to system classes. This is probably not the best use of that freedom. Has this been of _any_ help? :) Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David Goehrig Sent: Wednesday, July 08, 2009 12:33 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] doing bad things to Dictionaries. On Wed, Jul 8, 2009 at 1:06 PM, Michael Roberts <mike(a)mjr104.co.uk<mailto:mike@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] byte codes, parse-tree walking, etc.

by Igor Stasenko

2009/7/8 Cameron Sanders <camsanders01(a)roadrunner.com>: > 1) What classes should I look at to learn about the byte-code > generation? > I think you'd better look at NewCompiler. Don't look at compiler implementation in its current state :) > 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?) > There is InstructionStream, and of course see CompiledMethod itself. > Â Â Â Â 2.b) And what is the name (& path) of the C module that actually > implements the VM case statement (or whatever dispatch is used)? > VMMaker is _smalltalk_ package which implements such dispatch, and then translated to C & compiled to get a VM binary. Look for VMMaker package at squeaksource.com > 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. > VMMaker: Interpreter, ObjectMemory Image: Compiler/Parser (but better look a NewCompiler) InstructionStream, ContextPart, CompiledMethod > 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. > > _______________________________________________ > 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: > weird...Now I can also reproduce it in sq3.10.2-7179dev09.03.1 hahaha > > The same behaviour So it might be something for the squeak-dev list as well. Michael

July 8, 2009

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

by Igor Stasenko

2009/7/8 Hernan Wilkinson <hernan.wilkinson(a)gmail.com>: > it was just an example where you can "bind" as "late" as possible a > combination of symbols with its value... I like late binding :-) in this > example allows you to get rigth results... and of course > cosPiHalved is not the same as "a/b cos" where a is bound to pi and b to > 2... it is not only for literals. > If you like the late binding, and if you are using a set of functions which having no side effects , then you can, instead of computing the result , store the numerical operations (in same fashion as Fraction stores division) and compute the exact value(s) only when you really need them. Then you can bring in the power of mathematical apparatus/trigonometry rules and use them at full scale. Think, how many things we can add (in parallel to Fraction) SquaredNumber SquaredRootNumber CosFn SinFn TanFn PiFraction and so on.. limited only by your own limits/knowledge... But again, all of this stuff is more related to predicting than exact computing , which is happens to be inexact because of hardware limitations :) > On Wed, Jul 8, 2009 at 3:59 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> 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. >> >> _______________________________________________ >> 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 Mariano Martinez Peck

On Wed, Jul 8, 2009 at 6:13 PM, Michael Rueger <m.rueger(a)acm.org> wrote: > Mariano Martinez Peck wrote: > > > mmmm I tried this VM with squeak 3.10.2 and couldn't reproduce it. I > > guess it is because Sensor refactor. I am not saying InputSensor has the > > problem, just that perhaps because of this, I cannot reproduce it in > Squeak. > > > > The strange thing is that this doesn't happend to me in older Pharo > > versions. > > Is the image side code in 3.10 the same as in Pharo? I mean the drop > event handling. weird...Now I can also reproduce it in sq3.10.2-7179dev09.03.1 hahaha The same behaviour > > > 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] Annoying bug: UndefinedObject(Object)>>doesNotUnderstand: #mimeTypes

by Michael Rueger

Mariano Martinez Peck wrote: > mmmm I tried this VM with squeak 3.10.2 and couldn't reproduce it. I > guess it is because Sensor refactor. I am not saying InputSensor has the > problem, just that perhaps because of this, I cannot reproduce it in Squeak. > > The strange thing is that this doesn't happend to me in older Pharo > versions. Is the image side code in 3.10 the same as in Pharo? I mean the drop event handling. Michael

July 8, 2009

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

by Hernan Wilkinson

it was just an example where you can "bind" as "late" as possible a combination of symbols with its value... I like late binding :-) in this example allows you to get rigth results... and of course cosPiHalved is not the same as "a/b cos" where a is bound to pi and b to 2... it is not only for literals. On Wed, Jul 8, 2009 at 3:59 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 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. > > _______________________________________________ > 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 5:51 PM, Michael Rueger <m.rueger(a)acm.org> wrote: > 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... > mmmm I tried this VM with squeak 3.10.2 and couldn't reproduce it. I guess it is because Sensor refactor. I am not saying InputSensor has the problem, just that perhaps because of this, I cannot reproduce it in Squeak. The strange thing is that this doesn't happend to me in older Pharo versions. What we should do in this case? ask squeak-dev? vm-dev ? thanks! 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