- Pharo-dev - lists.pharo.org

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

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

by Yanni Chiu

Johan Brichau wrote: > > I am not a lawyer but as far as I understand this topic, no license > means nobody can use the code at all, which contradicts the fact of > having it in a public repository (and you being perfectly happy of > people using it). IANAL. "no license" means it's public domain, so *anybody* can use it. But, if they use it, they have no idea of the terms under which they can use it - a license would may the terms clear. Cautious users would then *not* use it. So the net effect would be that nobody (that is cautious) uses it. There is no contradiction with it being in a public repository. The author is perfectly happy for the public to use it. The problem is that users are likely not happy to use it, without any license terms.

Aug. 30, 2010

Re: [Pharo-project] ifEmpty:ifNotEmpty (was: WebClient-Core port to Pharo 1.1 final)

by Henrik Johansen

On Aug 30, 2010, at 4:45 35PM, StÃ©phane Ducasse wrote: > Ok so I can close the ticket then. > :) > Stef Unless you want it as part of a 1.0 patch, yes. Cheers, Henry >>>> ---- On Mon, 30 Aug 2010 05:57:47 -0700 Levente Uzonyi wrote ---- >>>> >>>>> I don't like the "magical" #asString, but you should discuss it with >>>>> Andreas. Collection >> #ifEmpty: doesn't return nil, but the collection in >>>>> the WebClient-Pharo package (and in Squeak), and I think it's better than >>>>> nil. >>>> >>>> I opened a ticked on this a few weeks back: http://code.google.com/p/pharo/issues/detail?id=2794 >>>> >>>> The ifEmpty:/ifNotEmpty: behavior of Squeak is demonstrably better and should be adopted. >>> >>> heu... I evaluated the following in a pharo1.1-dev and 1.2-core: >>> >>> (#(foo) ifEmpty:[#bar]) -> returns #(foo) >>> (#() ifNotEmpty:[#bar]) -> returns #() >>> >>> This seems to do what you propose? >>> Johan >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> Yes. >> Levente is right, I read the code of Andreas' wrong. >> Pharo 1.1/1.2 does this, so the override is for 1.0, where #ifEmpty: returns nil . >> >> Cheers, >> Henry >> _______________________________________________ >> 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] ifEmpty:ifNotEmpty (was: WebClient-Core port to Pharo 1.1 final)

by StÃ©phane Ducasse

Ok so I can close the ticket then. :) Stef >>> ---- On Mon, 30 Aug 2010 05:57:47 -0700 Levente Uzonyi wrote ---- >>> >>>> I don't like the "magical" #asString, but you should discuss it with >>>> Andreas. Collection >> #ifEmpty: doesn't return nil, but the collection in >>>> the WebClient-Pharo package (and in Squeak), and I think it's better than >>>> nil. >>> >>> I opened a ticked on this a few weeks back: http://code.google.com/p/pharo/issues/detail?id=2794 >>> >>> The ifEmpty:/ifNotEmpty: behavior of Squeak is demonstrably better and should be adopted. >> >> heu... I evaluated the following in a pharo1.1-dev and 1.2-core: >> >> (#(foo) ifEmpty:[#bar]) -> returns #(foo) >> (#() ifNotEmpty:[#bar]) -> returns #() >> >> This seems to do what you propose? >> Johan >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > Yes. > Levente is right, I read the code of Andreas' wrong. > Pharo 1.1/1.2 does this, so the override is for 1.0, where #ifEmpty: returns nil . > > Cheers, > Henry > _______________________________________________ > 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 It skipped my radar since it is not marked as fixed. do you want that I add you to the project developers on google so that you can changed the tag value? Stef On Aug 30, 2010, at 3:35 PM, jaayer wrote: > > > ---- On Mon, 30 Aug 2010 05:57:47 -0700 Levente Uzonyi wrote ---- > >> I don't like the "magical" #asString, but you should discuss it with >> Andreas. Collection >> #ifEmpty: doesn't return nil, but the collection in >> the WebClient-Pharo package (and in Squeak), and I think it's better than >> nil. > > I opened a ticked on this a few weeks back: http://code.google.com/p/pharo/issues/detail?id=2794 > > The ifEmpty:/ifNotEmpty: behavior of Squeak is demonstrably better and should be adopted. > > > _______________________________________________ > 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