[Vm-dev] Squeak VM port to Google Native Client
Javier Pimás
elpochodelagente at gmail.com
Wed Aug 31 19:27:50 UTC 2011
Thanks for your answer!
On Wed, Aug 31, 2011 at 2:52 PM, Yoshiki Ohshima <yoshiki at vpri.org> wrote:
>
> 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.
>
good because it means it can work with (almost) anything.
>
> 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).
>
>
yes, a bit
> 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.
>
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.
>
> 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.
>
No problem, I think we are almost there.
Regards,
Javier.
>
> -- Yoshiki
>
> > On Mon, Aug 29, 2011 at 2:15 PM, Yoshiki Ohshima <yoshiki at vpri.org>
> 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
> >
> >
>
--
Lic. Javier Pimás
Ciudad de Buenos Aires
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110831/29c853bf/attachment.htm
More information about the Vm-dev
mailing list