- Pharo-dev - lists.pharo.org

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

by StÃ©phane Ducasse

Originally I thought to shut up but today is the last days of summer holidays and I'm a positive thinking so let us try to help My suggestions: - put MIT now - accept other submissions even open the repositories to people that are cool (lukas, philippe, sven) - trust others! - have a look at HCHTTPClient and may be merge, migrate, - let pharo uses in it the image, we are not that dumb and with the merging capability and rss feed somebody can merge back really fast. Stef On Aug 31, 2010, at 8:38 AM, Andreas Raab wrote: > Hi - > > Thanks everyone for the reasoned and civil responses. It is good to see that we can have a disagreement without getting overly personal. Unfortunately, it seems that I'm effectively offered a no-win alternative here; I do not see how any of the discussed alternatives would help me achieve my goals. I will have to think about where to take things from here. If anyone has ideas, please let me know. > > Cheers, > - Andreas

Aug. 31, 2010

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

by Henrik Sperre Johansen

On 31.08.2010 08:47, StÃ©phane Ducasse wrote: >>> snip >>> >>>> Yeah, that's why I added the 200000 4KB docs / sec number. >>>> I really doubt the conversion will be a significant part of the processing time if what you send out is so small you are able to convert 800k messages per second... >>> It depends on the machine/load/etc. >> I feel like we already had this discussion over the cull: implementation, and I doubt either of us is going to change their mind, so let's stop here :) > > but cull: is in squeak now I think :) > I did not look carefully Yes, the discussion wasn't over its usefulness. Like now, it was whether the degree of optimization Levente presented was useful in any real scenarios :) Cheers, Henry

Aug. 31, 2010

Re: [Pharo-project] return character magic?

by StÃ©phane Ducasse

alchemist! Stef On Aug 31, 2010, at 1:20 AM, Nicolas Cellier wrote: > Henrik, you must be a kind of sorcerer or maybe a devil! > > Nicolas > > 2010/8/31 Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no>: >> On 30.08.2010 22:05, Nicolas Cellier wrote: >>> >>> 2010/8/30 StÃ©phane Ducasse<stephane.ducasse(a)inria.fr>: >>>> >>>> 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 :) >>>> >>> Any person able to understand MultiDisplayScanner arcanes wouldn't see >>> any magic in this. But I really wonder whether a single person can >>> manage such complexity... Henrik ? >>> >>> Nicolas >> >> Hurr durr, I hate a challenge, can't really stop... >> In Pharo, the display primitive fails, and the fallback code does not deal >> correctly with the characterToGlyphMap used by StrikeFonts to store arrows >> at the normal ^_ spots, and substitute with characters at slots 128/129. >> In Squeak, the glyph-by-glyph rendering is encountered, and neither >> hasGlyphOf: nor glyphInfoInto: takes the map into account >> Attached is the fixed code for all three methods, should work in both Pharo >> and Squeak with these. >> (Issue 2886 on the Pharo tracker) >> >> 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. 31, 2010

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

by Andreas Raab

On 8/30/2010 1:40 AM, 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). > Can you please clarify the license situation of those projects? The license situation is that the code that's there has not been made available with a specific license yet. I use that as a vehicle to allow people to check things out, to try stuff and to experiment with it while I'm developing the code and am not willing to give up control. If you feel you do need a license during that period (which is perfectly reasonable) you can always contact and ask me and I'll be more than happy to grant you a non-transferable license that restricts source redistribution but is otherwise completely free for your use (commercial or otherwise). The point isn't to keep people from trying things out, the point is to bring development to a point where I'm happy to release it in the chosen form to the general public. Cheers, - Andreas > On 30 Aug 2010, at 00:00, Andreas Raab wrote: > >> As you can see, when I mean to put code under the MIT license, I try to state that by including a copy of the license on the front page of the repository as well as setting the license field. Contrary to, for example, the following repositories: >> >> http://www.squeaksource.com/ar.html >> http://www.squeaksource.com/SqueakSSL.html >> http://www.squeaksource.com/WebClient.html >> >> which are not (or not yet) under MIT. Obviously, I'm trying to be as clear as possible on these matters, which is why I was pointing out that your repository incorrectly claims that the version of WebClient in it is LGPLv2. I'm surprised (and shocked) that apparently nobody in Pharo even tries to find out what the license status for WebClient is. > >

Aug. 31, 2010

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

by StÃ©phane Ducasse

>> snip >> >>> Yeah, that's why I added the 200000 4KB docs / sec number. >>> I really doubt the conversion will be a significant part of the processing time if what you send out is so small you are able to convert 800k messages per second... >> >> It depends on the machine/load/etc. > I feel like we already had this discussion over the cull: implementation, and I doubt either of us is going to change their mind, so let's stop here :) but cull: is in squeak now I think :) I did not look carefully >>> See the code I attached last mail, switching to convertToEncoding: 'utf8' sort of implied implementing something like that, which gives it nearly the same speed as convertToWithConverter: UTF8TextConverter new in your examples. >> >> Sorry, I didn't see that. It looks cool, but I still wouldn't use #convertToEncoding: in my code, because there's a similar looking method (#converToWithConverter:) with better performance :). > Sure, though I find it quite ugly, I wouldn't vehemently oppose using it either, but the issue here was finding something Andreas would accept :) >> But it's definitely better than the current version, though if a converter is added/changed/removed, the dictionary has to be updated manually. >> >> >> Levente > Yeah, the code was merely a proof of concept to show off that you could get acceptable (for some :P) performance using it, as a middleground between squeakToUtf8 and convertToWithConverter in terseness. > > 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. 31, 2010

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

by StÃ©phane Ducasse

don;t worry levente Nicolas was sensitive to the fact that you laugh because you consider that our process is close and that I have all the powers, which is false. We proposed in the past to Nicolas to help integrate changes but this is too boring in pharo so I do the dirty work and should work on making something simpler so that other can join if they want. BTW nicolas now we have menus and a lot more the rest (even automatic password settings) so a simple change is integrated in 2 min, merge and verification of the load in another image. so this is not bad. Stef On Aug 31, 2010, at 12:49 AM, Levente Uzonyi wrote: > On Mon, 30 Aug 2010, Nicolas Cellier wrote: > >> Hi Pharoers, > > snip > >> 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). > > Uh, what remark? > >> >> Nicolas >> > > snip > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 31, 2010

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

by StÃ©phane Ducasse

so now we understand why Pharo design is crap :) Sorry I could resist.... It would be nice if we were a bit more adults. What is strange is that some people catalyze communication problems (me included) but we should live with that. I added your bench to the issue too. Stef On Aug 31, 2010, at 12:34 AM, Levente Uzonyi wrote: > And another with "SmallDoc": > > smallDoc := ByteString new: 20 streamContents: [ :stream | > 20 timesRepeat: [ stream nextPut: (Character value: 128 atRandom - 1) ] ]. > (1 to: 5) collect: [ :run | > [ 1 to: 100000 do: [ :ix | > smallDoc squeakToUtf8 ] ] timeToRun ]. > "===> #(15 15 15 15 15)" > (1 to: 5) collect: [ :run | > [ 1 to: 100000 do: [ :ix | > smallDoc convertToWithConverter: UTF8TextConverter new ] ] timeToRun ]. > "===> #(34 34 34 35 32)" > (1 to: 5) collect: [ :run | > [ 1 to: 100000 do: [ :ix | > smallDoc convertToEncoding: 'utf-8' ] ] timeToRun ]. > "===> #(1256 1258 1259 1260 1260)" > > smallDoc := ByteString new: 20 streamContents: [ :stream | > 20 timesRepeat: [ stream nextPut: (Character value: 128 atRandom - 1) ] ]. > smallDoc at: 10 put: (Character value: 129). > (1 to: 5) collect: [ :run | > [ 1 to: 100000 do: [ :ix | > smallDoc squeakToUtf8 ] ] timeToRun ]. > "===> #(115 112 112 113 112)" > (1 to: 5) collect: [ :run | > [ 1 to: 100000 do: [ :ix | > smallDoc convertToWithConverter: UTF8TextConverter new ] ] timeToRun ]. > "===> #(157 125 124 126 125)" > (1 to: 5) collect: [ :run | > [ 1 to: 100000 do: [ :ix | > smallDoc convertToEncoding: 'utf-8' ] ] timeToRun ]. > "===> #(1416 1419 1419 1429 1428)"

Aug. 31, 2010

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

by StÃ©phane Ducasse

thanks added to http://code.google.com/p/pharo/issues/detail?id=2885 Stef On Aug 31, 2010, at 12:22 AM, Levente Uzonyi wrote: > > 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.

Aug. 31, 2010

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

by Andreas Raab

Hi - Thanks everyone for the reasoned and civil responses. It is good to see that we can have a disagreement without getting overly personal. Unfortunately, it seems that I'm effectively offered a no-win alternative here; I do not see how any of the discussed alternatives would help me achieve my goals. I will have to think about where to take things from here. If anyone has ideas, please let me know. Cheers, - Andreas On 8/30/2010 12: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. > > 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. > Bad vibrations. > > 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. > > 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 ? > > 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). > > Nicolas > > 2010/8/30 Mariano Martinez Peck<marianopeck(a)gmail.com>: >> >> >> 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 >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >

Aug. 31, 2010

[Pharo-project] What are you using to write reports?

by Friedrich Dominicus

I'm working slowly through Seaside, Aida, Pharo etc. I just wonder what you are using to make "usable" reports. (Be it in electronical form or printed). A related question, how does you interface e.g to let's say OpenOffice or maybe MS Office? Thanks for suggestions. Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

Aug. 31, 2010