- Pharo-dev - lists.pharo.org

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

by StÃ©phane Ducasse

A final point: I can understand that andreas does not want to get fork. I understand that he can think that we are stealing code. I think that this is fair to think that. Now as miguel mentioned about SPDF, the solution is in the process: one way to avoid fork is to be open to other changes and to get a real review process and some compromise. We should have contacted him publicly but we still have some communication problems :) This is a long period of time since we did not said any "vicious", I personally prefer positive energy and I'm ranting clean. Pharo is my red pil. :) Now I think that not putting license is not a solution that can scale but this is his choice. Stef

Aug. 30, 2010

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

by Torsten Bergmann

I agree with Andreas that the process for including packages in Pharo is not transparent (at least not me). Dont know the process for Squeak either - but at least we all should take care to keep the whole platform and forks open. Maybe the license should be a required field in Squeaksource for any new project. Havent followed the whole thread - but I still wonder what the reason for Andreas is to not release Webclient as MIT? Especially since I think it could be a nice addition to the standard images (Squeak, Pharo or whatever) ... Bye T. -- GMX DSL SOMMER-SPECIAL: Surf & Phone Flat 16.000 fÃ¼r nur 19,99 Â¿/mtl.!* http://portal.gmx.net/de/go/dsl

Aug. 30, 2010

Re: [Pharo-project] this style looks cool

by StÃ©phane Ducasse

Hi ja did you sign the license agreement? Just if you want your code to be in pharo: but may impression is that it would be a nice advertisement for your company the AnyMorphic style..... Stef On Aug 30, 2010, at 12:55 AM, ja(a)anymorphic.com wrote: > Tudor Girba <tudor.girba@...> writes: > > >> Is this Theme available? > > I can push the change monday morning. > ja > > > _______________________________________________ > 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] this style looks cool

by StÃ©phane Ducasse

people got excited :) On Aug 30, 2010, at 12:55 AM, ja(a)anymorphic.com wrote: > Tudor Girba <tudor.girba@...> writes: > > >> Is this Theme available? > > I can push the change monday morning. > ja > > > _______________________________________________ > 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

Hi pharoers What do you think? I think that we should not have any software parts whose license is not set clearly in Pharo. So I will remove WebClient from Pharo. I suggest that the people that want and know, group together and build an open-source one. Stef On Aug 30, 2010, at 12:00 AM, Andreas Raab wrote: > Hi Sven, > > [cc: pharo list since I think there are some larger issues to discuss] > > First of all thank you for your continued interest in WebClient. It is nice to see that people like to use it. However, I'm more than a bit surprised about what you are saying below about having WebClient in Pharo 1.2. Honestly, I was dumbfounded when I went to read some of the discussions on the Pharo list. > > May I ask what the due diligence process is for including packages in Pharo? I would have expected that the process includes 1) checking the project page on SS for the license and 2) sending the author a courtesy note along the lines of "hey we want to include your code, are you okay with that?" (in particular if the author of the package isn't on the Pharo list and consequently has no clue about what you're doing). > > 1. Regarding WebClient's license, please have a look at any of the following repositories, all of which are under MIT: > > http://www.squeaksource.com/Balloon3D.html > http://www.squeaksource.com/CroquetGL.html > http://www.squeaksource.com/ToolBuilder.html > http://www.squeaksource.com/TweakCore.html > ... etc ... > > 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. > > 2. Regarding my intentions / position you'll have to keep in mind that I don't read the Pharo list. I tried to follow it in the past only to be faced with several vicious attacks against Squeak and myself and as a consequence I stopped reading it. Consequently, this is the first time anyone has ever mentioned the inclusion of WebClient in Pharo to me. > > In short, my position is that we need more shared libraries, not more forks. You will probably see the irony that I specifically didn't set a license on WebClient to prevent such forks without any prior discussion (under the hopelessly naive assumption that there would be some sort of due diligence process) only to find out that you've forked WebClient already. How very ironic indeed. > > Because of my position above, I think WebClient should be an external package, loaded for example via Metacello configuration. In fact, that's exactly why I provided a Metacello configuration to begin with. Can someone perhaps explain where the urge to include (and consequently fork) WebClient comes from? WebClient is a perfectly good external package and for the time being I prefer it should stay that way. If you want to replace HTTPSocket, then have a look at Squeak 4.2 which contains a very simple HTTPSocket implementation that has hooks so that WebClient will be used if it's loaded. > > Regarding fixes for Pharo, as far as I know the only changes that I haven't included was a bunch of #asString sprinkled all over the places, and the abominations of replacing #squeakToUtf8 and #utf8ToSqueak with "convert[From|To]WithConverter: UTF8TextConverter new". On both of these issues I feel very strongly; I will not make the code substantially worse only to deal with shortcomings of Pharo. So if you cannot come to a reasonable resolution for these, you'll need the extension methods. Outside of that, I believe that not only have I integrated all the fixes that have been sent to me, I have also added several patches to WebClient-Pharo that provide important fixes for (in Pharo broken) network operations without which WebClient would not work in any released Pharo versions. > > Summary: > * I'm surprised and I'm shocked to see that there is apparently no due diligence regarding new packages in Pharo. I find this in particular shocking giving the wild claims on the Pharo web site that "From the beginning of Pharo we have maintained a strict rule that every contributor has to sign our license agreement." I haven't. (and geez, when did Michael got dropped from the Pharo board?) > > * I don't want WebClient to be included in Pharo since this means you will be producing a Pharo-only fork of WebClient which is counter-productive from my perspective. I want WebClient to remain a shared loadable package with a canonical source repository available to all forks of Squeak, including Pharo. > > * I have, and will continue to do so, integrate fixes for Pharo as long as I consider them reasonable. If there is interest, I can also provide an updated Metacello configuration; although that really just boils down to updating it to the latest package versions. > > Cheers, > - Andreas > > On 8/29/2010 4:43 AM, Sven Van Caekenberghe wrote: >> Andreas, >> >> The lastest fiddling that I did is now in PharoInBox: >> >> Name: WebClient-Core-SvenVanCaekenberghe.74 >> Author: SvenVanCaekenberghe >> Time: 27 August 2010, 1:59:46 pm >> UUID: d97ff218-9bde-4259-bf8a-f9d0fe116138 >> Ancestors: WebClient-Core-StephaneDucasse.73, WebClient-Core-pmm.73 >> >> merged in pharo-core 1.2 >> >> We're down to 2 unit test failures/errors againt your latest tests. >> >> A number of people including myself are interested, enthousiastic and willing to help bring WebClient to Pharo (1.1 and 1.2), and by using it, help it improve its core functionality. However, the current process, whereby you mostly ignore Pharo related fixes, makes that very difficult (we basically almost have to start over again with each commit you do, comparing changes becomes harder and harder). You can check the Pharo mailing lists. >> >> As I said before, it is your code and your decision what your standpoint is regarding portability (to Squeak derivatives and even other Smalltalks). I can understand it if you find it too much work. But I do think you should make it clear what your standpoint is. >> >> Regards, >> >> Sven >> >> On 29 Aug 2010, at 04:30, Andreas Raab wrote: >> >>> You're probably busy, so just a little "ping" :-) >>> >>> Cheers, >>> - Andreas >>> >>> -------- Original Message -------- >>> Subject: Re: WebClient-Core port to Pharo 1.1 final >>> Date: Wed, 25 Aug 2010 22:40:07 -0700 >>> From: Andreas Raab<andreas.raab(a)gmx.de> >>> To: Sven Van Caekenberghe<sven(a)beta9.be> >>> >>> Hi Sven, >>> >>> Sorry for the belated reply I think something is wrong with Thunderbird >>> 3's spam filter; it appears that messages with attachments get routinely >>> marked as spam or something. In any case a message on Squeak-dev just >>> got me to look for lost email and yours was among them :-) >>> >>> Do you know if these changes are still applicable? There have been >>> numerous changes in the meantime in WebClient and haven't been paying >>> much attention. >>> >>> Oh, and one more thing. When I went to the project page at >>> http://www.squeaksource.com/ADayAtTheBeach.html it claims that "Code >>> commited to this repository will be automatically under LGPLv2 license." >>> >>> Obviously, this is not true for WebClient; could I ask you to change the >>> declaration on your repository or move your versions to some other >>> repository? The way it is right now people might rightfully assume that >>> the WebClient versions in your repository are under LGPLv2 which is >>> simply incorrect. >>> >>> Thanks, >>> - Andreas >>> >>> On 8/12/2010 1:59 AM, Sven Van Caekenberghe wrote: >>>> Hi Andreas, >>>> >>>> I made some changes to the latest WebClient-Core in order to run it on Pharo 1.1: >>>> >>>> Sven Van Caekenberghe uploaded a new version of WebClient-Core to project A Day At The Beach: >>>> http://www.squeaksource.com/ADayAtTheBeach/WebClient-Core-SvenVanCaekenberg… >>>> >>>> ==================== Summary ==================== >>>> >>>> Name: WebClient-Core-SvenVanCaekenberghe.63 >>>> Author: SvenVanCaekenberghe >>>> Time: 12 August 2010, 10:46:11 am >>>> UUID: 149d44b2-138b-4d63-a158-f587b2bd391d >>>> Ancestors: WebClient-Core-ar.62 >>>> >>>> added some more #asString's where needed to deal with the different semantics of #, in Squeak vs Pharo; removed usage of #and:and:and:and: with a composition of #and: in WebClient>>connect >>>> >>>> ================================================ >>>> >>>> I still have some tests that fail, but I can't find the problem: >>>> >>>> >>>> >>>> >>>> >>>> >>>> 39 run, 34 passes, 0 expected failures, 0 failures, 5 errors, 0 unexpected passes >>>> Failures: >>>> >>>> Errors: >>>> WebClientServerTest>>#testMultipartFiles >>>> WebClientServerTest>>#testMultipartFiles2 >>>> WebClientServerTest>>#testServerError >>>> WebClientServerTest>>#testWebSockets >>>> WebClientServerTest>>#testWebSocketsFraming >>>> >>>> The #testServerError bothers me most. >>>> >>>> I am posting this to a Pharo list as well so that maybe others can help. >>>> Maybe I'll find the problems myself later on. >>>> >>>> Sven >>>> >>>> >>>> >> >> > > _______________________________________________ > 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 adi＠netstyle.ch

I fully agree with Stef. I don't remember why I assumed the license was MIT, maybe because on Andreas' blog it says: "we now have what I think is a pretty decent HTTP server and client implementation for Squeak 4.1". Isn't the missing license an issue for Squeak? Anyway, obviously its a no-go not only for Pharo but also for companies (like us at Cmsbox, who considered using WebClient in the future). Cheers, Adrian Zitat von StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi andreas > > 1- We talked a lot about Webclient used in the Pharo mailing-list and > we were stupid to think that you read it. Luckily you did it at last. > 2- I'm also surprised that nobody checked the license (me the first). > Shit happens even with the best attitude. We are paying attention to > contributor and > we learned something today. > 3- Philippe contacted you with fixes several times and got no reply, > sven too so people thought that you do not want to talk to them. > Apparently not > so this is good. > 4- We want to have a good web library in Pharo, so this will not > webclient. I do not believe that this is good to build any > software on libraries that have an unclear license. At least I would > not do it just to avoid to get trap in it. > 5- We will remove (by today) WebClient from Pharo. > 6- Pharoers will have to decide and probably to build an open one under MIT. > 6- Some people do not like that they cannot improve the code they see > and use daily. > 7- This is your right to criticize the code quality and design of > Pharo, there is no problem with that. We have another point of view > after the years we spent. Now they may be some little glitches and if > you have precise feedback we are open to hear them. > We are working working working and ... working on it and we are > improving everyday -- may be too slowly. > > Stef > > >> Hi Sven, >> >> [cc: pharo list since I think there are some larger issues to discuss] >> >> First of all thank you for your continued interest in WebClient. It >> is nice to see that people like to use it. However, I'm more than a >> bit surprised about what you are saying below about having WebClient >> in Pharo 1.2. Honestly, I was dumbfounded when I went to read some >> of the discussions on the Pharo list. >> >> May I ask what the due diligence process is for including packages >> in Pharo? I would have expected that the process includes 1) >> checking the project page on SS for the license and 2) sending the >> author a courtesy note along the lines of "hey we want to include >> your code, are you okay with that?" (in particular if the author of >> the package isn't on the Pharo list and consequently has no clue >> about what you're doing). >> >> 1. Regarding WebClient's license, please have a look at any of the >> following repositories, all of which are under MIT: >> >> http://www.squeaksource.com/Balloon3D.html >> http://www.squeaksource.com/CroquetGL.html >> http://www.squeaksource.com/ToolBuilder.html >> http://www.squeaksource.com/TweakCore.html >> ... etc ... >> >> 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. >> >> 2. Regarding my intentions / position you'll have to keep in mind >> that I don't read the Pharo list. I tried to follow it in the past >> only to be faced with several vicious attacks against Squeak and >> myself and as a consequence I stopped reading it. Consequently, this >> is the first time anyone has ever mentioned the inclusion of >> WebClient in Pharo to me. >> In short, my position is that we need more shared libraries, not >> more forks. You will probably see the irony that I specifically >> didn't set a license on WebClient to prevent such forks without any >> prior discussion (under the hopelessly naive assumption that there >> would be some sort of due diligence process) only to find out that >> you've forked WebClient already. How very ironic indeed. > >> Because of my position above, I think WebClient should be an >> external package, loaded for example via Metacello configuration. In >> fact, that's exactly why I provided a Metacello configuration to >> begin with. Can someone perhaps explain where the urge to include >> (and consequently fork) WebClient comes from? WebClient is a >> perfectly good external package and for the time being I prefer it >> should stay that way. If you want to replace HTTPSocket, then have a >> look at Squeak 4.2 which contains a very simple HTTPSocket >> implementation that has hooks so that WebClient will be used if it's >> loaded. >> >> Regarding fixes for Pharo, as far as I know the only changes that I >> haven't included was a bunch of #asString sprinkled all over the >> places, and the abominations of replacing #squeakToUtf8 and >> #utf8ToSqueak with "convert[From|To]WithConverter: UTF8TextConverter >> new". On both of these issues I feel very strongly; I will not make >> the code substantially worse only to deal with shortcomings of >> Pharo. So if you cannot come to a reasonable resolution for these, >> you'll need the extension methods. Outside of that, I believe that >> not only have I integrated all the fixes that have been sent to me, >> I have also added several patches to WebClient-Pharo that provide >> important fixes for (in Pharo broken) network operations without >> which WebClient would not work in any released Pharo versions. >> >> Summary: >> * I'm surprised and I'm shocked to see that there is apparently no >> due diligence regarding new packages in Pharo. I find this in >> particular shocking giving the wild claims on the Pharo web site >> that "From the beginning of Pharo we have maintained a strict rule >> that every contributor has to sign our license agreement." I >> haven't. (and geez, when did Michael got dropped from the Pharo >> board?) >> >> * I don't want WebClient to be included in Pharo since this means >> you will be producing a Pharo-only fork of WebClient which is >> counter-productive from my perspective. I want WebClient to remain a >> shared loadable package with a canonical source repository available >> to all forks of Squeak, including Pharo. >> >> * I have, and will continue to do so, integrate fixes for Pharo as >> long as I consider them reasonable. If there is interest, I can also >> provide an updated Metacello configuration; although that really >> just boils down to updating it to the latest package versions. >> >> Cheers, >> - Andreas >> >> On 8/29/2010 4:43 AM, Sven Van Caekenberghe wrote: >>> Andreas, >>> >>> The lastest fiddling that I did is now in PharoInBox: >>> >>> Name: WebClient-Core-SvenVanCaekenberghe.74 >>> Author: SvenVanCaekenberghe >>> Time: 27 August 2010, 1:59:46 pm >>> UUID: d97ff218-9bde-4259-bf8a-f9d0fe116138 >>> Ancestors: WebClient-Core-StephaneDucasse.73, WebClient-Core-pmm.73 >>> >>> merged in pharo-core 1.2 >>> >>> We're down to 2 unit test failures/errors againt your latest tests. >>> >>> A number of people including myself are interested, enthousiastic >>> and willing to help bring WebClient to Pharo (1.1 and 1.2), and by >>> using it, help it improve its core functionality. However, the >>> current process, whereby you mostly ignore Pharo related fixes, >>> makes that very difficult (we basically almost have to start over >>> again with each commit you do, comparing changes becomes harder and >>> harder). You can check the Pharo mailing lists. >>> >>> As I said before, it is your code and your decision what your >>> standpoint is regarding portability (to Squeak derivatives and even >>> other Smalltalks). I can understand it if you find it too much >>> work. But I do think you should make it clear what your standpoint >>> is. >>> >>> Regards, >>> >>> Sven >>> >>> On 29 Aug 2010, at 04:30, Andreas Raab wrote: >>> >>>> You're probably busy, so just a little "ping" :-) >>>> >>>> Cheers, >>>> - Andreas >>>> >>>> -------- Original Message -------- >>>> Subject: Re: WebClient-Core port to Pharo 1.1 final >>>> Date: Wed, 25 Aug 2010 22:40:07 -0700 >>>> From: Andreas Raab<andreas.raab(a)gmx.de> >>>> To: Sven Van Caekenberghe<sven(a)beta9.be> >>>> >>>> Hi Sven, >>>> >>>> Sorry for the belated reply I think something is wrong with Thunderbird >>>> 3's spam filter; it appears that messages with attachments get routinely >>>> marked as spam or something. In any case a message on Squeak-dev just >>>> got me to look for lost email and yours was among them :-) >>>> >>>> Do you know if these changes are still applicable? There have been >>>> numerous changes in the meantime in WebClient and haven't been paying >>>> much attention. >>>> >>>> Oh, and one more thing. When I went to the project page at >>>> http://www.squeaksource.com/ADayAtTheBeach.html it claims that "Code >>>> commited to this repository will be automatically under LGPLv2 license." >>>> >>>> Obviously, this is not true for WebClient; could I ask you to change the >>>> declaration on your repository or move your versions to some other >>>> repository? The way it is right now people might rightfully assume that >>>> the WebClient versions in your repository are under LGPLv2 which is >>>> simply incorrect. >>>> >>>> Thanks, >>>> - Andreas >>>> >>>> On 8/12/2010 1:59 AM, Sven Van Caekenberghe wrote: >>>>> Hi Andreas, >>>>> >>>>> I made some changes to the latest WebClient-Core in order to run >>>>> it on Pharo 1.1: >>>>> >>>>> Sven Van Caekenberghe uploaded a new version of WebClient-Core to >>>>> project A Day At The Beach: >>>>> http://www.squeaksource.com/ADayAtTheBeach/WebClient-Core-SvenVanCaekenberg… >>>>> >>>>> ==================== Summary ==================== >>>>> >>>>> Name: WebClient-Core-SvenVanCaekenberghe.63 >>>>> Author: SvenVanCaekenberghe >>>>> Time: 12 August 2010, 10:46:11 am >>>>> UUID: 149d44b2-138b-4d63-a158-f587b2bd391d >>>>> Ancestors: WebClient-Core-ar.62 >>>>> >>>>> added some more #asString's where needed to deal with the >>>>> different semantics of #, in Squeak vs Pharo; removed usage of >>>>> #and:and:and:and: with a composition of #and: in >>>>> WebClient>>connect >>>>> >>>>> ================================================ >>>>> >>>>> I still have some tests that fail, but I can't find the problem: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> 39 run, 34 passes, 0 expected failures, 0 failures, 5 errors, 0 >>>>> unexpected passes >>>>> Failures: >>>>> >>>>> Errors: >>>>> WebClientServerTest>>#testMultipartFiles >>>>> WebClientServerTest>>#testMultipartFiles2 >>>>> WebClientServerTest>>#testServerError >>>>> WebClientServerTest>>#testWebSockets >>>>> WebClientServerTest>>#testWebSocketsFraming >>>>> >>>>> The #testServerError bothers me most. >>>>> >>>>> I am posting this to a Pharo list as well so that maybe others can help. >>>>> Maybe I'll find the problems myself later on. >>>>> >>>>> Sven >>>>> >>>>> >>>>> >>> >>> >> >> _______________________________________________ >> 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] Poll: missing libraries to support business

by StÃ©phane Ducasse

On Aug 30, 2010, at 4:28 AM, Sudhakar Krishnamachari wrote: > > Good to see some of the concerns addressed. > > " > Now so far I do not see companies really putting effort so may be nothing will happen but this will not be > because of us. :)" > > > This is the chicken and egg situation. Bar highly motivated startups with some money in their pockets to splurge on with. The average co consists of average managers who want no risk..!. They want a technology they can blame for its shortcomings/ the support offered by another co if they are stuck for a fix. But in most ( I would say 90+% of timeline) cases the business continuity should not be affected. Sure this is clear. Now my point is pragmatic. > The average company will probably not invest their time on a technology if it does not meet the bar set by the current technology. Well lot of companies are using seaside and pharo and as such the fact that the infrastructure is getting better is important. > > Let me take Spring Architecture as an example in the Java world. J2EE was ( and to an extent is) entrenched in the world of Java enterprise. Way back about 8 yrs back or so .. Rod Johnson started his foray in to simplifying the complexity of J2EE with his framework. I would say through atleast 4+ yrs of the 8 he would have close to nil support from any company and like the Jim Collins "Good to Great" simile built up the giant wheel momentum now to engage nearly all known companies to use Spring all through instead of J2EE except in the niche cases. Its is an instruction to notice how Spring got interfaces to nearly all of Java connected that would be possibly needed for a medium enterprise case and then went into the depths/ specialization etc.. that is breadth first and then the depth. > > So I would say "WE" (including myself as a avowed Smaltalker) need to keep trying and pushing for a concerted go at getting Pharo up there.. and possibly the "GiantWheel momentum" will kick in with first a few co's and then more.. to push this rolling with god speed to its eventual greatness..!!.. welcome! > And that indeed is happening and its suprised me how far Pharo has already rolled and is building a momentum that is sure to go far if I can put my little effort as all others to get some of the minimal frameworks integrated. we need help > We have either of two approaches to take: meet up to the current bar set by Java/ .Net world in terms of programming baseline ( as I listed in the prior mail) or take a radical approach that differs so much and offers so much to pull in others..like Rails did. I would say if we are interested in the numbers game I would choose the former, if we wish to retain the intellectual high ground and move on the latter is fine.. we can have a vision, a vision without action does not exist. What we are doing are - providing robust infrastructure - making the system lean and clean - slowly rewriting parts now if people with other agendas want to focus on other parts we are more than happy. > > To get the numbers to have an interest in Pharo I will go back to my charter for Smalltalk spread in Universities / Colleges ( the underlying reason I started SmalltalkIndia) and see how far it can be resuscitated to create a mass base of users ( even if they are amateurs) and then hope a good percentage of them retain a greater interest to contribute spare time to improve the frameworks in Pharo. Would be great. Let me know how I can help Do you know I have free slides? http://stephane.ducasse.free.fr/Resources/LecturesInPowerpoint/ > ************************* > Just count how many smalltalkers we can get in a low cost centers who can code.. well > Contrast this with how many Java programmers you can get.. can manage with google/ info base available > > Count the external frameworks open source developed , tested and trustable to be used in production code from Java nearly all free. > Count the same for Smalltalk > > App servers.. comparable to Websphere/ weblogic/ Tomcat / lots of others, not to mention messaging queue, transaction control , JDBC like framework for nearly all DBs with high performance guaranteed, the list goes on.. > > The support logistics in terms CMS: viz SVN kinds, better integration / build systems like maven etc.. and evolutions in terms of frameworks that Java has spewed.. .Net in its Visual Studio et als.. > > Good brains together can counter all of the above arguments, but that is a limitation by itself, you cannot get good 25-50brains in one premises to work together on one single product, even if you do have them you cannot easily replace them with new recruits and be cost effective in general. > > From an ease of development and risk free managment angle, I find this an impossible proposition to convince any mgmt to take up Smalltalk for their dev. > > The target is the average developer, the risk averse corporate entity in all its evolution whether its .Net or Java. > > For all the reasons above, corporate use of ST is a difficult game for niche languages like Smalltalk, but a target I would like to see achieved in the near term.. > > ********************************* > > -Skrish > > > On Sun, Aug 29, 2010 at 8:32 PM, Sudhakar Krishnamachari <skrishnamachari(a)gmail.com> wrote: > My two cents long time in my blog on exactly the same subject: > > -Skrish > > > > _______________________________________________ > 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

Sven and philippe I was wondering what was the license of your submissions to webClient. Because this will be also a problem. Either you totally give it to andreas and he can do what he wants with it, or you retain the right on the code and andreas has to decide what he will do with it. Since you can change the license of your code I imagine that andreas will not include any code if the code is not given to him. Funny situation. I think that it is even more confusing than with the old Squeak-L. Stef On Aug 30, 2010, at 12:00 AM, Andreas Raab wrote: > Hi Sven, > > [cc: pharo list since I think there are some larger issues to discuss] > > First of all thank you for your continued interest in WebClient. It is nice to see that people like to use it. However, I'm more than a bit surprised about what you are saying below about having WebClient in Pharo 1.2. Honestly, I was dumbfounded when I went to read some of the discussions on the Pharo list. > > May I ask what the due diligence process is for including packages in Pharo? I would have expected that the process includes 1) checking the project page on SS for the license and 2) sending the author a courtesy note along the lines of "hey we want to include your code, are you okay with that?" (in particular if the author of the package isn't on the Pharo list and consequently has no clue about what you're doing). > > 1. Regarding WebClient's license, please have a look at any of the following repositories, all of which are under MIT: > > http://www.squeaksource.com/Balloon3D.html > http://www.squeaksource.com/CroquetGL.html > http://www.squeaksource.com/ToolBuilder.html > http://www.squeaksource.com/TweakCore.html > ... etc ... > > 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. > > 2. Regarding my intentions / position you'll have to keep in mind that I don't read the Pharo list. I tried to follow it in the past only to be faced with several vicious attacks against Squeak and myself and as a consequence I stopped reading it. Consequently, this is the first time anyone has ever mentioned the inclusion of WebClient in Pharo to me. > > In short, my position is that we need more shared libraries, not more forks. You will probably see the irony that I specifically didn't set a license on WebClient to prevent such forks without any prior discussion (under the hopelessly naive assumption that there would be some sort of due diligence process) only to find out that you've forked WebClient already. How very ironic indeed. > > Because of my position above, I think WebClient should be an external package, loaded for example via Metacello configuration. In fact, that's exactly why I provided a Metacello configuration to begin with. Can someone perhaps explain where the urge to include (and consequently fork) WebClient comes from? WebClient is a perfectly good external package and for the time being I prefer it should stay that way. If you want to replace HTTPSocket, then have a look at Squeak 4.2 which contains a very simple HTTPSocket implementation that has hooks so that WebClient will be used if it's loaded. > > Regarding fixes for Pharo, as far as I know the only changes that I haven't included was a bunch of #asString sprinkled all over the places, and the abominations of replacing #squeakToUtf8 and #utf8ToSqueak with "convert[From|To]WithConverter: UTF8TextConverter new". On both of these issues I feel very strongly; I will not make the code substantially worse only to deal with shortcomings of Pharo. So if you cannot come to a reasonable resolution for these, you'll need the extension methods. Outside of that, I believe that not only have I integrated all the fixes that have been sent to me, I have also added several patches to WebClient-Pharo that provide important fixes for (in Pharo broken) network operations without which WebClient would not work in any released Pharo versions. > > Summary: > * I'm surprised and I'm shocked to see that there is apparently no due diligence regarding new packages in Pharo. I find this in particular shocking giving the wild claims on the Pharo web site that "From the beginning of Pharo we have maintained a strict rule that every contributor has to sign our license agreement." I haven't. (and geez, when did Michael got dropped from the Pharo board?) > > * I don't want WebClient to be included in Pharo since this means you will be producing a Pharo-only fork of WebClient which is counter-productive from my perspective. I want WebClient to remain a shared loadable package with a canonical source repository available to all forks of Squeak, including Pharo. > > * I have, and will continue to do so, integrate fixes for Pharo as long as I consider them reasonable. If there is interest, I can also provide an updated Metacello configuration; although that really just boils down to updating it to the latest package versions. > > Cheers, > - Andreas > > On 8/29/2010 4:43 AM, Sven Van Caekenberghe wrote: >> Andreas, >> >> The lastest fiddling that I did is now in PharoInBox: >> >> Name: WebClient-Core-SvenVanCaekenberghe.74 >> Author: SvenVanCaekenberghe >> Time: 27 August 2010, 1:59:46 pm >> UUID: d97ff218-9bde-4259-bf8a-f9d0fe116138 >> Ancestors: WebClient-Core-StephaneDucasse.73, WebClient-Core-pmm.73 >> >> merged in pharo-core 1.2 >> >> We're down to 2 unit test failures/errors againt your latest tests. >> >> A number of people including myself are interested, enthousiastic and willing to help bring WebClient to Pharo (1.1 and 1.2), and by using it, help it improve its core functionality. However, the current process, whereby you mostly ignore Pharo related fixes, makes that very difficult (we basically almost have to start over again with each commit you do, comparing changes becomes harder and harder). You can check the Pharo mailing lists. >> >> As I said before, it is your code and your decision what your standpoint is regarding portability (to Squeak derivatives and even other Smalltalks). I can understand it if you find it too much work. But I do think you should make it clear what your standpoint is. >> >> Regards, >> >> Sven >> >> On 29 Aug 2010, at 04:30, Andreas Raab wrote: >> >>> You're probably busy, so just a little "ping" :-) >>> >>> Cheers, >>> - Andreas >>> >>> -------- Original Message -------- >>> Subject: Re: WebClient-Core port to Pharo 1.1 final >>> Date: Wed, 25 Aug 2010 22:40:07 -0700 >>> From: Andreas Raab<andreas.raab(a)gmx.de> >>> To: Sven Van Caekenberghe<sven(a)beta9.be> >>> >>> Hi Sven, >>> >>> Sorry for the belated reply I think something is wrong with Thunderbird >>> 3's spam filter; it appears that messages with attachments get routinely >>> marked as spam or something. In any case a message on Squeak-dev just >>> got me to look for lost email and yours was among them :-) >>> >>> Do you know if these changes are still applicable? There have been >>> numerous changes in the meantime in WebClient and haven't been paying >>> much attention. >>> >>> Oh, and one more thing. When I went to the project page at >>> http://www.squeaksource.com/ADayAtTheBeach.html it claims that "Code >>> commited to this repository will be automatically under LGPLv2 license." >>> >>> Obviously, this is not true for WebClient; could I ask you to change the >>> declaration on your repository or move your versions to some other >>> repository? The way it is right now people might rightfully assume that >>> the WebClient versions in your repository are under LGPLv2 which is >>> simply incorrect. >>> >>> Thanks, >>> - Andreas >>> >>> On 8/12/2010 1:59 AM, Sven Van Caekenberghe wrote: >>>> Hi Andreas, >>>> >>>> I made some changes to the latest WebClient-Core in order to run it on Pharo 1.1: >>>> >>>> Sven Van Caekenberghe uploaded a new version of WebClient-Core to project A Day At The Beach: >>>> http://www.squeaksource.com/ADayAtTheBeach/WebClient-Core-SvenVanCaekenberg… >>>> >>>> ==================== Summary ==================== >>>> >>>> Name: WebClient-Core-SvenVanCaekenberghe.63 >>>> Author: SvenVanCaekenberghe >>>> Time: 12 August 2010, 10:46:11 am >>>> UUID: 149d44b2-138b-4d63-a158-f587b2bd391d >>>> Ancestors: WebClient-Core-ar.62 >>>> >>>> added some more #asString's where needed to deal with the different semantics of #, in Squeak vs Pharo; removed usage of #and:and:and:and: with a composition of #and: in WebClient>>connect >>>> >>>> ================================================ >>>> >>>> I still have some tests that fail, but I can't find the problem: >>>> >>>> >>>> >>>> >>>> >>>> >>>> 39 run, 34 passes, 0 expected failures, 0 failures, 5 errors, 0 unexpected passes >>>> Failures: >>>> >>>> Errors: >>>> WebClientServerTest>>#testMultipartFiles >>>> WebClientServerTest>>#testMultipartFiles2 >>>> WebClientServerTest>>#testServerError >>>> WebClientServerTest>>#testWebSockets >>>> WebClientServerTest>>#testWebSocketsFraming >>>> >>>> The #testServerError bothers me most. >>>> >>>> I am posting this to a Pharo list as well so that maybe others can help. >>>> Maybe I'll find the problems myself later on. >>>> >>>> Sven >>>> >>>> >>>> >> >> > > _______________________________________________ > 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

Hi andreas 1- We talked a lot about Webclient used in the Pharo mailing-list and we were stupid to think that you read it. Luckily you did it at last. 2- I'm also surprised that nobody checked the license (me the first). Shit happens even with the best attitude. We are paying attention to contributor and we learned something today. 3- Philippe contacted you with fixes several times and got no reply, sven too so people thought that you do not want to talk to them. Apparently not so this is good. 4- We want to have a good web library in Pharo, so this will not webclient. I do not believe that this is good to build any software on libraries that have an unclear license. At least I would not do it just to avoid to get trap in it. 5- We will remove (by today) WebClient from Pharo. 6- Pharoers will have to decide and probably to build an open one under MIT. 6- Some people do not like that they cannot improve the code they see and use daily. 7- This is your right to criticize the code quality and design of Pharo, there is no problem with that. We have another point of view after the years we spent. Now they may be some little glitches and if you have precise feedback we are open to hear them. We are working working working and ... working on it and we are improving everyday -- may be too slowly. Stef > Hi Sven, > > [cc: pharo list since I think there are some larger issues to discuss] > > First of all thank you for your continued interest in WebClient. It is nice to see that people like to use it. However, I'm more than a bit surprised about what you are saying below about having WebClient in Pharo 1.2. Honestly, I was dumbfounded when I went to read some of the discussions on the Pharo list. > > May I ask what the due diligence process is for including packages in Pharo? I would have expected that the process includes 1) checking the project page on SS for the license and 2) sending the author a courtesy note along the lines of "hey we want to include your code, are you okay with that?" (in particular if the author of the package isn't on the Pharo list and consequently has no clue about what you're doing). > > 1. Regarding WebClient's license, please have a look at any of the following repositories, all of which are under MIT: > > http://www.squeaksource.com/Balloon3D.html > http://www.squeaksource.com/CroquetGL.html > http://www.squeaksource.com/ToolBuilder.html > http://www.squeaksource.com/TweakCore.html > ... etc ... > > 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. > > 2. Regarding my intentions / position you'll have to keep in mind that I don't read the Pharo list. I tried to follow it in the past only to be faced with several vicious attacks against Squeak and myself and as a consequence I stopped reading it. Consequently, this is the first time anyone has ever mentioned the inclusion of WebClient in Pharo to me. > In short, my position is that we need more shared libraries, not more forks. You will probably see the irony that I specifically didn't set a license on WebClient to prevent such forks without any prior discussion (under the hopelessly naive assumption that there would be some sort of due diligence process) only to find out that you've forked WebClient already. How very ironic indeed. > Because of my position above, I think WebClient should be an external package, loaded for example via Metacello configuration. In fact, that's exactly why I provided a Metacello configuration to begin with. Can someone perhaps explain where the urge to include (and consequently fork) WebClient comes from? WebClient is a perfectly good external package and for the time being I prefer it should stay that way. If you want to replace HTTPSocket, then have a look at Squeak 4.2 which contains a very simple HTTPSocket implementation that has hooks so that WebClient will be used if it's loaded. > > Regarding fixes for Pharo, as far as I know the only changes that I haven't included was a bunch of #asString sprinkled all over the places, and the abominations of replacing #squeakToUtf8 and #utf8ToSqueak with "convert[From|To]WithConverter: UTF8TextConverter new". On both of these issues I feel very strongly; I will not make the code substantially worse only to deal with shortcomings of Pharo. So if you cannot come to a reasonable resolution for these, you'll need the extension methods. Outside of that, I believe that not only have I integrated all the fixes that have been sent to me, I have also added several patches to WebClient-Pharo that provide important fixes for (in Pharo broken) network operations without which WebClient would not work in any released Pharo versions. > > Summary: > * I'm surprised and I'm shocked to see that there is apparently no due diligence regarding new packages in Pharo. I find this in particular shocking giving the wild claims on the Pharo web site that "From the beginning of Pharo we have maintained a strict rule that every contributor has to sign our license agreement." I haven't. (and geez, when did Michael got dropped from the Pharo board?) > > * I don't want WebClient to be included in Pharo since this means you will be producing a Pharo-only fork of WebClient which is counter-productive from my perspective. I want WebClient to remain a shared loadable package with a canonical source repository available to all forks of Squeak, including Pharo. > > * I have, and will continue to do so, integrate fixes for Pharo as long as I consider them reasonable. If there is interest, I can also provide an updated Metacello configuration; although that really just boils down to updating it to the latest package versions. > > Cheers, > - Andreas > > On 8/29/2010 4:43 AM, Sven Van Caekenberghe wrote: >> Andreas, >> >> The lastest fiddling that I did is now in PharoInBox: >> >> Name: WebClient-Core-SvenVanCaekenberghe.74 >> Author: SvenVanCaekenberghe >> Time: 27 August 2010, 1:59:46 pm >> UUID: d97ff218-9bde-4259-bf8a-f9d0fe116138 >> Ancestors: WebClient-Core-StephaneDucasse.73, WebClient-Core-pmm.73 >> >> merged in pharo-core 1.2 >> >> We're down to 2 unit test failures/errors againt your latest tests. >> >> A number of people including myself are interested, enthousiastic and willing to help bring WebClient to Pharo (1.1 and 1.2), and by using it, help it improve its core functionality. However, the current process, whereby you mostly ignore Pharo related fixes, makes that very difficult (we basically almost have to start over again with each commit you do, comparing changes becomes harder and harder). You can check the Pharo mailing lists. >> >> As I said before, it is your code and your decision what your standpoint is regarding portability (to Squeak derivatives and even other Smalltalks). I can understand it if you find it too much work. But I do think you should make it clear what your standpoint is. >> >> Regards, >> >> Sven >> >> On 29 Aug 2010, at 04:30, Andreas Raab wrote: >> >>> You're probably busy, so just a little "ping" :-) >>> >>> Cheers, >>> - Andreas >>> >>> -------- Original Message -------- >>> Subject: Re: WebClient-Core port to Pharo 1.1 final >>> Date: Wed, 25 Aug 2010 22:40:07 -0700 >>> From: Andreas Raab<andreas.raab(a)gmx.de> >>> To: Sven Van Caekenberghe<sven(a)beta9.be> >>> >>> Hi Sven, >>> >>> Sorry for the belated reply I think something is wrong with Thunderbird >>> 3's spam filter; it appears that messages with attachments get routinely >>> marked as spam or something. In any case a message on Squeak-dev just >>> got me to look for lost email and yours was among them :-) >>> >>> Do you know if these changes are still applicable? There have been >>> numerous changes in the meantime in WebClient and haven't been paying >>> much attention. >>> >>> Oh, and one more thing. When I went to the project page at >>> http://www.squeaksource.com/ADayAtTheBeach.html it claims that "Code >>> commited to this repository will be automatically under LGPLv2 license." >>> >>> Obviously, this is not true for WebClient; could I ask you to change the >>> declaration on your repository or move your versions to some other >>> repository? The way it is right now people might rightfully assume that >>> the WebClient versions in your repository are under LGPLv2 which is >>> simply incorrect. >>> >>> Thanks, >>> - Andreas >>> >>> On 8/12/2010 1:59 AM, Sven Van Caekenberghe wrote: >>>> Hi Andreas, >>>> >>>> I made some changes to the latest WebClient-Core in order to run it on Pharo 1.1: >>>> >>>> Sven Van Caekenberghe uploaded a new version of WebClient-Core to project A Day At The Beach: >>>> http://www.squeaksource.com/ADayAtTheBeach/WebClient-Core-SvenVanCaekenberg… >>>> >>>> ==================== Summary ==================== >>>> >>>> Name: WebClient-Core-SvenVanCaekenberghe.63 >>>> Author: SvenVanCaekenberghe >>>> Time: 12 August 2010, 10:46:11 am >>>> UUID: 149d44b2-138b-4d63-a158-f587b2bd391d >>>> Ancestors: WebClient-Core-ar.62 >>>> >>>> added some more #asString's where needed to deal with the different semantics of #, in Squeak vs Pharo; removed usage of #and:and:and:and: with a composition of #and: in WebClient>>connect >>>> >>>> ================================================ >>>> >>>> I still have some tests that fail, but I can't find the problem: >>>> >>>> >>>> >>>> >>>> >>>> >>>> 39 run, 34 passes, 0 expected failures, 0 failures, 5 errors, 0 unexpected passes >>>> Failures: >>>> >>>> Errors: >>>> WebClientServerTest>>#testMultipartFiles >>>> WebClientServerTest>>#testMultipartFiles2 >>>> WebClientServerTest>>#testServerError >>>> WebClientServerTest>>#testWebSockets >>>> WebClientServerTest>>#testWebSocketsFraming >>>> >>>> The #testServerError bothers me most. >>>> >>>> I am posting this to a Pharo list as well so that maybe others can help. >>>> Maybe I'll find the problems myself later on. >>>> >>>> Sven >>>> >>>> >>>> >> >> > > _______________________________________________ > 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] New bytecodes not in blue book ... (Eliot Miranda)

by Eliot Miranda

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 2010/8/29 James Ladd <james_ladd(a)hotmail.com> > Thanks Eliot. Your linked article clears it up: > http://www.mirandabanda.org/cogblog/2008/07/22/closures-part-ii-the-bytecod… > > 140 10001100 kkkkkkkk jjjjjjjj Push Temp At > kkkkkkkk In Temp Vector At: jjjjjjjj This fetches the local at offset j..j > on the stack and push the k..kâth element in it. > The next two store into the k..kâth element of the local at j..j, one > version popping the result off the stack. This is a general convention in > the Smalltalk-80 compiler. These are store and store-pop forms of almost > every store opcode. The store form is used in the stores into vat and vax in > things like > var := vat := vax := expr > whereas the pop form gets used in the store into var. > 141 10001101 kkkkkkkk jjjjjjjj Store Temp > At kkkkkkkk In Temp Vector At: jjjjjjjj > 142 10001110 kkkkkkkk jjjjjjjj Pop and > Store Temp At kkkkkkkk In Temp Vector At: jjjjjjjj > The final bytecode is more interesting. > > The wording is unclear to me: "This fetches the local at offset j..j on the > stack and push the k..kâth element in it." > > Does it mean, get local at index j..j and push onto the stack the k..k'th > element in it? > > So > > 109 <8C 00 01> pushTemp: 0 inVectorAt: 1 > > Get temp at 1 (j..j) and push element at 0 (k..k) ?? > > 97 <8E 00 01> popIntoTemp: 0 inVectorAt: 1 > > get vector at temp index 1 (j..j) and pop and store stack value into element 0 (k..k) ?? > > 116 <8D 00 01> storeIntoTemp: 0 inVectorAt: 1 > > I dont understand this one, store what? into element 0 of vector at 1 ?? > > In the pop variation I can understand where the value is coming from, but not the above > form. Please can you clarify? > > Rgs, James. > > > > > > > _______________________________________________ > 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