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

[Pharo-project] [update] 10414

by Torsten Bergmann

>Reorganize unit tests in a more modular way So I can delete this from my task list. Thanks! Bye Torsten -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

Aug. 13, 2009

Re: [Pharo-project] #< if at first you dont succeed..

by Nicolas Cellier

2009/8/13 Igor Stasenko <siguctua(a)gmail.com>: > 2009/8/13 Â <csrabak(a)bol.com.br>: >> For the mathematical part yes. Now, submiting to all the list, I want to >> propose a modification in the code based on Smalltalk style (the comments >> w/"csr" are only for my explanation and should not go to the production >> code!): >> >> < other >> "Can only compare with pure real or imaginary parts" >> ((self imaginary = 0) and: [other imaginary = 0]) >> ifTrue: [^ self real < other real].Â Â Â Â Â Â Â Â Â Â Â Â Â Â "csr: if it's true you > > i think, if imaginary part is zero , then Complex values should be > normalized back to real ones (obviously to conserve the memory), and > therefore the test 'self imaginary = 0' is redundant. > Hi Igor, this is Behavior of Complex package available in VW. However, I wonder how you can conciliate the previous requirement: -2 asComplex sqrt For example, I want this function myFun ^x sqrt arcSin But I know -4 myFun will fail... So, I hear you and write myFun ^x asComplex sqrt arcSin But there, problem, 4 myFun will raise an error, so as 4 asComplex myFun Then, i can write smelling code like this - that's no real fun ;) myFun ^x asComplex sqrt asComplex arcSin unless of course you propose I hide this shit behind some other selectors like: myFun ^x complexSqrt complexArcSin but then I will probably want some other extensions like the quaternionArcSin, the squareMatrixArcSin, etc... so, I don't know if I'm really satisfied with those selectors... Nicolas

Aug. 13, 2009

Re: [Pharo-project] Help on Polymorph [was How to build a GUI]

by StÃ©phane Ducasse

But you know you can also propose a solution with code. :) Take DrDoc and improve it. I agree more than 200% with you but my day job in not improving pharo or squeak. Pharo is a nice project but I have plenty of other things that I have to do (admin, research, PhD students....) Stef >> So far we should invent it. >> And I totally agree with you. If people do not see the good doc they >> will not write good comment. >> I started to work on DrDoc a kind of package meta data to add >> documentation to a package but it got stole >> I should push that again. What would be nice is to take one package >> and do it well as an example. >> >> >> It think it should be possible to write documentation at the >> package level. So developpers have a place where they can write an >> overview of their package. When we click on a package, >> documentation should be displayed by default or easily. > > Yes! Here is a post I made in April of 2003: > > > > The biggest frustration with using comments is that there is no good > > "starting place" for a given class category. For example, go browse > > the Seaside classes and categories and figure out where one should > > start. You can repeat this exercise for any number of categories. I > > propose that we we add a documentation attribute to the PackageInfo > > stuff, so there is a category level documentation spot, with links > to > > the appropriate class comments. > > > Any thoughts? > I didn't get any response, and I sent a similar type of thought to > Stef recently, but he's so busy I don't even know if he read my > email :) > > - Brian >> >> In the rubygems world, it is a common practice to write >> documentation in a README file which is displayed by RDoc on >> startup page (github works the same way). It seems to me that >> there's the same level of comment between Ruby class/methods and >> Pharo. The documentation at the package level may be the difference. >> >> Python has a real documentation effort.Each release come with its >> up to date documentation. It's a release criteria. Python shares >> some similarities with Pharo as they both have "batteries >> included". May be there should have a process to contribute to a >> centralized Pharo documentation which can be accessed within the IDE. >> >> Laurent. >> _______________________________________________ >> 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. 13, 2009

Re: [Pharo-project] [update] 10414

by Miguel Enrique CobÃ¡ Martinez

El jue, 13-08-2009 a las 22:26 +0200, Adrian Lienhard escribiÃ³: > update #10414 > If you execute in a Pharo-core image: > > ScriptLoader new cleanUpForProduction; cleanUpForRelease > > you get an image without tests and SUnit that is 8.0 MB on disk. > Whoa! Cool! Thanks > Adrian > ___________________ > http://www.adrian-lienhard.ch/ > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Aug. 13, 2009

[Pharo-project] [update] 10414

by Adrian Lienhard

update #10414 ----------------- 310+311: Reorganize unit tests in a more modular way such that they can be unloaded Now all unit tests are in the packages "Tests", "CollectionsTests", "KernelTests", "MorphicTests", etc. The key point of this reorganization is to make these packages really modular, i.e., they can be unloaded without leaving obsolete classes behind. I also made sure that SUnit with its GUI is unloadable. If you execute in a Pharo-core image: ScriptLoader new cleanUpForProduction; cleanUpForRelease you get an image without tests and SUnit that is 8.0 MB on disk. Adrian ___________________ http://www.adrian-lienhard.ch/

Aug. 13, 2009

Re: [Pharo-project] Complex number support discussion

by Schwab,Wilhelm K

Ken, A 2-10x performance hit is all the more reason why such a creation should be dormant unless specifically invoked - translation, no coercion into the controversial type. While there are uses for systems that are "smart" enough to give exact answers, most computation happens in a world of tolerances, with numbers that are not cherry picked for aesthetics. As somebody else (Sig perhaps) said, the behavior of the base system magnitude classes should not change when a different package is loaded. #asComplex is the gateway through which one can tell the system that complex numbers are expected and desired. The more you write, the more it becomes clear that there also would need to be a #asComplexSymbolic or something to invoke behavior one might expect from Maple and other symbolic systems. I strongly recommend starting with a numerical approach to a "closed system" of complex numbers. GSL provides much of what should be available, and can be mapped into Pharo by FFI/Alien. The result would get used. If you then want to compete with Maple and Mathematica, that really should be done separately. For examle, there are times when I use logs to estimate the number of digits required to hold a number, and if the argument is negative, I goofed and expect an error. 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: Thursday, August 13, 2009 12:09 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Complex number support discussion Igor Stasenko > P.S. diving into complex plane uncovers many potential pitfalls to > those who expecting a certain behavior of mathematical functions over > a real numbers. In first place square and square root. > It is good that with introduction of a complex numbers we can be sure > that x sqrt squared = x for any real x. > > The complex numbers gives us a impression that from now on, the square > function and squared root functions is reversable. But they are not > for a complex numbers. > In practice this means, that one, who using a complex math in his > code, should know well the properties of complex numbers, because this > is not so trivial as with real numbers & school algebra. And such > people, basically don't need the things with questionable or > controversial behavior such as #< operators on a complex plane. Then > the aim of Complex package developer should be to not introduce more > confusion to people who is not using/learnt the complex numbers, and > leave attempts to help people who can - because they could care for themselves well. I guess here I go to high school physics, where electricity and magnetism use complex numbers and relativity uses hyperbolic trig. [Perhaps 1st year physics if your high school did not cover this]. My own experience is that adapting to floating point lossage was far more painful for me than learning 2d mathematics. Again, we can remove Complex totally and make that, hyperbolic trig, ln, and so forth into loadable packages. I would recommend that the error reports for sqrt and ln (if kept) of negative numbers make mention that a loadable package exists to give the expected functionality. A minimal base image (lacking even tools, perhaps even Morphic) is certainly useful in the build process at some point. I suspect there are those who would make such an image even smaller by removing fractions and perhaps even floats. My own preference is to leverage meta-programming aspects (traits, live code, intelligent toolsets) because I think that is where Pharo/Squeak excels. I am certainly happy to pay additional computational cost for better approximations to math (e.g. interval mathematics) because I like the system to tell me where the deep and shallow waters are. A factor of two or even ten slower sounds like a lot, but as speeds continue to double every 18 months, getting the right answers rather than "the wrong answer fast" is why one puts up with slower runtime systems. $0.02, -KenD PS: Thanks all for the helpful suggestions on tightening up the math. I will take a closer look at the branch cuts and so forth. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 13, 2009

Re: [Pharo-project] Help on Polymorph [was How to build a GUI]

by Brian Brown

On Aug 13, 2009, at 12:21 PM, Brian Brown wrote: > I didn't get any response, and I sent a similar type of thought to > Stef recently, but he's so busy I don't even know if he read my > email :) > Scratch that - Matthew Fulmer thought it was a good idea as well :)

Aug. 13, 2009

Re: [Pharo-project] Help on Polymorph [was How to build a GUI]

by Brian Brown

On Aug 13, 2009, at 3:41 AM, laurent laffont wrote: > > > So far we should invent it. > And I totally agree with you. If people do not see the good doc they > will not write good comment. > I started to work on DrDoc a kind of package meta data to add > documentation to a package but it got stole > I should push that again. What would be nice is to take one package > and do it well as an example. > > > It think it should be possible to write documentation at the package > level. So developpers have a place where they can write an overview > of their package. When we click on a package, documentation should > be displayed by default or easily. Yes! Here is a post I made in April of 2003: > The biggest frustration with using comments is that there is no good > "starting place" for a given class category. For example, go browse > the Seaside classes and categories and figure out where one should > start. You can repeat this exercise for any number of categories. I > propose that we we add a documentation attribute to the PackageInfo > stuff, so there is a category level documentation spot, with links to > the appropriate class comments. > Any thoughts? I didn't get any response, and I sent a similar type of thought to Stef recently, but he's so busy I don't even know if he read my email :) - Brian > > In the rubygems world, it is a common practice to write > documentation in a README file which is displayed by RDoc on startup > page (github works the same way). It seems to me that there's the > same level of comment between Ruby class/methods and Pharo. The > documentation at the package level may be the difference. > > Python has a real documentation effort.Each release come with its up > to date documentation. It's a release criteria. Python shares some > similarities with Pharo as they both have "batteries included". May > be there should have a process to contribute to a centralized Pharo > documentation which can be accessed within the IDE. > > Laurent. > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 13, 2009

[Pharo-project] Complex number support discussion

by Ken.Dickey

Igor Stasenko > P.S. diving into complex plane uncovers many potential pitfalls to those > who expecting a certain behavior of mathematical functions over a real > numbers. In first place square and square root. > It is good that with introduction of a complex numbers we can be sure that > x sqrt squared = x for any real x. > > The complex numbers gives us a impression that from now on, the square > function and squared root functions is reversable. But they are not for a > complex numbers. > In practice this means, that one, who using a complex math in his code, > should know well the properties of complex numbers, because this is not so > trivial as with real numbers & school algebra. And such people, basically > don't need the things with questionable or controversial behavior such as > #< operators on a complex plane. Then the aim of Complex package developer > should be to not introduce more confusion to people who is not using/learnt > the complex numbers, and leave attempts to help people who can - because > they could care for themselves well. I guess here I go to high school physics, where electricity and magnetism use complex numbers and relativity uses hyperbolic trig. [Perhaps 1st year physics if your high school did not cover this]. My own experience is that adapting to floating point lossage was far more painful for me than learning 2d mathematics. Again, we can remove Complex totally and make that, hyperbolic trig, ln, and so forth into loadable packages. I would recommend that the error reports for sqrt and ln (if kept) of negative numbers make mention that a loadable package exists to give the expected functionality. A minimal base image (lacking even tools, perhaps even Morphic) is certainly useful in the build process at some point. I suspect there are those who would make such an image even smaller by removing fractions and perhaps even floats. My own preference is to leverage meta-programming aspects (traits, live code, intelligent toolsets) because I think that is where Pharo/Squeak excels. I am certainly happy to pay additional computational cost for better approximations to math (e.g. interval mathematics) because I like the system to tell me where the deep and shallow waters are. A factor of two or even ten slower sounds like a lot, but as speeds continue to double every 18 months, getting the right answers rather than "the wrong answer fast" is why one puts up with slower runtime systems. $0.02, -KenD PS: Thanks all for the helpful suggestions on tightening up the math. I will take a closer look at the branch cuts and so forth.

Aug. 13, 2009

Re: [Pharo-project] #< if at first you dont succeed..

by Ken.Dickey

Igor Stasenko > in given form, i really don't see what is the meaning of #< operator on > Complex numbers? Because , obviously, in first place, i expecting that #< > method serves to compare Complex numbers, not mix of real and complex, but > implemented in such form, the value of such method is nearly zero (in > complex plane ;). So, the question remains the same: is it worth adding it, > just for the sake of complete protocol(s)? How much is "if A=a and B=b and A<B then a<b" worth to you? -KenD

Aug. 13, 2009