Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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@gmx.de> To: Sven Van Caekenberghe<sven@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-SvenVanCaekenbergh...
==================== 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
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@gmx.de> To: Sven Van Caekenberghe<sven@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-SvenVanCaekenbergh...
==================== 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@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@gmx.de> To: Sven Van Caekenberghe<sven@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-SvenVanCaekenbergh...
==================== 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Adrian Same for squeakSSL. :) Stef On Aug 30, 2010, at 10:03 AM, adi@netstyle.ch wrote:
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@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@gmx.de> To: Sven Van Caekenberghe<sven@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-SvenVanCaekenbergh...
==================== 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
---- On Mon, 30 Aug 2010 00:24:37 -0700 Stéphane Ducasse wrote ----
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.
Andreas was having mail issues. A few days ago I emailed him a small WebClient package after discussing a feature with him on Squeak-Dev. I left a note on the mailing list telling him about it, and he replied saying that he never got it. I sent it again, and he informed me after doing some digging that it and other emails bearing attachments had gotten caught in his spam filter. If you don't get a response from him, send your email again or leave a message on Squeak-Dev. Andreas has shown a great willingness to cooperate and accept patches to make WebClient cross-compatible with Pharo.
ok On Aug 30, 2010, at 12:01 PM, jaayer wrote:
---- On Mon, 30 Aug 2010 00:24:37 -0700 Stéphane Ducasse wrote ----
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.
Andreas was having mail issues. A few days ago I emailed him a small WebClient package after discussing a feature with him on Squeak-Dev. I left a note on the mailing list telling him about it, and he replied saying that he never got it. I sent it again, and he informed me after doing some digging that it and other emails bearing attachments had gotten caught in his spam filter.
If you don't get a response from him, send your email again or leave a message on Squeak-Dev. Andreas has shown a great willingness to cooperate and accept patches to make WebClient cross-compatible with Pharo.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@gmx.de> To: Sven Van Caekenberghe<sven@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-SvenVanCaekenbergh...
==================== 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@gmx.de> To: Sven Van Caekenberghe<sven@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-SvenVanCaekenbergh...
==================== 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mon, Aug 30, 2010 at 10:12 AM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
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.
It can still be maintained as an external package and it seems it's Andreas intent. Anyway, WebClient must have a licence. No licence means nobody can use it (even Squeak). So I would like to know the licence before any decision. PS: I don't understand the '(code) forks are evil' statement, I think it encourages "project forks" and closes contribution. This currently happens it seems. Reminds me the squeak-vm on github thread ..... Laurent 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@gmx.de> To: Sven Van Caekenberghe<sven@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-SvenVanCaekenbergh...
==================== 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mon, 30 Aug 2010, Stéphane Ducasse wrote:
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.
Why do you have to have your "own" library? What's wrong with one that could be shared by all Squeak forks? Levente
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@gmx.de> To: Sven Van Caekenberghe<sven@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-SvenVanCaekenbergh...
==================== 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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". This is not our own library, this is a library we can contribute, control.... We do not want to be in the situation that somebody can change the license under our feet. We want a library where people can participate. Now Pharoers will decide, I think that we do not have problem with sharing on WebClient. I can understand that people do not like that they cannot improve an infrastructure that they will rely upon. We do not want string to number conversion, and rely on squeakToUtf. Now I was not even aware of the ConfigurationOfWebClient. There is none in the squeaksource repository. So how can we guess? I'm not reading squeak-dev and no idea that there is even somebody using metacello.
What's wrong with one that could be shared by all Squeak forks?
We do not have problem with sharing. You can take anything you like from Pharo. Seaside, Magritte, Pier, RB,.... are all MIT OB is MIT and lukas pushed it a lot recently for everybody. Moose is BSD, MIT, Glamour, Mondrian MIT ... and I'm sure that they are more. :) they are all external projects. We discussed on the mailing-list what to do and people thought that it would be good to get in included it. Probably we missed the point that we just need SocketStream to load the rest. I'm dull but learning everyday. For me I just cannot stand HTTPSocket and the network package so anything is better. But may be it was a mistake. Note that I hope that squeakers will not bash us as the guys that want to play it alone because this is not the case, but people can bash us if this helps them to feel good. Pharo is there for that too ;D. WebClient was the perfect case for sharing but Andreas decided differently. Now - since the license is unclear - since the license of the contributors is unclear we will not use it as an infrastructural assets for Pharo. I imagine that Seaside will not use it either. Stef
Levente
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@gmx.de> To: Sven Van Caekenberghe<sven@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-SvenVanCaekenbergh...
==================== 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mon, 30 Aug 2010, Stéphane Ducasse wrote:
I suggest that the people that want and know, group together and build an open-source one.
Why do you have to have your "own" library?
Did I say "pharo library"? reread carefully I said an "open-source one".
What I get from Andreas' words is that he's willing to make it open source if it won't be forked.
This is not our own library, this is a library we can contribute, control....
You can contribute to WebClient, but you don't have full control, just like any external packages.
We do not want to be in the situation that somebody can change the license under our feet. We want a library where people can participate. Now Pharoers will decide, I think that we do not have problem with sharing on WebClient. I can understand that people do not like that they cannot improve an infrastructure that they will rely upon. We do not want string to number conversion, and rely on squeakToUtf.
I think Andreas solved these issues with the WebClient-Pharo package, but I may be wrong.
Now I was not even aware of the ConfigurationOfWebClient. There is none in the squeaksource repository.
It's in MetacelloRepository.
So how can we guess? I'm not reading squeak-dev and no idea that there is even somebody using metacello.
Well, Squeak users also use Metacello. Dale is kind enough to maintain Metacello configurations for Squeak too.
What's wrong with one that could be shared by all Squeak forks?
We do not have problem with sharing. You can take anything you like from Pharo.
Seaside, Magritte, Pier, RB,.... are all MIT OB is MIT and lukas pushed it a lot recently for everybody. Moose is BSD, MIT, Glamour, Mondrian MIT ... and I'm sure that they are more. :) they are all external projects.
We discussed on the mailing-list what to do and people thought that it would be good to get in included it. Probably we missed the point that we just need SocketStream to load the rest. I'm dull but learning everyday. For me I just cannot stand HTTPSocket and the network package so anything is better.
But may be it was a mistake. Note that I hope that squeakers will not bash us as the guys that want to play it alone because this is not the case, but people can bash us if this helps them to feel good. Pharo is there for that too ;D. WebClient was the perfect case for sharing but Andreas decided differently.
I think he didn't decide yet, but prove me wrong.
Now - since the license is unclear - since the license of the contributors is unclear we will not use it as an infrastructural assets for Pharo. I imagine that Seaside will not use it either.
Well, we are about to use it for Seaside. It scales a lot better than Kom. Cog can't really speed up Kom (based on our benchmarks done with JMeter)*, probably because of the heavy use of notifications (DynamicBindings), but it can boost WebClient significantly. Levente *The benchmark is done with 50 concurrent "users", clicking the counter example as fast as they can: Label Throughput (kB/s) Average response time (ms) Squeak-Kom 69.53 690 Squeak-WebClient 105.46 447 Cog-Squeak-Kom 74.54 617 Cog-Squeak-WebClient 226.80 193 I didn't include the Pharo results, because when we did the benchmark, there was no Cog support for Pharo. The max response time for Cog-Squeak-WebClient (575ms) was less than the average of Cog-Squeak-Kom.
Stef
Levente
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@gmx.de> To: Sven Van Caekenberghe<sven@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-SvenVanCaekenbergh...
==================== 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
We want a library where people can participate. Now Pharoers will decide, I think that we do not have problem with sharing on WebClient. I can understand that people do not like that they cannot improve an infrastructure that they will rely upon. We do not want string to number conversion, and rely on squeakToUtf.
I think Andreas solved these issues with the WebClient-Pharo package, but I may be wrong.
What WebClient-Pharo does is to patch (and break) Pharo in the most absurd ways to make it ill-behaved like Squeak. For example, check out the implementation of String>>#,. Philippe (an expert in writing platform independent code) and Sven have fixed all these issues so that the code works flawlessly on both platforms, Squeak and Pharo.
Well, we are about to use it for Seaside. It scales a lot better than Kom. Cog can't really speed up Kom (based on our benchmarks done with JMeter)*, probably because of the heavy use of notifications (DynamicBindings), but it can boost WebClient significantly.
Kom is not ideal, we all know that (thanks for sharing the benchmarks). However, the current licensing situation of WebClient makes it totally useless for me and presumably many other people. Luckily there are many other options. Lukas -- Lukas Renggli www.lukas-renggli.ch
On Mon, 30 Aug 2010, Lukas Renggli wrote:
We want a library where people can participate. Now Pharoers will decide, I think that we do not have problem with sharing on WebClient. I can understand that people do not like that they cannot improve an infrastructure that they will rely upon. We do not want string to number conversion, and rely on squeakToUtf.
I think Andreas solved these issues with the WebClient-Pharo package, but I may be wrong.
What WebClient-Pharo does is to patch (and break) Pharo in the most absurd ways to make it ill-behaved like Squeak. For example, check out the implementation of String>>#,.
I don't like "magical typecasts", but you (the community) should discuss it with the author (Andreas) before forking the package.
Philippe (an expert in writing platform independent code) and Sven have fixed all these issues so that the code works flawlessly on both platforms, Squeak and Pharo.
Cool. Levente
Well, we are about to use it for Seaside. It scales a lot better than Kom. Cog can't really speed up Kom (based on our benchmarks done with JMeter)*, probably because of the heavy use of notifications (DynamicBindings), but it can boost WebClient significantly.
Kom is not ideal, we all know that (thanks for sharing the benchmarks). However, the current licensing situation of WebClient makes it totally useless for me and presumably many other people. Luckily there are many other options.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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. I guess that means the long-term plan of replacing HttpSocket in Squeak is out as well?
We do not want to be in the situation that somebody can change the license under our feet. We want a library where people can participate. Now Pharoers will decide, I think that we do not have problem with sharing on WebClient. I can understand that people do not like that they cannot improve an infrastructure that they will rely upon. We do not want string to number conversion, and rely on squeakToUtf.
I think Andreas solved these issues with the WebClient-Pharo package, but I may be wrong.
If you call overriding String #, (to accept any object responding to asString without raising errors) and Collection #ifEmpty: (to return nil instead of the collection ifNotEmpty) "solving the issues" in Pharo, then yeah, sure. If you call (re)introducing #squeakToUtf8/#utf8ToSqueak instead of using convertTo/FromEncoding: 'utf8', then yes. Personally, I'd call it forcing Squeakisms on anyone wanting to use WebClient, and potentially breaking any number of other packages. The rest I have no problems with, most are fixes/convenience methods which are already in, or should be introduced before Pharo 1.2 (for exampe the SocketStream fixes ) Cheers, Henry
Personally, I'd call it forcing Squeakisms on anyone wanting to use WebClient, and potentially breaking any number of other packages.
The rest I have no problems with, most are fixes/convenience methods which are already in, or should be introduced before Pharo 1.2 (for exampe the SocketStream fixes )
I think that we integrated all the socketStreams fixes last week or so. Stef
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?
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.
We do not want to be in the situation that somebody can change the license under our feet. We want a library where people can participate. Now Pharoers will decide, I think that we do not have problem with sharing on WebClient. I can understand that people do not like that they cannot improve an infrastructure that they will rely upon. We do not want string to number conversion, and rely on squeakToUtf.
I think Andreas solved these issues with the WebClient-Pharo package, but I may be wrong.
If you call overriding String #, (to accept any object responding to asString without raising errors) and Collection #ifEmpty: (to return nil instead of the collection ifNotEmpty) "solving the issues" in Pharo, then yeah, sure.
I don't like the "magical" #asString, but you should discuss it with Andreas. Collection >> #ifEmpty: doesn't return nil, but the collection in the WebClient-Pharo package (and in Squeak), and I think it's better than nil.
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
Personally, I'd call it forcing Squeakisms on anyone wanting to use WebClient, and potentially breaking any number of other packages.
The rest I have no problems with, most are fixes/convenience methods which are already in, or should be introduced before Pharo 1.2 (for exampe the SocketStream fixes )
Cheers, Henry _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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.
http://code.google.com/p/pharo/issues/list?thanks=2885 Thanks
---- On Mon, 30 Aug 2010 05:57:47 -0700 Levente Uzonyi wrote ----
I don't like the "magical" #asString, but you should discuss it with Andreas. Collection >> #ifEmpty: doesn't return nil, but the collection in the WebClient-Pharo package (and in Squeak), and I think it's better than nil.
I opened a ticked on this a few weeks back: http://code.google.com/p/pharo/issues/detail?id=2794 The ifEmpty:/ifNotEmpty: behavior of Squeak is demonstrably better and should be adopted.
On 30 Aug 2010, at 15:35, jaayer wrote:
---- On Mon, 30 Aug 2010 05:57:47 -0700 Levente Uzonyi wrote ----
I don't like the "magical" #asString, but you should discuss it with Andreas. Collection >> #ifEmpty: doesn't return nil, but the collection in the WebClient-Pharo package (and in Squeak), and I think it's better than nil.
I opened a ticked on this a few weeks back: http://code.google.com/p/pharo/issues/detail?id=2794
The ifEmpty:/ifNotEmpty: behavior of Squeak is demonstrably better and should be adopted.
heu... I evaluated the following in a pharo1.1-dev and 1.2-core: (#(foo) ifEmpty:[#bar]) -> returns #(foo) (#() ifNotEmpty:[#bar]) -> returns #() This seems to do what you propose? Johan
On Aug 30, 2010, at 4:00 07PM, Johan Brichau wrote:
On 30 Aug 2010, at 15:35, jaayer wrote:
---- On Mon, 30 Aug 2010 05:57:47 -0700 Levente Uzonyi wrote ----
I don't like the "magical" #asString, but you should discuss it with Andreas. Collection >> #ifEmpty: doesn't return nil, but the collection in the WebClient-Pharo package (and in Squeak), and I think it's better than nil.
I opened a ticked on this a few weeks back: http://code.google.com/p/pharo/issues/detail?id=2794
The ifEmpty:/ifNotEmpty: behavior of Squeak is demonstrably better and should be adopted.
heu... I evaluated the following in a pharo1.1-dev and 1.2-core:
(#(foo) ifEmpty:[#bar]) -> returns #(foo) (#() ifNotEmpty:[#bar]) -> returns #()
This seems to do what you propose? Johan _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Yes. Levente is right, I read the code of Andreas' wrong. Pharo 1.1/1.2 does this, so the override is for 1.0, where #ifEmpty: returns nil . Cheers, Henry
Ok so I can close the ticket then. :) Stef
---- On Mon, 30 Aug 2010 05:57:47 -0700 Levente Uzonyi wrote ----
I don't like the "magical" #asString, but you should discuss it with Andreas. Collection >> #ifEmpty: doesn't return nil, but the collection in the WebClient-Pharo package (and in Squeak), and I think it's better than nil.
I opened a ticked on this a few weeks back: http://code.google.com/p/pharo/issues/detail?id=2794
The ifEmpty:/ifNotEmpty: behavior of Squeak is demonstrably better and should be adopted.
heu... I evaluated the following in a pharo1.1-dev and 1.2-core:
(#(foo) ifEmpty:[#bar]) -> returns #(foo) (#() ifNotEmpty:[#bar]) -> returns #()
This seems to do what you propose? Johan _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Yes. Levente is right, I read the code of Andreas' wrong. Pharo 1.1/1.2 does this, so the override is for 1.0, where #ifEmpty: returns nil .
Cheers, Henry _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Aug 30, 2010, at 4:45 35PM, Stéphane Ducasse wrote:
Ok so I can close the ticket then. :) Stef
Unless you want it as part of a 1.0 patch, yes. Cheers, Henry
---- On Mon, 30 Aug 2010 05:57:47 -0700 Levente Uzonyi wrote ----
I don't like the "magical" #asString, but you should discuss it with Andreas. Collection >> #ifEmpty: doesn't return nil, but the collection in the WebClient-Pharo package (and in Squeak), and I think it's better than nil.
I opened a ticked on this a few weeks back: http://code.google.com/p/pharo/issues/detail?id=2794
The ifEmpty:/ifNotEmpty: behavior of Squeak is demonstrably better and should be adopted.
heu... I evaluated the following in a pharo1.1-dev and 1.2-core:
(#(foo) ifEmpty:[#bar]) -> returns #(foo) (#() ifNotEmpty:[#bar]) -> returns #()
This seems to do what you propose? Johan _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Yes. Levente is right, I read the code of Andreas' wrong. Pharo 1.1/1.2 does this, so the override is for 1.0, where #ifEmpty: returns nil .
Cheers, Henry _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Thanks It skipped my radar since it is not marked as fixed. do you want that I add you to the project developers on google so that you can changed the tag value? Stef On Aug 30, 2010, at 3:35 PM, jaayer wrote:
---- On Mon, 30 Aug 2010 05:57:47 -0700 Levente Uzonyi wrote ----
I don't like the "magical" #asString, but you should discuss it with Andreas. Collection >> #ifEmpty: doesn't return nil, but the collection in the WebClient-Pharo package (and in Squeak), and I think it's better than nil.
I opened a ticked on this a few weeks back: http://code.google.com/p/pharo/issues/detail?id=2794
The ifEmpty:/ifNotEmpty: behavior of Squeak is demonstrably better and should be adopted.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
My 2 cents about WebClient. - it should be an (un)loadable external package, and i am fully agree with Andreas on this point. It is tempting to integrate it into image, do some tweaks here and there and then ship it within a monolitic image. But then, from maintainer's point of view, it is quite hard to keep developing it and improving, since it may break things in random places over multiple forks etc etc, and then who will be accused in such breakage? - a maintainer. It is good to have a person, who personally responsible for maintaining a package, or even if by a group of people, it should use a separate repository for developing it. Otherwise, if you integrate it into image, by doing that you: - losing a maintainer , who willingly contributing to this project - in same turn, must take own responsibility for maintaining it, which means extra work for you, whenever you having problems with it. We should learn how to integrate things without intimately tying everything with a single bloated image. And WebClient could be right thing for learning that (Seaside too ;). -- Best regards, Igor Stasenko AKA sig.
El lun, 30-08-2010 a las 18:25 +0300, Igor Stasenko escribió:
My 2 cents about WebClient.
- it should be an (un)loadable external package, and i am fully agree with Andreas on this point. It is tempting to integrate it into image, do some tweaks here and there and then ship it within a monolitic image. But then, from maintainer's point of view, it is quite hard to keep developing it and improving, since it may break things in random places over multiple forks etc etc, and then who will be accused in such breakage? - a maintainer.
Of course not, we, the ones using it as part of our core image are the ones responsible of the correct functioning in our image. It would be childish to run crying to Andreas that it break our image because we are taking the decision of integrating it in the core image. Now, this of course doesn't apply to core functionality or that breaks the contract the code offers to its clients. That type of API changes will be discussed with Andreas and if no solution found, the pharo developers will found a workaround so that is remains working correctly. What I don't understand is why such imposition to the way of use the software. If it decided to have an open source license he can't restrict the uses of the software. This is a real open source implications.
It is good to have a person, who personally responsible for maintaining a package, or even if by a group of people, it should use a separate repository for developing it.
Otherwise, if you integrate it into image, by doing that you: - losing a maintainer , who willingly contributing to this project - in same turn, must take own responsibility for maintaining it, which means extra work for you, whenever you having problems with it.
Of course, that is the point. Nobody expects otherwise.
We should learn how to integrate things without intimately tying everything with a single bloated image.
Isn't as we are integrating moose or seaside in the core image is a basic infrastructure thing, a http client, that every modern language in the current times includes in their core libraries (java, ruby, lisp).
And WebClient could be right thing for learning that (Seaside too ;).
-- Miguel Cobá http://miguel.leugim.com.mx
2010/8/30 Miguel Enrique Cobá MartÃnez <miguel.coba@gmail.com>:
El lun, 30-08-2010 a las 18:25 +0300, Igor Stasenko escribió:
My 2 cents about WebClient.
- it should be an (un)loadable external package, and i am fully agree with Andreas on this point. It is tempting to integrate it into image, do some tweaks here and there and then ship it within a monolitic image. But then, from maintainer's point of view, it is quite hard to keep developing it and improving, since it may break things in random places over multiple forks etc etc, and then who will be accused in such breakage? - a maintainer.
Of course not, we, the ones using it as part of our core image are the ones responsible of the correct functioning in our image. It would be childish to run crying to Andreas that it break our image because we are taking the decision of integrating it in the core image. Now, this of course doesn't apply to core functionality or that breaks the contract the code offers to its clients. That type of API changes will be discussed with Andreas and if no solution found, the pharo developers will found a workaround so that is remains working correctly.
What I don't understand is why such imposition to the way of use the software. If it decided to have an open source license he can't restrict the uses of the software. This is a real open source implications.
It is good to have a person, who personally responsible for maintaining a package, or even if by a group of people, it should use a separate repository for developing it.
Otherwise, if you integrate it into image, by doing that you:  - losing a maintainer , who willingly contributing to this project  - in same turn, must take own responsibility for maintaining it, which means extra work for you, whenever you having  problems with it.
Of course, that is the point. Nobody expects otherwise.
Then you making things wrong, because then: - party A made feature A available - party B made feature B available - users want A and B features both, but party A and B do not communicate I think that Andreas wants to impose a teamwork, when multiple parties working on same project, rather than multiple parties working on each own fork of a same project. I think i understood the Anreas'es point well. As initial developer, he dont wants to be in position, when his creation moves into a different direction, than he is initially planned. At least, until Andreas to-do list is not empty, and project is not mature enough, it is wise to keep development under his personal control. That's how i understood his message about license.
We should learn how to integrate things without intimately tying everything with a single bloated image.
Isn't as we are integrating moose or seaside in the core image is a basic infrastructure thing, a http client, that every modern language in the current times includes in their core libraries (java, ruby, lisp).
And WebClient could be right thing for learning that (Seaside too ;).
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
2010/8/30 Miguel Enrique Cobá MartÃnez <miguel.coba@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@gmail.com>:
2010/8/30 Miguel Enrique Cobá MartÃnez <miguel.coba@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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.
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.
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.
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
2010/8/30 Stéphane Ducasse <stephane.ducasse@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
2010/8/31 Levente Uzonyi <leves@elte.hu>:
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?
Oh, you know, the missinterpreted _and_... (that's wall I call "lancer une pique"). I should have included you in the list of people not having to answer ;) Nicolas
Nicolas
snip
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/8/31 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
2010/8/31 Levente Uzonyi <leves@elte.hu>:
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?
Oh, you know, the missinterpreted _and_... (that's wall I call "lancer une pique"). wall -> what, and I should go to bed, bye
I should have included you in the list of people not having to answer ;)
Nicolas
Nicolas
snip
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Tue, 31 Aug 2010, Nicolas Cellier wrote:
2010/8/31 Levente Uzonyi <leves@elte.hu>:
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?
Oh, you know, the missinterpreted _and_... (that's wall I call "lancer une pique").
It wasn't me who misinterpreted that "and". I would agree with you, if I were using "or", but that wasn't the case.
I should have included you in the list of people not having to answer ;)
:) Levente
Nicolas
Nicolas
snip
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@gmail.com>:
2010/8/30 Miguel Enrique Cobá MartÃnez<miguel.coba@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
On Aug 30, 2010, at 2:57 47PM, Levente Uzonyi wrote:
On Mon, 30 Aug 2010, Henrik Johansen wrote:
On Aug 30, 2010, at 1:06 10PM, Levente Uzonyi wrote:
On Mon, 30 Aug 2010, Stéphane Ducasse wrote:
I suggest that the people that want and know, group together and build an open-source one.
Why do you have to have your "own" library?
Did I say "pharo library"? reread carefully I said an "open-source one".
What I get from Andreas' words is that he's willing to make it open source if it won't be forked.
So, definitely not MIT then.
Why? Because the MIT license explicitly sets no limit on the users right to modify, publish and distribute the software. A condition that it can not be published/used in a modified (forked) form would exclude using MIT.
I guess that means the long-term plan of replacing HttpSocket in Squeak is out as well?
I don't think so. Squeak releases won't come with WebClient loaded, Andreas mentioned it in his mail.
In a reply to the original announcement, Andreas also said: "On 5/4/2010 11:11 PM, Casey Ransberger wrote:
Are you intent on replacing HTTPSocket in the long run? I have an RPC-ish thing that uses it, so I'd like to be clear on whether I can expect it to be around for the next release.
In the long run: Yes. In the next release: No. And "replacing" can mean that the public interface in HTTPSocket remains. That's what the WebClient-HTTP package does. It patches HTTPSocket to use WebClient while preserving the identical external interface. " which to me implied eventual integration in Squeak core (as did the removal of HttpSocket functionality based on it being offered by WebClient)
If you call (re)introducing #squeakToUtf8/#utf8ToSqueak instead of using convertTo/FromEncoding: 'utf8', then yes.
In Squeak these methods avoid the creation of the TextConverter object if the receiver is a ByteString, which is usually the case.
Levente
Yes, the major performance differences come from not creating copies if the strings are ascii, and #convertTo/FromEncoding: doing subclass lookup to find the converter though. AFAICT, it's maximally about 2 times faster in the best case (small, pure ascii strings) where it avoids both copies and a lookup compared to a convertTo/FromEncoding modified to do lookup in a dictionary rather than iterating subclasses. For the WebSocket use-cases though, I really don't see how the performance matters all that much. You convert roughly 200k 4KB ascii strings per second either way, and with a single non-ascii char, the difference falls to near negligible. "MediumDoc is a pure ascii ByteString of size 4096" [1 to: 100000 do: [:ix |MediumDoc squeakToUtf8]] timeToRun 362 384 [1 to: 100000 do: [:ix | MediumDoc convertToEncoding: 'utf-8']] timeToRun 437 564 MediumDoc at: 2048 put: $Ã¥. [1 to: 100000 do: [:ix |MediumDoc squeakToUtf8]] timeToRun 1451 1438 [1 to: 100000 do: [:ix | MediumDoc convertToEncoding: 'utf-8']] timeToRun 1463 1470 Cheers, Henry
thanks henrik I always learn something :)
I suggest that the people that want and know, group together and build an open-source one.
Why do you have to have your "own" library?
Did I say "pharo library"? reread carefully I said an "open-source one".
What I get from Andreas' words is that he's willing to make it open source if it won't be forked.
So, definitely not MIT then.
Why? Because the MIT license explicitly sets no limit on the users right to modify, publish and distribute the software. A condition that it can not be published/used in a modified (forked) form would exclude using MIT.
I guess that means the long-term plan of replacing HttpSocket in Squeak is out as well?
I don't think so. Squeak releases won't come with WebClient loaded, Andreas mentioned it in his mail.
In a reply to the original announcement, Andreas also said:
"On 5/4/2010 11:11 PM, Casey Ransberger wrote:
Are you intent on replacing HTTPSocket in the long run? I have an RPC-ish thing that uses it, so I'd like to be clear on whether I can expect it to be around for the next release.
In the long run: Yes. In the next release: No. And "replacing" can mean that the public interface in HTTPSocket remains. That's what the WebClient-HTTP package does. It patches HTTPSocket to use WebClient while preserving the identical external interface. "
which to me implied eventual integration in Squeak core (as did the removal of HttpSocket functionality based on it being offered by WebClient)
If you call (re)introducing #squeakToUtf8/#utf8ToSqueak instead of using convertTo/FromEncoding: 'utf8', then yes.
In Squeak these methods avoid the creation of the TextConverter object if the receiver is a ByteString, which is usually the case.
Levente
Yes, the major performance differences come from not creating copies if the strings are ascii, and #convertTo/FromEncoding: doing subclass lookup to find the converter though.
AFAICT, it's maximally about 2 times faster in the best case (small, pure ascii strings) where it avoids both copies and a lookup compared to a convertTo/FromEncoding modified to do lookup in a dictionary rather than iterating subclasses.
For the WebSocket use-cases though, I really don't see how the performance matters all that much.
You convert roughly 200k 4KB ascii strings per second either way, and with a single non-ascii char, the difference falls to near negligible.
"MediumDoc is a pure ascii ByteString of size 4096" [1 to: 100000 do: [:ix |MediumDoc squeakToUtf8]] timeToRun 362 384 [1 to: 100000 do: [:ix | MediumDoc convertToEncoding: 'utf-8']] timeToRun 437 564 MediumDoc at: 2048 put: $Ã¥. [1 to: 100000 do: [:ix |MediumDoc squeakToUtf8]] timeToRun 1451 1438 [1 to: 100000 do: [:ix | MediumDoc convertToEncoding: 'utf-8']] timeToRun 1463 1470
Cheers, Henry
<TextConverting.zip> _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
On Tue, 31 Aug 2010, Levente Uzonyi wrote:
On Mon, 30 Aug 2010, Henrik Johansen wrote:
snip
"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
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)" Levente
On 31.08.2010 00:34, Levente Uzonyi wrote:
On Tue, 31 Aug 2010, Levente Uzonyi wrote:
On Mon, 30 Aug 2010, Henrik Johansen wrote:
snip
"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
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)"
Levente 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...
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. IMHO, that might be a nice tradeoff between speed and the two desires of not bringing back #squeakToUtf8 in Pharo, nor having to use the convertToWithConverter: call Andreas was strongly opposed to (and which I agree is rather ugly). Cheers, Henry
On Tue, 31 Aug 2010, Henrik Sperre Johansen 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.
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 :). 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
IMHO, that might be a nice tradeoff between speed and the two desires of not bringing back #squeakToUtf8 in Pharo, nor having to use the convertToWithConverter: call Andreas was strongly opposed to (and which I agree is rather ugly).
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 31.08.2010 01:21, Levente Uzonyi wrote:
On Tue, 31 Aug 2010, Henrik Sperre Johansen 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 :)
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
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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)"
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.
Levente Uzonyi <leves@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?
Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus
On Mon, 30 Aug 2010, Friedrich Dominicus wrote:
Levente Uzonyi <leves@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
El mar, 31-08-2010 a las 00:25 +0200, Levente Uzonyi escribió:
On Mon, 30 Aug 2010, Friedrich Dominicus wrote:
Levente Uzonyi <leves@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
On Mon, 30 Aug 2010, Miguel Enrique Cobá MartÃnez wrote:
El mar, 31-08-2010 a las 00:25 +0200, Levente Uzonyi escribió: On Mon, 30 Aug 2010, Friedrich Dominicus wrote:
Levente Uzonyi <leves@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."
From wikipedia: "Open-source software (OSS) is computer software that is available in source code form for which the source code and certain other rights normally reserved for copyright holders are provided under a software license that permits users to study, change, and improve the software."
There's nothing about forking or redistributing here. I could make a license that says: you can study, change and improve the software, but you can't redistribute it without my permission. "But the fact remains that it is forkable always. If you don't want it forkable, then use other non open source license." See above. You could "fork" it, but that wouldn't be open source anymore. Levente Cheers
Levente
Regards Friedrich
-- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
El mar, 31-08-2010 a las 00:43 +0200, Levente Uzonyi escribió:
On Mon, 30 Aug 2010, Miguel Enrique Cobá MartÃnez wrote:
El mar, 31-08-2010 a las 00:25 +0200, Levente Uzonyi escribió: On Mon, 30 Aug 2010, Friedrich Dominicus wrote:
Levente Uzonyi <leves@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."
From wikipedia: "Open-source software (OSS) is computer software that is available in source code form for which the source code and certain other rights normally reserved for copyright holders are provided under a software license that permits users to study, change, and improve the software."
There's nothing about forking or redistributing here. I could make a license that says: you can study, change and improve the software, but you can't redistribute it without my permission.
"But the fact remains that it is forkable always. If you don't want it forkable, then use other non open source license."
See above. You could "fork" it, but that wouldn't be open source anymore.
You must be kidding. The freedom to fork is a essential right of open source software: http://news.cnet.com/8301-13505_3-10379280-16.html http://asay.blogspot.com/2006/10/wither-right-to-fork.html http://www.gnu.org/philosophy/free-sw.html http://www.opensource.org/docs/osd http://www.opensource.org/node/357 period.
Levente
Cheers
Levente
Regards Friedrich
-- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
On Mon, 30 Aug 2010, Miguel Enrique Cobá MartÃnez wrote:
El mar, 31-08-2010 a las 00:43 +0200, Levente Uzonyi escribió: On Mon, 30 Aug 2010, Miguel Enrique Cobá MartÃnez wrote:
El mar, 31-08-2010 a las 00:25 +0200, Levente Uzonyi escribió: On Mon, 30 Aug 2010, Friedrich Dominicus wrote:
Levente Uzonyi <leves@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."
From wikipedia: "Open-source software (OSS) is computer software that is available in source code form for which the source code and certain other rights normally reserved for copyright holders are provided under a software license that permits users to study, change, and improve the software."
There's nothing about forking or redistributing here. I could make a license that says: you can study, change and improve the software, but you can't redistribute it without my permission.
"But the fact remains that it is forkable always. If you don't want it forkable, then use other non open source license."
See above. You could "fork" it, but that wouldn't be open source anymore.
"You must be kidding. The freedom to fork is a essential right of open source software: http://news.cnet.com/8301-13505_3-10379280-16.html http://asay.blogspot.com/2006/10/wither-right-to-fork.html http://www.gnu.org/philosophy/free-sw.html http://www.opensource.org/docs/osd http://www.opensource.org/node/357 period." If you agree with OSI. Levente
Levente
Cheers
Levente
Regards Friedrich
-- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/8/31 Levente Uzonyi <leves@elte.hu>:
On Mon, 30 Aug 2010, Miguel Enrique Cobá MartÃnez wrote:>
"You must be kidding. The freedom to fork is a essential right of open source software: http://news.cnet.com/8301-13505_3-10379280-16.html
http://asay.blogspot.com/2006/10/wither-right-to-fork.html
http://www.gnu.org/philosophy/free-sw.html http://www.opensource.org/docs/osd http://www.opensource.org/node/357
period."
If you agree with OSI.
Right. People always get into this argument. OSI has a definition of "Open Source" that is based on a moral position of having certain "freedoms" with the code. Legally, however, there is no such definition. When you write code, you (or your employer) own the code and you (or your employer) can release it under more or less any licenseâand with any restrictionsâyou desire. If I wanted, I could release code with the restriction that you can only use it on Wednesday! The right to create "derivative works"âobviously a significant component of forkingâis restricted by copyright law unless the creator explicitly grants that right to you. So you're perfectly free to say that WebClient is not "Open Source" if you wish; but you don't obtain specific rights just because the source is open. Your rights are entirely determined by your license with the creator(s). That's all I'll contribute to this discussion for the moment. We're working with intellectual property lawyers to prepare our ESUG talk on open source licensing; hopefully we'll be able to touch on some of this then and have some useful resources for the community as an output. Julian
That's all I'll contribute to this discussion for the moment. We're working with intellectual property lawyers to prepare our ESUG talk on open source licensing; hopefully we'll be able to touch on some of this then and have some useful resources for the community as an output.
Julian please no public advertisement for this cool conference on this mailing-list, we are serious people working and not dreaming about the charm of Barcelona. :D
Don't confuse open-source software with free software: http://www.gnu.org/philosophy/free-software-for-freedom.html 2010/8/31 Miguel Enrique Cobá MartÃnez <miguel.coba@gmail.com>:
El mar, 31-08-2010 a las 00:43 +0200, Levente Uzonyi escribió:
On Mon, 30 Aug 2010, Miguel Enrique Cobá MartÃnez wrote:
El mar, 31-08-2010 a las 00:25 +0200, Levente Uzonyi escribió: On Mon, 30 Aug 2010, Friedrich Dominicus wrote:
Levente Uzonyi <leves@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."
From wikipedia: "Open-source software (OSS) is computer software that is available in source code form for which the source code and certain other rights normally reserved for copyright holders are provided under a software license that permits users to study, change, and improve the software."
There's nothing about forking or redistributing here. I could make a license that says: you can study, change and improve the software, but you can't redistribute it without my permission.
"But the fact remains that it is forkable always. If you don't want it forkable, then use other non open source license."
See above. You could "fork" it, but that wouldn't be open source anymore.
You must be kidding. The freedom to fork is a essential right of open source software: http://news.cnet.com/8301-13505_3-10379280-16.html
http://asay.blogspot.com/2006/10/wither-right-to-fork.html
http://www.gnu.org/philosophy/free-sw.html http://www.opensource.org/docs/osd http://www.opensource.org/node/357
period.
Levente
Cheers
Levente
Regards Friedrich
-- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/
El mié, 01-09-2010 a las 15:44 +0900, Serge Stinckwich escribió:
Don't confuse open-source software with free software:
http://www.gnu.org/philosophy/free-software-for-freedom.html
I think that this has already gone off-topic. The original argument was that Andreas wanted to open source it (MIT likely) and at the same time prohibiting forking of the codebase. My point was that if it was open source or free software then the forking was a granted right. If he wanted to avoid it then he couldn't claim is free software or open source. With MIT you can fork (of course) but also with GPL (like the emacs/xemacs fork). Let not bring this thread in a free software vs open source war. Cheers
2010/8/31 Miguel Enrique Cobá MartÃnez <miguel.coba@gmail.com>:
El mar, 31-08-2010 a las 00:43 +0200, Levente Uzonyi escribió:
On Mon, 30 Aug 2010, Miguel Enrique Cobá MartÃnez wrote:
El mar, 31-08-2010 a las 00:25 +0200, Levente Uzonyi escribió: On Mon, 30 Aug 2010, Friedrich Dominicus wrote:
Levente Uzonyi <leves@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."
From wikipedia: "Open-source software (OSS) is computer software that is available in source code form for which the source code and certain other rights normally reserved for copyright holders are provided under a software license that permits users to study, change, and improve the software."
There's nothing about forking or redistributing here. I could make a license that says: you can study, change and improve the software, but you can't redistribute it without my permission.
"But the fact remains that it is forkable always. If you don't want it forkable, then use other non open source license."
See above. You could "fork" it, but that wouldn't be open source anymore.
You must be kidding. The freedom to fork is a essential right of open source software: http://news.cnet.com/8301-13505_3-10379280-16.html
http://asay.blogspot.com/2006/10/wither-right-to-fork.html
http://www.gnu.org/philosophy/free-sw.html http://www.opensource.org/docs/osd http://www.opensource.org/node/357
period.
Levente
Cheers
Levente
Regards Friedrich
-- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
2010/9/1 Miguel Enrique Cobá MartÃnez <miguel.coba@gmail.com>
El mié, 01-09-2010 a las 15:44 +0900, Serge Stinckwich escribió:
Don't confuse open-source software with free software:
http://www.gnu.org/philosophy/free-software-for-freedom.html
I think that this has already gone off-topic. The original argument was that Andreas wanted to open source it (MIT likely) and at the same time prohibiting forking of the codebase. My point was that if it was open source or free software then the forking was a granted right. If he wanted to avoid it then he couldn't claim is free software or open source.
With MIT you can fork (of course) but also with GPL (like the emacs/xemacs fork).
Let not bring this thread in a free software vs open source war.
+1 Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/
Cheers
2010/8/31 Miguel Enrique Cobá MartÃnez <miguel.coba@gmail.com>:
El mar, 31-08-2010 a las 00:43 +0200, Levente Uzonyi escribió:
On Mon, 30 Aug 2010, Miguel Enrique Cobá MartÃnez wrote:
El mar, 31-08-2010 a las 00:25 +0200, Levente Uzonyi escribió: On Mon, 30 Aug 2010, Friedrich Dominicus wrote:
Levente Uzonyi <leves@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."
From wikipedia: "Open-source software (OSS) is computer software that is available in source code form for which the source code and certain other rights normally reserved for copyright holders are provided under a software license that permits users to study, change, and improve the software."
There's nothing about forking or redistributing here. I could make a license that says: you can study, change and improve the software, but you can't redistribute it without my permission.
"But the fact remains that it is forkable always. If you don't want it forkable, then use other non open source license."
See above. You could "fork" it, but that wouldn't be open source anymore.
You must be kidding. The freedom to fork is a essential right of open source software: http://news.cnet.com/8301-13505_3-10379280-16.html
http://asay.blogspot.com/2006/10/wither-right-to-fork.html
http://www.gnu.org/philosophy/free-sw.html http://www.opensource.org/docs/osd http://www.opensource.org/node/357
period.
Levente
Cheers
Levente
Regards Friedrich
-- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project
mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing
list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
GPL is designed to hold people (mostly commercial interests) hostage. Some of what is going on here sounds the same: it's open but not really. A web client is not so terribly difficult to write that we should compromise on licensing in order to use one. I have a *terribly* simple one that I can port if there is interest. IIRC, I used it to download some large files, but don't expect much. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, August 30, 2010 6:25 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final On Mon, 30 Aug 2010, Friedrich Dominicus wrote:
Levente Uzonyi <leves@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mon, 30 Aug 2010, Schwab,Wilhelm K wrote:
GPL is designed to hold people (mostly commercial interests) hostage. Some of what is going on here sounds the same: it's open but not really. A web client is not so terribly difficult to write that we should compromise on licensing in order to use one. I have a *terribly* simple one that I can port if there is interest. IIRC, I used it to download some large files, but don't expect much.
GPL was just an example for an open source license with restrictions, it has nothing to do with WebClient. Btw WebClient is far from simple (it's also a server, handles redirects, special responses, can support SSL, etc). Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, August 30, 2010 6:25 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
On Mon, 30 Aug 2010, Friedrich Dominicus wrote:
Levente Uzonyi <leves@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Levente, I stand by the analogy of GPL's history and the more emotional undertones of the current discussion. Dismissing it won't make it go away. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, August 30, 2010 6:47 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final On Mon, 30 Aug 2010, Schwab,Wilhelm K wrote:
GPL is designed to hold people (mostly commercial interests) hostage. Some of what is going on here sounds the same: it's open but not really. A web client is not so terribly difficult to write that we should compromise on licensing in order to use one. I have a *terribly* simple one that I can port if there is interest. IIRC, I used it to download some large files, but don't expect much.
GPL was just an example for an open source license with restrictions, it has nothing to do with WebClient. Btw WebClient is far from simple (it's also a server, handles redirects, special responses, can support SSL, etc). Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, August 30, 2010 6:25 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
On Mon, 30 Aug 2010, Friedrich Dominicus wrote:
Levente Uzonyi <leves@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
"Schwab,Wilhelm K" <bschwab@anest.ufl.edu> writes:
Levente,
I stand by the analogy of GPL's history and the more emotional undertones of the current discussion. Dismissing it won't make it go away. IMHO you are fully right. The fact still is if something is OS it forkable. Maye under certain conditions but it surely is forkable.
I avoid GPL software as much as I can (but well I'm running Debian Linux) so there's not escape really. However I'm just using it... Makes life easier ;-) Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus
El lun, 30-08-2010 a las 13:06 +0200, Levente Uzonyi escribió:
On Mon, 30 Aug 2010, Stéphane Ducasse wrote:
I suggest that the people that want and know, group together and build an open-source one.
Why do you have to have your "own" library?
Did I say "pharo library"? reread carefully I said an "open-source one".
What I get from Andreas' words is that he's willing to make it open source if it won't be forked.
This is plain wrong, You CAN'T make something open source and at the same time hope that nobody will fork it. The possibility of forking is one of the main liberties granted by the free and open source software. If Andreas doesn't want anyone to fork then by definition can't be open source. As I said before, a way to avoid forking in an open source project is to be open and accepting code from contributors. Not accepting good code for bad reasons is what leads to forking. I, and I think, every Pharo user, are ok with the package being controlled by Andreas, as long as the patches are accepted and not rejected for bad reasons (like having the package part of pharo core: that is our problem, if there are issues by having it part of pharo core we'll solve them, without bothering Andreas because they are Pharo specific. But he can't also, by the same Open source nature, restrict the uses of the code). We all, greatly respect and admire his technical ability, that has never been denied. But his public interactions has more than one burned a lot of people, and this no-license issue is becoming one of them. We don't want tramps like that of the missing license. When the code was announced it was a public encourage to use it and test it, but we as community went to happy and without checking the license it was included in pharo. That was our error. So please, Andreas, if you want WebClient to be open source please do it, Pharo will use it and send you patches. If not say it too, and we'll find an alternative for this. Cheers -- Miguel Cobá http://miguel.leugim.com.mx
(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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project "
On 30/08/2010 12:06, Levente Uzonyi wrote:
On Mon, 30 Aug 2010, Stéphane Ducasse wrote:
Now - since the license is unclear - since the license of the contributors is unclear we will not use it as an infrastructural assets for Pharo. I imagine that Seaside will not use it either.
Well, we are about to use it for Seaside.
Is that legal? IANAL but it was my understanding that if code has no licence it means that noone but the author has any right to do anything with it whatsoever. Not to download it, use it or even read it. That's why licences explicitly grant you rights, because otherwise you have /none/.
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
Hi Andreas, 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? Best regards, Johan 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.
<ESUG> A little advertisement: Cincom pushed the idea to have a lawyer at ESUG to explain such kind of points, there will be a panel with Julian Fitzel, Bert Freudenberg so we will all learn. Prepare your questions. </ESUG> On Aug 30, 2010, at 10:40 AM, Johan Brichau wrote:
Hi Andreas,
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?
Best regards, Johan
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.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Johan Brichau wrote:
I am not a lawyer but as far as I understand this topic, no license means nobody can use the code at all, which contradicts the fact of having it in a public repository (and you being perfectly happy of people using it).
IANAL. "no license" means it's public domain, so *anybody* can use it. But, if they use it, they have no idea of the terms under which they can use it - a license would may the terms clear. Cautious users would then *not* use it. So the net effect would be that nobody (that is cautious) uses it. There is no contradiction with it being in a public repository. The author is perfectly happy for the public to use it. The problem is that users are likely not happy to use it, without any license terms.
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.
Hi Andreas, Thank you for clarifying your position and for pointing out the lack of a proper license for WebClient code. I and other people in the Pharo community made a mistake and we're sorry. We will be more careful in the future. But to our defense, as others pointed out, you're communications gave the impression that this was true open source, compatible with the standard Squeak one in spirit. Futhermore, and this to your credit as well, you yourself wrote the WebClient-Pharo package, giving the impression that you valued that port. It also proves that you did the actual effort. Thanks you! And indeed, you did incorporate some changes, so the intention was certainly there. Now, I would not say that we already actually forked the code. We just tried to port it. The process of following your progress proved difficult (you probably made a diff between your and our latest versions), precisely because of some of these little things like #asString, #utf8Encoding, #and:and:and:and:, but also some deeper ones like #pathForFile that kept coming back. You have every right to refuse to follow the Pharo Smalltalk spirit or style. I respect that, and the Pharo community as a whole should too. But your refusal to do so and the lack of a license give us no alternative than to look for other solutions. I wasn't there when the discussion that let to the birth of Pharo took place. But it is clear that the Smalltalk community is too small to not work together. The Smalltalk-80 inheritance and the enormeous contributions of the Squeak community over the years should be respected by all. At the same time you cannot ignore the positive effect that Pharo had since then. For me and many others, Pharo definitively has its place, along many other viable Smalltalk implementations. Regards, Sven On 30 Aug 2010, at 00:00, 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
Hi Sven - I had a quick look at the failing tests on Pharo and they seem mostly the result of bugs in Pharo's Network package. First, MimeDocument>>url needs to return an instance of Url not a string (check the senders; all users of it expect it to be a Url not a string) so if you change that to return a url it'll take care of the pathForFile issue. The failure of testMultiPartPost2 is a combination of two bugs in HTTPSocket. First, there's a typo in getResponseUpTo: at the end (this needs to be #copyFrom:to: (the "to" is missing the colon). Second, there is httpPostMultiPart: which adds an erroneous CrLf at the end of a persistent HTTP/1.1 connection. That causes an interesting series of things to go wrong (which I'm partly still investigating) but the easy solution is to insert a "Connection: close" header. Fixes attached. These are of course also broken in Pharo 1.0 and 1.1. Cheers, - Andreas On 8/30/2010 2:17 AM, Sven Van Caekenberghe wrote:
Hi Andreas,
Thank you for clarifying your position and for pointing out the lack of a proper license for WebClient code.
I and other people in the Pharo community made a mistake and we're sorry. We will be more careful in the future.
But to our defense, as others pointed out, you're communications gave the impression that this was true open source, compatible with the standard Squeak one in spirit.
Futhermore, and this to your credit as well, you yourself wrote the WebClient-Pharo package, giving the impression that you valued that port. It also proves that you did the actual effort. Thanks you!
And indeed, you did incorporate some changes, so the intention was certainly there.
Now, I would not say that we already actually forked the code. We just tried to port it. The process of following your progress proved difficult (you probably made a diff between your and our latest versions), precisely because of some of these little things like #asString, #utf8Encoding, #and:and:and:and:, but also some deeper ones like #pathForFile that kept coming back.
You have every right to refuse to follow the Pharo Smalltalk spirit or style. I respect that, and the Pharo community as a whole should too.
But your refusal to do so and the lack of a license give us no alternative than to look for other solutions.
I wasn't there when the discussion that let to the birth of Pharo took place. But it is clear that the Smalltalk community is too small to not work together.
The Smalltalk-80 inheritance and the enormeous contributions of the Squeak community over the years should be respected by all. At the same time you cannot ignore the positive effect that Pharo had since then. For me and many others, Pharo definitively has its place, along many other viable Smalltalk implementations.
Regards,
Sven
On 30 Aug 2010, at 00:00, 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
Thanks http://code.google.com/p/pharo/issues/detail?id=2893 Network will be soon in our radar. full of broken code Stef On Sep 1, 2010, at 6:16 AM, Andreas Raab wrote:
Hi Sven -
I had a quick look at the failing tests on Pharo and they seem mostly the result of bugs in Pharo's Network package. First, MimeDocument>>url needs to return an instance of Url not a string (check the senders; all users of it expect it to be a Url not a string) so if you change that to return a url it'll take care of the pathForFile issue.
The failure of testMultiPartPost2 is a combination of two bugs in HTTPSocket. First, there's a typo in getResponseUpTo: at the end (this needs to be #copyFrom:to: (the "to" is missing the colon). Second, there is httpPostMultiPart: which adds an erroneous CrLf at the end of a persistent HTTP/1.1 connection. That causes an interesting series of things to go wrong (which I'm partly still investigating) but the easy solution is to insert a "Connection: close" header.
Fixes attached. These are of course also broken in Pharo 1.0 and 1.1.
Cheers, - Andreas
On 8/30/2010 2:17 AM, Sven Van Caekenberghe wrote:
Hi Andreas,
Thank you for clarifying your position and for pointing out the lack of a proper license for WebClient code.
I and other people in the Pharo community made a mistake and we're sorry. We will be more careful in the future.
But to our defense, as others pointed out, you're communications gave the impression that this was true open source, compatible with the standard Squeak one in spirit.
Futhermore, and this to your credit as well, you yourself wrote the WebClient-Pharo package, giving the impression that you valued that port. It also proves that you did the actual effort. Thanks you!
And indeed, you did incorporate some changes, so the intention was certainly there.
Now, I would not say that we already actually forked the code. We just tried to port it. The process of following your progress proved difficult (you probably made a diff between your and our latest versions), precisely because of some of these little things like #asString, #utf8Encoding, #and:and:and:and:, but also some deeper ones like #pathForFile that kept coming back.
You have every right to refuse to follow the Pharo Smalltalk spirit or style. I respect that, and the Pharo community as a whole should too.
But your refusal to do so and the lack of a license give us no alternative than to look for other solutions.
I wasn't there when the discussion that let to the birth of Pharo took place. But it is clear that the Smalltalk community is too small to not work together.
The Smalltalk-80 inheritance and the enormeous contributions of the Squeak community over the years should be respected by all. At the same time you cannot ignore the positive effect that Pharo had since then. For me and many others, Pharo definitively has its place, along many other viable Smalltalk implementations.
Regards,
Sven
On 30 Aug 2010, at 00:00, 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
<NetworkFixes-ar.1.cs>_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Andreas, Thanks a lot for taking the time to look into these problems and for the patches. Shouldn't we try to capture these problems with unit tests running across Squeak and its derivatives ? What would be the procedure to contribute to these tests ? Sven On 01 Sep 2010, at 06:16, Andreas Raab wrote:
Hi Sven -
I had a quick look at the failing tests on Pharo and they seem mostly the result of bugs in Pharo's Network package. First, MimeDocument>>url needs to return an instance of Url not a string (check the senders; all users of it expect it to be a Url not a string) so if you change that to return a url it'll take care of the pathForFile issue.
The failure of testMultiPartPost2 is a combination of two bugs in HTTPSocket. First, there's a typo in getResponseUpTo: at the end (this needs to be #copyFrom:to: (the "to" is missing the colon). Second, there is httpPostMultiPart: which adds an erroneous CrLf at the end of a persistent HTTP/1.1 connection. That causes an interesting series of things to go wrong (which I'm partly still investigating) but the easy solution is to insert a "Connection: close" header.
Fixes attached. These are of course also broken in Pharo 1.0 and 1.1.
Cheers, - Andreas
On 8/30/2010 2:17 AM, Sven Van Caekenberghe wrote:
Hi Andreas,
Thank you for clarifying your position and for pointing out the lack of a proper license for WebClient code.
I and other people in the Pharo community made a mistake and we're sorry. We will be more careful in the future.
But to our defense, as others pointed out, you're communications gave the impression that this was true open source, compatible with the standard Squeak one in spirit.
Futhermore, and this to your credit as well, you yourself wrote the WebClient-Pharo package, giving the impression that you valued that port. It also proves that you did the actual effort. Thanks you!
And indeed, you did incorporate some changes, so the intention was certainly there.
Now, I would not say that we already actually forked the code. We just tried to port it. The process of following your progress proved difficult (you probably made a diff between your and our latest versions), precisely because of some of these little things like #asString, #utf8Encoding, #and:and:and:and:, but also some deeper ones like #pathForFile that kept coming back.
You have every right to refuse to follow the Pharo Smalltalk spirit or style. I respect that, and the Pharo community as a whole should too.
But your refusal to do so and the lack of a license give us no alternative than to look for other solutions.
I wasn't there when the discussion that let to the birth of Pharo took place. But it is clear that the Smalltalk community is too small to not work together.
The Smalltalk-80 inheritance and the enormeous contributions of the Squeak community over the years should be respected by all. At the same time you cannot ignore the positive effect that Pharo had since then. For me and many others, Pharo definitively has its place, along many other viable Smalltalk implementations.
Regards,
Sven
On 30 Aug 2010, at 00:00, 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
<NetworkFixes-ar.1.cs>
Hi Sven - Good question. It would definitely be good to cover those areas with tests but I fear that may require actual cooperation :-) If there is enough energy (which is hard to say) one might be able to start a "neutral" repository with tests but I'm not sure how well it would work in practice (it would mean the tests are fairly far away from the source it's covering which is generally not a good thing). If anyone has good ideas, please propose. Cheers, - Andreas On 9/1/2010 12:38 PM, Sven Van Caekenberghe wrote:
Andreas,
Thanks a lot for taking the time to look into these problems and for the patches. Shouldn't we try to capture these problems with unit tests running across Squeak and its derivatives ? What would be the procedure to contribute to these tests ?
Sven
On 01 Sep 2010, at 06:16, Andreas Raab wrote:
Hi Sven -
I had a quick look at the failing tests on Pharo and they seem mostly the result of bugs in Pharo's Network package. First, MimeDocument>>url needs to return an instance of Url not a string (check the senders; all users of it expect it to be a Url not a string) so if you change that to return a url it'll take care of the pathForFile issue.
The failure of testMultiPartPost2 is a combination of two bugs in HTTPSocket. First, there's a typo in getResponseUpTo: at the end (this needs to be #copyFrom:to: (the "to" is missing the colon). Second, there is httpPostMultiPart: which adds an erroneous CrLf at the end of a persistent HTTP/1.1 connection. That causes an interesting series of things to go wrong (which I'm partly still investigating) but the easy solution is to insert a "Connection: close" header.
Fixes attached. These are of course also broken in Pharo 1.0 and 1.1.
Cheers, - Andreas
participants (21)
-
adi＠netstyle.ch -
Andreas Raab -
Douglas Brebner -
Friedrich Dominicus -
Henrik Johansen -
Henrik Sperre Johansen
-
Igor Stasenko -
jaayer -
Johan Brichau -
Julian Fitzell -
laurent laffont -
Levente Uzonyi -
Lukas Renggli -
Mariano Martinez Peck -
Miguel Enrique Cobá MartÃnez -
Nicolas Cellier -
Schwab,Wilhelm K -
Serge Stinckwich -
Stéphane Ducasse -
Sven Van Caekenberghe -
Yanni Chiu