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

Re: [Pharo-project] Complex neurotic

by Schwab,Wilhelm K

Perhaps #isNumber should answer false. I would be very careful about advertising an order that might not behave as people expect. The example of -1 asComplex < 1 asComplex is simple enough, but anything that invokes dictionary ordering (or whatever other definition is used) will get tricky with questions of floating point precision. Also, Float has much more in common with Number than would Complex. A float can be approximated by a fraction; a Complex in general cannot. That alone might be justification for treating complex numbers as something different. Take the real or imaginary part or the modulus, and you have a number again. 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: Tuesday, August 11, 2009 9:46 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Complex neurotic > AFAIK, one has to be careful ordering complex numbers: I am aware of this. Â There are a large number of ways to define #< for complex numbers -- and a large number of problems with each of them. What I object to are bad behaviors for things which are perfectly well defined. Currently: -1 asComplex isNumber --> true Â 1 asComplex isNumber -> true -1 asComplex < 1 asComplex --> error -4 sqrt --> error -3 ln -> NaN > If in doubt, I would #shouldNotImplement #< until we can get a > conclusive answer. An answer to what? Â I wrote the test cases first and then did code to make the tests pass. I am certainly open to alternate definitions, but I think if an object answers true to isNumber it should behave as a number. What would you expect of the following? -1 asFloat < 1 asFloat. -1 asNumber < 1 asNumber. -1 asFraction < 1 asFraction. -1 asComplex < 1 asComplex. One can add checks and make off-axis complex numbers fail (why?), but why cause the last case above to fail? Smalltalk is known for reasonable behaviors. Â E.g in Java (1/2) + (1/3) + 1/6) can yield zero (integer division truncates). I much prefer to get an exact 1. Why should I expect complex numbers to be unreasonable? $0.02, -KenD _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 12, 2009

Re: [Pharo-project] SWHTTPClient

by Eagle Offshore

Wasn't there a curl plugin? Or did it not get finished? -Todd Blanchard

Aug. 12, 2009

Re: [Pharo-project] Complex neurotic

by Ken.Dickey

> AFAIK, one has to be careful ordering complex numbers: I am aware of this. Â There are a large number of ways to define #< for complex numbers -- and a large number of problems with each of them. What I object to are bad behaviors for things which are perfectly well defined. Currently: -1 asComplex isNumber --> true Â 1 asComplex isNumber -> true -1 asComplex < 1 asComplex --> error -4 sqrt --> error -3 ln -> NaN > If in doubt, I would #shouldNotImplement #< until we can get a conclusive > answer. Â An answer to what? Â I wrote the test cases first and then did code to make the tests pass. I am certainly open to alternate definitions, but I think if an object answers true to isNumber it should behave as a number. What would you expect of the following? -1 asFloat < 1 asFloat. -1 asNumber < 1 asNumber. -1 asFraction < 1 asFraction. -1 asComplex < 1 asComplex. One can add checks and make off-axis complex numbers fail (why?), but why cause the last case above to fail? Smalltalk is known for reasonable behaviors. Â E.g in Java (1/2) + (1/3) + 1/6) can yield zero (integer division truncates). I much prefer to get an exact 1. Why should I expect complex numbers to be unreasonable? $0.02, -KenD

Aug. 12, 2009

Re: [Pharo-project] Pharo Feature Roadmap Question

by Eagle Offshore

I have tried to get this running in Squeak on my own three or four times. I have had no luck with it. I love the idea in principle, but there are always errors I can't figure out when I try to make it work. -Todd Blanchard On Aug 11, 2009, at 12:27 AM, StÃ©phane Ducasse wrote: > if somebody helps yes :) > It should be in the list of items for 1.1 > > STef > > On Aug 11, 2009, at 6:10 AM, Eagle Offshore wrote: > >> It seems like Pharo 1.0 is crystallized already. >> >> Is native window support (Areithfa Ffenestri) in the near term plan? >> http://wiki.squeak.org/squeak/3862 >> >> -Todd Blanchard >> _______________________________________________ >> 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. 12, 2009

Re: [Pharo-project] SWHTTPClient

by Hernan Wilkinson

Thanks you all guys for the answers. We have no decided what to do yet... stunnel is an option too because the code we are writting now on pharo will have to run on GemStone later on, so that is another variable to have in mind also... Hernan. On Tue, Aug 11, 2009 at 3:42 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > Two reasons: (1) OpenSSL offers a lot more than just SSL sockets, so it is > worth wrapping; (2) it would be easy enough to do that is worth the effort. > Any time one introduces something like stunnel, there are setup > complexities, which become opportunities to make mistakes that leave data > unprotected. > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto: > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Esteban > Lorenzano > Sent: Tuesday, August 11, 2009 1:03 PM > To: pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] SWHTTPClient > > Sorry if this is not the case, but... why don't you use stunnel instead > trying to make https protocol work on squeak? > Is much more easy, I think. > > Cheers, > Esteban > > > On 2009-08-11 14:47:07 -0300, "Schwab,Wilhelm K" > <bschwab(a)anest.ufl.edu> said: > > > AFAICT, https is just http over an SSL socket. The less incorrect I > > am abo ut that, the more you are in fact looking for an SSL socket > implementation. > > My thought is to create that on top of OpenSSL, whether by plugin or > > FFI/ Alien. > > > > OpenSSL provides non-blocking calls, but my recollection is that they > > are n ot simple to use. A plugin that can start OS threads to prevent > > blocking ( on connect, read, and write) might be the easiest approach. > > Perhaps someon e who actually knows something about Squeak plugins > > could comment on whethe r that makes any sense :) > > > > Bill > > > > > > > > -----Original Message----- > > From: > > pharo-project-bounces(a)lists.gforge.inria.fr > > [mailto:pharo-project-bou > > nces(a)lists.gforge.inria.fr] On Behalf Of HernÃ¡n Morales Durand > > Sent: Tuesday, August 11, 2009 12:22 PM > > To: Pharo-project(a)lists.gforge.inria.fr > > Subject: Re: [Pharo-project] SWHTTPClient > > > > http://universes.dnsalias.net/universes/repositories/squeak-3.9/SWHTTP > > Clien > > t-bkv.19.mcz > > > > 2009/8/11 Hernan Wilkinson > > <hernan.wilkinson(a)gmail.com>: > >> Does anybody know how to download the SWHTTPClient? (still looking > >> for > > > >> a https client :-) ) > >> > >> _______________________________________________ > >> 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 12, 2009

Re: [Pharo-project] [Ann] RFB/VNC fully configurable by code.

by Keith Hodges

Miguel Enrique CobÃ¡ Martinez wrote: > El mar, 11-08-2009 a las 21:00 -0300, Mariano Martinez Peck escribiÃ³: > >> 2009/8/11 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com> >> El mar, 11-08-2009 a las 14:42 -0100, Mariano Martinez Peck >> escribiÃ³: >> >> > >> > I also thought in a Seaside/Pier component similar to the >> morph to >> > start/stop the vnc. For a Pier application it can be under >> "System >> > Managment" :) >> > >> > >> >> The seaside examples already has a component to control the >> RFB server. >> Search for WAVNCComponent. You can adapt it or make a new one >> specific >> to pier. Also, you can control the server directly with the >> RFBServer >> from pier. >> > > It is WAVNCController what I meant. > > >> Nice! I wasn't aware. Thanks for the tip. >> >> >> >> What I though was intended to apps that are not web >> apps/seaside apps >> and that run on a headless server. For them a way to >> start/stop the RFB >> server on demand will save cpu cycles for what the app does. >> >> >> Sounds a good thing for a Magma server :) >> > > Exactly, that is what I want this for. > > Why not just use the REPLServer Keith

Aug. 12, 2009

Re: [Pharo-project] [Ann] RFB/VNC fully configurable by code.

by Miguel Enrique CobÃ¡ Martinez

El mar, 11-08-2009 a las 21:00 -0300, Mariano Martinez Peck escribiÃ³: > > > 2009/8/11 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com> > El mar, 11-08-2009 a las 14:42 -0100, Mariano Martinez Peck > escribiÃ³: > > > > > I also thought in a Seaside/Pier component similar to the > morph to > > start/stop the vnc. For a Pier application it can be under > "System > > Managment" :) > > > > > > The seaside examples already has a component to control the > RFB server. > Search for WAVNCComponent. You can adapt it or make a new one > specific > to pier. Also, you can control the server directly with the > RFBServer > from pier. It is WAVNCController what I meant. > > Nice! I wasn't aware. Thanks for the tip. > > > > What I though was intended to apps that are not web > apps/seaside apps > and that run on a headless server. For them a way to > start/stop the RFB > server on demand will save cpu cycles for what the app does. > > > Sounds a good thing for a Magma server :) Exactly, that is what I want this for. -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Aug. 12, 2009

[Pharo-project] Sideways marketing of pharo, seaside, etc.

by Lawson English

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. 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. (interop between SL and Cobalt/Croquet is left as an exercise for the reader ;-)) 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. Feel free to ask any questions, privately if appropriate. Lawson English LEnglish5 (at) cox [dot] net Saijanai Kuhn in Second Life

Aug. 12, 2009

Re: [Pharo-project] [squeak-dev] Squeak 4.x should adopt Pharo 1.0

by Mariano Martinez Peck

On Tue, Aug 11, 2009 at 9:10 PM, <csrabak(a)bol.com.br> wrote: > > Pharo1.0beta latest update: #10413. > > BTW: it's not possible to copy text from the About this System Dialog... > Here in Linux works using ctrl + c not only to a workspace (inside image) but also to an external program. > > > Em 11/08/2009 19:05, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr > > escreveu: > > > Which image are you using? > Because on mine = core 10371 > deprecatedWarning = on > I do not get them. > > Stef > > On Aug 11, 2009, at 11:58 PM, Lawson English wrote: > > > Alexandre Bergel wrote: > >>> Great to hear. However, pharo gets upset by putting 'eureka'. > >>> 'EUREKA' > >>> into the method finder. > >>> > >>> Says that is EVIL. > >>> > >> > >> Interesting bug. The problem comes from the deprecation of > >> String>>asCharacter > >> > >> http://code.google.com/p/pharo/issues/detail?id=1062 > >&gt <http://code.google.com/p/pharo/issues/detail?id=1062%0A>&gt>; > >> > >>> I gotta assume that that is just a simple bug, right, or is > that > >>> facility no longer to be supported for some reason. > >>> > >> > >> Apparently, a number of deprecations in String are problematic > >> > >> Try: 'abc' . 'd'. 'abcd' > >> > >> Alexandre > >> > > > > > > I get ByteString(SequenceableCollection)>>upTo: has been > > deprecated. > > Use #copyUpTo: > > > > > > Lawson > > > > _______________________________________________ > > 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. 12, 2009

Re: [Pharo-project] [squeak-dev] Squeak 4.x should adopt Pharo 1.0

by csrabak＠bol.com.br

Pharo1.0beta latest update: #10413. BTW: it's not possible to copy text from the About this System Dialog... Em 11/08/2009 19:05, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr > escreveu: Which image are you using? Because on mine = core 10371 deprecatedWarning = on I do not get them. Stef On Aug 11, 2009, at 11:58 PM, Lawson English wrote: > Alexandre Bergel wrote: >>> Great to hear. However, pharo gets upset by putting 'eureka'. >>> 'EUREKA' >>> into the method finder. >>> >>> Says that is EVIL. >>> >> >> Interesting bug. The problem comes from the deprecation of >> String>>asCharacter >> >> http://code.google.com/p/pharo/issues/detail?id=1062 >> >> >>> I gotta assume that that is just a simple bug, right, or is that >>> facility no longer to be supported for some reason. >>> >> >> Apparently, a number of deprecations in String are problematic >> >> Try: 'abc' . 'd'. 'abcd' >> >> Alexandre >> > > > I get ByteString(SequenceableCollection)>>upTo: has been > deprecated. > Use #copyUpTo: > > > Lawson > > _______________________________________________ > 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. 12, 2009