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

Re: [Pharo-project] host menu sends deprecated author method

by Adrian Lienhard

I fixed this in #10414 but forgot to mention. As a side note, when making a method obsolete, it would be good to check the senders in the image and fix them at the same time... There are also obsolete sends in cleanUpForRelease that are not fixed yet. Cheers, Adrian On Aug 14, 2009, at 01:08 , Michael Roberts wrote: > http://code.google.com/p/pharo/issues/detail?id=1069. > > couldn't find an issue on the tracker but i'm sure someone else has > seen this? just launch the latest pharo image from the download page > and triggered within a few seconds. > > cs uploaded. > > thanks, > Mike > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 14, 2009

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

by Brian Brown

On Aug 13, 2009, at 2:49 PM, StÃ©phane Ducasse wrote: > 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....) I know that, you do amazing amounts in spite of your responsibilities and I really appreciate it. The only reason I sent you an email is because you were/are working on the PackageInfo replacement, so it seemed appropriate. Is DrDoc on SqueakSource? I'll take a look. - Brian > > 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 14, 2009

Re: [Pharo-project] OBDependencyWalker for Pharo

by HernÃ¡n Morales Durand

Oh, that page was obsolete sorry about that, working with PHP pages is so... fuckin horrible! However that's not the issue here. I need to do a little research to see why the Dependency Browser breaks with mysterious OB stuff? I will update the repository as soon as I find the cause. Thanks for reporting HernÃ¡n 2009/8/13 <csrabak(a)bol.com.br>: > Em 13/08/2009 21:34, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> escreveu: > >> Hi csrabak, >> Thanks for the feedback. I wonder how you've installed the DW? > > I followed http://cs.hernanmorales.com.ar/projects/dependencyBrowser/DBrowser-fr.php (Overture Pharo) tab (but I bet you _knew_ that ;-)! > > Notice I installed on Pharo1.0beta image. . . and use only "default" settings. . . > >> Anyone else experimented this trouble? > > This is something I cannot answer :-( > >> That MNU is fine, the problem is that message should never be sent to >> an OBInheritanceDependencyNode. Please note the two leftmost panes >> (columns) in the DependencyBrowser contains system categories or >> "packages", not classes. >> So I've tried to reproduce your problem with the three OB >> installations from Pharo: >> >> ScriptLoader loadOB. >> ScriptLoader loadSuperOB. >> ScriptLoader loadOBAlpha. >> >> selected every system category, gathering all dependencies in your >> Pharo version, and still cannot find that MNU. Can you provide me >> further details about it? >> >> Are you using latest OmniBrowser? > > I do supose so as at the time I wrote the e-mail I had the image uptodate (#10413). > >> Have you installed the DependencyBrowser with the script of my previous e-mail? > > I ran the script of your page. > >> This is happening when you select a particular package? > > Any package will do, but to stick to a simple one I click in "OmniBrowser" and kaboom! > >> Have you installed additional OB packages? > > I lost the control of what is considered "aditional" wrt to OB. So I attach the browser of the image I'm testing it: > > HTH > > -- > Cesar Rabak > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 14, 2009

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

by Schwab,Wilhelm K

Nicolas, I think you might be reading more than I intended into my mention of polymorphism. It is true that the real-to-complex transition fits as an extension of the domain of a function, but I'm less comfortable doing that with real-to-matrix. The real line is a subset of the complex plane. Real numbers can be treated as linear transformations[*] which makes them a 1x1 matrix. Still, it feels like a stretch to extend that into a higher dimensional space, but I might be missing something. However, my focus was not on mathematics but on the software aspects of the problem: in a C* world, there are only functions, and putting aside C++'s overloading capabilities, the procedural programmer is "forced" to start with a function, and to use a different name for each argument type. So they end up with normReal(x); normMatrix(x); etc. where we can simply do x := Float pi. x norm. x := Matrix vandermonde:5. x norm. and get sensible answers for each via polymorphism. Does that make sense? Of course, sometimes a number is just a number, and they can be pretty useful by themselves. We should not throw them away too easily. I suspect that any package that breaks floating point computation will be summarily ignored. Bill [*] If nothing else, that is the insight behind the Frechet Derivative which rearranges the familiar difference quotient to view the derivative itself as a linear transformation, all the way down to the one-dimensional case. -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Nicolas Cellier Sent: Thursday, August 13, 2009 8:23 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] #< if at first you dont succeed.. 2009/8/14 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Nicolas, > > If I'm following you on the matlab matrix exponential business, we should be able to handle such things polymorphically: exp sent to a matrix would do the right thing for a matrix, just as Float and Complex would respond appropriately. Â The sticking point here is whether operations on floats should produce complex numbers in place of bounds errors; based on the arguments presented over the past few days, I vote no. > > Bill > Agree for pragmatic reasons. I was just exploring alternatives implied by this no, and #complexSqrt and the like are one of them. To summarize, you tell me that if a function f is well defined other a whole set A, then you encourage it's extension to a superset B with polymorphism: f: A -> A f: B -> B Problems arise when f is defined only on a subset A* of A, but has an extension over B: f: A* -> A f: A -> B f: B -> B First two definitions are ambiguous, and expectations will vary with applications. This is the case of #sqrt. Igor said, very simple, just forget definition #2, keep #1 and #3 and write -2 asComplex sqrt. So far so good, and this is in the spirit of Squeak Complex implementation. But Igor added that in case of this property on a subset B* f: B* -> A then it would be better to automatically classify result as member of A for any element of B* Answer a Float rather than carrying a Complex with null imaginary part for example like 4 asComplex sqrt -> 2 rather than 2+0i. I argue that though the two features are appealling, they are hard to mix. That's the point that we were discussing, leading us to an ugly solution like FORTRAN non generic INTRINSIC functions... Concerning Matlab exp/mexp, ambiguity is between 1-D array (Array Programming Language/FloatArray like extension) and square matrix (infinite series expansion). That's a bit different, and the example was not that well chosen, I confess. Smalltalk implementations are potentially exposed to the same ambiguity though. That's longer, I don't know if clearer... Nicolas _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 14, 2009

[Pharo-project] Smalltalk Complex

by Ken.Dickey

Coming from Scheme and Lisp, where (sqrt -4) is expected to work, I was surprised to find it "broken" in Squeak when I first tried it out. [Some years ago now]. I noted Smalltalk in a list of languages implementing complex numbers; http://rosettacode.org/wiki/Complex_numbers#Smalltalk Unfortunately, my laptop died and is now in pieces on my desk while I try and resurrect it. Perhaps some kind soul will look at GNU Smalltalk's library and see what they do. Note that GNU Smalltalk files in a 'Complex' package first. Other Smalltalk examples? Thanks much, -KenD

Aug. 14, 2009

[Pharo-project] [Ann] Packages that load in Pharo -- Chronos

by csrabak＠bol.com.br

Aug. 14, 2009

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

by csrabak＠bol.com.br

Aug. 14, 2009

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

by Nicolas Cellier

Ken, as Bill already noticed, there might be a difference between an exact zero (0) and an inexact zero (0.0). Isn't that difference emphasized in Scheme? That reminds me http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-April/102247.ht… :) Nicolas 2009/8/13 Ken.Dickey <Ken.Dickey(a)whidbey.com>: > OK, here is a strict version. Â Complex>>< only compares numbers on the real or > imaginal axis and throws an "incomparable" error otherwise. Â The > ComplexTest>>textCompare checks obvious cases. > > Is this version (more) acceptable? > > As usual, please feel free to correct (or send me corrections) for better > coding style (e.g a shorter/better error message) as well as any dumbness on > my part. > > Cheers, > -KenD > ------------------------Complex > < other > Â Â Â Â "Can only compare with pure real or imaginary parts" > Â Â Â Â ((self imaginary = 0) and: [other imaginary = 0]) > Â Â Â Â ifTrue: [^ self real < other real] > Â Â Â Â ifFalse: [((self real = 0) and: [other real = 0]) > Â Â Â Â Â Â Â Â ifTrue: [^self imaginary < other imaginary] > Â Â Â Â Â Â Â Â ifFalse: [ArithmeticError new > Â Â Â Â Â Â Â Â Â Â Â Â signal: 'Complex numbers are not generally comparable'.] > Â Â Â Â Â Â Â Â ] > ------------------------ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 14, 2009

Re: [Pharo-project] OBDependencyWalker for Pharo

by csrabak＠bol.com.br

Em 13/08/2009 21:34, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> escreveu: > Hi csrabak, > Thanks for the feedback. I wonder how you've installed the DW? I followed http://cs.hernanmorales.com.ar/projects/dependencyBrowser/DBrowser-fr.php (Overture Pharo) tab (but I bet you _knew_ that ;-)! Notice I installed on Pharo1.0beta image. . . and use only "default" settings. . . > Anyone else experimented this trouble? This is something I cannot answer :-( > That MNU is fine, the problem is that message should never be sent to > an OBInheritanceDependencyNode. Please note the two leftmost panes > (columns) in the DependencyBrowser contains system categories or > "packages", not classes. > So I've tried to reproduce your problem with the three OB > installations from Pharo: > > ScriptLoader loadOB. > ScriptLoader loadSuperOB. > ScriptLoader loadOBAlpha. > > selected every system category, gathering all dependencies in your > Pharo version, and still cannot find that MNU. Can you provide me > further details about it? > > Are you using latest OmniBrowser? I do supose so as at the time I wrote the e-mail I had the image uptodate (#10413). > Have you installed the DependencyBrowser with the script of my previous e-mail? I ran the script of your page. > This is happening when you select a particular package? Any package will do, but to stick to a simple one I click in "OmniBrowser" and kaboom! > Have you installed additional OB packages? I lost the control of what is considered "aditional" wrt to OB. So I attach the browser of the image I'm testing it: HTH -- Cesar Rabak

Aug. 14, 2009

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

by Nicolas Cellier

2009/8/14 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Nicolas, > > If I'm following you on the matlab matrix exponential business, we should be able to handle such things polymorphically: exp sent to a matrix would do the right thing for a matrix, just as Float and Complex would respond appropriately. Â The sticking point here is whether operations on floats should produce complex numbers in place of bounds errors; based on the arguments presented over the past few days, I vote no. > > Bill > Agree for pragmatic reasons. I was just exploring alternatives implied by this no, and #complexSqrt and the like are one of them. To summarize, you tell me that if a function f is well defined other a whole set A, then you encourage it's extension to a superset B with polymorphism: f: A -> A f: B -> B Problems arise when f is defined only on a subset A* of A, but has an extension over B: f: A* -> A f: A -> B f: B -> B First two definitions are ambiguous, and expectations will vary with applications. This is the case of #sqrt. Igor said, very simple, just forget definition #2, keep #1 and #3 and write -2 asComplex sqrt. So far so good, and this is in the spirit of Squeak Complex implementation. But Igor added that in case of this property on a subset B* f: B* -> A then it would be better to automatically classify result as member of A for any element of B* Answer a Float rather than carrying a Complex with null imaginary part for example like 4 asComplex sqrt -> 2 rather than 2+0i. I argue that though the two features are appealling, they are hard to mix. That's the point that we were discussing, leading us to an ugly solution like FORTRAN non generic INTRINSIC functions... Concerning Matlab exp/mexp, ambiguity is between 1-D array (Array Programming Language/FloatArray like extension) and square matrix (infinite series expansion). That's a bit different, and the example was not that well chosen, I confess. Smalltalk implementations are potentially exposed to the same ambiguity though. That's longer, I don't know if clearer... Nicolas

Aug. 14, 2009