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

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

by Miguel Enrique CobÃ¡ MartÃnez

El mar, 31-08-2010 a las 00:25 +0200, Levente Uzonyi escribiÃ³: > On Mon, 30 Aug 2010, Friedrich Dominicus wrote: > > > Levente Uzonyi <leves(a)elte.hu> writes: > > > 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. > Hm I think this is impossible. If it's OS it's up to whomever get its > hand on it. Or am I mistaken? > > > Just think about GPL, it's open source, but you can't fork the code if you > don't release your changes as GPL too. I don't get it. If it is open source then is forkable. Period. If it is a special case like GPL, it add some other restriction, like you can't redistribute the new code without it being also GPL. You can fork it and not using GPL for the new changes, the restriction is that you can't redistribute it. But the fact remains that it is forkable always. If you don't want it forkable, then use other non open source license. Cheers > > > Levente > > > Regards > Friedrich > > -- > Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim > Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus > > _______________________________________________ > 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 -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Aug. 30, 2010

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

by Levente Uzonyi

On Mon, 30 Aug 2010, Friedrich Dominicus wrote: > Levente Uzonyi <leves(a)elte.hu> writes: > 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. Hm I think this is impossible. If it's OS it's up to whomever get its hand on it. Or am I mistaken? Just think about GPL, it's open source, but you can't fork the code if you don't release your changes as GPL too. Levente Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus _______________________________________________ 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 Levente Uzonyi

On Mon, 30 Aug 2010, Henrik Johansen wrote: > > 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. Andreas may still decide to release the source under the MIT license. > >> >>> 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) So you can expect the code to be released under MIT, but maybe not now. :) > > >> >>> 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. I mean, no converter objects are created. > > 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. More objects -> more gc. It probably doesn't matter if the image doesn't have to handle heavy load. > > 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 In Squeak(CogVM): "7-bit ByteString" mediumDoc := ByteString new: 4096 streamContents: [ :stream | 4096 timesRepeat: [ stream nextPut: (Character value: 128 atRandom - 1) ] ]. (1 to: 5) collect: [ :run | [ 1 to: 100000 do: [ :ix | mediumDoc squeakToUtf8 ] ] timeToRun ]. "===> #(344 345 344 347 344)" (1 to: 5) collect: [ :run | [ 1 to: 100000 do: [ :ix | mediumDoc convertToWithConverter: UTF8TextConverter new ] ] timeToRun ]. "===> #(404 373 375 374 374)" (1 to: 5) collect: [ :run | [ 1 to: 100000 do: [ :ix | mediumDoc convertToEncoding: 'utf-8' ] ] timeToRun ]. "===> #(1443 1440 1438 1443 1445)" "7-bit ByteString with a single 8-bit character" mediumDoc := ByteString new: 4096 streamContents: [ :stream | 4096 timesRepeat: [ stream nextPut: (Character value: 128 atRandom - 1) ] ]. mediumDoc at: 2048 put: (Character value: 128). (1 to: 5) collect: [ :run | [ 1 to: 100000 do: [ :ix | mediumDoc squeakToUtf8 ] ] timeToRun ]. "===> #(1262 1246 1249 1250 1249)." (1 to: 5) collect: [ :run | [ 1 to: 100000 do: [ :ix | mediumDoc convertToWithConverter: UTF8TextConverter new ] ] timeToRun ]. "===> #(1261 1256 1264 1260 1258)" (1 to: 5) collect: [ :run | [ 1 to: 100000 do: [ :ix | mediumDoc convertToEncoding: 'utf-8' ] ] timeToRun ]. "===> #(2591 2567 2538 2543 2582) Not neglible (~0.5 speed)" "8-bit ByteStrings (only 1000 conversion/test)" mediumDoc := ByteString new: 4096 streamContents: [ :stream | 4096 timesRepeat: [ stream nextPut: (Character value: 256 atRandom - 1) ] ]. (1 to: 5) collect: [ :run | [ 1 to: 1000 do: [ :ix | mediumDoc squeakToUtf8 ] ] timeToRun ]. "===> #(627 618 618 622 618)" (1 to: 5) collect: [ :run | [ 1 to: 1000 do: [ :ix | mediumDoc convertToWithConverter: UTF8TextConverter new ] ] timeToRun ]. "===> #(648 621 620 621 622)" (1 to: 5) collect: [ :run | [ 1 to: 1000 do: [ :ix | mediumDoc convertToEncoding: 'utf-8' ] ] timeToRun ]. "===> #(676 653 650 658 648)" "WideStrings" mediumDoc := String new: 4096 streamContents: [ :stream | 4096 timesRepeat: [ stream nextPut: (Character value: (1<<22) atRandom - 1) ] ]. (1 to: 5) collect: [ :run | [ 1 to: 1000 do: [ :ix | mediumDoc squeakToUtf8 ] ] timeToRun ]. "===> #(632 635 633 632 633)" (1 to: 5) collect: [ :run | [ 1 to: 1000 do: [ :ix | mediumDoc convertToWithConverter: UTF8TextConverter new ] ] timeToRun ]. "===> #(693 625 625 626 625)" (1 to: 5) collect: [ :run | [ 1 to: 1000 do: [ :ix | mediumDoc convertToEncoding: 'utf-8' ] ] timeToRun ]. "===> #(644 637 640 640 638)" So, for 7-bit ByteStrings (optionally with few 8-bit characters), it does make a difference to use #squeakToUtf8, for 8-bit ByteStrings and WideStrings it doesn't really matter. Levente > 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] Pharo-project Digest, Vol 28, Issue 282

by Eliot Miranda

Hi James, 2010/8/30 James Ladd <james_ladd(a)hotmail.com> > Hi Eliot, > > I cant use those thinks because im not in Smalltalk at the time, im in Java > on the JVM. > Ah, OK. Now I understand. > (Did someone say 'challenge') > > I thought about the store question in the shower this morning and I think > it means > take the top of the stack but dont pop it. Please let me know if Im wrong? > That's right. So... 140 10001100 kkkkkkkk jjjjjjjj Push Temp At kkkkkkkk In Temp Vector At: jjjjjjjj tempVector := activation localAt: kkkkkkkk. value := tempVector[jjjjjjjj]. activation push: value 141 10001101 kkkkkkkk jjjjjjjj Store Temp At kkkkkkkk In Temp Vector At: jjjjjjjj tempVector := activation localAt: kkkkkkkk. tempVector[jjjjjjjj] := activation stackTop. 142 10001110 kkkkkkkk jjjjjjjj Pop and Store Temp At kkkkkkkk In Temp Vector At: jjjjjjjj tempVector := activation localAt: kkkkkkkk. tempVector[jjjjjjjj] := activation stackTop. activation popStack. Clear? If so, I'd be very happy to improve my documentation based on your reading and my clarification. best, Eliot > Rgs, James. > > > Hi James, > > > > perhaps you could use the implementations of > > ContextPart pushRemoteTemp:inVectorAt: popIntoRemoteTemp:inVectorAt: > > storeIntoRemoteTemp:inVectorAt: > > (& Interpreter pushRemoteTemp:inVectorAt: popIntoRemoteTemp:inVectorAt: > if > > you have them to hand) as the spec and check the documentation. The > intent > > is that k..k is the index of the temp containing the remote vector and > j..j > > is the index in the remote temp vector. > > > > cheers > > Eliot > > > > > _______________________________________________ > 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 Levente Uzonyi

(sorry, pine can't quote your mail correctly...) On Mon, 30 Aug 2010, Miguel Enrique CobÃ¡ MartÃnez wrote: > El lun, 30-08-2010 a las 13:06 +0200, Levente Uzonyi escribiÃ³: > > 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." Maybe he'll be happy if you give your word that you won't fork it. "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. " Sometimes you have to ignore/fix contributions. For example: - ProcessWrapper on SqueakSource had 2 new package versions which totally broke the package. I asked the contributor why he did the changes, but I got no response in a few days, so I just removed the versions. - PostgresV3 had a contribution, someone fixed a bug. The fix was a simple one-liner, but ignored the (untold) fact that PostgresV3 is meant to be fast, therefore critical methods are optimized by hand. So I had to rewrite to keep up with our goal. "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)." I don't think the problem was that the package is part of PharoCore. I think the problem was that Andreas wasn't asked about the inclusion and the package was forked and maintained in PharoCore. Levente "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 _______________________________________________ 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] UbiquiTalk running in Pharo 1.1

by Sean P. DeNigris

I haven't done much with it, and there are some deprecation warnings, but it's running. In the attached screenshot, the "host 2" entry in the "Detected Hosts" window is the Squeak 4.1 image running on the right. http://forum.world.st/file/n2400767/Screen_shot_2010-08-30_at_August_30%2C_… Screen_shot_2010-08-30_at_August_30%2C_2010_5.47.42_PM.png Load it with: Gofer new squeaksource: 'KomHttpServer'; package: 'DynamicBindings'; load. Gofer new squeaksource: 'KomHttpServer'; package: 'KomServices'; load. Gofer new squeaksource: 'SPDProjectUpdates'; package: 'rST'; load. Gofer new squeaksource: 'OSProcess'; package: 'OSProcess'; load. Gofer new squeaksource: 'SPDProjectUpdates'; package: 'UbiquiTalk-Platform.pharo'; load. Gofer new squeaksource: 'SPDProjectUpdates'; package: 'UbiquiTalk-Cache'; load. Gofer new squeaksource: 'SPDProjectUpdates'; package: 'UbiquiTalk-GUI'; load. Gofer new squeaksource: 'SPDProjectUpdates'; package: 'UbiquiTalk-Utilities'; load. "requires Utilities" Gofer new squeaksource: 'SPDProjectUpdates'; package: 'UbiquiTalk-Kernel'; load. "requires Kernel" Gofer new squeaksource: 'SPDProjectUpdates'; package: 'UbiquiTalk-Plugins'; load. Gofer new squeaksource: 'SPDProjectUpdates'; package: 'UbiquiTalk-PDA'; load. Gofer new squeaksource: 'SPDProjectUpdates'; package: 'UbiquiTalk-Property Editors'; load. Gofer new squeaksource: 'SPDProjectUpdates'; package: 'UbiquiTalk-Tests'; load. "requires platform" Gofer new squeaksource: 'UbiquiTalk'; package: 'UTAllServices'; load. Sean -- View this message in context: http://forum.world.st/UbiquiTalk-running-in-Pharo-1-1-tp2400767p2400767.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 30, 2010

Re: [Pharo-project] Pharo-project Digest, Vol 28, Issue 282

by James Ladd

Hi Eliot, I cant use those thinks because im not in Smalltalk at the time, im in Java on the JVM. (Did someone say 'challenge') I thought about the store question in the shower this morning and I think it means take the top of the stack but dont pop it. Please let me know if Im wrong? Rgs, James. > Hi James, > > perhaps you could use the implementations of > ContextPart pushRemoteTemp:inVectorAt: popIntoRemoteTemp:inVectorAt: > storeIntoRemoteTemp:inVectorAt: > (& Interpreter pushRemoteTemp:inVectorAt: popIntoRemoteTemp:inVectorAt: if > you have them to hand) as the spec and check the documentation. The intent > is that k..k is the index of the temp containing the remote vector and j..j > is the index in the remote temp vector. > > cheers > Eliot >

Aug. 30, 2010

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

by Levente Uzonyi

On Mon, 30 Aug 2010, StÃ©phane Ducasse wrote: > This mailing-list is a public space. There are web archives all over the places and > people can post without been in it. I want to avoid personal emails exchange. > Now what should we run after him? Because the set up is like that no? > Because I'm extremely busy so nobody has the luxury not to be not busy still I spent > my morning trying to communicate. Just CC him. Levente > > > Stef > _______________________________________________ > 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

This mailing-list is a public space. There are web archives all over the places and people can post without been in it. I want to avoid personal emails exchange. Now what should we run after him? Because the set up is like that no? Because I'm extremely busy so nobody has the luxury not to be not busy still I spent my morning trying to communicate. Stef

Aug. 30, 2010

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

by Nicolas Cellier

2010/8/30 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > On Aug 30, 2010, at 9:57 PM, Nicolas Cellier wrote: > >> Hi Pharoers, >> I'm happy to read mail from Torsten, Igor and Miguel, thank you guys >> that's constructive. >> Andreas expressed his point very well, and i don't think it is >> hostile, maybe a bit sarcastic or disenchanted, but overall he keeps >> the door opened. >> The first thing to do is to cool down, relax and think. >> The second thing to do is engaging discussion with Andreas. >> >> Of course, the license is of prime importance, not having a license is >> a showstopper. >> If license is too restrictive then Andreas will probably fail to reach >> his goals... >> There will be de facto full rewrite rather than forks, but the net >> result will be the same: failure to share packages/libraries. > > why? > because if there is a rewrite it will be MIT. > >> That's why I personnally don't find Andreas defensive position a good strategy. >> Neither the attitude in response... >> It's like you're happy to throw his work away at first occasion >> without even trying to negociate. > > Oh no. I do not want that people bash us as people stealing work of other people. > Read my mail on webClient. > Sure, one thing is to remove WebClient and fulfill Andreas request. One other is to refuse to open discussion and engage a rewrite immediately. >> Bad vibrations. > > Writing all these mails is even more for me. > >> Before you engage in this (war)path, please, please, discuss. >> And remind this saying "il ne faut pas confondre vitesse et prÃ©cipitation". >> If no agreement is found then, ok, you'll get a license to carry on. > > > So far we talk in the desert. > Loading WebClient is one line. So this is as easy as to remove. > You don't have to shout in the desert. Just mail Andreas, he claimed not being informed. > >> After the license problem, there is the technical compatibility problem. >> Discussions about cross fork compatibility, compatibility layers or >> libraries (a la GREASE) will have to occur anyway, be it about Andreas >> library or from any other author. So you'll have to take time to >> discuss. Don't consider this as lost time. These discussions are >> considered necessary when they regularly happens in Pharo mailing >> list, aren't they ? It shouldn't be that hard to convince Andreas to >> change things like and:and:and:. For squeakToUtf8, I don't know, maybe >> provide some automated rewrite rules, and produce an automated Pharo >> version ? > > I already suggested that. Now there is an important point. Infrastructure code > should be supported, accessible to the community. We got burned with graphics > andreas' onwership in the past. And yes we learned from that. > The past is the past. Maybe there were clumsyness from both sides... I can't know. One thing is sure, without communication, no possible agreement. >> >> Please, discuss, argue, explain why you consider certain constructions >> as bad style. Propose alternatives (be constructive - remember >> coopetition ?). >> I consider being unable to explain one's own choice as a weakness. >> Don't be weak. >> Come-on guys, despite Levente's cutting remark, you're not inferior to >> squeakers ;) (and you don't have to answer to that stupid conclusion). > > I will let people decide as I did for the inclusion of webClient and we will rewrite one if > necessary and it will be MIT. This will be the same for the equivalent of SqueakSSL > we will try as much as possible to offer an infrastructure that let people control > their life and make money. > > Our goal is to have a core that could be bootstrap so to have many packages as external as possible > now I thought that it would help people to have webClient and also help us to remove this ugly network > package. > I should have know before the other HTTPClient library and we will not be here losing our time. > > Stef > Certainly, you don't have to convince me :). You might have to convince Andreas (I don't see him in copy). Maybe let another Pharoer negotiate... cheers Nicolas > > _______________________________________________ > 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