Squeak/Pharo/Cuis on Android
Locked
12
12
 
|
Bert Freudenberg wrote:
> On 03.03.2011, at 18:31, Juan Vuletich wrote: > > >> Bert Freudenberg wrote: >> >>> On 03.03.2011, at 17:30, Juan Vuletich wrote: >>> >>> >>> >>>> I guess I succeeded installing it. Now trying to run like this >>>> sh squeak.sh ../../imagename.image (in .../bin/) gives 'libGLU.so.1: cannot open shared object file: No such file or directory / could not find display driver vm-display-x11; wither: / -check that /udr/local/lib/squeak/4.4.7-2357/vm-display-x11.so exists or / ...' >>>> There's no vm-display-x11.so in the folder from the installation, but there is a so.vm-display... so copying this to have the '.so' at the end... Get the same error. I'm almost giving up. >>>> >>>> >>> Well, you're almost there ;) >>> >>> You need either the tar.gz or the .sh, not both. After extracting, you can either install it, or run directly from where you installed it. >>> >>> The libGLU error you are getting now indicates the VM loads successfully. But the vm-display-x11 is linked to OpenGL. The XO has no OpenGL libraries installed. So what you need to do is copy the system's so.vm-display-x11 (from /usr/lib/squeak) to your new VM directory, overwriting the current version. Then everything should be fine. The system version was compiled without OpenGL support. >>> >>> - Bert - >>> >>> >>> >> Did that. Get same error as before... >> >> Also tried the 'all in one' Cuis (based on Squeak's). The included .sh file does 'uname -m' to find out about the CPU. The answer on the XO is i586, not i686, and therefore 'all in one' can't run. I wonder if this would affect the stand alone linux vm, too... >> > > Unlikely. You would get a different error if this was the problem. > > I'd guess the VM inside the all-in-one is actually an i386 one, so it would run on anything newer than that, too. We should change the script. > Right. Patched the script so it would attempt running and got again the vm-display-X11 errors. > You really just need to make it use the right vm-display-x11 module. Do an ldd on it to see what it links to. > It points to stuff in /usr/lib/ , i.e. the version used by the original vm that came with the system. Anyway, I've already spent more time on this than I have... If someone succeeds in running a closures image on the XO, I'd like to know. (Same for WinCE, btw) Thanks for your help. Juan Vuletich > - Bert - > > > > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1204 / Virus Database: 1435/3479 - Release Date: 03/03/11 > > > > |
Re: Closure VM on XO (was Re: [squeak-dev] Squeak/Pharo/Cuis on Android)
|
|
In reply to this post by Casey Ransberger-2
Casey Ransberger wrote:
> Inline > > On Mar 3, 2011, at 2:26 PM, Juan Vuletich <[hidden email]> wrote: > > >> I'm pretty close to a new release of Cuis that should feel way more responsive on slow devices. It does world redraw about 10 times faster when there are many windows open. >> Unfortunately I couldn't run it on my XO, as the preloaded VM is pre-closures... Does anybody know how to run a closures image on the XO? >> > > I may be misunderstanding you; if not, you may experience a minor facepalm. XO is Fedora-based, so you should be able to grab the Linux VM sources and roll it up. > > There may be some reason that this is harder than I would expect, I don't know; compiling a VM on that hardware might be beyond just painful, but also impossible (insufficient RAM/storage, etc.) but you should still be able to compile it on another box and then drop the files in. > > Oh! And IIRC, I had to get an encryption key to flip the yes-I-am-grownup-programmer bit. > Becoming a linux hacker just to play with Cuis for 15 minutes on it is not worth it... > The displays on those things are unreal man. I'm tempted to rip it apart and scavenge the screen:) > Yes. The hardware is way cool (except for the keyboard and track pad). Too bad it runs linux... Cheers, Juan Vuletich |
Re: Closure VM on XO (was Re: [squeak-dev] Squeak/Pharo/Cuis on Android)
|
|
In reply to this post by Casey Ransberger-2
In latest CMakeVMMaker you can find
CogUnixNoGLConfig which , if you generate it, will build the 'vm-display-X11' module without dependency from opengl: ldd vm-display-X11 linux-gate.so.1 => (0x00690000) libSM.so.6 => /usr/lib/libSM.so.6 (0x007d0000) libICE.so.6 => /usr/lib/libICE.so.6 (0x007dc000) libdl.so.2 => /lib/libdl.so.2 (0x00449000) libpthread.so.0 => /lib/libpthread.so.0 (0x006c4000) libm.so.6 => /lib/libm.so.6 (0x00c2e000) libnsl.so.1 => /lib/libnsl.so.1 (0x00636000) libX11.so.6 => /usr/lib/libX11.so.6 (0x00110000) libc.so.6 => /lib/libc.so.6 (0x0022d000) libuuid.so.1 => /lib/libuuid.so.1 (0x00e04000) /lib/ld-linux.so.2 (0x00a61000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0x009c6000) libXau.so.6 => /usr/lib/libXau.so.6 (0x00837000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00aa1000) On 4 March 2011 04:04, Casey Ransberger <[hidden email]> wrote: > I had a VM installed, installed a second VM, and had the same error with the > same library, unless my memory wants debugging. I wasn't in a stock config > either, I backported and tweaked a lot of stuff to make Ubuntu work well for > me on it. I know I ripped out compiz and fusion, can't remember if I let > OpenGL live. I could have accidentally broken it while breaking things I > intended to break:) > Anyway, we'll never know. I gave the machine away, which is my favorite > thing to do with extra computers. Now I wish I'd have kept it another month, > just to know. > > On Thu, Mar 3, 2011 at 6:36 PM, Bert Freudenberg <[hidden email]> > wrote: >> >> On 03.03.2011, at 18:29, Casey Ransberger wrote: >> >> And, now I know why I didn't get Cog to work on the EeePC. Ah well. Thanks >> for educating me, Bert:) >> >> You do? I'd be surprised if you really got the libGLU error there. >> - Bert - >> >> On Thu, Mar 3, 2011 at 6:10 PM, Bert Freudenberg <[hidden email]> >> wrote: >>> >>> On 03.03.2011, at 17:30, Juan Vuletich wrote: >>> >>> > I guess I succeeded installing it. Now trying to run like this >>> > sh squeak.sh ../../imagename.image (in .../bin/) gives 'libGLU.so.1: >>> > cannot open shared object file: No such file or directory / could not find >>> > display driver vm-display-x11; wither: / -check that >>> > /udr/local/lib/squeak/4.4.7-2357/vm-display-x11.so exists or / ...' >>> > There's no vm-display-x11.so in the folder from the installation, but >>> > there is a so.vm-display... so copying this to have the '.so' at the end... >>> > Get the same error. I'm almost giving up. >>> >>> Well, you're almost there ;) >>> >>> You need either the tar.gz or the .sh, not both. After extracting, you >>> can either install it, or run directly from where you installed it. >>> >>> The libGLU error you are getting now indicates the VM loads successfully. >>> But the vm-display-x11 is linked to OpenGL. The XO has no OpenGL libraries >>> installed. So what you need to do is copy the system's so.vm-display-x11 >>> (from /usr/lib/squeak) to your new VM directory, overwriting the current >>> version. Then everything should be fine. The system version was compiled >>> without OpenGL support. >>> >>> - Bert - >>> >>> >>> >> >> >> >> -- >> Casey Ransberger >> >> >> >> >> >> > > > > -- > Casey Ransberger > > > > -- Best regards, Igor Stasenko AKA sig. |
|
|
In reply to this post by Juan Vuletich-4
On Fri, Mar 04, 2011 at 08:04:42AM -0300, Juan Vuletich wrote:
> > It points to stuff in /usr/lib/ , i.e. the version used by the original > vm that came with the system. > > Anyway, I've already spent more time on this than I have... If someone > succeeds in running a closures image on the XO, I'd like to know. (Same > for WinCE, btw) I don't have an XO, but I recall that many XO's in the field are running older versions of Linux. The VMs on squeakvm.org are built on a relatively up to date system, and the resulting VM will try to link at runtime to newer libraries that may not be present on your XO machine. The simple solution would be to find somebody with an old Linux box and build the VM there. Unfortunately my trusty old computer died a while back, so I cannot offer any help at the moment. If anyone out there has an old Linux box handy and can build a VM and send it to Juan, I'm sure he'll appreciate it :) Dave |
|
|
In reply to this post by Bert Freudenberg
Hi Bert,
On Thu, Mar 3, 2011 at 6:40 PM, Bert Freudenberg <[hidden email]> wrote:
Does the XO Geode support sse2? Actually, what is the exact processor in the X0? Right now the JIT won't use sse2 instructions if they aren;t available, which translates into no machine code floatng-point primitives. But I'm also using sse2 instructions to update the 64-bit microsecond clock, so without some rewrite teh current linux Cog does depend on sse2.
best Eliot >> |
|
CONTENTS DELETED
The author has deleted this message.
|
|
|
In reply to this post by Juan Vuletich-4
CONTENTS DELETED
The author has deleted this message.
|
|
|
In reply to this post by hilaire
Hilaire Fernandes wrote:
> Right the Geode does not support sse2. > I compiled a VM for the XO Fedora environment, I removed the sse2 flags > and the VM appears to make DrGeo works happily under the XO (with a nice > boost). > Oh wait, the locale does not work, can it be related to not using sse2 > instructions? I guess not. > > For Casey: > > I put the compiled VM in SVN as it is more handy for me. > > Fetch its tree from: > > https://gforge.inria.fr/scm/viewvc.php/drgeo2/VMs/xo/vm-2011-02-20/?root=istoa > > Instructions to fetch anonymously: > https://gforge.inria.fr/scm/?group_id=1308 > > Hilaire > > Thanks, Hilaire! Will try it this weekend. Cheers, Juan Vuletich > > Le 04/03/2011 17:20, Eliot Miranda a écrit : > >> Does the XO Geode support sse2? Actually, what is the exact processor >> in the X0? Right now the JIT won't use sse2 instructions if they aren;t >> available, which translates into no machine code floatng-point >> primitives. But I'm also using sse2 instructions to update the 64-bit >> microsecond clock, so without some rewrite teh current linux Cog does >> depend on sse2. >> >> > > > |
Re: Closure VM on XO (was Re: Squeak/Pharo/Cuis on Android)
|
|
In reply to this post by hilaire
Hilaire Fernandes wrote:
> Le 04/03/2011 12:10, Juan Vuletich a écrit : > >> Yes. The hardware is way cool (except for the keyboard and track pad). >> Too bad it runs linux... >> > > You will want it to run Cuis? ;-) > Yes, mainly. Scratch and the Sugar activities are great. I just miss the "easyness" for running apps I have in Win and Mac. Cheers, Juan Vuletich |
|
|
In reply to this post by Eliot Miranda-2
On Fri, 4 Mar 2011, Eliot Miranda wrote:
snip > Does the XO Geode support sse2? Actually, what is the exact processor in > the X0? Right now the JIT won't use sse2 instructions if they aren;t > available, which translates into no machine code floatng-point primitives. > But I'm also using sse2 instructions to update the 64-bit microsecond > clock, so without some rewrite teh current linux Cog does depend on sse2. Older XO's have Geode GX, newer have Geode LX CPUs. None of these support SSE at all, just MMX and an extended version of 3DNow!. There's no MFENCE (just SFENCE), so an alternative implementation is necessary for these CPUs. Levente > > best > Eliot snip |
Re: Squeak/Pharo/Cuis on Android
|
|
In reply to this post by Bert Freudenberg
Bert Freudenberg wrote:
> ... >> Cuis has a nice feature wherein if you click an hold on something that gets a context menu, it pops up after a split second. Juan did this for a small gadget once upon a time. >> > > Would be nice to have that in Squeak, too, IMHO. > > > See ivar sendMouseButton2Activity in MouseClickState. I guess it shouldn't be too hard to adapt this for Squeak. Cheers, Juan Vuletich |
|
|
In reply to this post by Levente Uzonyi-2
On 04.03.2011, at 23:15, Levente Uzonyi wrote: > On Fri, 4 Mar 2011, Eliot Miranda wrote: > > snip > >> Does the XO Geode support sse2? Actually, what is the exact processor in >> the X0? Right now the JIT won't use sse2 instructions if they aren;t >> available, which translates into no machine code floatng-point primitives. >> But I'm also using sse2 instructions to update the 64-bit microsecond >> clock, so without some rewrite teh current linux Cog does depend on sse2. > > Older XO's have Geode GX, newer have Geode LX CPUs. None of these support SSE at all, just MMX and an extended version of 3DNow!. There's no MFENCE (just SFENCE), so an alternative implementation is necessary for these CPUs. Production models of the XO-1 have a Geode LX. There is a link to the datasheet here: http://wiki.laptop.org/go/Hardware_specification There are at least a million of those machines. - Bert - |
|
|
In reply to this post by Levente Uzonyi-2
On Sat, 5 Mar 2011, Levente Uzonyi wrote:
> On Fri, 4 Mar 2011, Eliot Miranda wrote: > > snip > >> Does the XO Geode support sse2? Actually, what is the exact processor in >> the X0? Right now the JIT won't use sse2 instructions if they aren;t >> available, which translates into no machine code floatng-point primitives. >> But I'm also using sse2 instructions to update the 64-bit microsecond >> clock, so without some rewrite teh current linux Cog does depend on sse2. > > Older XO's have Geode GX, newer have Geode LX CPUs. None of these support SSE > at all, just MMX and an extended version of 3DNow!. There's no MFENCE (just > SFENCE), so an alternative implementation is necessary for these CPUs. According to http://www.linuxjournal.com/node/8212/print mfence is only necessary on x86_64 platforms, so I added the following two lines before the else branch in sqMemoryFence.h # elif !defined(__X86_64__) # define sqLowLevelMFence() asm volatile ("lock; addl $0,0(%%esp)":::"memory") I compiled it with r2361 and it works fine on my 32-bit Ubuntu 10.04. So if the -msse compiler flag is removed from the Makefiles, then Cog should run on the XO-1 too. The article also mentions smp_mb() which should be used on linux, but I couldn't find which header file defines it. Levente > > > Levente > >> >> best >> Eliot > > snip > > |
|
|
On Sun, Mar 6, 2011 at 1:53 PM, Levente Uzonyi <[hidden email]> wrote:
I'm not sure a bout that. It does state "Although many older x86 implementations accommodated self-modifying code without the need for any special instructions, newer revisions of the x86 architecture no longer require x86 CPUs to be so accommodating. Interestingly enough, this relaxation comes just in time to inconvenience JIT implementors."
I'd much rather you changed the define to be explicit about X0, than changed for all x86.
|
|
|
On Sun, 6 Mar 2011, Eliot Miranda wrote:
> On Sun, Mar 6, 2011 at 1:53 PM, Levente Uzonyi <[hidden email]> wrote: > >> On Sat, 5 Mar 2011, Levente Uzonyi wrote: >> >> On Fri, 4 Mar 2011, Eliot Miranda wrote: >>> >>> snip >>> >>> Does the XO Geode support sse2? Actually, what is the exact processor in >>>> the X0? Right now the JIT won't use sse2 instructions if they aren;t >>>> available, which translates into no machine code floatng-point >>>> primitives. >>>> But I'm also using sse2 instructions to update the 64-bit microsecond >>>> clock, so without some rewrite teh current linux Cog does depend on sse2. >>>> >>> >>> Older XO's have Geode GX, newer have Geode LX CPUs. None of these support >>> SSE at all, just MMX and an extended version of 3DNow!. There's no MFENCE >>> (just SFENCE), so an alternative implementation is necessary for these CPUs. >>> >> >> According to http://www.linuxjournal.com/node/8212/print mfence is only >> necessary on x86_64 platforms, so I added the following two lines before the >> else branch in sqMemoryFence.h >> > > I'm not sure a bout that. It does state > "Although many older x86 implementations accommodated self-modifying > code without the need for any special instructions, newer revisions of the > x86 architecture no longer require x86 CPUs to be so accommodating. > Interestingly enough, this relaxation comes just in time to inconvenience > JIT implementors." > > I'd much rather you changed the define to be explicit about X0, than changed > for all x86. That's right. Only platforms without SSE2 support should use this. It's up to you to integrate it. :) Levente > > > >> # elif !defined(__X86_64__) >> # define sqLowLevelMFence() asm volatile ("lock; addl >> $0,0(%%esp)":::"memory") >> >> I compiled it with r2361 and it works fine on my 32-bit Ubuntu 10.04. So if >> the -msse compiler flag is removed from the Makefiles, then Cog should run >> on the XO-1 too. >> >> The article also mentions smp_mb() which should be used on linux, but I >> couldn't find which header file defines it. >> >> >> Levente >> >> >>> >>> Levente >>> >>> >>>> best >>>> Eliot >>>> >>> >>> snip >>> >>> >>> >> > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |