- Pharo-dev - lists.pharo.org

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

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

by Mariano Martinez Peck

2010/8/30 Miguel Enrique CobÃ¡ MartÃnez <miguel.coba(a)gmail.com> > El lun, 30-08-2010 a las 18:25 +0300, Igor Stasenko escribiÃ³: > > My 2 cents about WebClient. > > > > - it should be an (un)loadable external package, and i am fully agree > > with Andreas on this point. > > It is tempting to integrate it into image, do some tweaks here and > > there and then ship it within a monolitic image. > > But then, from maintainer's point of view, it is quite hard to keep > > developing it and improving, since it may break > > things in random places over multiple forks etc etc, and then who will > > be accused in such breakage? - a maintainer. > > Of course not, we, the ones using it as part of our core image are the > ones responsible of the correct functioning in our image. It would be > childish to run crying to Andreas that it break our image because we are > taking the decision of integrating it in the core image. Now, this of > course doesn't apply to core functionality or that breaks the contract > the code offers to its clients. That type of API changes will be > discussed with Andreas and if no solution found, the pharo developers > will found a workaround so that is remains working correctly. > > Agree with Miguel. It is the smae situation as Gofer. Lukas is the main developer of Gofer but we (pharo developers) maintain it. When a message is removed or renamed for example, we take care about its senders, for all packages, included Gofer. And we are the responsible, not Lukas. > What I don't understand is why such imposition to the way of use the > software. If it decided to have an open source license he can't restrict > the uses of the software. This is a real open source implications. > > > > > > It is good to have a person, who personally responsible for > > maintaining a package, or even if by a group of people, > > it should use a separate repository for developing it. > > > > Otherwise, if you integrate it into image, by doing that you: > > - losing a maintainer , who willingly contributing to this project > > - in same turn, must take own responsibility for maintaining it, > > which means extra work for you, whenever you having > > problems with it. > > Of course, that is the point. Nobody expects otherwise. > > > > > We should learn how to integrate things without intimately tying > > everything with a single bloated image. > > Isn't as we are integrating moose or seaside in the core image is a > basic infrastructure thing, a http client, that every modern language in > the current times includes in their core libraries (java, ruby, lisp). > > > And WebClient could be right thing for learning that (Seaside too ;). > > > > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > 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] SerialPort - named ports on Linux

by Schwab,Wilhelm K

Hello all, I recalled seeing mention of the Linux vm's now supporting named ports, and I found the code for that, at least in the vm. My understanding gets fuzzy as we enter the plugin and primitives. At a minimum, there are a few ByName methods to be added, and Squeak 4.1 contains open and close methods that test on type (int vs. string) to open or close by name or not as appropriate. Is this as simple as gathering the changes and adding them to Pharo, or does it require VMMaker magic? Bill

Aug. 30, 2010

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

by Schwab,Wilhelm K

Noury, I would like a copy. Bill bschwab AT anest DOT ufl DOT edu ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Noury Bouraqadi [bouraqadi(a)gmail.com] Sent: Monday, August 30, 2010 9:41 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Sockets in Pharo CollaborActive Book Hi, I'm currently working on a chapter about Sockets for the Pharo by example book. I'm half way, though there is more material than what is on the pharo collabor-active book. It's a pitty, that pharo by example and the collaborative book aren't linked. Any way, I'll be happy ot send what I have written to anyone who request it. Noury On 29 aoÃ»t 2010, at 23:05, Sean P. DeNigris wrote: > > The description of sockets at > http://book.pharo-project.org/book/networking/Socket/ is: > > Socket is one of the main networking classes. You can create a new TCP > socket with the message #newTCP. >> >> This example creates a TCP socket and puts it into listening mode. After a >> client has connected, it reads data from the socket. >> >> | server client | >> server := Socket newTCP. >> server listenOn: 12345 backlogSize: 4. >> server waitForConnectionFor: 600. >> client := server accept. >> client receiveData >> > > Huh?! It looks like half the code in this snippet belongs on the server, > and the other half on the client. I tried: > Server doit: > server := Socket newTCP. > server listenOn: 12345 backlogSize: 4. > server waitForConnectionFor: 600. > Client doit: > server := Socket newTCP. > server listenOn: 12345 backlogSize: 4. > server waitForConnectionFor: 600. > client := server accept. > client receiveData. > but the server just hung forever. > > After flopping around for a while, and checking the swiki, it seemed to be > listenOn:backlogSize: that was the problem. Everything went well with: > Server DoIt: > server := Socket newTCP. > server listenOn: 8080. > server waitForConnectionFor: 600. > server sendData: 'Hello from the server' > Client PrintIt: > client := Socket newTCP. > client connectTo: (NetNameResolver localHostAddress) port: 8080. > client receiveData. > > Anyway, I'd like to have this be clearer, but my knowledge is very basic. > Also, the class comment for socket reads "...Sockets are the lowest level of > networking object in Squeak and are not normally used directly..." so is > this where we want to direct people first? > > Thanks. > Sean > -- > View this message in context: http://forum.world.st/Sockets-in-Pharo-CollaborActive-Book-tp2399361p239936… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project Noury _______________________________________________ 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] [update 1.2] #12120

by StÃ©phane Ducasse

12120 ----- - Fix for post enh of methodReference (remove timeStamp:. and related). Sorry for the potential mess. Stef

Aug. 30, 2010