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

[Pharo-project] OSX Pharo Shout Workspace is laggy

by sergio_101

i just downloaded the latest pharo image, and everything seems good, but the problem i am having is that when the dropdowns appear for tab completion, there is a noticeable lag in the system. it takes a few seconds to select one of the drop down items.. about four seconds or so.. my machine is a newer high powered macbook pro.. has anyone seen anything like this before? thanks! -- ---- peace, sergio photographer, journalist, visionary http://www.CodingForHire.com http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101

Nov. 6, 2010

Re: [Pharo-project] Writing API for XML (WAX) - Bibliography example

by jaayer

---- On Wed, 03 Nov 2010 11:28:13 -0700 Hannes Hirzel wrote ---- >Is XMLWriter in the upcoming 1.2 image? It is not in the 1.1 image. > >--Hannes The new XML writer is in the more recent versions, from version 96 on, but at the moment you have to download it manually through Monticello or from the XMLSupport page on squeaksource.com, as the most recent Metacello configuration still points to v. 93. I'll try to update it shortly.

Nov. 5, 2010

Re: [Pharo-project] Bugreport?

by Mariano Martinez Peck

Yes, usually, since SqueakVM is 32 bits, on a 64 bits OS, you need to install the 32bits OS libraries. For example, in Ubuntu, I remember doing: "*sudo* *apt*-*get* install ia32-libs" cheers mariano On Fri, Nov 5, 2010 at 6:32 PM, bb <bblochl(a)arcor.de> wrote: > Am 05.11.2010 10:31, schrieb bb: > > Am 05.11.2010 10:09, schrieb bb: > >> I tried to proceed as described on > >> http://pharo-project.org/community/issue-tracking and tried to search > in > >> the mailing list in the archive. But in trying to access the archive I > >> get the message from Nabble(?): > >> > >> This node has been deleted > >> > >> Here a problem description: > >> > >> I installed Pharo latest version on debian lenny 64 bit and it works > >> properly from start on, but I had/have some problems with Squeak. > >> > >> I installed Pharo (same procedure as above) on red hat 64 bit Kernel > >> 2.6.34.7-61.fc13.x86_64, AMD Turion 64 X2 Mobile Technology TL-56 and it > >> does not work, but Squeak works properly. The message is: > >> > >> [bb@localhost Pharo-1.1-OneClick.app]$ ./pharo.sh > >> libGLU.so.1: cannot open shared object file: No such file or directory > >> could not find module vm-display-X11 > >> Abgebrochen (Speicherabzug geschrieben) > >> [bb@localhost Pharo-1.1-OneClick.app] > >> > >> I installed repeatedly and tried to use available VM's from Squeak and > >> also tried some other "tricks", i.e copy all Pharo-files in the same > >> directory ... > >> > >> May be someone else has some experience with Pharon on red hat? > >> > >> Please tell me if it is worth to make a ticket? > >> > >> Regards BB > >> > > Appendix: The libGLU runtime library + development package are > > installed. I will check if there is something on error with that > > packages on fedora/red hat. > > > > May be someone else has some extended expirence with this issue? > > > > Tegards BB > > > > Thanks for the correct link for bug-reporting! > > Thanks for many helping contributions and help to that topic! > > At least I found a striking explanation and I think the developers of > Pharo might take care of: > > The libGLU-files on fedora13 are not in the directory /usr/lib but in > /usr/lib64. I cross-checked debian lenny and found that libs in > /usr/lib. (lenny does have a directory usr/lib64 as well.) > > I had to deal with such differences of different Linux brands and while > moving to 64 bit very often in the past. > > I am not a Pharo-developer, but I recommend to check the pathes set and > eventually extend the settings with the 64-bit alternatives. > > An alternative might be a hard link? > > ~$ ln /usr/lib64/libGLU.so.1 /usr/lib/libGLU.so.1 > > But now I ave another error message: > > ~ Pharo-1.1-OneClick.app]$ ./pharo.sh > libGLU.so.1: wrong ELF class: ELFCLASS64 > could not find module vm-display-X11 > Abgebrochen (Speicherabzug geschrieben) > > I am not allmighty and more or less just a hobbyist with just an > underdeveloped CS knowledge, but I think that there is a trial to link a > 32 bit Pharo with an object-file (libGLU.so.1) which was compiled for 64 > bit? (May be that debian still delivers a 32 bit object file, so it > works??) > > One might try to recompile with the '-m64' flag of gcc. May be a > compilerrun with correct autoconf (configure) scripts, set to CC="gcc > -m64" (or CC="gcc -m32") might help? > > So I would say, the problem is fixed but not solved. > > Regards BB > >

Nov. 5, 2010

Re: [Pharo-project] Bugreport?

by bb

Am 05.11.2010 10:31, schrieb bb: > Am 05.11.2010 10:09, schrieb bb: >> I tried to proceed as described on >> http://pharo-project.org/community/issue-tracking and tried to search in >> the mailing list in the archive. But in trying to access the archive I >> get the message from Nabble(?): >> >> This node has been deleted >> >> Here a problem description: >> >> I installed Pharo latest version on debian lenny 64 bit and it works >> properly from start on, but I had/have some problems with Squeak. >> >> I installed Pharo (same procedure as above) on red hat 64 bit Kernel >> 2.6.34.7-61.fc13.x86_64, AMD Turion 64 X2 Mobile Technology TL-56 and it >> does not work, but Squeak works properly. The message is: >> >> [bb@localhost Pharo-1.1-OneClick.app]$ ./pharo.sh >> libGLU.so.1: cannot open shared object file: No such file or directory >> could not find module vm-display-X11 >> Abgebrochen (Speicherabzug geschrieben) >> [bb@localhost Pharo-1.1-OneClick.app] >> >> I installed repeatedly and tried to use available VM's from Squeak and >> also tried some other "tricks", i.e copy all Pharo-files in the same >> directory ... >> >> May be someone else has some experience with Pharon on red hat? >> >> Please tell me if it is worth to make a ticket? >> >> Regards BB >> > Appendix: The libGLU runtime library + development package are > installed. I will check if there is something on error with that > packages on fedora/red hat. > > May be someone else has some extended expirence with this issue? > > Tegards BB > Thanks for the correct link for bug-reporting! Thanks for many helping contributions and help to that topic! At least I found a striking explanation and I think the developers of Pharo might take care of: The libGLU-files on fedora13 are not in the directory /usr/lib but in /usr/lib64. I cross-checked debian lenny and found that libs in /usr/lib. (lenny does have a directory usr/lib64 as well.) I had to deal with such differences of different Linux brands and while moving to 64 bit very often in the past. I am not a Pharo-developer, but I recommend to check the pathes set and eventually extend the settings with the 64-bit alternatives. An alternative might be a hard link? ~$ ln /usr/lib64/libGLU.so.1 /usr/lib/libGLU.so.1 But now I ave another error message: ~ Pharo-1.1-OneClick.app]$ ./pharo.sh libGLU.so.1: wrong ELF class: ELFCLASS64 could not find module vm-display-X11 Abgebrochen (Speicherabzug geschrieben) I am not allmighty and more or less just a hobbyist with just an underdeveloped CS knowledge, but I think that there is a trial to link a 32 bit Pharo with an object-file (libGLU.so.1) which was compiled for 64 bit? (May be that debian still delivers a 32 bit object file, so it works??) One might try to recompile with the '-m64' flag of gcc. May be a compilerrun with correct autoconf (configure) scripts, set to CC="gcc -m64" (or CC="gcc -m32") might help? So I would say, the problem is fixed but not solved. Regards BB

Nov. 5, 2010

Re: [Pharo-project] RoarVM - Pharo and Squeak on Multicore

by Igor Stasenko

On 5 November 2010 16:49, Stefan Marr <pharo(a)stefan-marr.de> wrote: > Hi: > > > On 03 Nov 2010, at 23:59, Stefan Marr wrote: >> Probably our VM is behaving slightly different from what the SqueakVM. (Not sure what the 'right' thing to do is thought) >> >> From my understanding, the idea is that if there is no event, the primitive will fail. >> And all other images have that case covered. They set the first array index to EventTypeNone. >> >> Thus, "InputEventFetcher>>primGetNextEvent: array" should look like: >> >> primGetNextEvent: array >> Â Â Â "Store the next OS event available into the provided array. >> Â Â Â Essential." >> Â Â Â <primitive: 94> >> Â Â Â array at: 1 put: EventTypeNone. "STEFAN: Added this line" >> Â Â Â ^nil >> >> However, since Pharo works on the other VM, I guess the primitive there is filling in the first slot of the array anyway. >> So, what is the specification? I think the primitives have changed since 'the bluebook'. > > Just to ask that question again: What is the conclusion, is the bug in the image or in the VM? > Here the Squeak implementation of it: primGetNextEvent: array "Store the next OS event available into the provided array. Essential. If the VM is not event driven the ST code will fall back to the old-style mechanism and use the state based primitives instead." | kbd buttons modifiers pos mapped | <primitive: 94> "Simulate the events" array at: 1 put: EventTypeNone. "assume no more events" "First check for keyboard" kbd := super primKbdNext. kbd = nil ifFalse:[ "simulate keyboard event" array at: 1 put: EventTypeKeyboard. "evt type" array at: 2 put: Time millisecondClockValue. "time stamp" array at: 3 put: (kbd bitAnd: 255). "char code" array at: 4 put: EventKeyChar. "key press/release" array at: 5 put: (kbd bitShift: -8). "modifier keys" ^self]. "Then check for mouse" buttons := super primMouseButtons. pos := super primMousePt. modifiers := buttons bitShift: -3. buttons := buttons bitAnd: 7. mapped := self mapButtons: buttons modifiers: modifiers. (pos = mousePosition and:[(mapped bitOr: (modifiers bitShift: 3)) = mouseButtons]) ifTrue:[^self]. array at: 1 put: EventTypeMouse; at: 2 put: Time millisecondClockValue; at: 3 put: pos x; at: 4 put: pos y; at: 5 put: mapped; at: 6 put: modifiers. so, i assume that problem is in Pharo , which does not handling a primitive failure correctly (by setting array at: 1 put: EventTypeNone. ) > Thanks > Stefan > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: Â +32 2 629 3525 > > > -- Best regards, Igor Stasenko AKA sig.

Nov. 5, 2010

Re: [Pharo-project] Pharo and Astronomy?

by Sean P. DeNigris

To use Ruby's Mechanize gem, I just wrote a small Ruby script that allows messages to be sent to Ruby objects. It runs an augmented XMLRPC server that caches non-XMLRPC Ruby objects and passes back an identifier to Smalltalk. Here's a snippet of my post to squeak-dev. All of the messages return proxies to Ruby objects, except the last, which returns an array of strings. Check the "Wrapping Ruby libraries - what is the best way?" thread for more info... ...run the following code in Squeak: agent := Mechanize new. loginPage := agent get: 'https://www.[a site here].com/home'. loginForm := loginPage formWith: #action -> '/login'. loginForm set: 'username' fieldTo: 'username'. loginForm set: 'password' fieldTo: 'password'. homePage := loginForm submit. mailPage := agent get: 'https://www.[a site here].com/messages'. messageLinks := mailPage linksWith: #href -> 'messages\?readmsg=true&threadid='. messages := messageLinks collect: [ :link | link click body ]. All of those messages were handled by the generic server code on the Ruby side except for mailPage linksWith:, which passes a Ruby regex, which is not supported by XMLRPC. Todo: * still deciding how much info to bring over to Squeak and when e.g. just the id, the inst vars, etc. * extending XMLRPC to handle Squeak/Ruby common types, like symbols * toying with the idea of using DNU to dynamically create the methods on the ST side (hand-written for now) * thinking about whether to look at OMeta or PetitParser HTH, Sean -- View this message in context: http://forum.world.st/Pharo-and-Astronomy-tp3027615p3029271.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 5, 2010

Re: [Pharo-project] RoarVM - Pharo and Squeak on Multicore

by Eagle Offshore

So how does it spread out the workload? Where can I read more about how it handles concurrency and race conditions? On Nov 3, 2010, at 1:10 AM, Torsten Bergmann wrote: > Read more: > > http://astares.blogspot.com/2010/11/roarvm-pharo-and-squeak-on-multicore.ht… > -- > GRATIS! Movie-FLAT mit Ã¼ber 300 Videos. > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome >

Nov. 5, 2010

Re: [Pharo-project] Pharo and Astronomy?

by Alexandre Bergel

> What numerical techniques are important to you? I am not sure exactly. As I said, I am trying to convince Astronomers :-) I will forward your post to them. Cheers, Alexandre > How large are the typical data sets, grids, etc? I do a lot of processing on 500,000 sample signals, so Smalltalk is out for most of that number crunching (FFT, DWT, norms, etc.) and visualization. So far, I could probably get away with Smalltalk curve fitting, but that won't always be the case. One option would be to tell NR and GSL "thanks but no thanks" and find or start an MIT numerics library. In my mind, it should be C-callable C++; the trick to that is proper use of extern "C". > > Just to make it clear, I have large parts of GSL mapped into Pharo. My concern now is how to release that w/o being adversely affected by GPL; help with understanding "GPL compatible licenses" would be appreciated. Like I said, I don't care what anyone else does with the code, but I won't have years of my work rendered useless to me for commercial interests. Nothing in GSL is worth taking that risk. There should not be any problem releasing the function definitions; the question is over how much, if any, of the wrappers I can release w/o losing it all to GPL. > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Alexandre Bergel [alexandre(a)bergel.eu] > Sent: Friday, November 05, 2010 7:24 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Pharo and Astronomy? > > Thanks Bill. I am at the stage of convincing Astronomers to use Pharo to do their soft, but this is not easy > > Cheers, > Alexandre > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 5, 2010

Re: [Pharo-project] Bugreport?

by Geert Claes

On Fri, Nov 5, 2010 at 4:15 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > > > On Fri, Nov 5, 2010 at 6:09 AM, bb <bblochl(a)arcor.de> wrote: > >> I tried to proceed as described on >> http://pharo-project.org/community/issue-tracking and tried to search in >> the mailing list in the archive. But in trying to access the archive I >> get the message from Nabble(?): >> >> > I think Nabble has changed. Geert may help. > > This should work: > http://forum.world.st/Pharo-Smalltalk-f1294837.html > Yes, the links look like they need updating, I placed all online forums under our own nicer "forum.world.st" subdomain rather than "nabble.com". I thought they said that the old links would keep working but it looks like that has changed. > Adrian: can we update the Nabble link in > http://www.pharo-project.org/community > to this new link? > > Thanks > > Mariano > > This node has been deleted >> >> Here a problem description: >> >> I installed Pharo latest version on debian lenny 64 bit and it works >> properly from start on, but I had/have some problems with Squeak. >> >> I installed Pharo (same procedure as above) on red hat 64 bit Kernel >> 2.6.34.7-61.fc13.x86_64, AMD Turion 64 X2 Mobile Technology TL-56 and it >> does not work, but Squeak works properly. The message is: >> >> [bb@localhost Pharo-1.1-OneClick.app]$ ./pharo.sh >> libGLU.so.1: cannot open shared object file: No such file or directory >> could not find module vm-display-X11 >> Abgebrochen (Speicherabzug geschrieben) >> [bb@localhost Pharo-1.1-OneClick.app] >> >> I installed repeatedly and tried to use available VM's from Squeak and >> also tried some other "tricks", i.e copy all Pharo-files in the same >> directory ... >> >> May be someone else has some experience with Pharon on red hat? >> >> Please tell me if it is worth to make a ticket? >> >> Regards BB >> >> >

Nov. 5, 2010

Re: [Pharo-project] Bugreport?

by Mariano Martinez Peck

On Fri, Nov 5, 2010 at 6:09 AM, bb <bblochl(a)arcor.de> wrote: > I tried to proceed as described on > http://pharo-project.org/community/issue-tracking and tried to search in > the mailing list in the archive. But in trying to access the archive I > get the message from Nabble(?): > > I think Nabble has changed. Geert may help. This should work: http://forum.world.st/Pharo-Smalltalk-f1294837.html Adrian: can we update the Nabble link in http://www.pharo-project.org/community to this new link? Thanks Mariano This node has been deleted > > Here a problem description: > > I installed Pharo latest version on debian lenny 64 bit and it works > properly from start on, but I had/have some problems with Squeak. > > I installed Pharo (same procedure as above) on red hat 64 bit Kernel > 2.6.34.7-61.fc13.x86_64, AMD Turion 64 X2 Mobile Technology TL-56 and it > does not work, but Squeak works properly. The message is: > > [bb@localhost Pharo-1.1-OneClick.app]$ ./pharo.sh > libGLU.so.1: cannot open shared object file: No such file or directory > could not find module vm-display-X11 > Abgebrochen (Speicherabzug geschrieben) > [bb@localhost Pharo-1.1-OneClick.app] > > I installed repeatedly and tried to use available VM's from Squeak and > also tried some other "tricks", i.e copy all Pharo-files in the same > directory ... > > May be someone else has some experience with Pharon on red hat? > > Please tell me if it is worth to make a ticket? > > Regards BB > >

Nov. 5, 2010