ChakraCore is the core part of the Chakra Javascript engine that powers Microsoft Edge
Thank you for that, now I can stop worrying that my objects in native-land will get eaten due to details I can only see by looking at a disassembly :stuck_out_tongue:
Hi! In case anyone finds it interesting, here's my little project: https://github.com/tondrej/chakracore-delphi
@fatcerberus seems you assumed incorrectly.
Microsoft says it has no plans to stop maintaining EdgeHTML and Chakra, although if usage were to decline, developers could expect them to hit end of support eventually.
Opera 15 lacked stuff that Opera 12 had
it was idiotic
@Fly-Style I think I'm the only regular external contributor to chakracore it would be cool to have another one around
I guess that covers node-chakracore.
@liminzhu has put up a statement about the future of ChakraCore in #5865 @Mouvedia @CatCatCatDog @fatcerberus
I'm fetching from https://aka.ms/chakracore/cc_linux_x64_1_11_4 for now... so far it seems to be stable
i.e. you hover over a line of JS, it highlights the bytecode generated for that line in the dump
So I guess in my reality my requirements are:
- Ability to get a bytecode dump via the API
- Ability to map generated bytecode instructions to source lines
I don't believe that we expose any of that to js-land debuggers (including via our debugging API). We have internal native debugging tools which can do that, and the bytecode instruction -> source line functionality is built in to the bytecode, but I don't think we surface that via JSRT at all
It's not obvious to me what exactly that would mean. One possible hackish solution would be to do
(new Error()).stack and see what that gives you. In node-chakracore we had some small amount of support for inspecting error.stack without just getting back an opaque string, but I forget exactly how we did that right now
(it was all via the chakrashim host layer, so any host can do it)
What I’m trying to do is support relative paths in
require() called from an ES module
In CommonJS that works because each module gets its own copy of require, but for ESM I’d need to know the URI of the module that called require
Pulling the stack trace off an Error object was my first idea too, but wondered if there was a “sanctioned” solution
There's also weirdness with this whole idea, like e.g. what would
["a.js", "b.js"].map(require) do? What is the "caller" of require there?
Intuitively, I would want that resolved against the module calling .map
And even if in this case we skip over internal library frames, the same issue could come up from shims or other things providing non-default library functionality
From an engine perspective, it's basically impossible to tell them apart I think, so the best way in my mind is to be specific and essentially bind the function to a particular context, e.g. specialize it for a given module
And yeah, I think the simplest way to do that is to do something like the commonjs approach where you inject a bit of code at the start
If you jam it all on one line, then it wouldn't impact user code much at all