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

Re: [Pharo-project] Sockets in Pharo CollaborActive Book

by Schwab,Wilhelm K

Stef, Noury, Thanks for doing this, and for the preview! Sometimes being a good friend means getting tough, and it's time for that. You are doing a great job of writing up how to create poorly designed socket applications. They are poorly designed because of what we inherit from Squeak. Servers should not listen for a time period; they need to listen until told otherwise, and trigger events (notifications if preferred) when a client tries to connect, at which point a dedicated process accepts the connection - that process more or less is the server. Clients should try to connect and read until told otherwise, either by a watchdog thread or by a user. Nothing should block in either case except the calling Smalltalk Process. If a client program does not hang because of a non-responsive server, an interacting user has the opportunity to hit a cancel button and put an end to wasted effort, or a watchdog can run and similarly #erminate the offending thread. IMHO, we should not direct energy at documenting the current state of sockets; we should do the few remaining things to get something that really works. At the same time, we should try as much as possible to allow IrDA and OpenSSL to appear as options. Bill ________________________________________ From: stephane ducasse [stephane.ducasse(a)free.fr] Sent: Monday, August 30, 2010 2:50 PM To: Schwab,Wilhelm K Subject: Fwd: [Pharo-project] Sockets in Pharo CollaborActive Book Begin forwarded message: > From: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Date: August 29, 2010 11:09:50 PM GMT+02:00 > To: DeNigris Sean <sean(a)clipperadams.com> > Subject: Re: [Pharo-project] Sockets in Pharo CollaborActive Book >

Aug. 30, 2010

[Pharo-project] Squeaksource default license (was Re: WebClient-Core port to Pharo 1.1 final)

by DeNigris Sean

<quote author="Torsten Bergmann"> Maybe the license should be a required field in Squeaksource for any new project. </quote> Yes! /And/ *default to MIT.* Even though in this case Andreas chose other-than MIT on purpose, how many projects are not MIT simply because the default is a choice other than "the one most valuable to the community." Let's use this opportunity to improve for the future :) Sean

Aug. 30, 2010

Re: [Pharo-project] Inter-image communication

by Sean P. DeNigris

While some of the suggestions (AMQP, STOMP) were over my head, I'm in the process of getting UbiquiTalk to work and already have rST going. But, for my use case i.e. sending remote commands between (only) two images on the same machine, why not just send the commands as strings over a socket, and evaluate them with the compiler? Obviously there's no security, but since it's in-house only... A proof-of-concept is below: Server image: server := Socket newTCP. server listenOn: 8081. server waitForConnectionFor: 600. server sendData: 'Workspace open' Client image: client := Socket newTCP. client connectTo: (NetNameResolver localHostAddress) port: 8081. Compiler evaluate: client receiveData. Add a loop and we're all set. Sean -- View this message in context: http://forum.world.st/Inter-image-communication-tp2320723p2400616.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 30, 2010

Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final

by Douglas Brebner

On 30/08/2010 12:06, Levente Uzonyi wrote: > On Mon, 30 Aug 2010, StÃ©phane Ducasse wrote: > >> >> Now >> - since the license is unclear >> - since the license of the contributors is unclear >> we will not use it as an infrastructural assets for Pharo. I imagine >> that Seaside will not use it either. > > Well, we are about to use it for Seaside. > Is that legal? IANAL but it was my understanding that if code has no licence it means that noone but the author has any right to do anything with it whatsoever. Not to download it, use it or even read it. That's why licences explicitly grant you rights, because otherwise you have /none/.

Aug. 30, 2010

Re: [Pharo-project] return character magic?

by StÃ©phane Ducasse

On Aug 30, 2010, at 8:33 PM, Johan Brichau wrote: > so what did you do? > > I see that the file got removed... I will submit a bug issue for that with the file attached. > > The *real* problem is that you cannot remove it either! It does _not_ want to go away! Oops! A bad spirit in pharo :) For me just resizing the window made it disappeared.

Aug. 30, 2010

Re: [Pharo-project] return character magic?

by Lukas Renggli

It happens with WideStrings, you get the normal display with ByteString instances. To reproduce just print an expression like "Character value: 1024" if you can't type non-ascii characters on your keyboard. Now, why the display changes I don't know either ... Lukas On 30 August 2010 20:31, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > A while ago I got the same with _ > > Stef > > On Aug 30, 2010, at 8:28 PM, Johan Brichau wrote: > >> Hi all, >> >> Just last week, I had a very strange phenomenon in my Pharo image: the return character (^) was changed by an up arrow (see screenshot below). >> I was not really able to reproduce the 'problem' but now we got a repeatable one: >> >> Just load the attached js file in a Seaside WAFilelibrary (WAFilelibrary addFileAt: ' ...'): you will see that the method will also have such a return char. >> >> What is going on? :-) >> >> I'm on Mac, using Pharo 1.1. >> >> cheers, >> Johan >> >> >> >> >> >> >> <Screen shot 2010-07-29 at 17.15.29.png> >> A MIME attachment of type <application/x-javascript> was removed here >> by a drop-attachments-by-name filter rule on the host <mail2-relais-roc.national.inria.fr>. >> >> >> _______________________________________________ >> 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 > -- Lukas Renggli www.lukas-renggli.ch

Aug. 30, 2010

Re: [Pharo-project] return character magic?

by Johan Brichau

so what did you do? I see that the file got removed... I will submit a bug issue for that with the file attached. The *real* problem is that you cannot remove it either! It does _not_ want to go away! On 30 Aug 2010, at 20:31, StÃ©phane Ducasse wrote: > A while ago I got the same with _ > > Stef > > On Aug 30, 2010, at 8:28 PM, Johan Brichau wrote: > >> Hi all, >> >> Just last week, I had a very strange phenomenon in my Pharo image: the return character (^) was changed by an up arrow (see screenshot below). >> I was not really able to reproduce the 'problem' but now we got a repeatable one: >> >> Just load the attached js file in a Seaside WAFilelibrary (WAFilelibrary addFileAt: ' ...'): you will see that the method will also have such a return char. >> >> What is going on? :-) >> >> I'm on Mac, using Pharo 1.1. >> >> cheers, >> Johan >> >> >> >> >> >> >> <Screen shot 2010-07-29 at 17.15.29.png> >> A MIME attachment of type <application/x-javascript> was removed here >> by a drop-attachments-by-name filter rule on the host <mail2-relais-roc.national.inria.fr>. >> >> >> _______________________________________________ >> 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. 30, 2010

Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final

by StÃ©phane Ducasse

thanks henrik I always learn something :) >>>> I suggest that the people that want and know, group together and build an open-source one. >>>>>> >>>>>> Why do you have to have your "own" library? >>>>> >>>>> Did I say "pharo library"? reread carefully I said an "open-source one". >>>> >>>> What I get from Andreas' words is that he's willing to make it open source if it won't be forked. >>> >>> So, definitely not MIT then. >> >> Why? > Because the MIT license explicitly sets no limit on the users right to modify, publish and distribute the software. > A condition that it can not be published/used in a modified (forked) form would exclude using MIT. > >> >>> I guess that means the long-term plan of replacing HttpSocket in Squeak is out as well? >> >> I don't think so. Squeak releases won't come with WebClient loaded, Andreas mentioned it in his mail. > > In a reply to the original announcement, Andreas also said: > > "On 5/4/2010 11:11 PM, Casey Ransberger wrote: > > Are you intent on replacing HTTPSocket in the long run? I have an > > RPC-ish thing that uses it, so I'd like to be clear on whether I can > > expect it to be around for the next release. > > In the long run: Yes. In the next release: No. And "replacing" can mean > that the public interface in HTTPSocket remains. That's what the > WebClient-HTTP package does. It patches HTTPSocket to use WebClient > while preserving the identical external interface. " > > which to me implied eventual integration in Squeak core > (as did the removal of HttpSocket functionality based on it being offered by WebClient) > > >> >>> If you call (re)introducing #squeakToUtf8/#utf8ToSqueak instead of using convertTo/FromEncoding: 'utf8', then yes. >> >> In Squeak these methods avoid the creation of the TextConverter object if the receiver is a ByteString, which is usually the case. >> >> >> Levente > > Yes, the major performance differences come from not creating copies if the strings are ascii, and #convertTo/FromEncoding: doing subclass lookup to find the converter though. > > AFAICT, it's maximally about 2 times faster in the best case (small, pure ascii strings) where it avoids both copies and a lookup compared to a convertTo/FromEncoding modified to do lookup in a dictionary rather than iterating subclasses. > > For the WebSocket use-cases though, I really don't see how the performance matters all that much. > > You convert roughly 200k 4KB ascii strings per second either way, and with a single non-ascii char, the difference falls to near negligible. > > "MediumDoc is a pure ascii ByteString of size 4096" > [1 to: 100000 do: [:ix |MediumDoc > squeakToUtf8]] timeToRun 362 384 > [1 to: 100000 do: [:ix | MediumDoc > convertToEncoding: 'utf-8']] timeToRun 437 564 > MediumDoc at: 2048 put: $Ã¥. > [1 to: 100000 do: [:ix |MediumDoc > squeakToUtf8]] timeToRun 1451 1438 > [1 to: 100000 do: [:ix | MediumDoc > convertToEncoding: 'utf-8']] timeToRun 1463 1470 > > Cheers, > Henry > > <TextConverting.zip> > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 30, 2010

Re: [Pharo-project] return character magic?

by StÃ©phane Ducasse

A while ago I got the same with _ Stef On Aug 30, 2010, at 8:28 PM, Johan Brichau wrote: > Hi all, > > Just last week, I had a very strange phenomenon in my Pharo image: the return character (^) was changed by an up arrow (see screenshot below). > I was not really able to reproduce the 'problem' but now we got a repeatable one: > > Just load the attached js file in a Seaside WAFilelibrary (WAFilelibrary addFileAt: ' ...'): you will see that the method will also have such a return char. > > What is going on? :-) > > I'm on Mac, using Pharo 1.1. > > cheers, > Johan > > > > > > > <Screen shot 2010-07-29 at 17.15.29.png> > A MIME attachment of type <application/x-javascript> was removed here > by a drop-attachments-by-name filter rule on the host <mail2-relais-roc.national.inria.fr>. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 30, 2010

[Pharo-project] return character magic?

by Johan Brichau

Hi all, Just last week, I had a very strange phenomenon in my Pharo image: the return character (^) was changed by an up arrow (see screenshot below). I was not really able to reproduce the 'problem' but now we got a repeatable one: Just load the attached js file in a Seaside WAFilelibrary (WAFilelibrary addFileAt: ' ...'): you will see that the method will also have such a return char. What is going on? :-) I'm on Mac, using Pharo 1.1. cheers, Johan A MIME attachment of type <application/x-javascript> was removed here by a drop-attachments-by-name filter rule on the host <mail2-relais-roc.national.inria.fr>.

Aug. 30, 2010