September 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Deleted or renamed behaviors

by StÃ©phane Ducasse

what is the idea? What we want to do with veronica is - get a declarative code model (MC2/Ginsu) --> - put all the version of squeak and pharo in a Gemstone DB - make sure that we can do historized queries sender in version 1.0 - diff between versions Stef On Aug 31, 2010, at 9:17 PM, HernÃ¡n Morales Durand wrote: > Ok, thanks for the reply. I've created a repository in SqS for a tool > supporting better tracking of change history > > http://www.squeaksource.com/ChangeTracker.html > > please do not hesitate to contact me to join this project. I'm > planning to use the OB framework but any suggestions are welcomed. > Cheers, > > HernÃ¡n > > 2010/8/31 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> not directly but indeed we should be much more imaginative with our tools. >> Now I'm spending my time on not really funny or exciting actions so I do not have time >> to invent new stuff and this is bad. >> I'm trying to make sure that this situation will change but so far still crawling. >> This is why we will add RB in Unstable because we should use powertools in Unstable. >> >> Stef >> >> On Aug 31, 2010, at 6:46 PM, HernÃ¡n Morales Durand wrote: >> >>> Hi all, >>> >>> Is there a tool to observe the replacements of renamed or removed >>> methods in Pharo? >>> Because it happened to me several times, when loading a package in >>> Pharo two or three months after I've released something, there are >>> methods removed and I have to search the change comments everywhere >>> (change log, mailing list, issues list, etc) and figure out the >>> replacements, and sometimes it isn't so direct. >>> Cheers, >>> >>> HernÃ¡n >>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > 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

Re: [Pharo-project] Memory problems on Windows

by StÃ©phane Ducasse

do you have the same problem with the normal VM? On Sep 1, 2010, at 5:25 AM, Jimmie Houchin wrote: > 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 > > > _______________________________________________ > 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] Fwd: Pharo1.1 bug report

by StÃ©phane Ducasse

Begin forwarded message: > From: Reza Razavi <razavi(a)acm.org> > Date: September 1, 2010 11:08:30 AM GMT+02:00 > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: Pharo1.1 bug report > > Salut Stef, > > Je voudrais te faire part ci-joint d'un rapport gÃ©nÃ©rÃ© par Pharo1.1 [Latest update: #11411], losqu'il rentre dans une boucle infinie (cf. ci-dessous pour les conditions). Je l'ai observÃ© aussi bien sous Linux (Ubuntu) que Windows (Vista). Toutefois, sous Linux, au bout d'une longue attente, la VM m'a affichÃ© un message dont la copie est Ã©galement jointe au format PNG. > > Ceci devrait Ãªtre rÃ©pÃ©table de la maniÃ¨re suivante (j'ai mis du temps avant de trouver) : > - Sauvegarder l'image avec des browsers ouverts > - AprÃ¨s un certain temps, je ne sais en effet pas quelle Ã©tait au juste la durÃ©e d'ouverture des browsers, on passe le curseur sur l'un des deux boutons " Instance " et " Classe ". > > J'espÃ¨re que ceci soit utile, > Bonne continuation, > Reza >

Sept. 1, 2010

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

by StÃ©phane Ducasse

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

Sept. 1, 2010

Re: [Pharo-project] Two notes on Sockets! (was Re: Sockets in Pharo CollaborActive Book)

by GÃ¶ran Krampe

Hi! On 09/01/2010 10:04 AM, StÃ©phane Ducasse wrote: >> 2. I haven't looked at Andreas' new WebServer but I presume it is a "standard" forking server just like the old Comanche/KomHttpServer codebase is. A while back I wrote Blackfoot - a SimpleCGI implementation and then I extracted the essential "forking Socket server" code from KomHttpServer so that it can be easily understood and reused. I tend to point to Blackfoot as a very good "example" to use in this regard. We could even split out the generic part as a "standard class" to use. In fact, Stephen Pair did this with the TcpServices library a long time ago when he rewrote Comanche into KomHttpServer BUT... I think it got a bit overengineered and would instead point to Blackfoot as a good candidate for such a "SocketServer" class. > > sound cool do you have a little 2 pages intro to blackfoot? Blackfoot in itself is a SimpleCGI implementation, I presented it on an OOPSLA back in... 2006 or so: http://goran.krampe.se/Blackfoot.pdf ...but my point was that it can easily serve as a good SIMPLE example of a forking Socket server using SocketStream. It is VERY small and IIRC the base "forking Socket server" is separate. regards, GÃ¶ran

Sept. 1, 2010

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

by Torsten Bergmann

>Well VBA and Excel is well working, I doubt that OpenOffice Basic can >compete with it. Yes, thats why I started to write a COM wrapper for Squeak in 2008 - unfortunately stopped due to missing time and missing callbacks in FFI. And Alien (providing callbacks) is still not available ... Using COM would open the whole windows world (from Office to SAP, ...) and by using CCW' and RCW's one could also use the .NET world. However - there was/is also a Squeak .NET bridge one can use. BTW: Did you look at Javas/Apache FOP? I know it is used by a few Seaside apps to create PDF's using XSL-FO. Bye T. -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

Sept. 1, 2010

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

by StÃ©phane Ducasse

would be cool to get inspired and produce material for smalltalkers. On Sep 1, 2010, at 9:03 AM, Michael Roberts wrote: >>> >> Cool, I appreciate you getting the ball rolling - I am trying to push it >> further! (and I don't know too much about sockets) > > no worries. I have found this guide really useful: http://beej.us/guide/bgnet/ > > Even if you don't read C, there are lots of comments throughout. > > cheers > Mike > > _______________________________________________ > 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

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

by Yang Ha Nguyen

On Wed, Sep 01, 2010 at 09:09:07AM +0200, Friedrich Dominicus wrote: >"Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> writes: > >And let's be honest a second time. MS-Office is the Standard by any >means. Yes there is LaTex and yes there is OpenOffice but sorry if >anyone talks about Office Software they mean MS-Office. And we have to >admit that the MS-Office tools are extremly useful, especially Excel is >quite good at that spreadsheets can do ;-) > I don't think there is some one who is not honest in this topic. M$-Office is *popular* doesn't mean that it's the standard. Talking about office suite doesn't imply that it's the office suite from M$, except for the situation that you were grown in a M$'s dominated education system. What feature makes OpenOffice.org not useful? Except for just not being able to perfectly handle M$'s proprietary format? Have you ever used OpenOffice.org Calc for your own sake? >> >> OpenOffice has some type of (Java??) scripting interface. That might >> be a little better and perhaps even friendlier than MS' offerings and >> might then be induced to create .xls files. >Well VBA and Excel is well working, I doubt that OpenOffice Basic can >compete with it. > Oh, I didn't know that OpenOffice.org Basic is a spreadsheet software. I doubt I've ever heard of its name as an spreadsheet application. M$ Excel just works with its own closed source VBA version, my OpenOffice.org Calc works with VBA, Python, and Java scripting languages. I've never spent a lot of time writing and maintaining source code with Python as with VB. What makes it not a good competitor to M$ Excel? Best regards, -- Yang Nguyen Life is a hack

Sept. 1, 2010

Re: [Pharo-project] Two notes on Sockets! (was Re: Sockets in Pharo CollaborActive Book)

by StÃ©phane Ducasse

On Sep 1, 2010, at 8:58 AM, GÃ¶ran Krampe wrote: > Hi all! > > Two notes (no, haven't read all posts on this subject): > > 1. IMHO for almost 99% of your needs you would use SocketStream and not Socket directly to write a socket client. I wrote the current SocketStream implementation and I have written several clients using it - like the latest StompProtocol on SS etc. Please, please, use SocketStream in your introduction to socket client programming! Yes this is the missing section in noury/luc chapter :) > 2. I haven't looked at Andreas' new WebServer but I presume it is a "standard" forking server just like the old Comanche/KomHttpServer codebase is. A while back I wrote Blackfoot - a SimpleCGI implementation and then I extracted the essential "forking Socket server" code from KomHttpServer so that it can be easily understood and reused. I tend to point to Blackfoot as a very good "example" to use in this regard. We could even split out the generic part as a "standard class" to use. In fact, Stephen Pair did this with the TcpServices library a long time ago when he rewrote Comanche into KomHttpServer BUT... I think it got a bit overengineered and would instead point to Blackfoot as a good candidate for such a "SocketServer" class. sound cool do you have a little 2 pages intro to blackfoot? Stef > > > regards, GÃ¶ran > > _______________________________________________ > 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

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

by StÃ©phane Ducasse

please continue :) On Sep 1, 2010, at 1:17 AM, Michael Roberts wrote: > 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 > > _______________________________________________ > 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