Squeak VM port to Google Native Client
Locked
12
12
Squeak VM port to Google Native Client
 
|
Hello, I'm playing with Google Native Client a bit and made a port of Squeak VM to it. It is far from complete (even the state where backspace or Cmd-p etc. does not work, sound does not work, etc.), It now reached to the state where I can say the basic part of it is working. The source code is available at: http://github.com/yoshikiohshima/NaClSqueak . Also, f you have Google Chrome 11 beta available, try to turn on the Native Client on (by typing "about:flags" into the title bar) and access: http://tinlizzie.org/~ohshima/squeak/squeak.html (The first try may take some time.) - It is gnuify-ed but we're still learning the JIT situation of NaCl. So, it' need some work to port Cog. - The image data is embedded as a C array in this executable. You can remove EMBEDDED_IMAGE_FILE flag off, and comment/uncomment the corresponding part of squeak.html, it can load the image separately via XMLHttpRequest of the browser. - There is some strange issue when you do fast drag the system window. - As you can see, the source code is derived from the Unix VM. It was hard for me to write some CMake stuff to set it up for the cross compilation. A help to merge it back to the Unix code would be greatly appreciated. - If Google takes over the world and all apps become a Native Client (may be even other browsers^^;), this port may be useful^^; -- Yoshiki |
Re: Squeak VM port to Google Native Client
|
|
Hi yoshiski In october we have two squeak from SqueakNOS and marcus wanted one of them to do that so we will build on your code then. Stef On May 4, 2011, at 8:18 AM, Yoshiki Ohshima wrote: > > Hello, > > I'm playing with Google Native Client a bit and made a port of > Squeak VM to it. It is far from complete (even the state where > backspace or Cmd-p etc. does not work, sound does not work, etc.), It > now reached to the state where I can say the basic part of it is > working. > > The source code is available at: > > http://github.com/yoshikiohshima/NaClSqueak > > . Also, f you have Google Chrome 11 beta available, try to turn on > the Native Client on (by typing "about:flags" into the title bar) and > access: > > http://tinlizzie.org/~ohshima/squeak/squeak.html > > (The first try may take some time.) > > - It is gnuify-ed but we're still learning the JIT situation of > NaCl. So, it' need some work to port Cog. > > - The image data is embedded as a C array in this executable. You > can remove EMBEDDED_IMAGE_FILE flag off, and comment/uncomment the > corresponding part of squeak.html, it can load the image > separately via XMLHttpRequest of the browser. > > - There is some strange issue when you do fast drag the system > window. > > - As you can see, the source code is derived from the Unix VM. It > was hard for me to write some CMake stuff to set it up for the > cross compilation. A help to merge it back to the Unix code would > be greatly appreciated. > > - If Google takes over the world and all apps become a Native Client > (may be even other browsers^^;), this port may be useful^^; > > -- Yoshiki |
Re: Squeak VM port to Google Native Client
|
|
In reply to this post by Yoshiki Ohshima-2
At Tue, 03 May 2011 23:18:04 -0700, Yoshiki Ohshima wrote: > > Hello, > > I'm playing with Google Native Client a bit and made a port of > Squeak VM to it. It is far from complete (even the state where > backspace or Cmd-p etc. does not work, sound does not work, etc.), It > now reached to the state where I can say the basic part of it is > working. > > The source code is available at: > > http://github.com/yoshikiohshima/NaClSqueak > > . Also, f you have Google Chrome 11 beta available, try to turn on > the Native Client on (by typing "about:flags" into the title bar) and > access: > > http://tinlizzie.org/~ohshima/squeak/squeak.html > > (The first try may take some time.) > > - It is gnuify-ed but we're still learning the JIT situation of > NaCl. So, it' need some work to port Cog. > > - The image data is embedded as a C array in this executable. You > can remove EMBEDDED_IMAGE_FILE flag off, and comment/uncomment the > corresponding part of squeak.html, it can load the image > separately via XMLHttpRequest of the browser. > > - There is some strange issue when you do fast drag the system > window. > > - As you can see, the source code is derived from the Unix VM. It > was hard for me to write some CMake stuff to set it up for the > cross compilation. A help to merge it back to the Unix code would > be greatly appreciated. > > - If Google takes over the world and all apps become a Native Client > (may be even other browsers^^;), this port may be useful^^; > > -- Yoshiki I forgot to mention that: - You can generate 64 bit binary if you compile it, but I don't have any environment handy to test it. Such test is also greatly appreciated. Thank you! -- Yoshiki |
Re: Squeak VM port to Google Native Client
|
|
In reply to this post by stephane ducasse-2
At Wed, 4 May 2011 07:41:16 +0200, stephane ducasse wrote: > > > Hi yoshiski > > In october we have two squeak from SqueakNOS and marcus wanted one of them to do that so we will build on your code then. Yay! I read on the Pharo mailing list that Marcu mentioned of Native Client. I hope you find my code any use. -- Yoshiki |
Re: Squeak VM port to Google Native Client
|
|
In reply to this post by Yoshiki Ohshima-2
Very interesting. Can you roughly say what needs to do to get the Squeak VM into NaCL? Cheers, - Andreas On 5/4/2011 8:18, Yoshiki Ohshima wrote: > > Hello, > > I'm playing with Google Native Client a bit and made a port of > Squeak VM to it. It is far from complete (even the state where > backspace or Cmd-p etc. does not work, sound does not work, etc.), It > now reached to the state where I can say the basic part of it is > working. > > The source code is available at: > > http://github.com/yoshikiohshima/NaClSqueak > > . Also, f you have Google Chrome 11 beta available, try to turn on > the Native Client on (by typing "about:flags" into the title bar) and > access: > > http://tinlizzie.org/~ohshima/squeak/squeak.html > > (The first try may take some time.) > > - It is gnuify-ed but we're still learning the JIT situation of > NaCl. So, it' need some work to port Cog. > > - The image data is embedded as a C array in this executable. You > can remove EMBEDDED_IMAGE_FILE flag off, and comment/uncomment the > corresponding part of squeak.html, it can load the image > separately via XMLHttpRequest of the browser. > > - There is some strange issue when you do fast drag the system > window. > > - As you can see, the source code is derived from the Unix VM. It > was hard for me to write some CMake stuff to set it up for the > cross compilation. A help to merge it back to the Unix code would > be greatly appreciated. > > - If Google takes over the world and all apps become a Native Client > (may be even other browsers^^;), this port may be useful^^; > > -- Yoshiki > |
Re: Squeak VM port to Google Native Client
|
|
In reply to this post by Yoshiki Ohshima-2
On 4 May 2011 08:18, Yoshiki Ohshima <[hidden email]> wrote: > > Hello, > > I'm playing with Google Native Client a bit and made a port of > Squeak VM to it. It is far from complete (even the state where > backspace or Cmd-p etc. does not work, sound does not work, etc.), It > now reached to the state where I can say the basic part of it is > working. > > The source code is available at: > > http://github.com/yoshikiohshima/NaClSqueak > > . Also, f you have Google Chrome 11 beta available, try to turn on > the Native Client on (by typing "about:flags" into the title bar) and > access: > > http://tinlizzie.org/~ohshima/squeak/squeak.html > > (The first try may take some time.) > > - It is gnuify-ed but we're still learning the JIT situation of > NaCl. So, it' need some work to port Cog. > > - The image data is embedded as a C array in this executable. You > can remove EMBEDDED_IMAGE_FILE flag off, and comment/uncomment the > corresponding part of squeak.html, it can load the image > separately via XMLHttpRequest of the browser. > > - There is some strange issue when you do fast drag the system > window. > > - As you can see, the source code is derived from the Unix VM. It > was hard for me to write some CMake stuff to set it up for the > cross compilation. A help to merge it back to the Unix code would > be greatly appreciated. > I recommend you to take a look on CMakeVMMaker. It is written in smalltalk, and generating cmake configuration files. Its also much simpler than cmake configs made by Ian (because i started making it without too deep knowledge about cmake), and actually i didn't wanted to make it too clever, like detecting a platform-specific subtleties, because then it ties your build to the platform where you compiling VM and therefore makes it harder to do a cross-compilation. So, with CMakeVMMaker you could just start from creating a new class with own configuration , and then gradually get a working configuration which (cross)compiles VM for your specific target, with your specific flags and set of plugins which proven to work. And of course, you can take a look at existing configurations for examples. > - If Google takes over the world and all apps become a Native Client > (may be even other browsers^^;), this port may be useful^^; > Yes, indeed. I like NaCl, because it will allow us to just run VM, instead of adopting it to browser in form of plugin. Do you have any description, what you need to do to get started building VM for NaCl? It would be interesting to read. > -- Yoshiki > -- Best regards, Igor Stasenko AKA sig. |
Re: Squeak VM port to Google Native Client
|
|
In reply to this post by Yoshiki Ohshima-2
On 04.05.2011, at 03:18, Yoshiki Ohshima wrote: > > - As you can see, the source code is derived from the Unix VM. It > was hard for me to write some CMake stuff to set it up for the > cross compilation. A help to merge it back to the Unix code would > be greatly appreciated. IMHO merging into the unix code does not make too much sense. It is a separate port. So it would live under platforms/ like the others. - Bert - |
Re: Squeak VM port to Google Native Client
|
|
In reply to this post by Andreas.Raab
On 04.05.2011, at 04:47, Andreas Raab wrote: > Very interesting. Can you roughly say what needs to do to get the Squeak VM into NaCL? I'm not quite sure what you're asking. NaCl downloads native code from your webpage and executes it. So "to get the Squeak VM into NaCl" you put it on a webserver. - Bert - |
Re: Squeak VM port to Google Native Client
|
|
On 5/4/2011 16:31, Bert Freudenberg wrote: > On 04.05.2011, at 04:47, Andreas Raab wrote: >> Very interesting. Can you roughly say what needs to do to get the Squeak VM into NaCL? > I'm not quite sure what you're asking. NaCl downloads native code from your webpage and executes it. So "to get the Squeak VM into NaCl" you put it on a webserver. If that were true, then Yoshiki would've to do absolutely nothing. Which in itself would be an interesting statement, but I suspect he *did* have to change something to make it work with NaCL. Thus my question: What? Not necessarily in specific terms but in general areas that need work. Cheers, - Andreas |
Re: Squeak VM port to Google Native Client
|
|
On 04.05.2011, at 11:41, Andreas Raab wrote: > On 5/4/2011 16:31, Bert Freudenberg wrote: >> On 04.05.2011, at 04:47, Andreas Raab wrote: >>> Very interesting. Can you roughly say what needs to do to get the Squeak VM into NaCL? >> I'm not quite sure what you're asking. NaCl downloads native code from your webpage and executes it. So "to get the Squeak VM into NaCl" you put it on a webserver. > If that were true, then Yoshiki would've to do absolutely nothing. Which in itself would be an interesting statement, but I suspect he *did* have to change something to make it work with NaCL. Thus my question: What? Not necessarily in specific terms but in general areas that need work. Ah. I parsed your question incorrectly. You were asking for a to-do list :) - Bert - |
Re: Squeak VM port to Google Native Client
|
|
In reply to this post by Andreas.Raab
On 4 May 2011 16:41, Andreas Raab <[hidden email]> wrote: > > On 5/4/2011 16:31, Bert Freudenberg wrote: >> >> On 04.05.2011, at 04:47, Andreas Raab wrote: >>> >>> Very interesting. Can you roughly say what needs to do to get the Squeak >>> VM into NaCL? >> >> I'm not quite sure what you're asking. NaCl downloads native code from >> your webpage and executes it. So "to get the Squeak VM into NaCl" you put it >> on a webserver. > > If that were true, then Yoshiki would've to do absolutely nothing. Which in > itself would be an interesting statement, but I suspect he *did* have to > change something to make it work with NaCL. Thus my question: What? Not > necessarily in specific terms but in general areas that need work. > Yeah. And that's what i looking for as well :) > Cheers, > - Andreas > > -- Best regards, Igor Stasenko AKA sig. |
Re: Squeak VM port to Google Native Client
|
|
In reply to this post by Andreas.Raab
At Wed, 04 May 2011 09:47:48 +0200, Andreas Raab wrote: > > Very interesting. Can you roughly say what needs to do to get the Squeak > VM into NaCL? - No stdio files. I wrote small wrappers for fopen, ftell, fseek, fread, and etc. for memory buffer. - No dlsym, dlopen and etc. The Unix VM depends on them so a little simplifications and hack to make a NaCl VM module visible to the main VM. (Thus no external plugin either.) - Write schemes to get the image data from the net. the JavaScript to NaCl module interface is very limited so you need to work around it. - Adapt to PPAPI that provides a way to get drawable pixel buffers and get events. - multi threading for separating the interpreter and browser/NaCl module interaction. - A lot of figuring out of which library functions actually exists, which of these work and what values to be expected from the browser. - ... -- Yoshiki > On 5/4/2011 8:18, Yoshiki Ohshima wrote: > > > > Hello, > > > > I'm playing with Google Native Client a bit and made a port of > > Squeak VM to it. It is far from complete (even the state where > > backspace or Cmd-p etc. does not work, sound does not work, etc.), It > > now reached to the state where I can say the basic part of it is > > working. > > > > The source code is available at: > > > > http://github.com/yoshikiohshima/NaClSqueak > > > > . Also, f you have Google Chrome 11 beta available, try to turn on > > the Native Client on (by typing "about:flags" into the title bar) and > > access: > > > > http://tinlizzie.org/~ohshima/squeak/squeak.html > > > > (The first try may take some time.) > > > > - It is gnuify-ed but we're still learning the JIT situation of > > NaCl. So, it' need some work to port Cog. > > > > - The image data is embedded as a C array in this executable. You > > can remove EMBEDDED_IMAGE_FILE flag off, and comment/uncomment the > > corresponding part of squeak.html, it can load the image > > separately via XMLHttpRequest of the browser. > > > > - There is some strange issue when you do fast drag the system > > window. > > > > - As you can see, the source code is derived from the Unix VM. It > > was hard for me to write some CMake stuff to set it up for the > > cross compilation. A help to merge it back to the Unix code would > > be greatly appreciated. > > > > - If Google takes over the world and all apps become a Native Client > > (may be even other browsers^^;), this port may be useful^^; > > > > -- Yoshiki > > |
Re: Squeak VM port to Google Native Client
|
|
In reply to this post by Igor Stasenko
At Wed, 4 May 2011 13:48:46 +0200, Igor Stasenko wrote: > > > On 4 May 2011 08:18, Yoshiki Ohshima <[hidden email]> wrote: > > > > Hello, > > > > I'm playing with Google Native Client a bit and made a port of > > Squeak VM to it. It is far from complete (even the state where > > backspace or Cmd-p etc. does not work, sound does not work, etc.), It > > now reached to the state where I can say the basic part of it is > > working. > > > > The source code is available at: > > > > http://github.com/yoshikiohshima/NaClSqueak > > > > . Also, f you have Google Chrome 11 beta available, try to turn on > > the Native Client on (by typing "about:flags" into the title bar) and > > access: > > > > http://tinlizzie.org/~ohshima/squeak/squeak.html > > > > (The first try may take some time.) > > > > - It is gnuify-ed but we're still learning the JIT situation of > > NaCl. So, it' need some work to port Cog. > > > > - The image data is embedded as a C array in this executable. You > > can remove EMBEDDED_IMAGE_FILE flag off, and comment/uncomment the > > corresponding part of squeak.html, it can load the image > > separately via XMLHttpRequest of the browser. > > > > - There is some strange issue when you do fast drag the system > > window. > > > > - As you can see, the source code is derived from the Unix VM. It > > was hard for me to write some CMake stuff to set it up for the > > cross compilation. A help to merge it back to the Unix code would > > be greatly appreciated. > > > > I recommend you to take a look on CMakeVMMaker. > It is written in smalltalk, and generating cmake configuration files. > Its also much simpler than cmake configs made by Ian (because i > started making it without too deep knowledge > about cmake), and actually i didn't wanted to make it too clever, like > detecting a platform-specific subtleties, > because then it ties your build to the platform where you compiling VM > and therefore makes it harder to do a cross-compilation. > > So, with CMakeVMMaker you could just start from creating a new class > with own configuration , and then gradually > get a working configuration which (cross)compiles VM for your specific > target, with your specific flags and > set of plugins which proven to work. > > And of course, you can take a look at existing configurations for examples. Sounds good! Cross compiling in mind from the beginning is very good. > > - If Google takes over the world and all apps become a Native Client > > (may be even other browsers^^;), this port may be useful^^; > > > > Yes, indeed. I like NaCl, because it will allow us to just run VM, > instead of adopting it to browser in form of plugin. > > Do you have any description, what you need to do to get started > building VM for NaCl? > It would be interesting to read. The documentation on it is scarse and some contradictions, but basically all you need is reading header files and the "Pepper C API" section of: http://code.google.com/chrome/nativeclient/docs/reference/pepperc/index.html with some guessworks and try and error. -- Yoshiki |
Re: Squeak VM port to Google Native Client
|
|
In reply to this post by Bert Freudenberg
At Wed, 4 May 2011 11:28:37 -0300, Bert Freudenberg wrote: > > > > On 04.05.2011, at 03:18, Yoshiki Ohshima wrote: > > > > > - As you can see, the source code is derived from the Unix VM. It > > was hard for me to write some CMake stuff to set it up for the > > cross compilation. A help to merge it back to the Unix code would > > be greatly appreciated. > > IMHO merging into the unix code does not make too much sense. It is > a separate port. So it would live under platforms/ like the others. That would be ok. OTOH, some files or major part of some files are idendical. So if there is a way to add a sub-configuration under unix, that may be good. -- Yoshiki |
|
|
Hi Yoshiki, we are starting to work on this, and maybe you can help us. I wanted to know what setup did you use for the tools, and what workflow you follow. Some questions I can think of now: - do you download your git repo over the squeak-svn?
- do you generate the code for unix and then modify by hand or you generate for a new platform? - Is there any image code? Thank you! Javier.
On Wed, May 4, 2011 at 12:30 PM, Yoshiki Ohshima <[hidden email]> wrote:
Lic. Javier Pimás Ciudad de Buenos Aires |
|
|
also, I'm seeing that you use a common.mk file for extra configuration for the makefile. Could you please pass it to me so that I get an example of what's missing?
Cheers, Javier.
On Mon, Aug 29, 2011 at 11:22 AM, Javier Pimás <[hidden email]> wrote: Hi Yoshiki, we are starting to work on this, and maybe you can help us. I wanted to know what setup did you use for the tools, and what workflow you follow. Some questions I can think of now: Lic. Javier Pimás Ciudad de Buenos Aires |
Re: Squeak VM port to Google Native Client
|
|
In reply to this post by melkyades
At Mon, 29 Aug 2011 11:22:03 -0300, Javier Pimás wrote: > > Hi Yoshiki, we are starting to work on this, and maybe you can help us. I wanted to know what setup did you use for the tools, and what workflow you follow. Some > questions I can think of now: > > - do you download your git repo over the squeak-svn? > - do you generate the code for unix and then modify by hand or you generate for a new platform? > - Is there any image code? Hi Javier! Last time I touched it was early May, and so much has changed in the Native Client SDK since then. It was SDK 0.2 and now it is 0.5. Good news is that they claim that API is now stabilizing (which should be somewhat different from 0.2), so now we can have a bit more stable version of VM, presumably. - My git repo was basically "on its own"; Into an empty git repository, I copied files (one file by one file) from squeak-svn and edit them as needed. (So, that was the discussion you quoted; I still think many files can be reused with a bit more ifdefs in the Unix code.) - The annoying kind of generated files, such as config.h, were indeed hand edited. - There is no code for image side yet. A bridge to Pepper API is called for, however. > also, I'm seeing that you use a common.mk file for extra configuration for the makefile. Could you please pass it to me so that I get an example of what's missing? Around this part of the SDK is radically changed since then. Common.mk in the examples/ directory looked like the following back then. But it needs to be adopted the new regime. -- Yoshiki ----------------------------------- # Copyright (c) 2011, The Native Client Authors. All rights reserved. # Use of this source code is governed by a BSD-style license that can be # found in the LICENSE file. # # Common makefile for the examples. This has some basic variables, such as # CC (the compiler) and some suffix rules such as .c.o. # # The main purpose of this makefile component is to demonstrate building a # Native Client module (.nexe) .SUFFIXES: .c .cc .cpp .o .PHONY: check_variables ifeq ($(origin OS), undefined) ifeq ($(shell uname -s), Darwin) OS=Darwin else OS=$(shell uname -o) endif endif ifeq ($(OS), $(filter $(OS), Windows_NT Cygwin)) PLATFORM = win TARGET = x86 endif ifeq ($(OS), $(filter $(OS), Darwin MACOS)) PLATFORM = mac TARGET = x86 endif # Look for 'Linux' in the $(OS) string. $(OS) is assumed to be a Linux # variant if the result of $(findstring) is not empty. ifneq (, $(findstring Linux, $(OS))) PLATFORM = linux TARGET = x86 endif PYTHON ?= /usr/bin/python NACL_SDK_ROOT ?= . NACL_TOOLCHAIN_DIR = toolchain/$(PLATFORM)_$(TARGET) CC = $(NACL_SDK_ROOT)/$(NACL_TOOLCHAIN_DIR)/bin/nacl-gcc CPP = $(NACL_SDK_ROOT)/$(NACL_TOOLCHAIN_DIR)/bin/nacl-g++ NACL_STRIP = $(NACL_SDK_ROOT)/$(NACL_TOOLCHAIN_DIR)/bin/nacl-strip NACL_SEL_LDR32 = $(NACL_SDK_ROOT)/$(NACL_TOOLCHAIN_DIR)/bin/nacl-sel_ldr NACL_SEL_LDR64 = $(NACL_SDK_ROOT)/$(NACL_TOOLCHAIN_DIR)/bin/nacl64-sel_ldr CFLAGS = -Wall -Wno-long-long -pthread -Werror OPT_FLAGS = -O2 DEBUG_FLAGS = -g # Make all the object files depend on the entire list of header files. This # is a little brutal, but it gets the job dome simply without a make depend # step. %_x86_32_dbg.o: %.c $(HFILES) $(CC) $(CFLAGS) -m32 $(INCLUDES) $(DEBUG_FLAGS) -c -o $@ $< %_x86_32_dbg.o: %.cc $(HFILES) $(CPP) $(CFLAGS) -m32 $(INCLUDES) $(DEBUG_FLAGS) -c -o $@ $< %_x86_64_dbg.o: %.c $(HFILES) $(CC) $(CFLAGS) -m64 $(INCLUDES) $(DEBUG_FLAGS) -c -o $@ $< %_x86_64_dbg.o: %.cc $(HFILES) $(CPP) $(CFLAGS) -m64 $(INCLUDES) $(DEBUG_FLAGS) -c -o $@ $< %_x86_32.o: %.c $(HFILES) $(CC) $(CFLAGS) -m32 $(INCLUDES) $(OPT_FLAGS) -c -o $@ $< %_x86_32.o: %.cc $(HFILES) $(CPP) $(CFLAGS) -m32 $(INCLUDES) $(OPT_FLAGS) -c -o $@ $< %_x86_32.o: %.cpp $(HFILES) $(CPP) $(CFLAGS) -m32 $(INCLUDES) $(OPT_FLAGS) -c -o $@ $< %_x86_64.o: %.c $(HFILES) $(CC) $(CFLAGS) -m64 $(INCLUDES) $(OPT_FLAGS) -c -o $@ $< %_x86_64.o: %.cc $(HFILES) $(CPP) $(CFLAGS) -m64 $(INCLUDES) $(OPT_FLAGS) -c -o $@ $< %_x86_64.o: %.cpp $(HFILES) $(CPP) $(CFLAGS) -m64 $(INCLUDES) $(OPT_FLAGS) -c -o $@ $< # Generate list of .o files based on the list of .c and .cc files OBJECTS_X86_32 = $(CFILES:%.c=%_x86_32.o) $(CCFILES:%.cc=%_x86_32.o) OBJECTS_X86_64 = $(CFILES:%.c=%_x86_64.o) $(CCFILES:%.cc=%_x86_64.o) OBJECTS_X86_32_DBG = $(CFILES:%.c=%_x86_32_dbg.o) $(CCFILES:%.cc=%_x86_32_dbg.o) OBJECTS_X86_64_DBG = $(CFILES:%.c=%_x86_64_dbg.o) $(CCFILES:%.cc=%_x86_64_dbg.o) # Make sure certain variables are defined. This rule is set as a dependency # for all the .nexe builds in the examples. check_variables: ifeq ($(origin OS), undefined) @echo "Error: OS is undefined" ; exit 42 endif ifeq ($(origin PLATFORM), undefined) @echo "Error: PLATFORM is undefined (OS = $(OS))" ; exit 42 endif ifeq ($(origin TARGET), undefined) @echo "Error: TARGET is undefined (OS = $(OS))" ; exit 42 endif ifeq ($(origin NACL_SDK_ROOT), undefined) @echo "Error: NACL_SDK_ROOT is undefined" ; exit 42 endif |
|
|
hi! We've already made it compile with PP 0.5, but it's not displaying anything in the browser. Maybe it's the image or the browser version, or something related to PPAPI changes. Which image and chrome version did you use? Actually, we tried your live demo but it isn't working in our browser either. Regards, Javier On Mon, Aug 29, 2011 at 2:15 PM, Yoshiki Ohshima <[hidden email]> wrote:
Lic. Javier Pimás Ciudad de Buenos Aires |
Re: Squeak VM port to Google Native Client
|
|
At Wed, 31 Aug 2011 10:41:49 -0300, Javier Pimás wrote: > > hi! We've already made it compile with PP 0.5, but it's not displaying anything in the browser. Maybe it's the image or the browser version, or something related to PPAPI > changes. Which image and chrome version did you use? Actually, we tried your live demo but it isn't working in our browser either. I started with NaCl SDK 0.2. That was for Chrome 11 or 12? The vanilla 4.1 Squeak image did work and so did 3.0, IIRC. One part that we would need to look at is how the JavaScript code in squeak.html drives display cycle. This part seems to be changed a lot (Many parts have changed on their side). What I'd do is to revive my test project (git://github.com/yoshikiohshima/NaClueakTest.git) first. As you can see this is basically a hybrid of hello_world and pi_generator with the interpret() function that runs in infinite loop. I'd start again from the latest hello_world.c that works. Then, convert some C++ code in pi_generator to C and merge it into hello_world in the way similar to the stuff in my code. I did NaClueakTest experiment on Windows, but I strongly urge to play with Native Client on Linux. My Log() function can be replaced with fprintf to stderr and you can do more sensible debugging. Hope this helps. If you have more troubles, I'd like to find some time to do it by myself. It should not take too long. -- Yoshiki > On Mon, Aug 29, 2011 at 2:15 PM, Yoshiki Ohshima <[hidden email]> wrote: > > At Mon, 29 Aug 2011 11:22:03 -0300, > Javier Pimás wrote: > > > > Hi Yoshiki, we are starting to work on this, and maybe you can help us. I wanted to know what setup did you use for the tools, and what workflow you follow. Some > > questions I can think of now: > > > > - do you download your git repo over the squeak-svn? > > - do you generate the code for unix and then modify by hand or you generate for a new platform? > > - Is there any image code? > > Hi Javier! > > Last time I touched it was early May, and so much has changed in the > Native Client SDK since then. It was SDK 0.2 and now it is 0.5. Good > news is that they claim that API is now stabilizing (which should be > somewhat different from 0.2), so now we can have a bit more stable > version of VM, presumably. > > - My git repo was basically "on its own"; Into an empty git > repository, I copied files (one file by one file) from squeak-svn > and edit them as needed. (So, that was the discussion you quoted; > I still think many files can be reused with a bit more ifdefs in > the Unix code.) > > - The annoying kind of generated files, such as config.h, were > indeed hand edited. > > - There is no code for image side yet. A bridge to Pepper API is > called for, however. > > > also, I'm seeing that you use a common.mk file for extra configuration for the makefile. Could you please pass it to me so that I get an example of what's missing? > > Around this part of the SDK is radically changed since then. > Common.mk in the examples/ directory looked like the following back > then. But it needs to be adopted the new regime. > > -- Yoshiki > > ----------------------------------- > # Copyright (c) 2011, The Native Client Authors. All rights reserved. > # Use of this source code is governed by a BSD-style license that can be > # found in the LICENSE file. > # > # Common makefile for the examples. This has some basic variables, such as > # CC (the compiler) and some suffix rules such as .c.o. > # > # The main purpose of this makefile component is to demonstrate building a > # Native Client module (.nexe) > > .SUFFIXES: .c .cc .cpp .o > > .PHONY: check_variables > > ifeq ($(origin OS), undefined) > ifeq ($(shell uname -s), Darwin) > OS=Darwin > else > OS=$(shell uname -o) > endif > endif > > ifeq ($(OS), $(filter $(OS), Windows_NT Cygwin)) > PLATFORM = win > TARGET = x86 > endif > ifeq ($(OS), $(filter $(OS), Darwin MACOS)) > PLATFORM = mac > TARGET = x86 > endif > > # Look for 'Linux' in the $(OS) string. $(OS) is assumed to be a Linux > # variant if the result of $(findstring) is not empty. > ifneq (, $(findstring Linux, $(OS))) > PLATFORM = linux > TARGET = x86 > endif > > PYTHON ?= /usr/bin/python > NACL_SDK_ROOT ?= . > > NACL_TOOLCHAIN_DIR = toolchain/$(PLATFORM)_$(TARGET) > > CC = $(NACL_SDK_ROOT)/$(NACL_TOOLCHAIN_DIR)/bin/nacl-gcc > CPP = $(NACL_SDK_ROOT)/$(NACL_TOOLCHAIN_DIR)/bin/nacl-g++ > NACL_STRIP = $(NACL_SDK_ROOT)/$(NACL_TOOLCHAIN_DIR)/bin/nacl-strip > NACL_SEL_LDR32 = $(NACL_SDK_ROOT)/$(NACL_TOOLCHAIN_DIR)/bin/nacl-sel_ldr > NACL_SEL_LDR64 = $(NACL_SDK_ROOT)/$(NACL_TOOLCHAIN_DIR)/bin/nacl64-sel_ldr > > CFLAGS = -Wall -Wno-long-long -pthread -Werror > OPT_FLAGS = -O2 > DEBUG_FLAGS = -g > > # Make all the object files depend on the entire list of header files. This > # is a little brutal, but it gets the job dome simply without a make depend > # step. > %_x86_32_dbg.o: %.c $(HFILES) > $(CC) $(CFLAGS) -m32 $(INCLUDES) $(DEBUG_FLAGS) -c -o $@ $< > > %_x86_32_dbg.o: %.cc $(HFILES) > $(CPP) $(CFLAGS) -m32 $(INCLUDES) $(DEBUG_FLAGS) -c -o $@ $< > > %_x86_64_dbg.o: %.c $(HFILES) > $(CC) $(CFLAGS) -m64 $(INCLUDES) $(DEBUG_FLAGS) -c -o $@ $< > > %_x86_64_dbg.o: %.cc $(HFILES) > $(CPP) $(CFLAGS) -m64 $(INCLUDES) $(DEBUG_FLAGS) -c -o $@ $< > > %_x86_32.o: %.c $(HFILES) > $(CC) $(CFLAGS) -m32 $(INCLUDES) $(OPT_FLAGS) -c -o $@ $< > > %_x86_32.o: %.cc $(HFILES) > $(CPP) $(CFLAGS) -m32 $(INCLUDES) $(OPT_FLAGS) -c -o $@ $< > > %_x86_32.o: %.cpp $(HFILES) > $(CPP) $(CFLAGS) -m32 $(INCLUDES) $(OPT_FLAGS) -c -o $@ $< > > %_x86_64.o: %.c $(HFILES) > $(CC) $(CFLAGS) -m64 $(INCLUDES) $(OPT_FLAGS) -c -o $@ $< > > %_x86_64.o: %.cc $(HFILES) > $(CPP) $(CFLAGS) -m64 $(INCLUDES) $(OPT_FLAGS) -c -o $@ $< > > %_x86_64.o: %.cpp $(HFILES) > $(CPP) $(CFLAGS) -m64 $(INCLUDES) $(OPT_FLAGS) -c -o $@ $< > > # Generate list of .o files based on the list of .c and .cc files > OBJECTS_X86_32 = $(CFILES:%.c=%_x86_32.o) $(CCFILES:%.cc=%_x86_32.o) > OBJECTS_X86_64 = $(CFILES:%.c=%_x86_64.o) $(CCFILES:%.cc=%_x86_64.o) > OBJECTS_X86_32_DBG = $(CFILES:%.c=%_x86_32_dbg.o) $(CCFILES:%.cc=%_x86_32_dbg.o) > OBJECTS_X86_64_DBG = $(CFILES:%.c=%_x86_64_dbg.o) $(CCFILES:%.cc=%_x86_64_dbg.o) > > # Make sure certain variables are defined. This rule is set as a dependency > # for all the .nexe builds in the examples. > check_variables: > ifeq ($(origin OS), undefined) > @echo "Error: OS is undefined" ; exit 42 > endif > ifeq ($(origin PLATFORM), undefined) > @echo "Error: PLATFORM is undefined (OS = $(OS))" ; exit 42 > endif > ifeq ($(origin TARGET), undefined) > @echo "Error: TARGET is undefined (OS = $(OS))" ; exit 42 > endif > ifeq ($(origin NACL_SDK_ROOT), undefined) > @echo "Error: NACL_SDK_ROOT is undefined" ; exit 42 > endif > > -- > Lic. Javier Pimás > Ciudad de Buenos Aires > > |
|
|
Thanks for your answer! On Wed, Aug 31, 2011 at 2:52 PM, Yoshiki Ohshima <[hidden email]> wrote:
good because it means it can work with (almost) anything.
yes, a bit
excelent, that's our idea too. We are in a place were the code doesn't even get loaded to the browser so it must be the html part.
No problem, I think we are almost there. Regards, Javier.
Lic. Javier Pimás Ciudad de Buenos Aires |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |