[v8-users] Re: Problems compiling on Snow Leopard / gcc 4.2.1
On Thu, Jul 16, 2009 at 3:23 AM, Tom Robinson tlrobin...@gmail.com wrote: #define __amd64 1 According to the v8 home page, i32 and ARM are supported, but not i64. Then again, the wording is a bit ambiguous: ...runs on Windows XP and Vista, Mac OS X 10.5 (Leopard), and Linux systems that use IA-32 or ARM processors. which could be interpreted to mean that only the Linux ports have that limitation, whereas Win/Mac don't (but i doubt that's the intention of the text). :-? -- - stephan beal http://wanderinghorse.net/home/stephan/ --~--~-~--~~~---~--~~ v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users -~--~~~~--~~--~--~---
[v8-users] Re: Problems compiling on Snow Leopard / gcc 4.2.1
Someone mentioned to me that the bleeding_edge branch as i64 support, so I tried compiling that with the arch=x64 flag, but no such luck. Different error though: [3][0] ~/scratch/v8-bleeding $ scons arch=x64 scons: Reading SConscript files ... scons: done reading SConscript files. scons: Building targets ... g++ -o obj/release/platform-macos.o -c -Wall -Werror -W -Wno-unused- parameter -pedantic -fno-strict-aliasing -O3 -fomit-frame-pointer - fdata-sections -ffunction-sections -ansi -mmacosx-version-min=10.4 - m64 -fno-rtti -fno-exceptions -Wall -Werror -W -Wno-unused-parameter - pedantic -fno-strict-aliasing -O3 -fomit-frame-pointer -fdata-sections -ffunction-sections -ansi -mmacosx-version-min=10.4 -m64 - DV8_TARGET_ARCH_X64 -DENABLE_LOGGING_AND_PROFILING -Isrc src/platform- macos.cc In file included from src/platform-macos.cc:31: /usr/include/ucontext.h:42:2: error: #error ucontext routines are deprecated, and require _XOPEN_SOURCE to be defined scons: *** [obj/release/platform-macos.o] Error 1 scons: building terminated because of errors. I get the same error if I add the -arch i386 error to the gcc CCFLAGS in the SConstruct file, but compilation does get a lot further than before. On Jul 16, 2009, at 2:16 AM, Stephan Beal wrote: On Thu, Jul 16, 2009 at 3:23 AM, Tom Robinson tlrobin...@gmail.com wrote: #define __amd64 1 According to the v8 home page, i32 and ARM are supported, but not i64. Then again, the wording is a bit ambiguous: ...runs on Windows XP and Vista, Mac OS X 10.5 (Leopard), and Linux systems that use IA-32 or ARM processors. which could be interpreted to mean that only the Linux ports have that limitation, whereas Win/Mac don't (but i doubt that's the intention of the text). :-? -- - stephan beal http://wanderinghorse.net/home/stephan/ --~--~-~--~~~---~--~~ v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users -~--~~~~--~~--~--~---
[v8-users] Property Interceptors - anything similar for functions?
Hi, The property interceptors provide a way to handle any object property with a callback. I was wondering if there is something similar to handle any object method. Thank you, Ravi --~--~-~--~~~---~--~~ v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users -~--~~~~--~~--~--~---
[v8-users] Re: Property Interceptors - anything similar for functions?
A method is nothing but a property with a function as value.
So you can do:
object_template-Set(
f, FunctionTemplate::New(callback)-GetFunction());
or with a property accessor:
HandleValue return_data(LocalString property, const AccessorInfo info) {
return info.Data();
}
object_template-SetAccessor(
String::New(f),
return_data, NULL,
FunctionTemplate::New(callback)-GetFunction());
Matthias
On Thu, Jul 16, 2009 at 5:06 PM, Ravichinn...@yahoo.com wrote:
Hi,
The property interceptors provide a way to handle any object property
with a callback. I was wondering if there is something similar to
handle any object method.
Thank you,
Ravi
--~--~-~--~~~---~--~~
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
-~--~~~~--~~--~--~---
[v8-users] Re: Property Interceptors - anything similar for functions?
Thanks Stephan. Interceptors do seem to handle functions, but, I couldn't figure out a way to access the function arguments. I wish there were an example for such a scenario. On Jul 16, 11:22 am, Stephan Beal sgb...@googlemail.com wrote: On Thu, Jul 16, 2009 at 5:06 PM, Ravi chinn...@yahoo.com wrote: The property interceptors provide a way to handle any object property with a callback. I was wondering if there is something similar to handle any object method. In theory, since a method is-a property, methods can also be handled via interceptors. i haven't tried it, but since JS does not syntactically differentiate between (a.b = c) based on the types of a.b and c, then interceptors should work on methods in the same way they work on non-method members. In theory, of course. -- - stephan bealhttp://wanderinghorse.net/home/stephan/ --~--~-~--~~~---~--~~ v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users -~--~~~~--~~--~--~---
[v8-users] Re: Property Interceptors - anything similar for functions?
The interceptor just returns the function, you aren't calling the function. The arguments come in when you call the function. On Thu, Jul 16, 2009 at 5:39 PM, Ravichinn...@yahoo.com wrote: Thanks Stephan. Interceptors do seem to handle functions, but, I couldn't figure out a way to access the function arguments. I wish there were an example for such a scenario. On Jul 16, 11:22 am, Stephan Beal sgb...@googlemail.com wrote: On Thu, Jul 16, 2009 at 5:06 PM, Ravi chinn...@yahoo.com wrote: The property interceptors provide a way to handle any object property with a callback. I was wondering if there is something similar to handle any object method. In theory, since a method is-a property, methods can also be handled via interceptors. i haven't tried it, but since JS does not syntactically differentiate between (a.b = c) based on the types of a.b and c, then interceptors should work on methods in the same way they work on non-method members. In theory, of course. -- - stephan bealhttp://wanderinghorse.net/home/stephan/ --~--~-~--~~~---~--~~ v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users -~--~~~~--~~--~--~---
[v8-users] novel use of v8 - CSS Scripting Layout
I've produced a proposal for a CSS Scripting Layout specification. I've extended Chrome as a sample implementation. Of course, it relies heavily on v8 and I have gleaned a lot of useful knowledge from this group over the course of its development. I think it is a novel use of v8 and may be of interest to v8 developers. at the core is a constraint satisfaction system that requires a high degree of v8 reentrancy. I'd like to hear feedback from this community. TIA http://blogs.eforceglobal.com/dkarisch/archive/2009/07/16/536.aspx CSS Scripting Layout... a new set of CSS properties and object specifications that together compose a powerful declarative means to describe complex arbitrary layout criteria that are both reusable and extensible. The new properties are Javascript expressions that are woven together in a constraint resolving system to perform a specified layout. Additionally, a set of global objects defined in the constraint resolution Javascript execution environment enable powerful operations to be expressed succinctly resulting in more readable and compact layout specifications. --~--~-~--~~~---~--~~ v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users -~--~~~~--~~--~--~---
[v8-users] Re: Property Interceptors - anything similar for functions?
Thanks Dean. The scenario I'm working on is: having a generic handler to capture all the property and method calls on an object. For example, let's say an object Obj is being used in javaScript, I'd like to capture and record any operation on that Obj, like var a = Obj.A document.write(a) Obj.method1(arg1, arg2); Obj.b = 2; . Here, I do not know the names of Obj's properties/methods ahead. I'd simply like to know that the script accessed Obj property 'A', invoked 'method1' on Obj with arguments 'arg1' and 'arg2', and set the property 'b'. Using Interceptors, is there anyway to figure out the arguments 'arg1' and 'arg2' on 'method1', or will I have to add a function callback after knowing (in the interceptor) that it's trying to invoke a method called 'method1'. Thank you. On Jul 16, 11:49 am, Dean McNamee de...@chromium.org wrote: The interceptor just returns the function, you aren't calling the function. The arguments come in when you call the function. On Thu, Jul 16, 2009 at 5:39 PM, Ravichinn...@yahoo.com wrote: Thanks Stephan. Interceptors do seem to handle functions, but, I couldn't figure out a way to access the function arguments. I wish there were an example for such a scenario. On Jul 16, 11:22 am, Stephan Beal sgb...@googlemail.com wrote: On Thu, Jul 16, 2009 at 5:06 PM, Ravi chinn...@yahoo.com wrote: The property interceptors provide a way to handle any object property with a callback. I was wondering if there is something similar to handle any object method. In theory, since a method is-a property, methods can also be handled via interceptors. i haven't tried it, but since JS does not syntactically differentiate between (a.b = c) based on the types of a.b and c, then interceptors should work on methods in the same way they work on non-method members. In theory, of course. -- - stephan bealhttp://wanderinghorse.net/home/stephan/- Hide quoted text - - Show quoted text - --~--~-~--~~~---~--~~ v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users -~--~~~~--~~--~--~---
[v8-users] Re: Problems compiling on Snow Leopard / gcc 4.2.1
Tom, Can you please try with bleeding_edge revision 2489? This should make sure that the gcc flags and the target architecture are consistent. I do not have a Snow Leopard machine to test on currently, but this change should fix the confusion of gcc building for a 64-bit target when we are generating ia32 code in the JIT. Thanks, -Ivan P.S. Also note that the x64 build is certainly not at a state where you should be testing it yet unless of course you want to commit fixes to it. On Thu, Jul 16, 2009 at 02:26, Tom Robinsontlrobin...@gmail.com wrote: Someone mentioned to me that the bleeding_edge branch as i64 support, so I tried compiling that with the arch=x64 flag, but no such luck. Different error though: [3][0] ~/scratch/v8-bleeding $ scons arch=x64 scons: Reading SConscript files ... scons: done reading SConscript files. scons: Building targets ... g++ -o obj/release/platform-macos.o -c -Wall -Werror -W -Wno-unused- parameter -pedantic -fno-strict-aliasing -O3 -fomit-frame-pointer - fdata-sections -ffunction-sections -ansi -mmacosx-version-min=10.4 - m64 -fno-rtti -fno-exceptions -Wall -Werror -W -Wno-unused-parameter - pedantic -fno-strict-aliasing -O3 -fomit-frame-pointer -fdata-sections -ffunction-sections -ansi -mmacosx-version-min=10.4 -m64 - DV8_TARGET_ARCH_X64 -DENABLE_LOGGING_AND_PROFILING -Isrc src/platform- macos.cc In file included from src/platform-macos.cc:31: /usr/include/ucontext.h:42:2: error: #error ucontext routines are deprecated, and require _XOPEN_SOURCE to be defined scons: *** [obj/release/platform-macos.o] Error 1 scons: building terminated because of errors. I get the same error if I add the -arch i386 error to the gcc CCFLAGS in the SConstruct file, but compilation does get a lot further than before. On Jul 16, 2009, at 2:16 AM, Stephan Beal wrote: On Thu, Jul 16, 2009 at 3:23 AM, Tom Robinson tlrobin...@gmail.com wrote: #define __amd64 1 According to the v8 home page, i32 and ARM are supported, but not i64. Then again, the wording is a bit ambiguous: ...runs on Windows XP and Vista, Mac OS X 10.5 (Leopard), and Linux systems that use IA-32 or ARM processors. which could be interpreted to mean that only the Linux ports have that limitation, whereas Win/Mac don't (but i doubt that's the intention of the text). :-? -- - stephan beal http://wanderinghorse.net/home/stephan/ --~--~-~--~~~---~--~~ v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users -~--~~~~--~~--~--~---
