- Pharo-dev - lists.pharo.org

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

by Stefan Marr

On 06 Nov 2010, at 10:16, StÃ©phane Ducasse wrote: > Should it be included in pharo? > IfTrue: open a bug tracker issue That depends on what you think is the correct thing to do... Anyway: http://code.google.com/p/pharo/issues/detail?id=3209 -- 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

Nov. 6, 2010

Re: [Pharo-project] [Ann][Cuis] New Cuis Release

by StÃ©phane Ducasse

I found them. Now the question is how to handle the list.... On Nov 6, 2010, at 10:24 AM, StÃ©phane Ducasse wrote: > > On Nov 5, 2010, at 2:41 PM, Juan Vuletich wrote: > >> Hi Folks, >> >> Cuis 2.8 is available at www.jvuletich.org/Cuis/Index.html . The release notes describes changes in recent versions (starting at 2.0). I believe many of the enhancements could be also useful for Pharo and rather easy to harvest. So, take a look! > > > Do you have a list of CSes somewhere? > >> >> Cheers, >> Juan Vuletich >> > >

Nov. 6, 2010

Re: [Pharo-project] [Ann][Cuis] New Cuis Release

by StÃ©phane Ducasse

On Nov 5, 2010, at 2:41 PM, Juan Vuletich wrote: > Hi Folks, > > Cuis 2.8 is available at www.jvuletich.org/Cuis/Index.html . The release notes describes changes in recent versions (starting at 2.0). I believe many of the enhancements could be also useful for Pharo and rather easy to harvest. So, take a look! Do you have a list of CSes somewhere? > > Cheers, > Juan Vuletich >

Nov. 6, 2010

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

by StÃ©phane Ducasse

Should it be included in pharo? IfTrue: open a bug tracker issue >>> 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. 6, 2010

Re: [Pharo-project] [Ann][Cuis] New Cuis Release

by StÃ©phane Ducasse

you can add ESUG as sponsors Stef On Nov 5, 2010, at 2:41 PM, Juan Vuletich wrote: > Hi Folks, > > Cuis 2.8 is available at www.jvuletich.org/Cuis/Index.html . The release notes describes changes in recent versions (starting at 2.0). I believe many of the enhancements could be also useful for Pharo and rather easy to harvest. So, take a look! > > Cheers, > Juan Vuletich >

Nov. 6, 2010

Re: [Pharo-project] Bugreport?

by bb

There is a SqueakVM for 64 bit as well, see: http://www.squeakvm.org/squeak64/ As squeak is running on my machine with fedora13 64 bit WITHOUT the 32 bit libGLU.so.1 (as I have explained in another mail, the only libGLU is in the directory /usr/lib64) one can make sure that there is a 64 bit version running (and offered in the fedora13 64 bit repository, from where I have installed). Vice verse, on my 64 bit debian lenny installation squeak does not run. On that system as (nearly) only the 32 bit libs installed. (I will analyse that case if I find some time.) There seems to be a situation of shift to 64 bit with some library breaks in different systems. Indeed it is possible to install the 32 bit libs with apt-get on debian like machines and yum or rpm or other tools on other linux brands. That would not help so much because it does not solve he incompatibility of my installed 64 bit SqueakVM running on my machine with the 32 bit pharo-image. (I have not yet tried, but in this logic I would have to install a 32 bit squeak as well.) The file vm-display-X11 of my actual squeak version is in directory /usr/lib64/squeak/3.10-5. I tried to change pharo.sh to point explicitely to that directory to use that vm. The result: ~ Pharo-1.1-OneClick.app$ ./pharo2.sh libGLU.so.1: wrong ELF class: ELFCLASS64 could not find display driver vm-display-X11; either: - check that /usr/local/lib/squeak/4.0.3-2202/vm-display-X11.so exists, or - use the '-plugins <path>' option to tell me where it is, or - remove DISPLAY from your environment. Abgebrochen (Speicherabzug geschrieben) ~ Pharo-1.1-OneClick.app$ As you can see pharo is looking for the vm of squeak version 4.0.3-2202 instead of 3.10-5. I do not know where to change this path in pharo and if it makes sense? I do not understand, that there are so.*-versions in .../Contents/Linux/? In my oppinion the clean and save solution for the future is to provide an additional 64 bit pharo-image beside the 32 bit version. Regards BB Am 05.11.2010 22:57, schrieb 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. 6, 2010

Re: [Pharo-project] OSX Pharo Shout Workspace is laggy

by Levente Uzonyi

On Fri, 5 Nov 2010, sergio_101 wrote: >> Is that Pharo 1.1.1 or Pharo 1.2? If it's Pharo 1.2, are you using >> eCompletion or OCompletion? >> > > Pharo-1.1-11411 > Latest update: #11411 > > not sure how to tell which completion i am using.... In that case you're using OCompletion. If you load it's latest version, it should be significantly faster. Here's a script for loading it: Gofer new squeaksource: 'OCompletion'; package: 'Ocompletion'; load. This solves all but two bottlenecks (which are related to Shout). One of them can be fixed by filing in this patch: http://leves.web.elte.hu/squeak/SystemDictionary.ul.1.cs Here's a script to do it: 'http://leves.web.elte.hu/squeak/SystemDictionary.ul.1.cs' asUrl retrieveContents contentStream fileInAnnouncing: 'Loading...'. I'm working on the solution for the last bottleneck (which occurs when your code doesn't look like Smalltalk code at all, or when it sends several unimplemented messages), but that probably doesn't bite you at all. Levente > > 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] OSX Pharo Shout Workspace is laggy

by sergio_101

> Is that Pharo 1.1.1 or Pharo 1.2? If it's Pharo 1.2, are you using > eCompletion or OCompletion? > Pharo-1.1-11411 Latest update: #11411 not sure how to tell which completion i am using.... 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] OSX Pharo Shout Workspace is laggy

by Levente Uzonyi

On Fri, 5 Nov 2010, sergio_101 wrote: > i just downloaded the latest pharo image, and everything seems good, Is that Pharo 1.1.1 or Pharo 1.2? If it's Pharo 1.2, are you using eCompletion or OCompletion? Levente > 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

[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