August 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Vm-dev] building Cog on 64 bits debian

by Igor Stasenko

On 14 August 2011 18:39, laurent laffont <laurent.laffont(a)gmail.com> wrote: > > Thanks Levente. > After searching & trying finally I've passed this problem by: > mv /usr/bin/gcc /usr/bin/real.gcc > and then creating /usr/bin/gcc : > #!/bin/sh > exec real.gcc -m32 $@ > and chmod +x /usr/bin/gcc > > Now I have: > [ 94%] Built target vm-display-null > Scanning dependencies of target vm-display-X11 > [ 94%] Building C object vm-display-X11/CMakeFiles/vm-display-X11.dir/root/securedvm/platforms/unix/vm-display-X11/sqUnixX11.c.o > [ 95%] Building C object vm-display-X11/CMakeFiles/vm-display-X11.dir/root/securedvm/platforms/unix/vm-display-X11/sqUnixMozilla.c.o > Linking C shared library /root/securedvm/results/vm-display-X11 > /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../libSM.so when searching for -lSM > /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../libSM.a when searching for -lSM > /usr/bin/ld: skipping incompatible /usr/lib/libSM.so when searching for -lSM > /usr/bin/ld: skipping incompatible /usr/lib/libSM.a when searching for -lSM > /usr/bin/ld: cannot find -lSM > collect2: ld returned 1 exit status > looks like you don't have 32bit version of this library. That's why it refusing to link. As for compiler options, i don't think that you need to use workarounds (like creating real.gcc etc) , because the -m32 flag is there: # This is automatically generated file using CogUnixConfig on 14 August 2011 10:01:34 pm ... message("Adding module: vm-sound-null") add_definitions( -DLSB_FIRST=1 -DUSE_GLOBAL_STRUCT=0 -DCOGMTVM=0 -m32 -g0 -O2 -msse2 -D_GNU_SOURCE -DNDEBUG -DITIMER_HEARTBEAT=1 -DNO_VM_PROFILE=1 -DDEBUGVM=0) ... Try building using: make VERBOSE=1 to see what flags are passed to compiler. And please, create a subclass of CogUnixConfig , like Cog32OnDebian64Config and play with definitions there. In image you can do: Cog32OnDebian64Config generateWithSources or Cog32OnDebian64Config generate the difference that first will generate cmake files + source files, while second one is only cmake files (takes less than second) I suspecting that problem with linker flags, which tries to link 32-bit output with 64-bit binary. It seems that we're missing the flag there that it should use 32-bit binary for output. > Laurent > > On Sat, Aug 13, 2011 at 4:36 PM, Levente Uzonyi <leves(a)elte.hu> wrote: >> >> On Sat, 13 Aug 2011, laurent laffont wrote: >> >> (no quotes thx to gmail...) >> >> This issue was discussed several times. The simplest solution is to define CC as "gcc -m32" (and optionally CXX as "g++ -m32" if you need g++). Another solution is to check how cmake supports cross compilation. IIRC autotools has some flags for this. >> >> >> Levente > > > -- Best regards, Igor Stasenko AKA sig.

Aug. 14, 2011

Re: [Pharo-project] optimizing primitiveFindFirstInString

by Levente Uzonyi

On Sun, 14 Aug 2011, Philippe Marschall wrote: > Hi > > In Seaside we get a lot of performance gains out of > primitiveFindFirstInString. One thing that always annoyed me a bit is > that it's not as optimized as it could be. > > The inclusionMap you give it are 256 consecutive boolean values (0 or > 1). There is no need for this to be a 256 element ByteArray when each > element can only be 0 or 1. We could as well make it a 32 element > ByteArray and each byte holding eight bit values. Instead of using the > asciiValue to directly index into the inclusionMap we would use the top > five bits to index into the inclusionMap and the bottom 3 bits to "index > into the byte". > > Did that make any sense? Do you want to save space? Are you storing lots of inclusion maps (maybe CharacterSets)? If not, then IMHO it's not worth to adding this feature to this primitive, because runtime performance will be worse on both the image side and the VM side. Levente > > Cheers > Philippe > > >

Aug. 14, 2011

[Pharo-project] Fwd: [Vm-dev] Socket's readSemaphore is losing signals with Cog on Linux

by StÃ©phane Ducasse

can be a valuable information for some of you. Would be good to fix it for real. Stef Begin forwarded message: > From: Andreas Raab <andreas.raab(a)gmx.de> > Date: August 14, 2011 7:58:06 PM GMT+02:00 > To: vm-dev(a)lists.squeakfoundation.org > Subject: Re: [Vm-dev] Socket's readSemaphore is losing signals with Cog on Linux > Reply-To: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> > > On 8/13/2011 13:42, Levente Uzonyi wrote: >> Socket's readSemaphore is losing signals with CogVMs on linux. We found several cases (RFB, PostgreSQL) when processes are stuck in the following method: >> >> Socket >> waitForDataIfClosed: closedBlock >> "Wait indefinitely for data to arrive. This method will block until >> data is available or the socket is closed." >> >> [ >> (self primSocketReceiveDataAvailable: socketHandle) >> ifTrue: [^self]. >> self isConnected >> ifFalse: [^closedBlock value]. >> self readSemaphore wait ] repeat >> >> When we inspect the contexts, the process is waiting for the readSemaphore, but evaluating (self primSocketReceiveDataAvailable: socketHandle) yields true. Signaling the readSemaphore makes the process running again. As a workaround we replaced #wait with #waitTimeoutMSecs: and all our problems disappeared. >> >> The interpreter VM doesn't seem to have this bug, so I guess the bug was introduced with the changes of aio.c. > > Oh, interesting. We know this problem fairly well and have always worked around by changing the wait in the above to a "waitTimeoutMSecs: 500" which turns it into a soft busy loop. It would be interesting to see if there's a bug in Cog which causes this. FWIW, here is the relevant portion: > > "Soft 500ms busy loop - to protect against AIO probs; > occasionally, VM-level AIO fails to trip the semaphore" > self readSemaphore waitTimeoutMSecs: 500. > > Cheers, > - Andreas >

Aug. 14, 2011

[Pharo-project] optimizing primitiveFindFirstInString

by Philippe Marschall

Hi In Seaside we get a lot of performance gains out of primitiveFindFirstInString. One thing that always annoyed me a bit is that it's not as optimized as it could be. The inclusionMap you give it are 256 consecutive boolean values (0 or 1). There is no need for this to be a 256 element ByteArray when each element can only be 0 or 1. We could as well make it a 32 element ByteArray and each byte holding eight bit values. Instead of using the asciiValue to directly index into the inclusionMap we would use the top five bits to index into the inclusionMap and the bottom 3 bits to "index into the byte". Did that make any sense? Cheers Philippe

Aug. 14, 2011

[Pharo-project] Congratulations on help system

by Max Leske

Just wanted to let the people who wrote the Pharo help system know that I think you did a great job. I especially enjoy the editor workspace for writing help texts (BTW: could autocompleteion and syntax highlighting be turned off by default for editor workspaces?). I encourage everyone to write for the help system. The help on help is an excellent tutorial that also shows how valuable the help system can be in getting to know a new tool. While I'm at it, I'll also write a small help part for Filesystem. Cheers, Max

Aug. 14, 2011

Re: [Pharo-project] [Vm-dev] building Cog on 64 bits debian

by laurent laffont

On Sun, Aug 14, 2011 at 6:37 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > > On Sun, 14 Aug 2011, laurent laffont wrote: > > Hm, yeah. IIRC autotools used gcc (via libtool) for linking instead of ld. > You'll need another export LDFLAGS="-m32". > Does not help. It looks like flags are "discared". For example with the libSM no found for vm-display-X11, I tried LDFLAGS="-L/usr/lib32" as # ls /usr/lib32/*SM* /usr/lib32/libSM.so.6 /usr/lib32/libSM.so.6.0.1 but still try to link on /usr/lib/libSM.so Laurent. > > > Levente >

Aug. 14, 2011

Re: [Pharo-project] BDD: Cucumber Toy Project

by Tudor Girba

This is really cool. Please keep us posted :) Doru On 14 Aug 2011, at 16:37, Sean P. DeNigris wrote: > I'm playing with Polymorph to make a BDD tool like Ruby's Cucumber (but > infinitely better because we're in a live image and don't have to cram the > infinite richness of our imagination into dead text, lol). > > It's amazing how a few lines of code got me *very* close to an active essay > of the cucumber book's first example. > > Here is a screenshot of the Cucumber book: > http://forum.world.st/file/n3742986/Screen_Shot_2011-08-14_at_10.30.11_AM.p… > > And here is a quick Polymorph view: > http://forum.world.st/file/n3742986/Screen_Shot_2011-08-14_at_10.29.44_AM.p… > > Hopefully I'll have something we can play with by ESUG! > > Sean > > -- > View this message in context: http://forum.world.st/BDD-Cucumber-Toy-Project-tp3742986p3742986.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- www.tudorgirba.com "Speaking louder won't make the point worthier."

Aug. 14, 2011

Re: [Pharo-project] [Vm-dev] building Cog on 64 bits debian

by Levente Uzonyi

On Sun, 14 Aug 2011, laurent laffont wrote: Hm, yeah. IIRC autotools used gcc (via libtool) for linking instead of ld. You'll need another export LDFLAGS="-m32". Levente

Aug. 14, 2011

Re: [Pharo-project] [Vm-dev] building Cog on 64 bits debian

by laurent laffont

On Sun, Aug 14, 2011 at 6:21 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > > On Sun, 14 Aug 2011, laurent laffont wrote: > > (no quote, gmail, etc...) > > All you need is: > export CC="gcc -m32" CXX="g++ -m32" > > I tried: ~/securedvm/build# export CC="gcc -m32" ~/securedvm/build# export CXX="g++ -m32" ~/securedvm/build# make bla bla........ [ 95%] Built target CogVM Linking C shared library /root/securedvm/results/vm-display-null collect2: ld terminated with signal 11 [Segmentation fault] ld: skipping incompatible /usr/lib32/libm.so when searching for -lm ld: skipping incompatible /usr/lib32/libm.a when searching for -lm ld: skipping incompatible /usr/lib32/libdl.so when searching for -ldl ld: skipping incompatible /usr/lib32/libdl.a when searching for -ldl ld: skipping incompatible /usr/lib32/libpthread.so when searching for -lpthread ld: skipping incompatible /usr/lib32/libpthread.a when searching for -lpthread ld: skipping incompatible /usr/lib32/libc.so when searching for -lc ld: skipping incompatible /usr/lib32/libc.a when searching for -lc ld: i386 architecture of input file `CMakeFiles/vm-display-null.dir/root/securedvm/platforms/unix/vm-display-null/sqUnixDisplayNull.c.o' is incompatible with i386:x86-64 output > > Levente >

Aug. 14, 2011

Re: [Pharo-project] BDD: Cucumber Toy Project

by StÃ©phane Ducasse

you should send it to the awards :) On Aug 14, 2011, at 4:37 PM, Sean P. DeNigris wrote: > I'm playing with Polymorph to make a BDD tool like Ruby's Cucumber (but > infinitely better because we're in a live image and don't have to cram the > infinite richness of our imagination into dead text, lol). > > It's amazing how a few lines of code got me *very* close to an active essay > of the cucumber book's first example. > > Here is a screenshot of the Cucumber book: > http://forum.world.st/file/n3742986/Screen_Shot_2011-08-14_at_10.30.11_AM.p… > > And here is a quick Polymorph view: > http://forum.world.st/file/n3742986/Screen_Shot_2011-08-14_at_10.29.44_AM.p… > > Hopefully I'll have something we can play with by ESUG! > > Sean > > -- > View this message in context: http://forum.world.st/BDD-Cucumber-Toy-Project-tp3742986p3742986.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Aug. 14, 2011