Yep, we diagnosed the same yesterday. What happens is this: When trying to
construct an External value, we check if the given void* fits in a Smi. If
it does, we return a Smi, otherwise we create a Foreign object which wraps
the void*. The latter case is problematic, and this is exactly what is
After several discussions, it is not so clear anymore what to do. First of
all, SilkJS does not follow https://developers.google.com/v8/embed#dynamic on
how to handle foreign (i.e. C/C++) pointers when embedding v8. The return
value of External::New is supposed to live in an internal field, but it
Chromium's bindings layer uses External to associate opaque data with
V8 objects and callbacks (see methods accepting HandleValue data in
V8 api).
So making External into a non-Value might involve some bindings work.
--
Vyacheslav Egorov
On Fri, Sep 7, 2012 at 2:50 PM, Sven Panne
Shouldn't use use GetPointerFromInternalField and SetPointerInInternalField
for this? For SetInternalField one could change the signature to use Data
or provide an overloaded version. Anyway, saying External is-a Value in its
current state is plainly wrong... :-)
On Fri, Sep 7, 2012 at 3:02 PM,
I have no issue with JS being able to crash SilkJS. In fact, I see it as a
feature. The whole point of SilkJS is to provide a C-like and low-level
Linux/OSX programming environment using JavaScript.
In C, you can crash your programs as trivially as:
fwrite(buf, 10, 1, (FILE *)0xdeadbeef);
On Fri, Sep 7, 2012 at 3:18 PM, mschwartz myk...@gmail.com wrote:
I have no issue with JS being able to crash SilkJS. In fact, I see it as
a feature. The whole point of SilkJS is to provide a C-like and low-level
Linux/OSX programming environment using JavaScript.
In C, you can crash your
On Fri, Sep 7, 2012 at 5:25 PM, Jakob Kummerow jkumme...@chromium.orgwrote:
The part of the V8 API documentation that applies here is how to wrap an
External (that was created in C++!) safely before passing it into JS (where
it can't be used anyway! It can only be read from C++). And that's by
There are hundreds of thousands of google search results (hits) about
NodeJS crashing and core dumping and how to keep your server up and
running. I see Chrome throw up Aw snap pages frequently enough. I've
seen segfault messages in apache logfiles.
The fact that SilkJS can crash is fine
On Fri, Sep 7, 2012 at 5:57 PM, mschwartz myk...@gmail.com wrote:
As I see it, the API you exposed in your header files and documentation is
something of a contract, and I abided by it. My code has worked extremely
well and quite robustly for well over a year. You change the API, you
break
On Fri, Sep 7, 2012 at 5:48 PM, Stephan Beal sgb...@googlemail.com wrote:
On Fri, Sep 7, 2012 at 5:25 PM, Jakob Kummerow jkumme...@chromium.orgwrote:
The part of the V8 API documentation that applies here is how to wrap an
External (that was created in C++!) safely before passing it into JS
I'd also point out that the traditional means that API designers use to
change an API is to mark existing API they want people to stop using as
deprecated, but allow that API to continue to work. Additionally, if I
turn on some switch, the API might emit a message saying that some
deprecated
Returns External::New()
Please, please, please, don't break this going forward.
struct ScriptWrapper {
PersistentScript script;
};
static JSVAL compileScript (JSARGS args) {
HandleScope scope;
ScriptWrapper *wrapper = new ScriptWrapper;
wrapper-script =
As a point of information, the X64 build works fine.
On Wednesday, September 5, 2012 2:33:03 PM UTC-7, mschwartz wrote:
It is out of the blue that SilkJS compiled for 32-bit Ubuntu is throwing
an error at startup. Actually it's V8 that is throwing the error.
The script being compiled by v8
I've been able to verify this using a fresh install of SilkJS and v8 on 32
bit Ubuntu 12.04 on both EC2 hosts and a VirtualBox host instantiated by
Vagrant (see https://github.com/obscurerichard/vagrant-silkjs for a quick
way to reproduce the environment).
This version of v8
14 matches
Mail list logo
