- Pharo-dev - lists.pharo.org

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

by Andreas Raab

Hi Sven - I had a quick look at the failing tests on Pharo and they seem mostly the result of bugs in Pharo's Network package. First, MimeDocument>>url needs to return an instance of Url not a string (check the senders; all users of it expect it to be a Url not a string) so if you change that to return a url it'll take care of the pathForFile issue. The failure of testMultiPartPost2 is a combination of two bugs in HTTPSocket. First, there's a typo in getResponseUpTo: at the end (this needs to be #copyFrom:to: (the "to" is missing the colon). Second, there is httpPostMultiPart: which adds an erroneous CrLf at the end of a persistent HTTP/1.1 connection. That causes an interesting series of things to go wrong (which I'm partly still investigating) but the easy solution is to insert a "Connection: close" header. Fixes attached. These are of course also broken in Pharo 1.0 and 1.1. Cheers, - Andreas On 8/30/2010 2:17 AM, Sven Van Caekenberghe wrote: > Hi Andreas, > > Thank you for clarifying your position and for pointing out the lack of a proper license for WebClient code. > > I and other people in the Pharo community made a mistake and we're sorry. We will be more careful in the future. > > But to our defense, as others pointed out, you're communications gave the impression that this was true open source, compatible with the standard Squeak one in spirit. > > Futhermore, and this to your credit as well, you yourself wrote the WebClient-Pharo package, giving the impression that you valued that port. It also proves that you did the actual effort. Thanks you! > > And indeed, you did incorporate some changes, so the intention was certainly there. > > Now, I would not say that we already actually forked the code. We just tried to port it. The process of following your progress proved difficult (you probably made a diff between your and our latest versions), precisely because of some of these little things like #asString, #utf8Encoding, #and:and:and:and:, but also some deeper ones like #pathForFile that kept coming back. > > You have every right to refuse to follow the Pharo Smalltalk spirit or style. I respect that, and the Pharo community as a whole should too. > > But your refusal to do so and the lack of a license give us no alternative than to look for other solutions. > > I wasn't there when the discussion that let to the birth of Pharo took place. But it is clear that the Smalltalk community is too small to not work together. > > The Smalltalk-80 inheritance and the enormeous contributions of the Squeak community over the years should be respected by all. At the same time you cannot ignore the positive effect that Pharo had since then. For me and many others, Pharo definitively has its place, along many other viable Smalltalk implementations. > > Regards, > > Sven > > On 30 Aug 2010, at 00:00, Andreas Raab wrote: > >> Hi Sven, >> >> [cc: pharo list since I think there are some larger issues to discuss] >> >> First of all thank you for your continued interest in WebClient. It is nice to see that people like to use it. However, I'm more than a bit surprised about what you are saying below about having WebClient in Pharo 1.2. Honestly, I was dumbfounded when I went to read some of the discussions on the Pharo list. >> >> May I ask what the due diligence process is for including packages in Pharo? I would have expected that the process includes 1) checking the project page on SS for the license and 2) sending the author a courtesy note along the lines of "hey we want to include your code, are you okay with that?" (in particular if the author of the package isn't on the Pharo list and consequently has no clue about what you're doing). >> >> 1. Regarding WebClient's license, please have a look at any of the following repositories, all of which are under MIT: >> >> http://www.squeaksource.com/Balloon3D.html >> http://www.squeaksource.com/CroquetGL.html >> http://www.squeaksource.com/ToolBuilder.html >> http://www.squeaksource.com/TweakCore.html >> ... etc ... >> >> As you can see, when I mean to put code under the MIT license, I try to state that by including a copy of the license on the front page of the repository as well as setting the license field. Contrary to, for example, the following repositories: >> >> http://www.squeaksource.com/ar.html >> http://www.squeaksource.com/SqueakSSL.html >> http://www.squeaksource.com/WebClient.html >> >> which are not (or not yet) under MIT. Obviously, I'm trying to be as clear as possible on these matters, which is why I was pointing out that your repository incorrectly claims that the version of WebClient in it is LGPLv2. I'm surprised (and shocked) that apparently nobody in Pharo even tries to find out what the license status for WebClient is. >> >> 2. Regarding my intentions / position you'll have to keep in mind that I don't read the Pharo list. I tried to follow it in the past only to be faced with several vicious attacks against Squeak and myself and as a consequence I stopped reading it. Consequently, this is the first time anyone has ever mentioned the inclusion of WebClient in Pharo to me. >> >> In short, my position is that we need more shared libraries, not more forks. You will probably see the irony that I specifically didn't set a license on WebClient to prevent such forks without any prior discussion (under the hopelessly naive assumption that there would be some sort of due diligence process) only to find out that you've forked WebClient already. How very ironic indeed. >> >> Because of my position above, I think WebClient should be an external package, loaded for example via Metacello configuration. In fact, that's exactly why I provided a Metacello configuration to begin with. Can someone perhaps explain where the urge to include (and consequently fork) WebClient comes from? WebClient is a perfectly good external package and for the time being I prefer it should stay that way. If you want to replace HTTPSocket, then have a look at Squeak 4.2 which contains a very simple HTTPSocket implementation that has hooks so that WebClient will be used if it's loaded. >> >> Regarding fixes for Pharo, as far as I know the only changes that I haven't included was a bunch of #asString sprinkled all over the places, and the abominations of replacing #squeakToUtf8 and #utf8ToSqueak with "convert[From|To]WithConverter: UTF8TextConverter new". On both of these issues I feel very strongly; I will not make the code substantially worse only to deal with shortcomings of Pharo. So if you cannot come to a reasonable resolution for these, you'll need the extension methods. Outside of that, I believe that not only have I integrated all the fixes that have been sent to me, I have also added several patches to WebClient-Pharo that provide important fixes for (in Pharo broken) network operations without which WebClient would not work in any released Pharo versions. >> >> Summary: >> * I'm surprised and I'm shocked to see that there is apparently no due diligence regarding new packages in Pharo. I find this in particular shocking giving the wild claims on the Pharo web site that "From the beginning of Pharo we have maintained a strict rule that every contributor has to sign our license agreement." I haven't. (and geez, when did Michael got dropped from the Pharo board?) >> >> * I don't want WebClient to be included in Pharo since this means you will be producing a Pharo-only fork of WebClient which is counter-productive from my perspective. I want WebClient to remain a shared loadable package with a canonical source repository available to all forks of Squeak, including Pharo. >> >> * I have, and will continue to do so, integrate fixes for Pharo as long as I consider them reasonable. If there is interest, I can also provide an updated Metacello configuration; although that really just boils down to updating it to the latest package versions. >> >> Cheers, >> - Andreas > >

Sept. 1, 2010

Re: [Pharo-project] Sockets in Pharo CollaborActive Book

by Miguel Enrique CobÃ¡ MartÃnez

El mar, 31-08-2010 a las 23:59 -0400, Schwab,Wilhelm K escribiÃ³: > The deeper question is whether we want to document how things are, or they they *should be* - which is VERY much different from the eventless and timeout ridden design that we have now. It desperately needs to be redesigned. > Maybe it needs someone to lead the effort. Why don't you begin with this? It appears that you know a lot about sockets. Certainly the pharo community will be grateful of your efforts. But saying again and again that sockets sucks doesn't fix it for anybody, including you. So, as Stef says, less saying, more coding. Very respectfully, show us your code :) Cheers > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Sean P. DeNigris [sean(a)clipperadams.com] > Sent: Tuesday, August 31, 2010 10:41 PM > To: pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Sockets in Pharo CollaborActive Book > > Michael Roberts-2 wrote: > > > > The example > > <snip> > > is only server side. If you follow the sections, you can see I used > > netcat as the client and illustrated some simple cmd line debugging > > techniques. the code above whilst it could of course contains bugs > > and not use the right API is consistent in what it tries to do. > > > Ah, okay. Now I got it. The client temporary variable, along with the fact > that this snippet is a section to itself confused me and I didn't keep > reading. > > >so is this where we want to direct people first? > > Michael Roberts-2 wrote: > > > > well, no, but sockets are fundamental and should be explained. I had > > only imagined it the seed for something bigger. the colab book will > > not expand unless people start somewhere. It is a work in progress as > > well, remember that... > > > Cool, I appreciate you getting the ball rolling - I am trying to push it > further! (and I don't know too much about sockets) > > Sean > -- > View this message in context: http://forum.world.st/Sockets-in-Pharo-CollaborActive-Book-tp2399361p240254… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Sept. 1, 2010

Re: [Pharo-project] Sockets in Pharo CollaborActive Book

by Schwab,Wilhelm K

The deeper question is whether we want to document how things are, or they they *should be* - which is VERY much different from the eventless and timeout ridden design that we have now. It desperately needs to be redesigned. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Sean P. DeNigris [sean(a)clipperadams.com] Sent: Tuesday, August 31, 2010 10:41 PM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Sockets in Pharo CollaborActive Book Michael Roberts-2 wrote: > > The example > <snip> > is only server side. If you follow the sections, you can see I used > netcat as the client and illustrated some simple cmd line debugging > techniques. the code above whilst it could of course contains bugs > and not use the right API is consistent in what it tries to do. > Ah, okay. Now I got it. The client temporary variable, along with the fact that this snippet is a section to itself confused me and I didn't keep reading. >so is this where we want to direct people first? Michael Roberts-2 wrote: > > well, no, but sockets are fundamental and should be explained. I had > only imagined it the seed for something bigger. the colab book will > not expand unless people start somewhere. It is a work in progress as > well, remember that... > Cool, I appreciate you getting the ball rolling - I am trying to push it further! (and I don't know too much about sockets) Sean -- View this message in context: http://forum.world.st/Sockets-in-Pharo-CollaborActive-Book-tp2399361p240254… Sent from the Pharo Smalltalk mailing list archive at Nabble.com. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 1, 2010

[Pharo-project] Serial ports on Linux

by Schwab,Wilhelm K

I have been able to do serial I/O on Windows, but not Linux. Running in a terminal to capture output yields "Error while saving old state" while trying to open just about any number or name I can think of (including 0 and /dev/ttyS0), but the open method gives no indication that there is a problem; it returns a perfectly valid looking serial port with the #port set to whatever it was given. Subsequent reads fail, and are probably a bit more honest about what is happening: "Error while reading: serial port is not open." I am not sure whether that is always the case, but it certainly is on this machine when I try /dev/ttyUSB0, which does not exist here. Any ideas? Bill

Sept. 1, 2010

[Pharo-project] Memory problems on Windows

by Jimmie Houchin

Hello, I am developing an application which processes and generates a large amount of data. In a recent attempt I encountered an Space is Low error. This is occurring in a Pharo 1.1 image using the latest Pharo and Cog VMs. I am opening the vm with the -memory: 1000 parameter. The below code I have applied the from the Squeak list from the 100 Million Objects thread. But the problem occurs at about 500mb of ram on a computer with 3 (or 6) gb of ram, with only 65% of physical ram in use. The os is Vista. Any help in using more memory, as much as necessary for the app, would be greatly appreciated. initializeMemorySettings "Initialize the memory and GC settings to be more in line with QF requirements" "The following settings affect the rate incremental GCs and tenuring" "Limit incremental GC activity to run every 40k allocations" SmalltalkImage current vmParameterAt: 5 put: 40000. "allocations between GCs (default: 4000)" "Limit tenuring threshold to only tenure w/ > 10k survivors" SmalltalkImage current vmParameterAt: 6 put: 10000. "tenuring threshold (default: 2000)" "These settings affect overall memory usage" "Only give memory back to the OS when we have more than 16MB free" SmalltalkImage current vmParameterAt: 24 put: 16*1024*1024. "default 8MB" "Try to keep 8MB headroom at all times" SmalltalkImage current vmParameterAt: 25 put: 8*1024*1024. "default 4MB" "These settings describe what to do when we're close to running out of free space" "Tell the VM that we'd rather grow than spinning in tight GC loops" SmalltalkImage current gcBiasToGrow: true. "default: false" "Tell the VM to do a fullGC for good measure if the above growth exceeded 16MB" SmalltalkImage current gcBiasToGrowLimit: 16*1024*1024. "default: 0" Thanks, Jimmie Houchin

Sept. 1, 2010

Re: [Pharo-project] Sockets in Pharo CollaborActive Book

by Sean P. DeNigris

Michael Roberts-2 wrote: > > The example > <snip> > is only server side. If you follow the sections, you can see I used > netcat as the client and illustrated some simple cmd line debugging > techniques. the code above whilst it could of course contains bugs > and not use the right API is consistent in what it tries to do. > Ah, okay. Now I got it. The client temporary variable, along with the fact that this snippet is a section to itself confused me and I didn't keep reading. >so is this where we want to direct people first? Michael Roberts-2 wrote: > > well, no, but sockets are fundamental and should be explained. I had > only imagined it the seed for something bigger. the colab book will > not expand unless people start somewhere. It is a work in progress as > well, remember that... > Cool, I appreciate you getting the ball rolling - I am trying to push it further! (and I don't know too much about sockets) Sean -- View this message in context: http://forum.world.st/Sockets-in-Pharo-CollaborActive-Book-tp2399361p240254… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Sept. 1, 2010

Re: [Pharo-project] Sockets in Pharo CollaborActive Book

by Michael Roberts

Hi, it just so happens I wrote that section on the colab wiki 1) primarily to play around with the wiki engine 2) I was debugging Magma socket issues and I could not find decent cookbook / snippets to illustrate some simple examples and how to test it outside of Pharo itself. I just thought as an exercise i would write it down.... so in response to this entire thread, huh? The example > > | server client | > server := Socket newTCP. > server listenOn: 12345 backlogSize: 4. > server waitForConnectionFor: 600. > client := server accept. > client receiveData is only server side. If you follow the sections, you can see I used netcat as the client and illustrated some simple cmd line debugging techniques. the code above whilst it could of course contains bugs and not use the right API is consistent in what it tries to do. >so is this where we want to direct people first? well, no, but sockets are fundamental and should be explained. I had only imagined it the seed for something bigger. the colab book will not expand unless people start somewhere. It is a work in progress as well, remember that... I agree it would be great if there could be some synergy between all the documentation efforts. I saw the colab book as a fairly free form area to write stuff down in a simple manner that was hosted on a wiki like space. PBE is a more coherent, dedicated and managed publishing effort. I had imagined the colab wiki could be a feeder for PBE but time will tell. It requires significant effort to produce something of the quality of PBE. cheers, Mike

Aug. 31, 2010

Re: [Pharo-project] squeaksource seems down...

by Sean P. DeNigris

It's working now for me. Sean -- View this message in context: http://forum.world.st/squeaksource-seems-down-tp2402271p2402423.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 31, 2010

Re: [Pharo-project] Distinguishing system and user objects

by Schwab,Wilhelm K

I have been looking at the (horribly named) #timeStamp of methods; if my initials/name appear a substring, then it's a red flag that I might have written it, or at least want to be alerted that I might have unpackaged efforts. The following is a first attempt at releasing the code I use to save a later load packages: http://squeaksource.com/PharoInbox/Migrate-Core-BillSchwab.2.mcz It might not work w/o my stream extensions and other infrastructure - fair warning. If remotely interested, look at the class comment of Migrate; expect to subclass it and override a few methods (#me, #homeGrownPackages) to get it to do anything meaningful. This design allows me to distribute its core functionality but have my own concrete class that is not for public viewing. The #suspectMethodsReport might be of interest to you. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of HernÃ¡n Morales Durand [hernan.morales(a)gmail.com] Sent: Tuesday, August 31, 2010 4:29 PM To: Pharo Development Subject: [Pharo-project] Distinguishing system and user objects Hi guys, Given any Pharo image and a (any) package or class category, how do you find if the package/class category belongs to the official image release? Thanks, HernÃ¡n _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 31, 2010

Re: [Pharo-project] Distinguishing system and user objects

by Miguel Enrique CobÃ¡ MartÃnez

El mar, 31-08-2010 a las 17:29 -0300, HernÃ¡n Morales Durand escribiÃ³: > Hi guys, > > Given any Pharo image and a (any) package or class category, how do > you find if the package/class category belongs to the official image > release? > Thanks, In a pharo dev image there is a packages.txt that is generated in image build time. It contains the list of packages that were added to a Pharo Core image to create a Pharo Dev image. Cheers -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Aug. 31, 2010