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

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

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

by Henrik Johansen

On Aug 30, 2010, at 2:57 47PM, Levente Uzonyi wrote: > On Mon, 30 Aug 2010, Henrik Johansen wrote: > >> >> On Aug 30, 2010, at 1:06 10PM, Levente Uzonyi wrote: >> >>> On Mon, 30 Aug 2010, StÃ©phane Ducasse wrote: >>> >>>>>> >>>>>> 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

Aug. 30, 2010

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

by Igor Stasenko

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. > > 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. > Then you making things wrong, because then: - party A made feature A available - party B made feature B available - users want A and B features both, but party A and B do not communicate I think that Andreas wants to impose a teamwork, when multiple parties working on same project, rather than multiple parties working on each own fork of a same project. I think i understood the Anreas'es point well. As initial developer, he dont wants to be in position, when his creation moves into a different direction, than he is initially planned. At least, until Andreas to-do list is not empty, and project is not mature enough, it is wise to keep development under his personal control. That's how i understood his message about license. >> >> 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 -- Best regards, Igor Stasenko AKA sig.

Aug. 30, 2010

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

by Miguel Enrique CobÃ¡ MartÃnez

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. 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

Aug. 30, 2010

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

by Miguel Enrique CobÃ¡ MartÃnez

El lun, 30-08-2010 a las 13:06 +0200, Levente Uzonyi escribiÃ³: > On Mon, 30 Aug 2010, StÃ©phane Ducasse wrote: > > >>> > >>> 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. This is plain wrong, You CAN'T make something open source and at the same time hope that nobody will fork it. The possibility of forking is one of the main liberties granted by the free and open source software. If Andreas doesn't want anyone to fork then by definition can't be open source. As I said before, a way to avoid forking in an open source project is to be open and accepting code from contributors. Not accepting good code for bad reasons is what leads to forking. I, and I think, every Pharo user, are ok with the package being controlled by Andreas, as long as the patches are accepted and not rejected for bad reasons (like having the package part of pharo core: that is our problem, if there are issues by having it part of pharo core we'll solve them, without bothering Andreas because they are Pharo specific. But he can't also, by the same Open source nature, restrict the uses of the code). We all, greatly respect and admire his technical ability, that has never been denied. But his public interactions has more than one burned a lot of people, and this no-license issue is becoming one of them. We don't want tramps like that of the missing license. When the code was announced it was a public encourage to use it and test it, but we as community went to happy and without checking the license it was included in pharo. That was our error. So please, Andreas, if you want WebClient to be open source please do it, Pharo will use it and send you patches. If not say it too, and we'll find an alternative for this. Cheers -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Aug. 30, 2010

Re: [Pharo-project] OBMorphicIcons (was Re: this style looks cool)

by Guillermo Polito

*contents := (StandardFileStream fileNamed: 'loop_icon.jpg') contents. encondedContents := (Base64MimeConverter mimeEncode: contents readStream) .* That basically gives you the string you have to embed in a method... Cheers, Guille On Mon, Aug 30, 2010 at 9:42 AM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > > > > This looks useful; how do you turn an image into a method, though? > > Hi! > > Have a look at the class side of MenuIcons. There are a bunch of > import/export methods. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > 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 Igor Stasenko

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. 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. We should learn how to integrate things without intimately tying everything with a single bloated image. And WebClient could be right thing for learning that (Seaside too ;). -- Best regards, Igor Stasenko AKA sig.

Aug. 30, 2010