Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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.
Re: [Pharo-project] Poll: missing libraries to support business
On Aug 30, 2010, at 4:28 AM, Sudhakar Krishnamachari wrote: Good to see some of the concerns addressed. Now so far I do not see companies really putting effort so may be nothing will happen but this will not be because of us. :) This is the chicken and egg situation. Bar highly motivated startups with some money in their pockets to splurge on with. The average co consists of average managers who want no risk..!. They want a technology they can blame for its shortcomings/ the support offered by another co if they are stuck for a fix. But in most ( I would say 90+% of timeline) cases the business continuity should not be affected. Sure this is clear. Now my point is pragmatic. The average company will probably not invest their time on a technology if it does not meet the bar set by the current technology. Well lot of companies are using seaside and pharo and as such the fact that the infrastructure is getting better is important. Let me take Spring Architecture as an example in the Java world. J2EE was ( and to an extent is) entrenched in the world of Java enterprise. Way back about 8 yrs back or so .. Rod Johnson started his foray in to simplifying the complexity of J2EE with his framework. I would say through atleast 4+ yrs of the 8 he would have close to nil support from any company and like the Jim Collins Good to Great simile built up the giant wheel momentum now to engage nearly all known companies to use Spring all through instead of J2EE except in the niche cases. Its is an instruction to notice how Spring got interfaces to nearly all of Java connected that would be possibly needed for a medium enterprise case and then went into the depths/ specialization etc.. that is breadth first and then the depth. So I would say WE (including myself as a avowed Smaltalker) need to keep trying and pushing for a concerted go at getting Pharo up there.. and possibly the GiantWheel momentum will kick in with first a few co's and then more.. to push this rolling with god speed to its eventual greatness..!!.. welcome! And that indeed is happening and its suprised me how far Pharo has already rolled and is building a momentum that is sure to go far if I can put my little effort as all others to get some of the minimal frameworks integrated. we need help We have either of two approaches to take: meet up to the current bar set by Java/ .Net world in terms of programming baseline ( as I listed in the prior mail) or take a radical approach that differs so much and offers so much to pull in others..like Rails did. I would say if we are interested in the numbers game I would choose the former, if we wish to retain the intellectual high ground and move on the latter is fine.. we can have a vision, a vision without action does not exist. What we are doing are - providing robust infrastructure - making the system lean and clean - slowly rewriting parts now if people with other agendas want to focus on other parts we are more than happy. To get the numbers to have an interest in Pharo I will go back to my charter for Smalltalk spread in Universities / Colleges ( the underlying reason I started SmalltalkIndia) and see how far it can be resuscitated to create a mass base of users ( even if they are amateurs) and then hope a good percentage of them retain a greater interest to contribute spare time to improve the frameworks in Pharo. Would be great. Let me know how I can help Do you know I have free slides? http://stephane.ducasse.free.fr/Resources/LecturesInPowerpoint/ * Just count how many smalltalkers we can get in a low cost centers who can code.. well Contrast this with how many Java programmers you can get.. can manage with google/ info base available Count the external frameworks open source developed , tested and trustable to be used in production code from Java nearly all free. Count the same for Smalltalk App servers.. comparable to Websphere/ weblogic/ Tomcat / lots of others, not to mention messaging queue, transaction control , JDBC like framework for nearly all DBs with high performance guaranteed, the list goes on.. The support logistics in terms CMS: viz SVN kinds, better integration / build systems like maven etc.. and evolutions in terms of frameworks that Java has spewed.. .Net in its Visual Studio et als.. Good brains together can counter all of the above arguments, but that is a limitation by itself, you cannot get good 25-50brains in one premises to work together on one single product, even if you do have them you cannot easily replace them with new recruits and be cost effective in general. From an ease of development and risk free managment angle, I find this an impossible proposition to convince any mgmt to take up Smalltalk for their dev. The target is the average developer, the
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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.duca...@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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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
Re: [Pharo-project] this style looks cool
people got excited :) On Aug 30, 2010, at 12:55 AM, j...@anymorphic.com wrote: Tudor Girba tudor.gi...@... writes: Is this Theme available? I can push the change monday morning. ja ___ 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
Re: [Pharo-project] this style looks cool
Hi ja did you sign the license agreement? Just if you want your code to be in pharo: but may impression is that it would be a nice advertisement for your company the AnyMorphic style. Stef On Aug 30, 2010, at 12:55 AM, j...@anymorphic.com wrote: Tudor Girba tudor.gi...@... writes: Is this Theme available? I can push the change monday morning. ja ___ 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] WebClient-Core port to Pharo 1.1 final
I agree with Andreas that the process for including packages in Pharo is not transparent (at least not me). Dont know the process for Squeak either - but at least we all should take care to keep the whole platform and forks open. Maybe the license should be a required field in Squeaksource for any new project. Havent followed the whole thread - but I still wonder what the reason for Andreas is to not release Webclient as MIT? Especially since I think it could be a nice addition to the standard images (Squeak, Pharo or whatever) ... Bye T. -- GMX DSL SOMMER-SPECIAL: Surf Phone Flat 16.000 für nur 19,99 ¿/mtl.!* http://portal.gmx.net/de/go/dsl ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
On Mon, Aug 30, 2010 at 10:12 AM, Stéphane Ducasse stephane.duca...@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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
Adrian Same for squeakSSL. :) Stef On Aug 30, 2010, at 10:03 AM, a...@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.duca...@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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
On Aug 30, 2010, at 10:27 AM, Torsten Bergmann wrote: I agree with Andreas that the process for including packages in Pharo is not transparent (at least not me). read the open and transparent discussions that happened over the past months in this mailing-list: check for webClient in the title :) For pharo: this is really simple - we discuss in the mailing-list - reach a consensus - act. Tell me once you will have read the mails if this is not what we did and how we could improve them. I would like to have the same process than python but we are too small for that right now. Dont know the process for Squeak either - but at least we all should take care to keep the whole platform and forks open. Maybe the license should be a required field in Squeaksource for any new project. Havent followed the whole thread - but I still wonder what the reason for Andreas is to not release Webclient as MIT? Especially since I think it could be a nice addition to the standard images (Squeak, Pharo or whatever) ... Bye T. -- GMX DSL SOMMER-SPECIAL: Surf Phone Flat 16.000 für nur 19,99 ¿/mtl.!* http://portal.gmx.net/de/go/dsl ___ 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.2] #12119
12119 - - Issue 2880: remove WebClient from pharo. Thanks Andreas Raab. Andreas is right no code without license in Pharo. Good catch. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] does anybody has a copy of HTTPClient of colin Curtin?
hi guys Colin curtin mentioned to mike that he would like to donate his HTTPClient to squeak and pharo http://map.squeak.org/package/8644a5ff-923c-438f-b5b0-a281de346040 ---BeginMessage--- Michael, I'm not sure if I responded to you, but I remember typing the email :) I am the author, I'd love to relicense it for Pharo, I don't have the code, do you have a copy? Thanks, Colin On Mon, Mar 02, 2009 at 11:51:41PM -0800, Michael Rueger wrote: Hi Colin, this is more a less an educated guess that this email works and you are actually the one who wrote the HTTPClient for Squeak back then. I've been using your HTTPClient for a while (thanks for writing it!!!) and there might be a chance to include it in Pharo (http://www.pharo-project.org/home). Would you be willing to relicense it under MIT which is now the preferred license for Squeak and Pharo distributions? Kind regards Michael Rueger ---End Message--- Stef___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] this style looks cool
Stéphane Ducasse stephane.duca...@... writes: did you sign the license agreement? For the License, I send a fax to you, now. I pushed the changes used and created by Anymorphic into Pharo-Inbox under the Name Polymorph-Themes-Pro. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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
Re: [Pharo-project] does anybody has a copy of HTTPClient of colin Curtin?
There is a copy here: http://web.archive.org/web/20070222111811rn_1/alpineguy.com/httpclient/ On 30 août 10, at 11:07, Stéphane Ducasse wrote: hi guys Colin curtin mentioned to mike that he would like to donate his HTTPClient to squeak and pharo http://map.squeak.org/package/8644a5ff-923c-438f-b5b0-a281de346040 Re: Squeak HTTPClient.eml Stef___ 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
Re: [Pharo-project] does anybody has a copy of HTTPClient of colin Curtin?
I committed a version of HTTPClient that loads in Pharo to http://www.squeaksource.com/PharoTaskForces The code looks really clean and nice. Unfortunately there are no tests and it does not seem to work out of the box, but that was not expected either. Lukas On 30 August 2010 11:19, Alain Fischer mailinglist.fisc...@bluewin.ch wrote: There is a copy here: http://web.archive.org/web/20070222111811rn_1/alpineguy.com/httpclient/ On 30 août 10, at 11:07, Stéphane Ducasse wrote: hi guys Colin curtin mentioned to mike that he would like to donate his HTTPClient to squeak and pharo http://map.squeak.org/package/8644a5ff-923c-438f-b5b0-a281de346040 Re: Squeak HTTPClient.eml Stef___ 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 -- 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
Re: [Pharo-project] does anybody has a copy of HTTPClient of colin Curtin?
Actually the line blow works out of the box, I had the proxy settings missing (which are obviously not picked up): HCFacade httpGet: 'http://www.google.com/' On 30 August 2010 11:30, Lukas Renggli reng...@gmail.com wrote: I committed a version of HTTPClient that loads in Pharo to http://www.squeaksource.com/PharoTaskForces The code looks really clean and nice. Unfortunately there are no tests and it does not seem to work out of the box, but that was not expected either. Lukas On 30 August 2010 11:19, Alain Fischer mailinglist.fisc...@bluewin.ch wrote: There is a copy here: http://web.archive.org/web/20070222111811rn_1/alpineguy.com/httpclient/ On 30 août 10, at 11:07, Stéphane Ducasse wrote: hi guys Colin curtin mentioned to mike that he would like to donate his HTTPClient to squeak and pharo http://map.squeak.org/package/8644a5ff-923c-438f-b5b0-a281de346040 Re: Squeak HTTPClient.eml Stef___ 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 -- Lukas Renggli www.lukas-renggli.ch -- 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
Re: [Pharo-project] does anybody has a copy of HTTPClient of colin Curtin?
Thanks Alain. I hope you are going well - Alain is the guy that was the first to talk to me about Seaside You got a huge impact alain :) Stef On Aug 30, 2010, at 11:19 AM, Alain Fischer wrote: There is a copy here: http://web.archive.org/web/20070222111811rn_1/alpineguy.com/httpclient/ On 30 août 10, at 11:07, Stéphane Ducasse wrote: hi guys Colin curtin mentioned to mike that he would like to donate his HTTPClient to squeak and pharo http://map.squeak.org/package/8644a5ff-923c-438f-b5b0-a281de346040 Re: Squeak HTTPClient.eml Stef___ 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
Re: [Pharo-project] does anybody has a copy of HTTPClient of colin Curtin?
Thanks lukas!!! My mail server just decided to push 3561 mails on me even if it should remove them from the server :) Stef On Aug 30, 2010, at 11:30 AM, Lukas Renggli wrote: I committed a version of HTTPClient that loads in Pharo to http://www.squeaksource.com/PharoTaskForces The code looks really clean and nice. Unfortunately there are no tests and it does not seem to work out of the box, but that was not expected either. Lukas On 30 August 2010 11:19, Alain Fischer mailinglist.fisc...@bluewin.ch wrote: There is a copy here: http://web.archive.org/web/20070222111811rn_1/alpineguy.com/httpclient/ On 30 août 10, at 11:07, Stéphane Ducasse wrote: hi guys Colin curtin mentioned to mike that he would like to donate his HTTPClient to squeak and pharo http://map.squeak.org/package/8644a5ff-923c-438f-b5b0-a281de346040 Re: Squeak HTTPClient.eml Stef___ 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 -- 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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] does anybody has a copy of HTTPClient of colin Curtin?
lukas the first thing I would love is to have beautiful abstractions and name (working of course). :) Stef On Aug 30, 2010, at 11:38 AM, Lukas Renggli wrote: Actually the line blow works out of the box, I had the proxy settings missing (which are obviously not picked up): HCFacade httpGet: 'http://www.google.com/' On 30 August 2010 11:30, Lukas Renggli reng...@gmail.com wrote: I committed a version of HTTPClient that loads in Pharo to http://www.squeaksource.com/PharoTaskForces The code looks really clean and nice. Unfortunately there are no tests and it does not seem to work out of the box, but that was not expected either. Lukas On 30 August 2010 11:19, Alain Fischer mailinglist.fisc...@bluewin.ch wrote: There is a copy here: http://web.archive.org/web/20070222111811rn_1/alpineguy.com/httpclient/ On 30 août 10, at 11:07, Stéphane Ducasse wrote: hi guys Colin curtin mentioned to mike that he would like to donate his HTTPClient to squeak and pharo http://map.squeak.org/package/8644a5ff-923c-438f-b5b0-a281de346040 Re: Squeak HTTPClient.eml Stef___ 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 -- Lukas Renggli www.lukas-renggli.ch -- 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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] does anybody has a copy of HTTPClient of colin Curtin?
On 30 Aug 2010, at 11:38, Lukas Renggli wrote: Actually the line blow works out of the box, I had the proxy settings missing (which are obviously not picked up): HCFacade httpGet: 'http://www.google.com/' Yes it does (in Pharo1.2a Latest update: #12119 (not 12118 !!)). I has underscore assignments though... We have to be 100% sure about the license. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [SPAM] Re: does anybody has a copy of HTTPClient of colin Curtin?
On 30 Aug 2010, at 11:46, Stéphane Ducasse wrote: the first thing I would love is to have beautiful abstractions and name (working of course). :) You mentioned that a couple of times before, what do you mean exactely ? In the context of HTTP the concepts are pretty well known and defined by standards and hundreds of implementations. That does of course not yet mean that there are good and bad abstractions, even in this context. Sven ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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
Re: [Pharo-project] [SPAM] Re: does anybody has a copy of HTTPClient of colin Curtin?
On Aug 30, 2010, at 11:54 AM, Sven Van Caekenberghe wrote: On 30 Aug 2010, at 11:46, Stéphane Ducasse wrote: the first thing I would love is to have beautiful abstractions and name (working of course). :) You mentioned that a couple of times before, what do you mean exactely ? the idea behind pharo is that newbies like me in certain domain should be able to take the implementation as a good example / reference how to implement it. For example, for me WebAddress looks strange, I thought that URI where WebAddress but I'm probably too newbie on web. In the context of HTTP the concepts are pretty well known and defined by standards and hundreds of implementations. Indeed That does of course not yet mean that there are good and bad abstractions, even in this context. I want to be outshined :) This album of Soundgarden was so cool (I never read the lyrics but the music was powerful). http://www.youtube.com/watch?v=q6c1iv2Jhcc ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Magnitude should be reimplemented as a Trait
On Sun, 29 Aug 2010 07:28:19 -0700 Nicolas Cellier wrote I'm not comfortable with English, but to me Magnitude is about ordering rather than just comparing. I expect a TOrderable to describe a fully or partially ordered set. If you define this, then it is a fully ordered set: = aMagnitude ^(self aMagnitude) not Beware, due to introduction of NaN, Float is not fully ordered, this require overriding above message in Number. Nicolas Comparable has parallels in other languages like Java and C#'s Comparable and IComparable interfaces. Also, one of its categories is comparing. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] does anybody has a copy of HTTPClient of colin Curtin?
On 30 août 10, at 11:41, Stéphane Ducasse wrote: Thanks Alain. I hope you are going well - Alain is the guy that was the first to talk to me about Seaside You got a huge impact alain :) I am going well even if I don't do a lot of Smalltalk ... still hoping to use more Smalltalk ... Nice to read the impact about Seaside ... :-) Stef On Aug 30, 2010, at 11:19 AM, Alain Fischer wrote: There is a copy here: http://web.archive.org/web/20070222111811rn_1/alpineguy.com/httpclient/ On 30 août 10, at 11:07, Stéphane Ducasse wrote: hi guys Colin curtin mentioned to mike that he would like to donate his HTTPClient to squeak and pharo http://map.squeak.org/package/8644a5ff-923c-438f-b5b0-a281de346040 Re: Squeak HTTPClient.eml Stef___ 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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.
Re: [Pharo-project] Magnitude should be reimplemented as a Trait
+1 So this is ok :) What I would love in my wildest dream is to have magnitude using TComparable :) But this may be too complex. I would like to have the time to check how we can make trait implementation leaner, smaller. Stef On Aug 30, 2010, at 12:11 PM, jaayer wrote: On Sun, 29 Aug 2010 07:28:19 -0700 Nicolas Cellier wrote I'm not comfortable with English, but to me Magnitude is about ordering rather than just comparing. I expect a TOrderable to describe a fully or partially ordered set. If you define this, then it is a fully ordered set: = aMagnitude ^(self aMagnitude) not Beware, due to introduction of NaN, Float is not fully ordered, this require overriding above message in Number. Nicolas Comparable has parallels in other languages like Java and C#'s Comparable and IComparable interfaces. Also, one of its categories is comparing. ___ 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] squeaksource no license is dangerous
hi guys after get burned during some years about the license of Squeak. What do you think to force people to put a license on projects on squeaksource? I have the impression that it would avoid bad situation in the future. Even if I could live with it like it is too. This is just that we just wait to get bitten... Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Fwd: ImageSegment incompatible with swapping classes that have instances?
Begin forwarded message: From: Noury Bouraqadi bouraq...@gmail.com Date: August 30, 2010 11:18:44 AM GMT+02:00 To: Martinez Peck Mariano marianop...@gmail.com Cc: Ducasse Stéphane stephane.duca...@inria.fr, Marcus Denker marcus.den...@inria.fr, Luc Fabresse luc.fabre...@mines-douai.fr Subject: ImageSegment incompatible with swapping classes that have instances? Hi, The swapping out a class that has instances does not work. More precisely, it crashes the image when loading back. At least in my small example. Evaluate the code in the ClassProxy comment. Noury Class proxy example.st Description: Binary data ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Fwd: ImageSegment incompatible with swapping classes that have instances?
Begin forwarded message: From: Mariano Martinez Peck marianop...@gmail.com Date: August 30, 2010 12:06:36 PM GMT+02:00 To: Noury Bouraqadi bouraq...@gmail.com Cc: Ducasse Stéphane stephane.duca...@inria.fr, Marcus Denker marcus.den...@inria.fr, Luc Fabresse luc.fabre...@mines-douai.fr Subject: Re: ImageSegment incompatible with swapping classes that have instances? On Mon, Aug 30, 2010 at 11:18 AM, Noury Bouraqadi bouraq...@gmail.com wrote: Hi, The swapping out a class that has instances does not work. More precisely, it crashes the image when loading back. What a hacky guy you are ;) I discover that it fails even before...Implement this in ClassProxy: hello Transcript show: 'Hello' Then evaluate: o := MyObject new. o foo: 123. p := ClassProxy new. p become: MyObject. o hello. and the vm will crash and nothing in the transcript... funny, does someone know why it doesn't work ? Cheers mariano At least in my small example. Evaluate the code in the ClassProxy comment. Noury ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Fwd: WebClient-Core port to Pharo 1.1 final
Begin forwarded message: From: Philippe Marschall philippe.marsch...@netcetera.ch Date: August 30, 2010 12:17:13 PM GMT+02:00 To: stephane.duca...@inria.fr Subject: Re: WebClient-Core port to Pharo 1.1 final On 08/30/2010 09:45 AM, Stéphane Ducasse wrote: 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. Well with intentionally no license there is no way to telling what you're allowed to do and what not: - modify - redistribute - redistribute modifications - even loading Without knowing that there's no way I can put any license on my code. There's no way of telling whether what I did (redistribute modifications under the same name) was even legal. Cheers Philippe ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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-WebClient105.46 447 Cog-Squeak-Kom 74.54 617 Cog-Squeak-WebClient226.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
Re: [Pharo-project] squeaksource no license is dangerous
On Mon, 30 Aug 2010 03:35:28 -0700 Stéphane Ducasse wrote hi guys after get burned during some years about the license of Squeak. What do you think to force people to put a license on projects on squeaksource? I have the impression that it would avoid bad situation in the future. Even if I could live with it like it is too. This is just that we just wait to get bitten... There is an HTML parser on SS with a non-compete clause in its license. There are many other projects on SS that either have no explicit license or are licensed in a non-OSI-approved manner. I have thought of complaining in the past, but nowhere on SS (at least nowhere I could find) does it say that code uploaded to it must be open source; in fact, the site doesn't seem to even mention open source at all. If SS is supposed to be the Google Code or Source Forge of the Smalltalk community, only accepting open source code, it should be upfront about it; likewise if it is open to all Smalltalk code, including proprietary. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Magnitude should be reimplemented as a Trait
On Mon, 30 Aug 2010 03:32:18 -0700 Stéphane Ducasse wrote +1 So this is ok :) What I would love in my wildest dream is to have magnitude using TComparable :) But this may be too complex. I would like to have the time to check how we can make trait implementation leaner, smaller. Stef Actually, if you change Magnitude's class definition to this: Object subclass: #Magnitude uses: TComparable instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Kernel-Numbers' and then manually remove its comparing and testing messages, everything seems to work. (Same number of passed/failed tests in KernelTests-Numbers as before ) But I could see this potentially causing build issues. Also, Magnitude's testing messages, despite what their category name implies, do not return booleans; instead they return other Magnitudes. I have recategorized those messages (#min:, #max:, and #min:max:) in TComparable under comparing in the attached fileout. TComparable2.st Description: Binary data ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] squeaksource no license is dangerous
after get burned during some years about the license of Squeak. What do you think to force people to put a license on projects on squeaksource? I have the impression that it would avoid bad situation in the future. Even if I could live with it like it is too. This is just that we just wait to get bitten... The problem is that there are thousands of projects without a license. Additionally, since the License field was added to SqueakSource relatively late it cannot be easily added anymore. There is an HTML parser on SS with a non-compete clause in its license. There are many other projects on SS that either have no explicit license or are licensed in a non-OSI-approved manner. I have thought of complaining in the past, but nowhere on SS (at least nowhere I could find) does it say that code uploaded to it must be open source; in fact, the site doesn't seem to even mention open source at all. If SS is supposed to be the Google Code or Source Forge of the Smalltalk community, only accepting open source code, it should be upfront about it; likewise if it is open to all Smalltalk code, including proprietary. SqueakSource is more like GitHub. There are various commercial and proprietary projects hosted there, some of them you can't even see as you lack the required permissions. There is no need for code to be open source to store it on SqueakSource. 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
Levente Uzonyi le...@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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] WebClient-Core port to Pharo 1.1 final
Before some of us are continue to lament or are too quick in decisions like removing/forking/reimplementing the web lib or judging on all this I think it would be wise to wait for a response from Andreas. First: his response was directly to Sven (with Pharo in CC) and please reread what he wrote: which are not (or not yet) under MIT. Which means there is a chance that the code will be under MIT. But as he wrote: that I specifically didn't set a license on WebClient to prevent such forks without any prior discussion It is fairly reasonable to discuss it first since all our time is limited and the more forks we have the more time may be wasted. A fork would only be necessary if Squeak and Pharo differ too much in the underlying base. Which again leads to the question if it would be possible to reshape both systems onto a common clean kernel ... but thats another story. I think that even a fork of a package would be no problem (you can hardly prevent it when you set something real open source) but there should be a way that contributions/fixes can be folded back into the original (external) code stream. your repository incorrectly claims that the version of WebClient in it is LGPLv2. Yes, Sven uploaded a WebClient-Core-Sven72.mcz to squeaksource/ADayAtTheBeach and this repository is LGPLv2. Andreas was just surprised that someone relicensed his code even before he has put a license tag onto the original package. Same for the inclusion into the MIT licensed Pharo core image. On the other hand he published ConfigurationOfWebClient-ar.1.mcz into the MIT licensed squeaksource/MetacelloRepository instead of keeping the Configuration into the unlicensed package repository. So it looks like he wanted to do an MIT release ... However: Andreas has to put a license tag onto his code so we can finally stop this whole side discussion and continue to move forward nobody in Pharo even tries to find out what the license status for WebClient is. Yes ... looks like there was/is a missing/incomplete process in license checking In short, my position is that we need more shared libraries, not more forks +1 I think WebClient should be an external package External - Internal is just a question of a modularized image and loading/unloading. In case of Andreas deciding for MIT and a code integration into the base images (Squeak, Pharo, ...) the community has one leading place for the code (the external package). Similar to what I do for HelpSystem. So Managing the code external is OK since this would allow all us all to load it into own custom images or merge changes into own custom adoptions (if they are necessary). In case Andreas decides for non-MIT there is no option - the community has to find a more open alternative if it wants to include it in Pharo or even port it to other Smalltalk systems (for instance to reuse the code in conjunction with Seaside on VW/VAST/...) My 2cent Bye T. -- GMX DSL SOMMER-SPECIAL: Surf Phone Flat 16.000 für nur 19,99 euro;/mtl.!* http://portal.gmx.net/de/go/dsl ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Where does an HTTP Client fit in ?
Hi, Many valid things have been said from both sides regarding WebClient. As far as I understand it, there are 2 possible 'places' where code can reside: inside Pharo(Core) or outside. The inside code does not have to be compatible with other Squeak/Smalltalks (apart from maybe ANSI and other standards, I am not qualified here). The outside code can choose its compatibility target. Seaside goes very far here, but it hurts to think about the amount of effort that is being put in to achieve this (if it wasn't for the proof of its existence and portability, I would not believe this was even possible) (*) Some other packages might target just one Smalltalk. We cannot demand this from any other, even if it would be a good idea. My question is, where does a (future) HTTP Client fit in ? Both places are possible, one requiring more effort than the other. If I look at what is inside PharoCore, there is an important dependency on HTTP client access at least (Monticello, Updating, Gofer, ...). From that standpoint such a client should be 'inside'. Furthermore, many people have indicated that a good HTTP client (and/or server) is (are) very important today. Any Smalltalk looks silly without a proper HTTP implementation. Even though an 'outside' client (based on Grease for example) would be doable and a good idea, the 'inside' route feels more natural. BTW, In Java both exist (it is in the standard J2SE libs, and there are many clients, like http://hc.apache.org/ ). What do others think ? Sven (*) I respect this very much, it is a remarkable achievement. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] this style looks cool
thanks I will check if the inria secretary got it. Stef On Aug 30, 2010, at 11:13 AM, j...@anymorphic.com wrote: Stéphane Ducasse stephane.duca...@... writes: did you sign the license agreement? For the License, I send a fax to you, now. I pushed the changes used and created by Anymorphic into Pharo-Inbox under the Name Polymorph-Themes-Pro. ___ 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
Re: [Pharo-project] squeaksource no license is dangerous
As lukas said we were more in the mood to help people developing software, even private one. Now it may turn out that we were too naive... but this is life :) Stef On Aug 30, 2010, at 1:12 PM, jaayer wrote: On Mon, 30 Aug 2010 03:35:28 -0700 Stéphane Ducasse wrote hi guys after get burned during some years about the license of Squeak. What do you think to force people to put a license on projects on squeaksource? I have the impression that it would avoid bad situation in the future. Even if I could live with it like it is too. This is just that we just wait to get bitten... There is an HTML parser on SS with a non-compete clause in its license. There are many other projects on SS that either have no explicit license or are licensed in a non-OSI-approved manner. I have thought of complaining in the past, but nowhere on SS (at least nowhere I could find) does it say that code uploaded to it must be open source; in fact, the site doesn't seem to even mention open source at all. If SS is supposed to be the Google Code or Source Forge of the Smalltalk community, only accepting open source code, it should be upfront about it; likewise if it is open to all Smalltalk code, including proprietary. ___ 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] OBMorphicIcons (was Re: this style looks cool)
Message: 4 Date: Mon, 30 Aug 2010 03:41:45 +0200 From: Tudor Girba tudor.gi...@gmail.com Subject: Re: [Pharo-project] this style looks cool To: Pharo-project@lists.gforge.inria.fr Message-ID: 6950297a-3ff9-46b5-9ac5-caa382233...@gmail.com Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Hi Bill, As I said, all you have to do is to override #browserIcon on the class side of your class to return a symbol that corresponds to a method in OBMorphicIcons. Please look at the implementors of #browserIcon. For example: Announcement classbrowserIcon ^ #announcement OBMorphicIconsannouncement ^ ((ColorForm extent: 1...@12 depth: 8 fromArray: ... Cheers, Doru This looks useful; how do you turn an image into a method, though? Thank you, Rob ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] this style looks cool
On Mon, Aug 30, 2010 at 11:13 AM, j...@anymorphic.com j...@anymorphic.comwrote: Stéphane Ducasse stephane.duca...@... writes: did you sign the license agreement? For the License, I send a fax to you, now. I pushed the changes used and created by Anymorphic into Pharo-Inbox under the Name Polymorph-Themes-Pro. this is awesome!!! I have just tested in Pharo 1.1 and it is really really cool. I love it. I will use it for all my images :) Hope it is integrated in Pharo. If people don't agree, not as default, but at least include it so that those who want can set it and use it. Thanks a lot mariano ___ 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
Re: [Pharo-project] OBMorphicIcons (was Re: this style looks cool)
This looks useful; how do you turn an image into a method, though? Hi! Have a look at the class side of MenuIcons. There are a bunch of import/export methods. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
We do not want a process/system where one single person controls something important. - first it does not scale. - second it is not good for the ecosystem feeling. - third we got burnt in the past (remember 3.9 fonts problems - 3.9 was shipped with bug because we could not touched graphics and we needed to integrate other fixes) and we do not want that again. - fourth we are reading to share and we know how to do it but not at any price. Now I have to work. :) Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Information about ESUG 2010 conference
Dear Smalltalkers, I'd like to remind you that all information about the ESUG conference is on-line as usual http://www.esug.org/Conferences/2010 you'll there many info including (but not limited to:) -The conference schedule: http://www.esug.org/wiki/pier/Conferences/2010/SchedulePDF?view=PRDownloadView_n28 -Venue : http://www.esug.org/wiki/pier/Conferences/2010/Venue -A list of Hotels: http://www.esug.org/wiki/pier/Conferences/2010/Accomodation Last, a statistic: So far we have 133 registered people! Definitely the ESUG conference is the place to be to meet the community. For any question, please feel free to contact the esug board (bo...@esug.org). See you in Barcelona, Noury Esug treasurer ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Magnitude should be reimplemented as a Trait
On Aug 30, 2010, at 1:25 PM, jaayer wrote: On Mon, 30 Aug 2010 03:32:18 -0700 Stéphane Ducasse wrote +1 So this is ok :) What I would love in my wildest dream is to have magnitude using TComparable :) But this may be too complex. I would like to have the time to check how we can make trait implementation leaner, smaller. Stef Actually, if you change Magnitude's class definition to this: Object subclass: #Magnitude uses: TComparable instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Kernel-Numbers' and then manually remove its comparing and testing messages, everything seems to work. (Same number of passed/failed tests in KernelTests-Numbers as before ) But I could see this potentially causing build issues. Excellent! I would not have dare doing it. We are trying to get the system bootstrap and bumping in a lot of issues and shaking the system. So I was implying more that. I'm also thorn apart about the pluggability of traits - my meta sin. :) http://code.google.com/p/pharo/issues/detail?id=2884 Also, Magnitude's testing messages, despite what their category name implies, do not return booleans; instead they return other Magnitudes. I have recategorized those messages (#min:, #max:, and #min:max:) in TComparable under comparing in the attached fileout.TComparable2.st___ Indeed http://code.google.com/p/pharo/issues/detail?id=2882 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
On Mon, 30 Aug 2010, Stéphane Ducasse wrote: We do not want a process/system where one single person controls something important. - first it does not scale. - second it is not good for the ecosystem feeling. - third we got burnt in the past (remember 3.9 fonts problems - 3.9 was shipped with bug because we could not touched graphics and we needed to integrate other fixes) and we do not want that again. - fourth we are reading to share and we know how to do it but not at any price. It's a bit funny to read that from a benevolent dictator. Levente Now I have to work. :) Stef ___ 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
Re: [Pharo-project] MethodName
Hi! I can't load it. I've got an error: Instances of Timestamp are not indexable Alexandre On 29 Aug 2010, at 22:07, Benjamin Van Ryseghem wrote: Hello everyone As you may already known, I'm working on a new tool named MethodName which is the merge of MethodFinder and MessagesName with some cool improvement :) It works on Pharo1.2 - 12109 because it needs NullTextStyler ( Gofer new squeaksource: 'PharoTaskForces'; package: 'NullTextStyler'; load.) You can download the sources by evaluating this : Gofer new squeaksource: 'PharoTaskForces'; package: 'MethodName'; load. For opening a new MethodName window there's two ways : - evaluate : MethodName new openInWorld. - click World Tools Method Name How it works : - You choose thank to the radio button where you want to search (Selectors / Class names/ Source) - You type the text you want to search : + Source : 1) *string or string or string* or *string* - it answers all the methods which source contains string 2) begin*end - it answers all the methods which source contains begin(whatever)end. + Class names : 1) name - it answers the class which the name is name 2) name* / *name / *name* / begin*end ... - * replaces any string. + Selectors: 1) the same behaviour that for class names 2) the behaviour of MethodFinder Moreover you can reduce the field of search by clicking on Change environment which open a PackageChooser window. A PackageChooser let you choose the set of classes which will be browsed during the search. The left list shows all the available packages and the right list shows the already selected packages. To add packages, just select them then click to add them or click to select all the packages. It's the same to remove packages. Instead of browsing tons of packages in the goal of finding the one you want, you can use the text field to enter the name of the package or a part of the name using some *. When all the packages are selected, just click Ok :) I hope it's a bit clear and a bit useful ^^ Benjamin ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
We do not want a process/system where one single person controls something important. - first it does not scale. - second it is not good for the ecosystem feeling. - third we got burnt in the past (remember 3.9 fonts problems - 3.9 was shipped with bug because we could not touched graphics and we needed to integrate other fixes) and we do not want that again. - fourth we are reading to share and we know how to do it but not at any price. It's a bit funny to read that from a benevolent dictator. I'm happy that this makes you smile. Apparently you did not study enough history... if we can call that history. Then you probably do not read not well enough this list because we always discuss and I often do not have hard thoughts. I'm trying to learn from people and more act as a catalyst. Our process is not close we just do a simple quality control. Now you can do whatever you want with your software, I will not argue on that. Now I prefer to talk with you about software and not things that are too emotional, because I learn more from it. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] MethodName
excellent we spent the week-end (or the part allocated to code) chasing it. Which image? version We do not understand why fileIn has a problem when MethodReference get a real timestamp. Stef Hi! I can't load it. I've got an error: Instances of Timestamp are not indexable Alexandre On 29 Aug 2010, at 22:07, Benjamin Van Ryseghem wrote: Hello everyone As you may already known, I'm working on a new tool named MethodName which is the merge of MethodFinder and MessagesName with some cool improvement :) It works on Pharo1.2 - 12109 because it needs NullTextStyler ( Gofer new squeaksource: 'PharoTaskForces'; package: 'NullTextStyler'; load.) You can download the sources by evaluating this : Gofer new squeaksource: 'PharoTaskForces'; package: 'MethodName'; load. For opening a new MethodName window there's two ways : - evaluate : MethodName new openInWorld. - click World Tools Method Name How it works : - You choose thank to the radio button where you want to search (Selectors / Class names/ Source) - You type the text you want to search : + Source : 1) *string or string or string* or *string* - it answers all the methods which source contains string 2) begin*end - it answers all the methods which source contains begin(whatever)end. + Class names : 1) name - it answers the class which the name is name 2) name* / *name / *name* / begin*end ... - * replaces any string. + Selectors: 1) the same behaviour that for class names 2) the behaviour of MethodFinder Moreover you can reduce the field of search by clicking on Change environment which open a PackageChooser window. A PackageChooser let you choose the set of classes which will be browsed during the search. The left list shows all the available packages and the right list shows the already selected packages. To add packages, just select them then click to add them or click to select all the packages. It's the same to remove packages. Instead of browsing tons of packages in the goal of finding the one you want, you can use the text field to enter the name of the package or a part of the name using some *. When all the packages are selected, just click Ok :) I hope it's a bit clear and a bit useful ^^ Benjamin ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ 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
Re: [Pharo-project] MethodName
I attached PharoDebug.log Alexandre PharoDebug.log Description: Binary data On 30 Aug 2010, at 09:12, Stéphane Ducasse wrote: excellent we spent the week-end (or the part allocated to code) chasing it. Which image? version We do not understand why fileIn has a problem when MethodReference get a real timestamp. Stef Hi! I can't load it. I've got an error: Instances of Timestamp are not indexable Alexandre On 29 Aug 2010, at 22:07, Benjamin Van Ryseghem wrote: Hello everyone As you may already known, I'm working on a new tool named MethodName which is the merge of MethodFinder and MessagesName with some cool improvement :) It works on Pharo1.2 - 12109 because it needs NullTextStyler ( Gofer new squeaksource: 'PharoTaskForces'; package: 'NullTextStyler'; load.) You can download the sources by evaluating this : Gofer new squeaksource: 'PharoTaskForces'; package: 'MethodName'; load. For opening a new MethodName window there's two ways : - evaluate : MethodName new openInWorld. - click World Tools Method Name How it works : - You choose thank to the radio button where you want to search (Selectors / Class names/ Source) - You type the text you want to search : + Source : 1) *string or string or string* or *string* - it answers all the methods which source contains string 2) begin*end - it answers all the methods which source contains begin(whatever)end. + Class names : 1) name - it answers the class which the name is name 2) name* / *name / *name* / begin*end ... - * replaces any string. + Selectors: 1) the same behaviour that for class names 2) the behaviour of MethodFinder Moreover you can reduce the field of search by clicking on Change environment which open a PackageChooser window. A PackageChooser let you choose the set of classes which will be browsed during the search. The left list shows all the available packages and the right list shows the already selected packages. To add packages, just select them then click to add them or click to select all the packages. It's the same to remove packages. Instead of browsing tons of packages in the goal of finding the one you want, you can use the text field to enter the name of the package or a part of the name using some *. When all the packages are selected, just click Ok :) I hope it's a bit clear and a bit useful ^^ Benjamin ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ 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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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
Re: [Pharo-project] Sockets in Pharo CollaborActive Book
Hi, I'm currently working on a chapter about Sockets for the Pharo by example book. I'm half way, though there is more material than what is on the pharo collabor-active book. It's a pitty, that pharo by example and the collaborative book aren't linked. Any way, I'll be happy ot send what I have written to anyone who request it. Noury On 29 août 2010, at 23:05, Sean P. DeNigris wrote: The description of sockets at http://book.pharo-project.org/book/networking/Socket/ is: Socket is one of the main networking classes. You can create a new TCP socket with the message #newTCP. This example creates a TCP socket and puts it into listening mode. After a client has connected, it reads data from the socket. | server client | server := Socket newTCP. server listenOn: 12345 backlogSize: 4. server waitForConnectionFor: 600. client := server accept. client receiveData Huh?! It looks like half the code in this snippet belongs on the server, and the other half on the client. I tried: Server doit: server := Socket newTCP. server listenOn: 12345 backlogSize: 4. server waitForConnectionFor: 600. Client doit: server := Socket newTCP. server listenOn: 12345 backlogSize: 4. server waitForConnectionFor: 600. client := server accept. client receiveData. but the server just hung forever. After flopping around for a while, and checking the swiki, it seemed to be listenOn:backlogSize: that was the problem. Everything went well with: Server DoIt: server := Socket newTCP. server listenOn: 8080. server waitForConnectionFor: 600. server sendData: 'Hello from the server' Client PrintIt: client := Socket newTCP. client connectTo: (NetNameResolver localHostAddress) port: 8080. client receiveData. Anyway, I'd like to have this be clearer, but my knowledge is very basic. Also, the class comment for socket reads ...Sockets are the lowest level of networking object in Squeak and are not normally used directly... so is this where we want to direct people first? Thanks. Sean -- View this message in context: http://forum.world.st/Sockets-in-Pharo-CollaborActive-Book-tp2399361p2399361.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project Noury ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] ifEmpty:ifNotEmpty (was: WebClient-Core port to Pharo 1.1 final)
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
Re: [Pharo-project] ifEmpty:ifNotEmpty (was: WebClient-Core port to Pharo 1.1 final)
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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] ifEmpty:ifNotEmpty (was: WebClient-Core port to Pharo 1.1 final)
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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] OBMorphicIcons (was Re: this style looks cool)
*contents := (StandardFileStream fileNamed: 'loop_icon.jpg') contents. encondedContents := (Base64MimeConverter mimeEncode: contents readStream) .* That basically gives you the string you have to embed in a method... Cheers, Guille On Mon, Aug 30, 2010 at 9:42 AM, Alexandre Bergel alexan...@bergel.euwrote: This looks useful; how do you turn an image into a method, though? Hi! Have a look at the class side of MenuIcons. There are a bunch of import/export methods. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
2010/8/30 Miguel Enrique Cobá Martínez miguel.c...@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. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.2] #12120
12120 - - Fix for post enh of methodReference (remove timeStamp:. and related). Sorry for the potential mess. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Sockets in Pharo CollaborActive Book
Noury, I would like a copy. Bill bschwab AT anest DOT ufl DOT edu From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Noury Bouraqadi [bouraq...@gmail.com] Sent: Monday, August 30, 2010 9:41 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Sockets in Pharo CollaborActive Book Hi, I'm currently working on a chapter about Sockets for the Pharo by example book. I'm half way, though there is more material than what is on the pharo collabor-active book. It's a pitty, that pharo by example and the collaborative book aren't linked. Any way, I'll be happy ot send what I have written to anyone who request it. Noury On 29 août 2010, at 23:05, Sean P. DeNigris wrote: The description of sockets at http://book.pharo-project.org/book/networking/Socket/ is: Socket is one of the main networking classes. You can create a new TCP socket with the message #newTCP. This example creates a TCP socket and puts it into listening mode. After a client has connected, it reads data from the socket. | server client | server := Socket newTCP. server listenOn: 12345 backlogSize: 4. server waitForConnectionFor: 600. client := server accept. client receiveData Huh?! It looks like half the code in this snippet belongs on the server, and the other half on the client. I tried: Server doit: server := Socket newTCP. server listenOn: 12345 backlogSize: 4. server waitForConnectionFor: 600. Client doit: server := Socket newTCP. server listenOn: 12345 backlogSize: 4. server waitForConnectionFor: 600. client := server accept. client receiveData. but the server just hung forever. After flopping around for a while, and checking the swiki, it seemed to be listenOn:backlogSize: that was the problem. Everything went well with: Server DoIt: server := Socket newTCP. server listenOn: 8080. server waitForConnectionFor: 600. server sendData: 'Hello from the server' Client PrintIt: client := Socket newTCP. client connectTo: (NetNameResolver localHostAddress) port: 8080. client receiveData. Anyway, I'd like to have this be clearer, but my knowledge is very basic. Also, the class comment for socket reads ...Sockets are the lowest level of networking object in Squeak and are not normally used directly... so is this where we want to direct people first? Thanks. Sean -- View this message in context: http://forum.world.st/Sockets-in-Pharo-CollaborActive-Book-tp2399361p2399361.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project Noury ___ 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] SerialPort - named ports on Linux
Hello all, I recalled seeing mention of the Linux vm's now supporting named ports, and I found the code for that, at least in the vm. My understanding gets fuzzy as we enter the plugin and primitives. At a minimum, there are a few ByName methods to be added, and Squeak 4.1 contains open and close methods that test on type (int vs. string) to open or close by name or not as appropriate. Is this as simple as gathering the changes and adding them to Pharo, or does it require VMMaker magic? Bill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
2010/8/30 Miguel Enrique Cobá Martínez miguel.c...@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
[Pharo-project] return character magic?
Hi all, Just last week, I had a very strange phenomenon in my Pharo image: the return character (^) was changed by an up arrow (see screenshot below). I was not really able to reproduce the 'problem' but now we got a repeatable one: Just load the attached js file in a Seaside WAFilelibrary (WAFilelibrary addFileAt: ' ...'): you will see that the method will also have such a return char. What is going on? :-) I'm on Mac, using Pharo 1.1. cheers, Johan inline: Screen shot 2010-07-29 at 17.15.29.png A MIME attachment of type application/x-javascript was removed here by a drop-attachments-by-name filter rule on the host mail2-relais-roc.national.inria.fr. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] return character magic?
A while ago I got the same with _ Stef On Aug 30, 2010, at 8:28 PM, Johan Brichau wrote: Hi all, Just last week, I had a very strange phenomenon in my Pharo image: the return character (^) was changed by an up arrow (see screenshot below). I was not really able to reproduce the 'problem' but now we got a repeatable one: Just load the attached js file in a Seaside WAFilelibrary (WAFilelibrary addFileAt: ' ...'): you will see that the method will also have such a return char. What is going on? :-) I'm on Mac, using Pharo 1.1. cheers, Johan Screen shot 2010-07-29 at 17.15.29.png A MIME attachment of type application/x-javascript was removed here by a drop-attachments-by-name filter rule on the host mail2-relais-roc.national.inria.fr. ___ 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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: 10 do: [:ix |MediumDoc squeakToUtf8]] timeToRun 362 384 [1 to: 10 do: [:ix | MediumDoc convertToEncoding: 'utf-8']] timeToRun 437 564 MediumDoc at: 2048 put: $å. [1 to: 10 do: [:ix |MediumDoc squeakToUtf8]] timeToRun 1451 1438 [1 to: 10 do: [:ix | MediumDoc convertToEncoding: 'utf-8']] timeToRun 1463 1470 Cheers, Henry TextConverting.zip ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] return character magic?
so what did you do? I see that the file got removed... I will submit a bug issue for that with the file attached. The *real* problem is that you cannot remove it either! It does _not_ want to go away! On 30 Aug 2010, at 20:31, Stéphane Ducasse wrote: A while ago I got the same with _ Stef On Aug 30, 2010, at 8:28 PM, Johan Brichau wrote: Hi all, Just last week, I had a very strange phenomenon in my Pharo image: the return character (^) was changed by an up arrow (see screenshot below). I was not really able to reproduce the 'problem' but now we got a repeatable one: Just load the attached js file in a Seaside WAFilelibrary (WAFilelibrary addFileAt: ' ...'): you will see that the method will also have such a return char. What is going on? :-) I'm on Mac, using Pharo 1.1. cheers, Johan Screen shot 2010-07-29 at 17.15.29.png A MIME attachment of type application/x-javascript was removed here by a drop-attachments-by-name filter rule on the host mail2-relais-roc.national.inria.fr. ___ 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
Re: [Pharo-project] return character magic?
It happens with WideStrings, you get the normal display with ByteString instances. To reproduce just print an expression like Character value: 1024 if you can't type non-ascii characters on your keyboard. Now, why the display changes I don't know either ... Lukas On 30 August 2010 20:31, Stéphane Ducasse stephane.duca...@inria.fr wrote: A while ago I got the same with _ Stef On Aug 30, 2010, at 8:28 PM, Johan Brichau wrote: Hi all, Just last week, I had a very strange phenomenon in my Pharo image: the return character (^) was changed by an up arrow (see screenshot below). I was not really able to reproduce the 'problem' but now we got a repeatable one: Just load the attached js file in a Seaside WAFilelibrary (WAFilelibrary addFileAt: ' ...'): you will see that the method will also have such a return char. What is going on? :-) I'm on Mac, using Pharo 1.1. cheers, Johan Screen shot 2010-07-29 at 17.15.29.png A MIME attachment of type application/x-javascript was removed here by a drop-attachments-by-name filter rule on the host mail2-relais-roc.national.inria.fr. ___ 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 -- 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
Re: [Pharo-project] return character magic?
On Aug 30, 2010, at 8:33 PM, Johan Brichau wrote: so what did you do? I see that the file got removed... I will submit a bug issue for that with the file attached. The *real* problem is that you cannot remove it either! It does _not_ want to go away! Oops! A bad spirit in pharo :) For me just resizing the window made it disappeared. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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/. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Inter-image communication
While some of the suggestions (AMQP, STOMP) were over my head, I'm in the process of getting UbiquiTalk to work and already have rST going. But, for my use case i.e. sending remote commands between (only) two images on the same machine, why not just send the commands as strings over a socket, and evaluate them with the compiler? Obviously there's no security, but since it's in-house only... A proof-of-concept is below: Server image: server := Socket newTCP. server listenOn: 8081. server waitForConnectionFor: 600. server sendData: 'Workspace open' Client image: client := Socket newTCP. client connectTo: (NetNameResolver localHostAddress) port: 8081. Compiler evaluate: client receiveData. Add a loop and we're all set. Sean -- View this message in context: http://forum.world.st/Inter-image-communication-tp2320723p2400616.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Squeaksource default license (was Re: WebClient-Core port to Pharo 1.1 final)
quote author=Torsten Bergmann Maybe the license should be a required field in Squeaksource for any new project. /quote Yes! /And/ *default to MIT.* Even though in this case Andreas chose other-than MIT on purpose, how many projects are not MIT simply because the default is a choice other than the one most valuable to the community. Let's use this opportunity to improve for the future :) Sean ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Sockets in Pharo CollaborActive Book
Stef, Noury, Thanks for doing this, and for the preview! Sometimes being a good friend means getting tough, and it's time for that. You are doing a great job of writing up how to create poorly designed socket applications. They are poorly designed because of what we inherit from Squeak. Servers should not listen for a time period; they need to listen until told otherwise, and trigger events (notifications if preferred) when a client tries to connect, at which point a dedicated process accepts the connection - that process more or less is the server. Clients should try to connect and read until told otherwise, either by a watchdog thread or by a user. Nothing should block in either case except the calling Smalltalk Process. If a client program does not hang because of a non-responsive server, an interacting user has the opportunity to hit a cancel button and put an end to wasted effort, or a watchdog can run and similarly #erminate the offending thread. IMHO, we should not direct energy at documenting the current state of sockets; we should do the few remaining things to get something that really works. At the same time, we should try as much as possible to allow IrDA and OpenSSL to appear as options. Bill From: stephane ducasse [stephane.duca...@free.fr] Sent: Monday, August 30, 2010 2:50 PM To: Schwab,Wilhelm K Subject: Fwd: [Pharo-project] Sockets in Pharo CollaborActive Book Begin forwarded message: From: Stéphane Ducasse stephane.duca...@inria.fr Date: August 29, 2010 11:09:50 PM GMT+02:00 To: DeNigris Sean s...@clipperadams.com Subject: Re: [Pharo-project] Sockets in Pharo CollaborActive Book ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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 marianop...@gmail.com: 2010/8/30 Miguel Enrique Cobá Martínez miguel.c...@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
Re: [Pharo-project] return character magic?
2010/8/30 Stéphane Ducasse stephane.duca...@inria.fr: On Aug 30, 2010, at 8:33 PM, Johan Brichau wrote: so what did you do? I see that the file got removed... I will submit a bug issue for that with the file attached. The *real* problem is that you cannot remove it either! It does _not_ want to go away! Oops! A bad spirit in pharo :) Any person able to understand MultiDisplayScanner arcanes wouldn't see any magic in this. But I really wonder whether a single person can manage such complexity... Henrik ? Nicolas For me just resizing the window made it disappeared. ___ 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
Re: [Pharo-project] Sockets in Pharo CollaborActive Book
Stef, Noury, Thanks for doing this, and for the preview! Sometimes being a good friend means getting tough, and it's time for that. You are doing a great job of writing up how to create poorly designed socket applications. They are poorly designed because of what we inherit from Squeak. Servers should not listen for a time period; they need to listen until told otherwise, and trigger events (notifications if preferred) when a client tries to connect, at which point a dedicated process accepts the connection - that process more or less is the server. Clients should try to connect and read until told otherwise, either by a watchdog thread or by a user. Nothing should block in either case except the calling Smalltalk Process. If a client program does not hang because of a non-responsive server, an interacting user has the opportunity to hit a cancel button and put an end to wasted effort, or a watchdog can run and similarly #erminate the offending thread. John pointed us to a kind of socket that raises events on data. Our problem is that we do not have manpower for that. IMHO, we should not direct energy at documenting the current state of sockets; we should do the few remaining things to get something that really works. At the same time, we should try as much as possible to allow IrDA and OpenSSL to appear as options. Noury and luc started to rewrite sockets using Alien and people can help. Nothing will happen magically :) Bill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Sockets in Pharo CollaborActive Book
On Mon, Aug 30, 2010 at 5:09 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Stef, Noury, Thanks for doing this, and for the preview! Sometimes being a good friend means getting tough, and it's time for that. You are doing a great job of writing up how to create poorly designed socket applications. They are poorly designed because of what we inherit from Squeak. Servers should not listen for a time period; they need to listen until told otherwise, and trigger events (notifications if preferred) when a client tries to connect, at which point a dedicated process accepts the connection - that process more or less is the server. Clients should try to connect and read until told otherwise, either by a watchdog thread or by a user. Nothing should block in either case except the calling Smalltalk Process. If a client program does not hang because of a non-responsive server, an interacting user has the opportunity to hit a cancel button and put an end to wasted effort, or a watchdog can run and similarly #erminate the offending thread. John pointed us to a kind of socket that raises events on data. Our problem is that we do not have manpower for that. IMHO, we should not direct energy at documenting the current state of sockets; we should do the few remaining things to get something that really works. At the same time, we should try as much as possible to allow IrDA and OpenSSL to appear as options. Noury and luc started to rewrite sockets using Alien and people can help. Nothing will happen magically :) How should I help with that (a little)? Cheers, Guille Bill ___ 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Sockets in Pharo CollaborActive Book
Stef, Where does one go to sign up? I am not certain that Alien is appropriate or necessary to make a solid socket foundation, but I am certain that the existing code is very sub-optimal and needs a real jolt. If we are serious about fixing it (Linux, Windows and Mac), I am serious about helping. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.duca...@inria.fr] Sent: Monday, August 30, 2010 4:09 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Sockets in Pharo CollaborActive Book Stef, Noury, Thanks for doing this, and for the preview! Sometimes being a good friend means getting tough, and it's time for that. You are doing a great job of writing up how to create poorly designed socket applications. They are poorly designed because of what we inherit from Squeak. Servers should not listen for a time period; they need to listen until told otherwise, and trigger events (notifications if preferred) when a client tries to connect, at which point a dedicated process accepts the connection - that process more or less is the server. Clients should try to connect and read until told otherwise, either by a watchdog thread or by a user. Nothing should block in either case except the calling Smalltalk Process. If a client program does not hang because of a non-responsive server, an interacting user has the opportunity to hit a cancel button and put an end to wasted effort, or a watchdog can run and similarly #erminate the offending thread. John pointed us to a kind of socket that raises events on data. Our problem is that we do not have manpower for that. IMHO, we should not direct energy at documenting the current state of sockets; we should do the few remaining things to get something that really works. At the same time, we should try as much as possible to allow IrDA and OpenSSL to appear as options. Noury and luc started to rewrite sockets using Alien and people can help. Nothing will happen magically :) Bill ___ 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
Re: [Pharo-project] SerialPort - named ports on Linux
On Mon, Aug 30, 2010 at 02:24:37PM -0400, Schwab,Wilhelm K wrote: Hello all, I recalled seeing mention of the Linux vm's now supporting named ports, and I found the code for that, at least in the vm. My understanding gets fuzzy as we enter the plugin and primitives. At a minimum, there are a few ByName methods to be added, and Squeak 4.1 contains open and close methods that test on type (int vs. string) to open or close by name or not as appropriate. Is this as simple as gathering the changes and adding them to Pharo, or does it require VMMaker magic? Bill, I don't have a Pharo image handy to check right now, but look at class SerialPort. Methods such as #openPort: should accept either integer (port number) or string (named device) parameters (if not, grab it from a Squeak image). All changes are in the VMs already, so there is nothing to worry about on the VMMaker side. If you need the background on this, it's at http://bugs.squeak.org/view.php?id=7266. Dave ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Sockets in Pharo CollaborActive Book
Your English does not suck as bad as Squeak's sockets framework :) I'm in too. I can't do it all, but I can help and I can certainly set a high bar by ensuring that it works across Linux and Windows and does not lock when the network hardware loses power. Sockets are sufficiently fundamental that we should document how to use them properly AND make Pharo work that way. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopol...@gmail.com] Sent: Monday, August 30, 2010 4:16 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Sockets in Pharo CollaborActive Book My english sucks :P. It's How can I help with that? xD On Mon, Aug 30, 2010 at 5:15 PM, Guillermo Polito guillermopol...@gmail.commailto:guillermopol...@gmail.com wrote: On Mon, Aug 30, 2010 at 5:09 PM, Stéphane Ducasse stephane.duca...@inria.frmailto:stephane.duca...@inria.fr wrote: Stef, Noury, Thanks for doing this, and for the preview! Sometimes being a good friend means getting tough, and it's time for that. You are doing a great job of writing up how to create poorly designed socket applications. They are poorly designed because of what we inherit from Squeak. Servers should not listen for a time period; they need to listen until told otherwise, and trigger events (notifications if preferred) when a client tries to connect, at which point a dedicated process accepts the connection - that process more or less is the server. Clients should try to connect and read until told otherwise, either by a watchdog thread or by a user. Nothing should block in either case except the calling Smalltalk Process. If a client program does not hang because of a non-responsive server, an interacting user has the opportunity to hit a cancel button and put an end to wasted effort, or a watchdog can run and similarly #erminate the offending thread. John pointed us to a kind of socket that raises events on data. Our problem is that we do not have manpower for that. IMHO, we should not direct energy at documenting the current state of sockets; we should do the few remaining things to get something that really works. At the same time, we should try as much as possible to allow IrDA and OpenSSL to appear as options. Noury and luc started to rewrite sockets using Alien and people can help. Nothing will happen magically :) How should I help with that (a little)? Cheers, Guille Bill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.frmailto: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
Re: [Pharo-project] SerialPort - named ports on Linux
Dave, It's not obvious to me that Pharo won't take strings, but it looks that way because Squeak 4.1 has tests on type and by-name methods that are not in Pharo. One thought I had was to file the class out of Squeak and into Pharo, perhaps fixing _ vs. := and any other hassles that might arise. Should that work? Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of David T. Lewis [le...@mail.msen.com] Sent: Monday, August 30, 2010 4:25 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] SerialPort - named ports on Linux On Mon, Aug 30, 2010 at 02:24:37PM -0400, Schwab,Wilhelm K wrote: Hello all, I recalled seeing mention of the Linux vm's now supporting named ports, and I found the code for that, at least in the vm. My understanding gets fuzzy as we enter the plugin and primitives. At a minimum, there are a few ByName methods to be added, and Squeak 4.1 contains open and close methods that test on type (int vs. string) to open or close by name or not as appropriate. Is this as simple as gathering the changes and adding them to Pharo, or does it require VMMaker magic? Bill, I don't have a Pharo image handy to check right now, but look at class SerialPort. Methods such as #openPort: should accept either integer (port number) or string (named device) parameters (if not, grab it from a Squeak image). All changes are in the VMs already, so there is nothing to worry about on the VMMaker side. If you need the background on this, it's at http://bugs.squeak.org/view.php?id=7266. Dave ___ 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
