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

Re: [Pharo-project] OBDependencyWalker for Pharo

by HernÃ¡n Morales Durand

Hi csrabak, Thanks for the feedback. I wonder how you've installed the DW? Anyone else experimented this trouble? 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? Have you installed the DependencyBrowser with the script of my previous e-mail? This is happening when you select a particular package? Have you installed additional OB packages? Cheers, HernÃ¡n 2009/8/13 <csrabak(a)bol.com.br>: > It is not an instalallation problem. It is an execution problem. . . Fire DW > and select any class in left pane it will show a "Gathering..." dialog and > then MNU: OBInheritanceDependencyNode doesn't understand theClass. . . > > > Em 13/08/2009 01:28, HernÃ¡n Morales Durand < hernan.morales(a)gmail.com > > escreveu: > > Hello there, > I cannot reproduce the installation problem in #10413. To install DW > with the OmniBrowser support in a clean Pharo #10413 just doIt the > following: > > ScriptLoader loadOBAlpha. > Installer ss project: 'DependencyWalker'; > install: 'DependencyWalker'; > install: 'OBDependencyWalker'; > install: 'DWTraitsFix'. > > let me know if you find errors with that procedure. > > HernÃ¡n > > 2009/8/12 : >> In my attempt to install OBDependencyWalker in Pharo beta #10413, I >> discovered that it triggers DNUs because #theClass is no longer available >> in >> this image version. >> >> I could not find easily the rationale for stripping the method. >> >> Is this a known fact and OBDependencyWalker should be modified, or >> #theClass >> needs to be reinstated? > &gt ; >> >> >> _______________________________________________ >> 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] #< if at first you dont succeed..

by Schwab,Wilhelm K

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 -----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 6:46 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] #< if at first you dont succeed.. 2009/8/14 Igor Stasenko <siguctua(a)gmail.com>: > 2009/8/14 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> 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... >> > > You are right about drawbacks of normalization. > I suggested that by taking Ken's implication, that any real number is > a complex number with imaginary part = 0. > > I'm not very satisfied with selectors , like arcSin/complexArcSin too, > but is there other way to put two different functions into a single > class (Float) - without assigning different selectors to them? > I hope you agree with me that arcSin and complexArcSin is two > different functions with different behavior , as well as sqrt and > complexSqrt. > They could be the same (with complex behavior) , if we imply that real > numbers is a complex numbers with imaginary part =0. But once we > assume that , we automatically losing the set of functions which > defined strictly over a real set and which should throw an error(s) if > argument is not in valid range. > And i'm not in favor of losing that. > Agree, from pragmatic POV, it's better to not break a majority of existing code Complex is unused in base image, and most #sqrt senders wouldn't know how to deal with a damn imaginary result. I have no solution for this simple annoying thing. Installing error handlers to deal with complex extension is quite boring too... Regarding quality of design decisions, Matlab is far from being my top choice (definition of < for complex would be a grief quite related to this thread...), but I note the existence of mexp msin etc... (exp would collect the exponential of each matrix element)... It's good to know we are not the only ones annoyed, so yes, we could tolerate these unsatisfying selector variations. Mathematical expressions are context dependent (idealy notations are defined in preamble). Translated in Smalltalk world, that would mean MethodDictionary would be Context dependent... But I should better stop here, I can feel like a burning smell coming from my neurons. 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

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

by Nicolas Cellier

2009/8/14 Igor Stasenko <siguctua(a)gmail.com>: > 2009/8/14 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> 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... >> > > You are right about drawbacks of normalization. > I suggested that by taking Ken's implication, that any real number is > a complex number with imaginary part = 0. > > I'm not very satisfied with selectors , like arcSin/complexArcSin too, > but is there other way to put two different functions into a single > class (Float) - without assigning different selectors to them? > I hope you agree with me that arcSin and complexArcSin is two > different functions with different behavior , as well as > sqrt and complexSqrt. > They could be the same (with complex behavior) , if we imply that real > numbers is a complex numbers with imaginary part =0. But once we > assume that , we automatically losing the set of functions which > defined strictly over a real set and which should throw an error(s) if > argument is not in valid range. > And i'm not in favor of losing that. > Agree, from pragmatic POV, it's better to not break a majority of existing code Complex is unused in base image, and most #sqrt senders wouldn't know how to deal with a damn imaginary result. I have no solution for this simple annoying thing. Installing error handlers to deal with complex extension is quite boring too... Regarding quality of design decisions, Matlab is far from being my top choice (definition of < for complex would be a grief quite related to this thread...), but I note the existence of mexp msin etc... (exp would collect the exponential of each matrix element)... It's good to know we are not the only ones annoyed, so yes, we could tolerate these unsatisfying selector variations. Mathematical expressions are context dependent (idealy notations are defined in preamble). Translated in Smalltalk world, that would mean MethodDictionary would be Context dependent... But I should better stop here, I can feel like a burning smell coming from my neurons. Nicolas

Aug. 13, 2009

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

by Schwab,Wilhelm K

Treating reals as complex (giving them a zero imaginary part) is a bad idea. Reasons include: (1) need float and double for FFI (2) compatibility with other dialects (3) avoid wasting space to hold unneeded imaginary parts Sig is correct to point out that sometimes one wants to do purely real arithmetic with the domains of various functions restricted as appropriate. Complex numbers should be separate from reals. -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Thursday, August 13, 2009 6:07 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] #< if at first you dont succeed.. 2009/8/14 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 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... > You are right about drawbacks of normalization. I suggested that by taking Ken's implication, that any real number is a complex number with imaginary part = 0. I'm not very satisfied with selectors , like arcSin/complexArcSin too, but is there other way to put two different functions into a single class (Float) - without assigning different selectors to them? I hope you agree with me that arcSin and complexArcSin is two different functions with different behavior , as well as sqrt and complexSqrt. They could be the same (with complex behavior) , if we imply that real numbers is a complex numbers with imaginary part =0. But once we assume that , we automatically losing the set of functions which defined strictly over a real set and which should throw an error(s) if argument is not in valid range. And i'm not in favor of losing that. > Nicolas > > _______________________________________________ > 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

Aug. 13, 2009

Re: [Pharo-project] question on browser buttons

by csrabak＠bol.com.br

Aug. 13, 2009

[Pharo-project] question on browser buttons

by Michael Roberts

folks, just wondering what people think about the big 'blue' class browser buttons. Pharo is looking really nice, but i tend to prefer somewhat smaller, plainer buttons. e.g on the test runner, or the preference browser. the browser ones are twice as high! they just seem to stick out a bit. is it easy to switch off these blue buttons, or make all buttons consistent? thanks, Mike

Aug. 13, 2009

[Pharo-project] host menu sends deprecated author method

by Michael Roberts

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

Aug. 13, 2009

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

by Igor Stasenko

2009/8/14 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 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... > You are right about drawbacks of normalization. I suggested that by taking Ken's implication, that any real number is a complex number with imaginary part = 0. I'm not very satisfied with selectors , like arcSin/complexArcSin too, but is there other way to put two different functions into a single class (Float) - without assigning different selectors to them? I hope you agree with me that arcSin and complexArcSin is two different functions with different behavior , as well as sqrt and complexSqrt. They could be the same (with complex behavior) , if we imply that real numbers is a complex numbers with imaginary part =0. But once we assume that , we automatically losing the set of functions which defined strictly over a real set and which should throw an error(s) if argument is not in valid range. And i'm not in favor of losing that. > Nicolas > > _______________________________________________ > 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.

Aug. 13, 2009

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

by csrabak＠bol.com.br

Aug. 13, 2009

Re: [Pharo-project] OBDependencyWalker for Pharo

by csrabak＠bol.com.br

Aug. 13, 2009