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

Re: [Pharo-project] Fwd: [squeak-dev] Re: Usability and look-and-feel(was Re: The future ofSqueak & Pharo (was Re: [ANN] Pharo MITlicenseclean))

by Gary Chambers

As I mentioned on squeak-dev... With the StandardToolSet I get 300ms or less... Regards, Gary ----- Original Message ----- From: "Damien Cassou" <damien.cassou(a)gmail.com> To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr>; "David RÃ¶thlisberger" <roethlis(a)iam.unibe.ch> Sent: Thursday, July 09, 2009 5:22 PM Subject: [Pharo-project] Fwd: [squeak-dev] Re: Usability and look-and-feel(was Re: The future ofSqueak & Pharo (was Re: [ANN] Pharo MITlicenseclean)) > ---------- Forwarded message ---------- > From: Andreas Raab <andreas.raab(a)gmx.de> > Date: Thu, Jul 9, 2009 at 5:40 PM > Subject: [squeak-dev] Re: Usability and look-and-feel (was Re: The > future ofSqueak & Pharo (was Re: [Pharo-project] [ANN] Pharo MIT > licenseclean)) > To: The general-purpose Squeak developers list > <squeak-dev(a)lists.squeakfoundation.org> > > > > [ToolSet default browse: Behavior selector: nil] timeToRun. > > On my box this takes 506 msecs in Squeak 3.10, using Pharo it's at > 5020 msecs. That's 10x slower. > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 9, 2009

Re: [Pharo-project] Squeak Forks Popularity & Trends Estimate

by Robert Peters

Hello everyone, 1. Whichever fork is most professional will win. I believe this was one of the goals of the Pharo project, so I'd have to say Pharo will eventually lead. 2. Smalltalk in all its forms will fail unless it can grab developer interest from outside the current community. Pharo may be better than Squeak, but if everyone moves from Squeak to Pharo, your audience is still too small to be significant. I'm a web-application developer (Django, GAE) and self-taught Python coder. I learned Python because it was easy, and there is a wealth of information available on the internet. If I have any problem in Python, I simply type 'python issue' into Google and within a few clicks I'm usually looking at the answer. When I tried to learn Smalltalk, it was intensely frustrating. There were no on-line resources, no tutorials, no explanations. I think the real question is, "Is Smalltalk a better language than Python?" By better, I mean, "Can I get done more coding tasks faster, in a more sustainable way?" Right now, the answer to this question is a resounding 'No'. But that answer might change with a slick Smalltalk package, and an abundance of developer resources. As it is, Smalltalk is a language for eccentrics. But it doesn't need to be that way. All of this to say that I really like the beautiful simplicity of Smalltalk's main paradigm - Message Passing. It's simple. It's elegant. But learning it is a stone bitch, and once you've learned it, it has only limited value (compared, for example, to the wealth of things one can do in Python). I wish this would change. -- View this message in context: http://n2.nabble.com/Squeak-Forks-Popularity---Trends-Estimate-tp3211130p32… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 9, 2009

[Pharo-project] Fwd: [squeak-dev] Re: Usability and look-and-feel (was Re: The future ofSqueak & Pharo (was Re: [ANN] Pharo MIT licenseclean))

by Damien Cassou

---------- Forwarded message ---------- From: Andreas Raab <andreas.raab(a)gmx.de> Date: Thu, Jul 9, 2009 at 5:40 PM Subject: [squeak-dev] Re: Usability and look-and-feel (was Re: The future ofSqueak & Pharo (was Re: [Pharo-project] [ANN] Pharo MIT licenseclean)) To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> [ToolSet default browse: Behavior selector: nil] timeToRun. On my box this takes 506 msecs in Squeak 3.10, using Pharo it's at 5020 msecs. That's 10x slower. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

July 9, 2009

[Pharo-project] New Pharo based on core 10373

by Damien Cassou

I've just released both Pharo and Pharo-web with some bug fixes that annoyed a lot of people: http://pharo-project.org/pharo-download -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

July 9, 2009

Re: [Pharo-project] OB, Completion and class variables (when used on the class side)

by Damien Cassou

On Thu, Jul 9, 2009 at 8:03 AM, Torsten Bergmann<astares(a)gmx.de> wrote: >>please open an issue and attach Romain Robbes to it. > > Issue opened (Issue #942) but how can I attach Romain to it? You should be able to change the owner of the report. I've done it myself. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

July 9, 2009

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

by Hernan Wilkinson

So, Stef, what do we do? :-) I think we have discussed very interesting things is this thread. My conclusions are: 1) Nicolas made a change to avoid confusion when comparing "exact numbers" with "inexact numbers" (among others) 2) This change surprised some people (me in the first place) because it is not how other Smalltalks behave, it is a change in the philosophy of Smalltalk and thus it logically generates disagreements 3) It is clear that Floats are needed due to performance issues, and it is also clear that when performance is not a problem Smalltalk numbers should behave as close as possible (if not equal to) arithmetic. So, I devise these paths: 1) Leave things as they are now in the latest Pharo image, and wait to see if Nicola's change affects real applications (not just tests as it was my case) 2) Same as 1 but making float equals work only when comparing between floats 3) Change the Number hierarchy and make a clear distinction between exact numbers and inexact numbers. Make exact numbers behave as one expects in real math 4) Go back to how things were I think they are pretty much the options... My vote goes for 1 right now. To make 2 we need to experiment more and see how it behaves. I really like 3, I'd love to see that implemented in Smalltalk but doing that model is not easy, it will take time (hey, you have a research track there!), and 4 does not make sense after Nicolas explanations Bye, Hernan. On Thu, Jul 9, 2009 at 6:04 AM, Andres Valloud<avalloud(a)smalltalk.comcastbiz.net> wrote: > Stephane, >> Computer float numbers are NOT math float numbers. Let us accept it. >> >> > > I agree with your sentiment. Â At the risk of being overly precise, I'd > state that computer float numbers are not our everyday decimal numbers. > I'd avoid the reference to "math" because computer floating point > numbers do have significant math behind them. > > Andres. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 9, 2009

Re: [Pharo-project] Integrator process

by Adrian Lienhard

Here a small diagram of the process: Not sure how to attach this to the wiki, though. Adrian On Jul 9, 2009, at 09:15 , StÃ©phane Ducasse wrote: > I tried to give a description of the boring work we are doing in the > back. > > http://code.google.com/p/pharo/wiki/IntegrationProcessDescription > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 9, 2009

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

by Andres Valloud

Stephane, > Computer float numbers are NOT math float numbers. Let us accept it. > > I agree with your sentiment. At the risk of being overly precise, I'd state that computer float numbers are not our everyday decimal numbers. I'd avoid the reference to "math" because computer floating point numbers do have significant math behind them. Andres.

July 9, 2009

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

by Marcus Denker

On 08.07.2009, at 20:45, Cameron Sanders wrote: > 1) What classes should I look at to learn about the byte-code > generation? > These slides give an introduction: http://marcusdenker.de/talks/07SCGSmalltalk/11Bytecode.pdf > 2) What are good examples of code that handles/manipulates/processes > the byte-code? There are multiple parts of the system dealing with bytecode: 1) VM. This is SLANG, compiled to C, compiled to a Binary. 2) Compiler. Generates Bytecode. Here the old one is very strange (to me at least). Anthony's newcompiler is much easier to understand, This has a backend called "IR Builder" that can be used to generate bytecode easily. (Or to modify code on the level of bytecode abstraction, see http://scg.unibe.ch/research/bytesurgeon ) 3) Debugger / Simulator. This is in class ContextPart. A bytecode interpreter written in Smalltalk that the Debugger uses for stepping. > e.g. like the code used for searching for symbol > references in the byte-code, what is that called? (Is that > MethodFinder stuff?) > No. Check SystemNavigation, method #allCallsOn: Marcus -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

July 9, 2009

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

by Nicolas Cellier

2009/7/8 Ignacio Vivona <altobarba(a)gmail.com>: > The question is why do you want Floats to be the default implementation of > reals instead of ScaledDecimals? > Ignacio, This is a good question, and I don't have the answer. It would be worth experimenting. Newspeak project wanted to follow this road AFAIK, unfortunately they died before they did it, so we won't benefit from their work... Michael proposed this earlier in the thread. Unfortunately, current ScaledDecimal implementations will reserve more surprises like 0.5s1 * 0.5s1 -> 0.3s1 We should better have the number of decimal digits undefined 0.5s*0.5s -> 0.25s But still limit number of printed characters 1.0s / 3.0s -> 0.3333333s.... Or maybe use a special notation for repeated pattern 1.0s / 3.0s -> 0.3333333(3) 1.0s / 7.0s -> 0.(142857) > 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.) > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 9, 2009