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@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
