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

Re: [Pharo-project] Socket>>connectTo:port: fail

by HernÃ¡n Morales Durand

Hi Serge, This works for me: | socket1 socket2 | socket1 := Socket newTCP. socket2 := Socket newTCP. socket1 listenOn: 6665. address := NetNameResolver addressForName: '127.0.0.1' timeout: 20. socket2 connectTo: address port:6665. Regards HernÃ¡n 2009/8/13 Serge Stinckwich <serge.stinckwich(a)gmail.com>: > Hi all, > do some modifications occurs recently in the socket classes ? > Because when i'm trying to do : > > | socket | > socket := Socket newTCP. > socket connectTo: #[127 0 0 1] port:6665. > > I have a DNU now : ByteArray>>doesNotUnderstand:#port: > I'm using the last Pharo. > Thank you, > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Smalltalkers do: [:it | All with: Class, (And love: it)] > http://doesnotunderstand.org/ > > _______________________________________________ > 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] OBDependencyWalker for Pharo

by HernÃ¡n Morales Durand

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 <csrabak(a)bol.com.br>: > 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? > > > > _______________________________________________ > 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] Socket>>connectTo:port: fail

by Serge Stinckwich

Hi all, do some modifications occurs recently in the socket classes ? Because when i'm trying to do : | socket | socket := Socket newTCP. socket connectTo: #[127 0 0 1] port:6665. I have a DNU now : ByteArray>>doesNotUnderstand:#port: I'm using the last Pharo. Thank you, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/

Aug. 13, 2009

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

by Schwab,Wilhelm K

+1 -----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: Wednesday, August 12, 2009 9:06 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] #< if at first you dont succeed.. 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. > returned, so no need the iFalse part" > ((self real = 0) and: [other real = 0]) > ifTrue: [^self imaginary < other imaginary]. "csr: same here" > ArithmeticError new signal: 'Complex numbers are not generally comparable' > "csr: Only will happen if no one of the above blocks returned" > But back to the question: 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)? 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. > HTH > > Em 12/08/2009 21:39, Ken.Dickey < Ken.Dickey(a)whidbey.com > escreveu: > > 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 co mparable'.] ] > ------------------------ > > > > _______________________________________________ > 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] #< if at first you dont succeed..

by Schwab,Wilhelm K

Ken, At least it is non-ambiguous from a mathematical perspective, though I am still curious why this is so important to you - there might be a better solution to your problem. I would replace #= with #closeTo:. Float>>= runs through #asTrueFraction, which yields a rational but can still miss. Speaking of #closeTo:, the tolerances look a little wide to me at first glance; it deserves a careful look. 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: Wednesday, August 12, 2009 7:40 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] #< if at first you dont succeed.. 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'.] ] ------------------------

Aug. 13, 2009

Re: [Pharo-project] Croquet - was Sideways marketing of pharo, seaside, etc.

by Serge Stinckwich

There is almost no traffic on the croquet mailing-list (user+dev) since months ... There seems to be more activity in the OpenCobalt web site : http://opencobalt.org/ On Thu, Aug 13, 2009 at 5:00 AM, Schwab,Wilhelm K<bschwab(a)anest.ufl.edu> wrote: > Aside from > > Â http://www.duke.edu/~julian/Cobalt/Foundational_Technology_files/logo_small… > > which strikes me as surpising[*] coming from Smalltalkers, I do not see them running away from Smalltalk. > > Could it simply be that nobody wanted a 3D OS (Croquet), and that a conferencing tool (Qwaq) seemed viable? Â I still think Croquet would have been more useful had the 3D rendering system been made more readily reusable, so that one could easily drop a 3D world into a windowed program vs. finding that "we're not in Kansas anymore." Â Retained mode 3D can be a good thing. Â Tweak was a mistake too. > > So far at least, Cobalt appears to be delivering Squeak images, so perhaps this is not a huge slap in the face. Â My big concern now is for the future of Cog. Â Any ideas? Â Eliot seems to be telling us we're going to have a nice Christmas, JIT wise. Â Here's hoping he is correct. > > Bill > > [*] the capitalization is off and there are no connections with the "brand." Â It is unusual, perhaps even arguably disrespectful to Smalltalk's origins. > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Marcus Denker > Sent: Wednesday, August 12, 2009 10:50 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Croquet - was Sideways marketing of pharo, seaside, etc. > > On Wed, Aug 12, 2009 at 9:19 AM, Schwab,Wilhelm K<bschwab(a)anest.ufl.edu> wrote: >> Stef, >> >> I don't dispute it, but what is this about Croquet being dead? >> > > For one, the page > > http://www.duke.edu/~julian/Cobalt/About.html you can read: > *Croquet is no longer under active development > > And the http://opencroquet.org/ site seems to be not actively maintained. > Last news from 2008, all about cobalt. I don't see any that anyone actually claims to be a member of the consortium, either. > > Not much happening in Cobalt, it seems. I actually wonder if they have anyone on the team with advanced technical knowledge about the deep inner working of Croquet or even just the Squeak parts. > > All very strange.... I am happy that I am not involved in it or the politics around all this. > Looks all very ugly to me. > > Â Â Â Marcus > > >> Bill >> >> >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of >> StÃ©phane Ducasse >> Sent: Wednesday, August 12, 2009 2:22 AM >> To: Pharo-project(a)lists.gforge.inria.fr; lenglish5(a)cox.net >> Subject: Re: [Pharo-project] Sideways marketing of pharo, seaside, etc. >> >> >> On Aug 12, 2009, at 2:39 AM, Lawson English wrote: >> >>> Hey all, I'm in one of my manic brainstorming moods and whilest I'm >>> working on a baby interface between Second Life and Squeak, it dawns >>> on me that there is a huge potential for evangelicalism on your part >>> here: >>> One of hte myriad complains Second LIfe power users have is that the >>> build-in programming tools are extremely limited. There are numerous >>> options for plugins as with Eclipse and emacs (I believe) but they >>> all run as standalone tools with no easy integration with the 3D >>> virtual world experience, which is hte main reason why people bother >>> to script things in SL in the first place: they have interactive >>> feedback with potentialky thousands of other people. >>> >>> The point being that seaside runs just fine on localhost and the >>> builtin SL browser works just fine with everything seaside I have >>> tested. >> >> what do you mean by the previous sentence? >> >>> If Â someone wanted to entice potentially 100,000 Second LIfe users to >>> install seaside, implementing a nice LSL scripting interface in a >>> seaside webpage, complete with syntax coloring, databases of scripts, >>> version control, etc etc, would go a long way toards convincing the >>> Second Life powerusers, at least, that seaside is a worthwhile >>> install. >>> >>> If/when I get my interface to the client-server packets proxy >>> working, one could see potential for many more elaborate uses for >>> squeak/ seaside and Second LIfe. >> >> Keep us informed it looks exciting. >> >>> (interop between SL and Cobalt/Croquet is left as an exercise for the >>> reader ;-)) >> >> I thought Croquet was dead as an open-source project. >> >>> Anyway, if someone with a talent for writing editor code wanted to >>> look at the existing external LSL scripting editors and port >>> something to squeak for use on a webpage in seaside, I can almost >>> promise you that squeak/seaside useage would go up by a huge, HUGE >>> factor. Such a project is beyond me, personally due to my lack of >>> formal education, etc., but it should be a worthy project for anyone >>> wishing to promote seaside/smalltalk use. >> >> May be this is a nice job for helvetia. Lukas? >> mixing SL in Smalltalk :) >> >>> Feel free to ask any questions, privately if appropriate. >>> >>> Lawson English LEnglish5 (at) cox [dot] net Saijanai Kuhn in Second >>> Life >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> > > > > -- > -- > Marcus Denker Â -- Â denker(a)acm.org > http://www.marcusdenker.de > > _______________________________________________ > 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 > -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/

Aug. 13, 2009

Re: [Pharo-project] Problem with new Inspector

by Mariano Martinez Peck

2009/8/12 <csrabak(a)bol.com.br> > Oh well :-| I understand your gripe now, you resent the yellow button does > not bring a menu on this pane, right!? > > If this is considered a bug, then yes, a BT must be opened... > that's exactly what I want :) Not only for people who don't use or don't know about shortcuts but also because not all the commands are accessible by shortcuts. Bye Mariano > > Em 12/08/2009 22:59, *Mariano Martinez Peck < marianopeck(a)gmail.com >*escreveu: > > > > > 2009/8/12 <csrabak(a)bol.com.br<http://mce_host/compose?to=csrabak@bol.com.br> > > > >> In the Inspector you have three panes, the bottom right is a small one and >> it receives messages when I type, for example, self class, or self >> allInstances, I can print the results or even inspect the result, is that >> you want to do? >> > But HOW do you print the results? using ctrl + p or ctrl + i ? > I want (actually I use shortcuts, but for others) to be able yo use the > right button for this. > > Cheers, > > mariano > >> >> >> Em 12/08/2009 22:02, *Mariano Martinez Peck < marianopeck(a)gmail.com<http://mce_host/compose?to=marianopeck@gmail.com>> >> * escreveu: >> >> >> Hi folks: I have a problem with the new inspector. To reproduce: >> >> 1) Go to a workspace. >> 2) Type ScriptLoader or any other class and inspect it. >> 3) If I want to sends messages to THAT object, it seems the place to do it >> is in the pane that is above on the right. Is this correct? >> The problem is that there the right button doesn't work. So, I can only >> use shortcuts. >> >> This is not good for newbie people. In addition, not all the commands are >> accessible by a shortcut. >> >> Any has the same problem? If so, I will open a bug ticket. >> >> Best, >> >> Mariano >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr<http://../../../undefined/compose?to=Pharo> >> 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] Problem with new Inspector

by csrabak＠bol.com.br

Aug. 13, 2009

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

by Igor Stasenko

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. > returned, so no need the iFalse part" > ((self real = 0) and: [other real = 0]) > ifTrue: [^self imaginary < other imaginary]. "csr: same here" > ArithmeticError new signal: 'Complex numbers are not generally comparable' > "csr: Only will happen if no one of the above blocks returned" > But back to the question: 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)? 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. > HTH > > Em 12/08/2009 21:39, Ken.Dickey < Ken.Dickey(a)whidbey.com > escreveu: > > 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 co mparable'.] > ] > ------------------------ > > > > _______________________________________________ > 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] Problem with new Inspector

by Mariano Martinez Peck

2009/8/12 <csrabak(a)bol.com.br> > In the Inspector you have three panes, the bottom right is a small one and > it receives messages when I type, for example, self class, or self > allInstances, I can print the results or even inspect the result, is that > you want to do? > But HOW do you print the results? using ctrl + p or ctrl + i ? I want (actually I use shortcuts, but for others) to be able yo use the right button for this. Cheers, mariano > > > Em 12/08/2009 22:02, *Mariano Martinez Peck < marianopeck(a)gmail.com >*escreveu: > > > Hi folks: I have a problem with the new inspector. To reproduce: > > 1) Go to a workspace. > 2) Type ScriptLoader or any other class and inspect it. > 3) If I want to sends messages to THAT object, it seems the place to do it > is in the pane that is above on the right. Is this correct? > The problem is that there the right button doesn't work. So, I can only use > shortcuts. > > This is not good for newbie people. In addition, not all the commands are > accessible by a shortcut. > > Any has the same problem? If so, I will open a bug ticket. > > Best, > > Mariano > > > _______________________________________________ > 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