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

[Pharo-project] Metacello for pharo 1.2
by Cyrille Delaunay Sept. 2, 2010

Sept. 2, 2010

When I try to load moose in a pharo 1.2 image, Metacello is loading (via ConfigurationOfMetacello) an ancient version of OB which is no longer compatible with pharo 1.2 (at least for the use of 'Preferences'). Does anyone know if there is a version of metacello working for 1.2?

3 3

[Pharo-project] programmatically update a Pharo image
by Cyrille Delaunay Sept. 2, 2010

Sept. 2, 2010

Hello, Is there a 'magic' command to programmatically update and load the last version of a Pharo 1.2 core image?

5 14

[Pharo-project] Smalltalk Image writer?
by James Ladd Sept. 2, 2010

Sept. 2, 2010

>>we are interested in a Smalltalk based image writer too :) While I work through reading and writing the Smalltalk image myself (in Java) I'll be writing down what I find. I'd be happy to try and write a Smalltalk based image writer. Please tell me your requirements and I'll try and include them. Rgs, James.

3 2

[Pharo-project] MethodName
by Benjamin Van Ryseghem Sept. 2, 2010

Sept. 2, 2010

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

5 9

Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
by Andreas Raab Sept. 2, 2010

Sept. 2, 2010

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

21 78

Re: [Pharo-project] Smalltalk Image writer?
by James Ladd Sept. 2, 2010

Sept. 2, 2010

Thank John, great suggestion. > Message: 4 > Date: Wed, 1 Sep 2010 19:05:43 -0700 > From: John M McIntosh <johnmci(a)smalltalkconsulting.com> > Subject: Re: [Pharo-project] Smalltalk Image writer? > To: Pharo-project(a)lists.gforge.inria.fr > Message-ID: > <CCE85492-BBB6-4F08-BCC5-84F08A00FA5A(a)smalltalkconsulting.com> > Content-Type: text/plain; charset="us-ascii" > > You should look at the > > http://www.squeaksource.com/SystemTracing > SystemTracer64 writeImage: 'squeak64.image'. > > That is setup to take a 32bit image and create a 64bit image file by writing out all the bits... > >

1 0

Re: [Pharo-project] Serial ports on Linux
by Schwab,Wilhelm K Sept. 2, 2010

Sept. 2, 2010

Markus, If you have some experience with serial I/O on Linux, I would appreciate your giving it a quick shakedown; if it is just plain broken or is still known to work, it would be nice to confirm either way. I would like to use the binary distribution, but it does not report enough of what it is trying to do (so no clues when things fail) and I end up hacking to add tracing with possible installation troubles as a result. That said, this time around, I find myself in serialPortOpenByName() and puzzled by the failure being allegedly detected by: /* save the old state */ if (tcgetattr(sp->spDescriptor, &sp->spTermios)) My question: is there old state to save on the first pass? errno is not helpful; it is set to 5 aka I/O error :( I find myself wondering whether this should be conditional on the internal state of the descriptor, and the failure to open simply being that it gives up too easily? Then again, it could be detecting a true error condition and preventing certain disaster in the lines that would follow. Any ideas? I can't get /dev/ttyS0 to open by name or number. 'COM1' worked nicely on Windows. Bill Markus Lampert markuslampert at yahoo.com Wed Sep 1 15:28:38 UTC 2010 Hi Bill, haven't used the serial interface with the new VMs (yet), but previously under Linux I had to use the vm option '-notimer'. I did not find any negative side effects with that option. Hope this helps, Markus

1 1

[Pharo-project] Deleted or renamed behaviors
by HernÃ¡n Morales Durand Sept. 1, 2010

Sept. 1, 2010

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

2 5

Re: [Pharo-project] Linux vm default plugins directory
by Schwab,Wilhelm K Sept. 1, 2010

Sept. 1, 2010

Bert, Eliot, FWIW, I have had terrible results with LD_LIBRARY_PATH on Ubuntu - maybe I'm just missing something. I probably should let the squeak script handle it, but it seems silly to use a script to call a script, so I've typically gone straight to the vm; that appears to be getting harder to do with time. About plugins not loading, my big point is that we should not have to guess about what is or is not happening. The vm does not provide enough information to reliably fix problems. Bill On 01.09.2010, at 21:12, Eliot Miranda wrote: > Hi Wilhelm, > > On Wed, Sep 1, 2010 at 12:01 PM, Schwab,Wilhelm K <bschwab at anest.ufl.edu> wrote: > >> A recurring theme is that I encounter a problem for which there is no explanation from the system, hack the vm sources to add some tracing, and correct the problem. As a result, I end up building the vm from source and so tend to use a shell script that runs it. >> > Set LD_LIBRARY_PATH to include the relevant directory. Here's the script I use at Teleplace The current "squeak" script fills in the plugins path, so there is no need to fiddle with LD_LIBRARY_PATH. http://squeakvm.org/svn/squeak/trunk/platforms/unix/cmake/squeak.in However, I occasionally too see a plugin that inexplicably does not want to load. - Bert -

1 0

[Pharo-project] Linux vm default plugins directory
by Schwab,Wilhelm K Sept. 1, 2010

Sept. 1, 2010

A recurring theme is that I encounter a problem for which there is no explanation from the system, hack the vm sources to add some tracing, and correct the problem. As a result, I end up building the vm from source and so tend to use a shell script that runs it. FWIW, without a -plugins option, this is what happens with the current sources: Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.vm-sound-OSS Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.vm-sound-MacOSX Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.vm-sound-Sun Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.vm-sound-pulse Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.vm-sound-ALSA Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.MiscPrimitivePlugin Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.FilePlugin Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.SecurityPlugin Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.LargeIntegers Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.BitBltPlugin Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.B2DPlugin Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.LocalePlugin Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.SocketPlugin Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.FloatArrayPlugin Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.Matrix2x3Plugin Note the extra / in the paths. Some of the plugins should fail to load; the point is that *all* of them fail to load. Bill

1 0