Duktape - embeddable Javascript engine with a focus on portability and compact footprint



Build status Test status

⚠️ Master branch is undergoing incompatible changes for Duktape 3.x. To track Duktape 2.x, follow the v2-maintenance branch.


Duktape is an embeddable Javascript engine, with a focus on portability and compact footprint.

Duktape is easy to integrate into a C/C++ project: add duktape.c, duktape.h, and duk_config.h to your build, and use the Duktape API to call ECMAScript functions from C code and vice versa.

Main features:

  • Embeddable, portable, compact
  • ECMAScript E5/E5.1 compliant, with some semantics updated from ES2015+
  • Partial support for ECMAScript 2015 (E6) and ECMAScript 2016 (E7), Post-ES5 feature status, kangax/compat-table
  • ES2015 TypedArray and Node.js Buffer bindings
  • WHATWG Encoding API living standard
  • Built-in debugger
  • Built-in regular expression engine
  • Built-in Unicode support
  • Minimal platform dependencies
  • Combined reference counting and mark-and-sweep garbage collection with finalization
  • Custom features like coroutines
  • Property virtualization using a subset of ECMAScript ES2015 Proxy object
  • Bytecode dump/load for caching compiled functions
  • Distributable includes an optional logging framework, CommonJS-based module loading implementations, CBOR bindings, etc
  • Liberal MIT license (see LICENSE.txt)

See duktape.org for packaged end-user downloads and documentation. The end user downloads are also available from the duktape-releases repo as both binaries and in unpacked form as git tags.

Have fun!


About this repository

This repository is intended for Duktape developers only, and contains Duktape internals: test cases, internal documentation, sources for the duktape.org web site, etc.

Getting started: end user

When embedding Duktape in your application you should use the packaged source distributables available from duktape.org/download.html. See duktape.org/guide.html#gettingstarted for the basics.

The distributable src/ directory contains a duk_config.h configuration header and amalgamated sources for Duktape default configuration. If necessary, use python tools/configure.py to create header and sources for customized configuration options, see http://wiki.duktape.org/Configuring.html. For example, to enable fastint support (example for Linux):

$ tar xvfJ duktape-2.0.0.tar.xz
$ cd duktape-2.0.0
$ rm -rf src-custom
$ python tools/configure.py \
      --source-directory src-input \
      --output-directory src-custom \
      --config-metadata config \

# src-custom/ will now contain: duktape.c, duktape.h, duk_config.h.

You can download and install Duktape using the vcpkg dependency manager:

$ git clone https://github.com/Microsoft/vcpkg.git
$ cd vcpkg
$ ./bootstrap-vcpkg.sh
$ ./vcpkg integrate install
$ vcpkg install duktape

The Duktape port in vcpkg is kept up to date by Microsoft team members and community contributors. If the version is out of date, please create an issue or pull request on the vcpkg repository.

You can also clone this repository, make modifications, and build a source distributable on Linux, macOS, and Windows using python util/dist.py. You'll need Python 2 and Python YAML binding.

Getting started: modifying and rebuilding the distributable

If you intend to change Duktape internals and want to rebuild the source distributable in Linux, macOS, or Windows:

# Linux; can often install from packages or using 'pip'
# Install Node.js >= 14.x
$ sudo apt-get install python python-yaml
$ python util/dist.py

# macOS
# Install Python 2.7.x
# Install Node.js >= 14.x
$ pip install PyYAML
$ python util/dist.py

# Windows
; Install Python 2.7.x from python.org, and add it to PATH
; Install Node.js >= 14.x
> pip install PyYAML
> python util\dist.py

The source distributable directory will be in dist/.

For platform specific notes see http://wiki.duktape.org/DevelopmentSetup.html.

Getting started: other development (Linux only)

Other development stuff, such as building the website and running test cases, is based on a Makefile supported for Linux x86-64 only.

There are some Docker images which can simplify the development setup and also document the needed packages. These are also supported for Linux x86-64 only. For example:

# Build Docker images.  This takes a long time.
$ make docker-images

# Equivalent of 'make dist-source', but runs inside a container.
$ make docker-dist-source-wd

# Run a shell with /work/duktape containing a disposable master snapshot.
$ make docker-shell-master

# Run a shell with /work/duktape mounted from current directory.
# This allows editing, building, testing, etc with an interactive
# shell running in the container.
$ make docker-shell-wdmount

# For non-native images you may need:
# https://github.com/multiarch/qemu-user-static

There is limited support for developing on macOS via Docker. On Apple M1:

$ make docker-images-arm64
$ DOCKER_ARCH=arm64 make docker-shell-wdmount

Branch policy

  • The master branch is used for active development. Even though pull requests are tested before merging, master may still be broken from time to time. When development on a new major release starts, master will also get API incompatible changes without warning. For these reasons you should generally not depend on the master branch for building your project; use a release tag (e.g. v2.4.0) or a release maintenance branch (e.g. v2.4-maintenance or v2-maintenance) instead.

  • Pull requests and their related branches are frequently rebased so you should not fork off them. Pull requests may be open for a while for testing and discussion.

  • Release tags like v1.4.1 are used for releases and match the released distributables. These are stable once the release is complete.

  • Maintenance branches are used for backporting fixes and features for maintenance releases. Documentation changes go to master for maintenance releases too. For example, v1.5-maintenance was created for the 1.5.0 release and is used for 1.5.x maintenance releases.

  • A maintenance branch is also created for a major release when master moves on to active development of the next major release. For example, v1-maintenance was created when 1.5.0 was released (last planned 1.x release) and development of 2.0.0 (with API incompatible changes) started on master. The 1.6.0 and 1.7.0 releases were made from v1-maintenance for example.


Duktape uses Semantic Versioning for official releases. Builds from Duktape repo are not official releases and don't follow strict semver, mainly because DUK_VERSION needs to have some compromise value that won't be strictly semver conforming. Because Duktape tracks the latest ECMAScript specification versions, compliance fixes are made in minor versions even when they are technically not backwards compatible. See Versioning for details.

Reporting bugs


Security critical GitHub issues (for example anything leading to a segfault) are tagged security.



Copyright and license

See AUTHORS.rst and LICENSE.txt.

Duktape Wiki is part of Duktape documentation and under the same copyright and license.

  • Strange assert, unmoved heapptr was selected for finalization

    Strange assert, unmoved heapptr was selected for finalization

    Were there any major changes to garbage collection?

    Take this with a grain of salt since usually the bugs I present is some weird thing I messed up in my side, but this was a strange one.

    In my app I have certain indices in the stash reserved for some object pools. The pools get allocated at the beginning as arrays, and they are left there. I simply grab the heapptr and add/remove objects to that array. I haven't had any issues with it ever, suddenly today I got an assert triggered when I pushed the stashed pool's heapptr:

    /* One particular problem case is where an object has been
    		 * queued for finalization but the finalizer hasn't been
    		 * executed.
    		duk_heaphdr *curr;
    		for (curr = thr->heap->finalize_list;
    		     curr != NULL;
    		     curr = DUK_HEAPHDR_GET_NEXT(thr->heap, curr)) {
    			DUK_ASSERT(curr != (duk_heaphdr *) ptr);

    Again, I might have corrupted something somewhere, who knows, just looking for some info in case there were some changes that might have caused this? This portion of my code (with the pool) hasn't been touched in a very long time...

    The heapptr which is an array inside an array inside the heap stash is only ever grabbed from the stash index once at the beginning, the pushed into the stack only 3 places in the code. The stash is not messed with again other than in initializing those arrays at the beginning.

    If it helps, the objects that are stored in that pool (the heapptr that caused the assert) are revived when being finalized. That is, the pool is full of preallocated Ecmascirpt objects that I grab from the pool return them when I need one, then nullify that object's index. When the object get's finalized I keep it alive by storing it back in the pool.

    bug security 
    opened by harold-b 268
  • Add support for debugger heap walking

    Add support for debugger heap walking

    Add support for safe debugger heap walking:

    • Add a primitive to inspect an object and its properties and flags without side effects. This allows the debug client to enumerate properties, look up the prototype chain, walk referenced objects, etc.
    • Add a mechanism for some kind of heap locking to avoid garbage collection while walking the heap.


    • [x] Add a new debugger command for inspecting an object
    • [x] Add new debugger commands to "lock" the heap for walking (see discussion in #358) => For now, uses automatic locking during paused state; future work is to add an explicit GC during paused state if that is necessary for some reason
    • [x] Add sizeof(void *) to BasicInfo
    • [x] Add optional heapptr target to GetBytecode?
    • [ ] Debugger protocol documentation
    • [ ] Wiki page for debugger heap walking with more verbose discussion and example command sequences - https://github.com/svaarala/duktape-wiki/pull/81
    • [ ] Some minimal implementation in the web UI
    • [ ] Document garbage collection behavior during paused state into debugger documentation; refzero cases go through mark-and-sweep now
    • [ ] Read through debugger.rst and update design notes and future work re: inspect
    • [ ] Releases

    Low level issues to resolve:

    • [x] What to do about virtual properties - i.e. properties logically part of the object and visible to Ecmascript code, but not concretely part of the object's internal property table? For comparison, enumeration code needs to "fake" these properties. => For now, virtual properties are not returned in inspection; future work.
    • [ ] Make the InspectHeapObject command optional because of the relatively high footprint.
    • [ ] Should property keys be object references to heap strings? If yes, what to do about artificial keys? If no, how would user code be able to dump all heap strings? Should there be a LookupString command to find an interned string?

    Consider overlaps with existing commands:

    • [ ] InspectHeapObject and DumpHeap: Could DumpHeap simply provide a list of heap pointers which the debug client would then inspect using InspectHeapObject so that there'd be no formatting overlap?
    • [ ] InspectHeapObject and GetBytecode: GetBytecode could be replaced by simply getting a reference to the currently executing function and then adding the bytecode, constants, and inner functions into the InspectHeapObject result. There's a small issue in representing structured values there; temporary objects may need to be created to hold the constants, etc.
    enhancement debugger 
    opened by svaarala 228
  • Implement debugger halt-on-throw

    Implement debugger halt-on-throw

    When the debugger is attached and an error is thrown with no active catch site, either a runtime error thrown by Duktape or directly by Ecmascript code, the debug client is notified and execution is paused at the error site to allow the developer to view program state. This is useful, as this information will be lost once the stack is unwound.

    Implementation checklist:

    • [x] Implement the basic logic for debugger error intercept.
    • [x] Add a Throw notification to alert the client to the error.
    • [x] Ensure yield/resume awareness to avoid spurious pauses.
    • [x] Fix C stack overflow when an error is thrown at max recursion (double error pileup).
    • [x] Fix crashes when intercepting errors originating from the compiler (fixed by not intercepting them).
    • [x] Fix an assert failure when execution is stopped inside a Duktape/C call.
    • [x] Finalize changes and ensure consistency with Duktape codebase.
    opened by fatcerberus 132
  • Improve opcode dispatch further by using a local curr_pc in executor

    Improve opcode dispatch further by using a local curr_pc in executor

    With #265 bytecode dispatch uses a cached thr->curr_pc pointer which is copied back into the topmost activation act->curr_pc whenever activation states may change or an up-to-date activation state is needed (e.g. for line numbers in the debugger).

    This can probably be improved a bit further:

    • Use a local variable in the bytecode executor for curr_pc. Make that variable volatile so that it is always stored back into the stack frame after a dispatch.
    • Store a pointer to the stack frame location which holds curr_pc (i.e. a duk_instr_t ** with &curr_pc as its value) in thr->ptr_curr_pc.
    • Wherever thr->curr_pc was copied back into act->curr_pc after #265, copy the value from *thr->ptr_curr_pc instead.

    This is faster because thr is sometimes spilled but the stack frame pointer is not.

    Preliminary testing suggests this is roughly 5% faster than #265 (to be verified with more careful testing).


    • [x] Main source changes to implement the change
    • [x] Perhaps simplify management of thr->ptr_curr_pc: bytecode executor can establish it, and restore it before exiting (it always has a setjmp catchpoint so it can do this reliably)
    • [x] Check volatile declarations
    • [x] Verify performance difference
    • [x] Update doc/execution.rst
    • [x] Testcases (apitest, qecmatest, test262)
    • [x] Test debugger manually
    opened by svaarala 116
  • Add initial ES6 symbol support

    Add initial ES6 symbol support

    This is a prototype for an implementation approach where Symbols are duk_hstrings with a specific byte prefix which cannot occur for valid (extended) UTF-8 strings. The existing internal string concept is essentially taken a step further to support ES6 Symbols. There's no new internal type for Symbols as such, and the C API sees Symbols as just strings.

    • [x] Code change for symbol support
    • [x] Fix compiler warnings
    • [x] Fix Reflect.keys()
    • [x] Testcase support
    • [x] Fix perftest coercion issues
    • [x] Check key coercion for duk_def_prop() and other property calls
    • [x] Wiki pull for symbols howto (should cover the C API aspects especially) - https://github.com/svaarala/duktape-wiki/pull/152
    • [x] 2.x migration notes
    • [x] Releases entry
    • [x] Read through pull comments and add cleanup issues to #1120
    opened by svaarala 108
  • Fix debugger re-entry while detaching

    Fix debugger re-entry while detaching

    Fixes #597. Possibly related to debugger read callback re-entry issue described in #591.


    • [x] Fix debugger re-entry when dbg_processing was set to zero during detach1()
    • [x] Fix Duktape never doing detach2() if detach1() occurred outside of debugger message loop
    • [x] Fix write_cb NULLing for duk_debug_write_byte()
    • [x] Any way to repeat @harold-b's issue with repeated read calls not resetting callbacks to NULL? => Could not reproduce.
    • [x] Add fix backport notes for earlier releases where appropriate
    • [x] Releases
    bug debugger 
    opened by svaarala 108
  • Implement application-defined debugger command support

    Implement application-defined debugger command support

    This adds application-defined message support to the debug protocol. When Duktape receives a request message beginning with the code for AppRequest (currently 0x22), it pushes all the remaining dvalues in the message to the valstack and calls heap->dbg_request_cb. That callback can push its own values to the stack, and these are sent back to the client as a REP, or optionally return -1 to send the value on the stack top as an ERR response.

    It is also possible for the target to send application-defined notifys (AppNotify, 0x07) to the client by calling duk_debugger_notify().

    This branch is merge-ready.

    enhancement debugger 
    opened by fatcerberus 106
  • Add a Node.js-like module loader extra

    Add a Node.js-like module loader extra

    A module loading framework and require() implementation based on Node.js. Semantics match Node.js wherever possible and most features of the Node module system are provided.



    • Application provides callbacks to perform module resolution and loading
    • Module caching based on resolved module ID
    • Tolerates circular require() chains
    • Supports module.exports, module.loaded, and module.require
    • Supports require.cache
    • Supports __filename (but not __dirname)


    • [x] Expose duk__push_require_function() to calling code? => duk_module_node_init() registers a global require, so not needed
    • [x] Manual tests to ensure correctness of all features such as module.loaded, require.cache, etc.
    • [x] Full documentation, in particular for callbacks
    • [x] More/better sanity checks/guards around callback invocations? => callbacks are now Duktape/C functions
    • [x] Rename extra to module-node
    • [x] Match Node.js module ID semantics (module.id === module.filename)
    opened by fatcerberus 99
  • Implement WHATWG Encoding API support

    Implement WHATWG Encoding API support

    Implements #961.

    Add TextEncoder and TextDecoder built-ins as described by the WHATWG Encoding specification. For this pull, only UTF-8/CESU-8 support is implemented. UTF-16 and all legacy encodings are left as future work.

    Specification: https://encoding.spec.whatwg.org/#api


    • [x] Implement the WHATWG Encoding API: TextEncoder and TextDecoder
    • [x] Config option - DUK_USE_ENCODING_BUILTINS
    • [x] Support Encoding API with bufferobjects disabled? Bindings could then work with plain buffers instead of Uint8Arrays (out of spec).
    • [x] Node.js Buffer .toString() can share code with TextDecoder? => Save for later
    • [x] Test cases for both encode and decode
    • [x] Website note (Encoding API listed in features)
    • [x] RELEASES entry
    opened by fatcerberus 91
  • Error thrown in try/finally with no catch causes internal error

    Error thrown in try/finally with no catch causes internal error

    try { throw new Error("A pig ate everyone at 8:12"); }
    finally { print("*munch*"); }

    The finally runs, but leads to "internal error in bytecode executor longjmp handler". What's odd is that I can't always reproduce it. Depending on the surrounding lines, it sometimes works correctly.

    opened by fatcerberus 80
  • Avoid finalizer rerun unless object is rescued

    Avoid finalizer rerun unless object is rescued

    Change duk_hobject_run_finalizer() so that:

    • If DUK_HEAPHDR_FLAG_FINALIZED is already set, do nothing.
    • Set DUK_HEAPHDR_FLAG_FINALIZED just before running finalizer.

    This should guarantee the semantics described in #109 (= at most one finalizer call per rescue cycle) because:

    • The only place where a finalizer is called is duk_hobject_run_finalizer().
    • The FINALIZED flag is only cleared by an explicit rescue, detected by either mark-and-sweep or refcounting.

    Other changes:

    • Heap destruction finalizer behavior changes: allow finalizers to create new finalizable objects whose finalizers are also executed, sanity limit.
    • Explicit Proxy check, don't call finalizer on a Proxy object.


    • [x] Review changes
    • [x] Try to come up with a repro case for finalizer re-run, most obvious cases are already fixed
    • [x] Test case for runaway finalizer which spawns 1 or 2 new objects per finalization
    • [x] Test case for new finalizer argument
    • [x] Ensure "mark-and-sweep running" is checked even when mark-and-sweep not enabled
    • [x] Website changes for new guarantee
    • [x] Internal doc changes for new guarantee
    • [x] Add second parameter to finalizer indicating if rescue is possible or not (true: heap being destroyed, can't rescue; false: normal rescue possible)
    • [x] Finalizer documentation changes for new 2nd argument
    • [x] Run heap destruction finalizers in a loop to allow any new finalizable objects created by previous finalizers to also be finalized
    • [x] Add a sanity limit to the finalization loop
    • [x] Releases
    • [x] Assert run with mark-and-sweep + refcounting
    • [x] Assert run with mark-and-sweep only
    • [x] Assert run with refcounting only

    Fixes #109. See #108.

    opened by svaarala 76
  • Regexp [\s\S]* not matching emojis

    Regexp [\s\S]* not matching emojis

    Hi, apologies if this is not a Duktape issue.

    I'm actually updating an old plugin for Movian and I'm new to both as a coder.

    So as the title says after reading some web content using showtime.httpReq(), the regex match and exec parsing will abruptly end upon finding an emoji, as if they weren't matching \S. But all online Ecmascript compliant regex testers I tried say it should match.

    I cannot reproduce the problem with a snippet because I can't figure out how to properly build a string with an emoji. I tried several ways, including codepoint format, octets and whatnot, but for some reason d() (Not sure it's a print debug function of Movian or Duktape) doesn't print the emojis right whereas it does print the ones from the web just fine to the terminal. I have checked the web source and they don't appear to be escaped, however pasting the emoji as is in vscode gives me ugly output as well.

    Any pointers please?

    Edit: where are the sources for regex?

    opened by ecv80 2
  • dist-files/Makefile.sharedlibrary: link against libm

    dist-files/Makefile.sharedlibrary: link against libm

    Closes #2464.

    I hit an issue with polkit, it segfaults if libduktape.so is not linked against libm.so.
    As an alternative, I tried to make sure polkit's daemon and all libs are linked against libm (see the attached patch), but this didn't help.
    Unless there's something I miss, it doesn't look like linking duktape against libm is optional, so I'm adding it to the example Makefile.sharedlibrary.


    diff --git a/meson.build b/meson.build
    index dd09b28..e8ba5e6 100644
    --- a/meson.build
    +++ b/meson.build
    @@ -138,7 +138,7 @@ duktape_req_version = '>= 2.2.0'
     js_engine = get_option('js_engine')
     if js_engine == 'duktape'
       js_dep = dependency('duktape', version: duktape_req_version)
    -  libm_dep = cc.find_library('m')
    +  libm_dep = declare_dependency( link_args : [ '-Wl,--no-as-needed' , '-lm', '-Wl,--as-needed' ] )
       thread_dep = dependency('threads')
       func = 'pthread_condattr_setclock'
       config_h.set('HAVE_' + func.to_upper(), cc.has_function(func, prefix : '#include <pthread.h>'))
    diff --git a/src/polkit/meson.build b/src/polkit/meson.build
    index 63dc1e8..22b2988 100644
    --- a/src/polkit/meson.build
    +++ b/src/polkit/meson.build
    @@ -38,6 +38,7 @@ install_headers(
     common_deps = [
    +  libm_dep,
     enum_sources = gnome.mkenums_simple(
    @@ -110,7 +111,7 @@ pkg.generate(
       description: 'PolicyKit Authorization API',
       filebase: name,
       subdirs: pk_api_name,
    -  requires: common_deps,
    +  libraries: common_deps,
       variables: [
         'datadir=' + ('${prefix}' / pk_datadir),
    diff --git a/src/polkitagent/meson.build b/src/polkitagent/meson.build
    index bee3820..e4e3438 100644
    --- a/src/polkitagent/meson.build
    +++ b/src/polkitagent/meson.build
    @@ -39,6 +39,7 @@ deps = [
    +  libm_dep,
     c_flags = [
    opened by tinywrkb 3
  • Duktape fails to compile with DJGPP (DOS port of GCC)

    Duktape fails to compile with DJGPP (DOS port of GCC)

    There is a very simple fix, though... I added in

    #ifdef __DJGPP

    in duk_config.h after the OS/compiler detection logic and my test program compiled and ran flawlessly.

    opened by shdon 15
  • Force linking against libm

    Force linking against libm

    When the default LDFLAGS from the environment has --as-needed, then the generated shared libs would not be linked against libm.
    I suggest adding something like -Wl,--no-as-needed,-lm to the Makefile command.
    Example of an app that segfault when duktape is not linked against libm is polkit.

    I don't feel confident to send this as a PR, as I can't properly test this change, I'm not sure if this just need to be in Makefile.sharedlibrary, and how this affect other libc than glibc, so someone else will have to handle this issue.

    opened by tinywrkb 4
  • Protection against infinite loop, overruns stack, segfault

    Protection against infinite loop, overruns stack, segfault


    I'm building my own visual debugger[1] (and it is nearly done :-) ), and I need to add a protection against infinite loop[2]. And I'm at my wit's end.

    First I altered my code to use the following limit: -DDUK_USE_CALLSTACK_LIMIT=10 And used a JS code like this one: function somme(a) {return somme(a+1) + 2;};somme(5);

    It seems that when the limit is reached, Duktape is looping trying to generate a DUK_ERROR_RANGE, namely looping on DUK_ERROR_RANGE(thr, DUK_STR_CALLSTACK_LIMIT);, and then segfault. That does look like the ticket #1391.

    I built an example:

    • python2 tools/configure.py -DDUK_USE_FATAL_HANDLER -DDUK_USE_INTERRUPT_COUNTER -DDUK_USE_DEBUGGER_SUPPORT -DDUK_USE_CALLSTACK_LIMIT=10 --output-directory duktape-src
    • use and alteration of the sources available here: examples/debug-trans-dvalue/ [4]
    • build with gcc -g duk_trans_dvalue.c duktape.c test.c -o toto.bin -lm

    And again Duktape is looping on DUK_ERROR_RANGE(thr, DUK_STR_CALLSTACK_LIMIT); and the segfault.

    So, is there someone having an idea on how to manage in a proper way an infinite loop[3] ?

    PS : I'm using duktape-2.6.0.tar.xz, and linux

    [1] Yes I already said it once #2449 [2] to be more precise, I'm building a tool for teaching basic programming. [3] I can imagine to run a script only on a step-by-step, but it would be inefficient (a lot of interruptions, slow speed, etc) [4] I removed some comments and used a specific JS Code:

     *  Example program using the dvalue debug transport.
    #include <stdio.h>
    #include <stdlib.h>
    #include "duktape.h"
    #include "duk_trans_dvalue.h"
    void my_cooperate(duk_trans_dvalue_ctx *ctx, int block) {
    	static int first_blocked = 1;
    	if (!block) {
    	duk_trans_dvalue_send_req_cmd(ctx, 0x13);
    void my_received(duk_trans_dvalue_ctx *ctx, duk_dvalue *dv) {
    	(void) ctx;
    void my_handshake(duk_trans_dvalue_ctx *ctx, const char *line) {
    	(void) ctx;
    	fprintf(stderr, "Received handshake line: '%s'\n", line);
    void my_detached(duk_trans_dvalue_ctx *ctx) {
    	(void) ctx;
    	fprintf(stderr, "Debug transport detached\n");
    static duk_ret_t native_print(duk_context *ctx) {
    	duk_push_string(ctx, " ");
    	duk_insert(ctx, 0);
    	duk_join(ctx, duk_get_top(ctx) - 1);
    	printf("%s\n", duk_to_string(ctx, -1));
    	return 0;
    int main(int argc, char *argv[]) {
    	duk_context *ctx;
    	duk_trans_dvalue_ctx *trans_ctx;
    	int exitval = 0;
    	(void) argc; (void) argv;  /* suppress warning */
    	ctx = duk_create_heap_default();
    	if (!ctx) {
    		fprintf(stderr, "Failed to create Duktape heap\n");
    		exitval = 1;
    		goto cleanup;
    	duk_push_c_function(ctx, native_print, DUK_VARARGS);
    	duk_put_global_string(ctx, "print");
    	trans_ctx = duk_trans_dvalue_init();
    	if (!trans_ctx) {
    		fprintf(stderr, "Failed to create debug transport context\n");
    		exitval = 1;
    		goto cleanup;
    	trans_ctx->cooperate = my_cooperate;
    	trans_ctx->received = my_received;
    	trans_ctx->handshake = my_handshake;
    	trans_ctx->detached = my_detached;
    	                    NULL,  /* app request cb */
    	                    (void *) trans_ctx);
    	fprintf(stderr, "Debugger attached, running eval\n");
    	duk_eval_string(ctx, "function somme(a) {return somme(a+1) + 2;};somme(5);");
    	if (trans_ctx) {
    		trans_ctx = NULL;
    	if (ctx) {
    	return exitval;
    opened by lemmel 1
Sami Vaarala
Sami Vaarala
ChakraCore is an open source Javascript engine with a C API.

ChakraCore ChakraCore is a Javascript engine with a C API you can use to add support for Javascript to any C or C compatible project. It can be compil

null 8.7k Jul 1, 2022
Structy is an irresponsibly dumb and simple struct serialization/deserialization library for C, Python, and vanilla JavaScript.

Structy Structy is an irresponsibly dumb and simple struct serialization/deserialization library for C, Python, and vanilla JavaScript. You can think

Stargirl Flowers 47 Jun 19, 2022
:sparkles: Magical headers that make your C++ library accessible from JavaScript :rocket:

Quick start | Requirements | Features | User guide | Contributing | License nbind is a set of headers that make your C++11 library accessible from Jav

charto 1.9k Jul 2, 2022
Sol3 (sol2 v3.0) - a C++ <-> Lua API wrapper with advanced features and top notch performance - is here, and it's great! Documentation:

sol2 sol2 is a C++ library binding to Lua. It currently supports all Lua versions 5.1+ (LuaJIT 2.0+ and MoonJIT included). sol2 aims to be easy to use

The Phantom Derpstorm 3k Jun 23, 2022
Libraries and examples to support Pimoroni Pico add-ons in C++ and MicroPython.

Pimoroni Pico Libraries and Examples Welcome to the brave new world of Pico! This repository contains the C/C++ and MicroPython libraries for our rang

Pimoroni Ltd 497 Jun 30, 2022
Tools and libraries to glue C/C++ APIs to high-level languages

CppSharp is a tool and set of libraries which facilitates the usage of native C/C++ code with the .NET ecosystem. It consumes C/C++ header and library

Mono Project 2.4k Jun 24, 2022
A tool for generating cross-language type declarations and interface bindings.

Djinni Djinni is a tool for generating cross-language type declarations and interface bindings. It's designed to connect C++ with either Java or Objec

Dropbox 2.8k Jun 21, 2022
The missing bridge between Java and native C++

JavaCPP Commercial support: Introduction JavaCPP provides efficient access to native C++ inside Java, not unlike the way some C/C++ compilers interact

Bytedeco 3.9k Jun 30, 2022
Seamless operability between C++11 and Python

pybind11 — Seamless operability between C++11 and Python Setuptools example • Scikit-build example • CMake example Warning Combining older versions of

pybind 11.2k Jun 27, 2022
SWIG is a software development tool that connects programs written in C and C++ with a variety of high-level programming languages.

SWIG (Simplified Wrapper and Interface Generator) Version: 4.1.0 (in progress) Tagline: SWIG is a compiler that integrates C and C++ with languages

SWIG 4.5k Jun 25, 2022
A minimalist and mundane scripting language.

Drift Script A minimalist and mundane scripting language. I like all simple things, simple and beautiful, simple and strong. I know that all developme

Drift 11 Apr 3, 2022
Elk is a tiny embeddable JavaScript engine that implements a small but usable subset of ES6

Elk is a tiny embeddable JavaScript engine that implements a small but usable subset of ES6. It is designed for microcontroller development. Instead of writing firmware code in C/C++, Elk allows to develop in JavaScript. Another use case is providing customers with a secure, protected scripting environment for product customisation.

Cesanta Software 1.4k Jun 27, 2022
Kokkos C++ Performance Portability Programming EcoSystem: The Programming Model - Parallel Execution and Memory Abstraction

Kokkos: Core Libraries Kokkos Core implements a programming model in C++ for writing performance portable applications targeting all major HPC platfor

Kokkos 1k Jun 25, 2022
A Gen implementation in C. With memory efficiency, portability and speed in mind

A Gen implementation in C. With memory efficiency, portability and speed in mind

Gen Programming Language 3 May 11, 2022
Low dependency(C++11 STL only), good portability, header-only, deep neural networks for embedded

LKYDeepNN LKYDeepNN 可訓練的深度類神經網路 (Deep Neural Network) 函式庫。 輕量,核心部份只依賴 C++11 標準函式庫,低相依性、好移植,方便在嵌入式系統上使用。 Class diagram 附有訓練視覺化 demo 程式 訓練視覺化程式以 OpenCV

Lin Kao-Yuan 39 Apr 27, 2022
Stealthy way to hijack the existing game process handle within the game launcher (currently supports Steam and Battle.net). Achieve external game process read/write with minimum footprint.

Launcher Abuser Stealthy way to hijack the existing game process handle within the game launcher (currently supports Steam and Battle.net). Achieve ex

Ricardo Nacif 75 Jun 29, 2022
32Kb, small memory footprint, single binary that run list of commands in parallel and waits for their termination

await 32K, small memory footprint, single binary that run list of commands in parallel and waits for their termination documentation linux install cur

Slava 52 Jun 24, 2022
Very low footprint JSON parser written in portable ANSI C

Very low footprint JSON parser written in portable ANSI C. BSD licensed with no dependencies (i.e. just drop the C file into your project) Never recur

James McLaughlin 1.2k Jun 15, 2022
Mesh - A memory allocator that automatically reduces the memory footprint of C/C++ applications.

Mesh: Compacting Memory Management for C/C++ Mesh is a drop in replacement for malloc(3) that can transparently recover from memory fragmentation with

PLASMA @ UMass 1.4k Jun 22, 2022
Very low footprint JSON parser written in portable ANSI C

Very low footprint JSON parser written in portable C89 (sometimes referred to as ANSI C). BSD licensed with no dependencies (i.e. just drop the C file

null 1.2k Jun 15, 2022
dqlite is a C library that implements an embeddable and replicated SQL database engine with high-availability and automatic failover

dqlite dqlite is a C library that implements an embeddable and replicated SQL database engine with high-availability and automatic failover. The acron

Canonical 3k Jun 27, 2022
The Atomic Game Engine is a multi-platform 2D and 3D engine with a consistent API in C++, C#, JavaScript, and TypeScript

The Atomic Game Engine is a multi-platform 2D and 3D engine with a consistent API in C++, C#, JavaScript, and TypeScript

null 2.7k Jun 19, 2022
An embeddable fulltext search engine. Groonga is the successor project to Senna.

README Groonga is an open-source fulltext search engine and column store. Reference manual See doc/source/ directory or http://groonga.org/docs/. Here

Groonga Project 678 Jun 19, 2022
Orbit is a multiplatform-focus graphical engine build on top of OpenGl, ImGui

Orbit Engine Orbit is a multiplatform-focus graphical engine build on top of OpenGl, ImGui and more... The development of the engine is documented via

Madsycode 11 Jul 3, 2021
Golang bindings of Sciter: the Embeddable HTML/CSS/script engine for modern UI development

Go bindings for Sciter Check this page for other language bindings (Delphi / D / Go / .NET / Python / Rust). Attention The ownership of project is tra

Terra Informatica Software, Inc 2.4k Jun 22, 2022
A Vulkan game engine with a focus on data oriented design

The Fling Engine aims to be a cross platform Vulkan game engine that will experiment with the following: Low-level engine systems such as render API a

Fling Engine 295 Jun 18, 2022
KoanLogic 378 Jun 22, 2022
PTHash is a C++ library implementing fast and compact minimal perfect hash functions

Fast and compact minimal perfect hash functions in C++.

Giulio Ermanno Pibiri 65 Jun 18, 2022
A Powerful, Easy-to-Use, Compact, Cross-Platform and Installation-Free Crypto Tool. 一个强大,易用,小巧,跨平台且免安装的加密解密签名工具。

GpgFrontend GpgFrontend is a Powerful, Easy-to-Use, Compact, Cross-Platform, and Installation-Free OpenPGP Crypto Tool. By using GpgFrontend, you can

Saturn&Eric 136 Jun 21, 2022