I need to write an extension for Thunderbird. The extension will be used to do some text mining and relies on native C++ code. From my understanding, Thunderbird extensions are now mostly written in JavaScript and XPCOM is being slowly deprecated (https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM).
Besides, XPCOM seems a bit heavy and I would like an easier path to access my C++ code. Are there any alternatives besides XPCOM to access C++ code from a thunderbird extension?
Thanks!
Take a look at js-ctypes (https://developer.mozilla.org/en-US/docs/Mozilla/js-ctypes)
Little example:
Components.utils.import("resource://gre/modules/FileUtils.jsm");
Components.utils.import("resource://gre/modules/ctypes.jsm")
// path to C++ lib (/home/username/.thunderbird/PROFILE/extensions/EXTNAME/components/lib.so)
var libPath = FileUtils.getFile("ProfD", ["extensions", "EXTNAME", "components", "lib.so"]);
var lib = ctypes.open(libPath.path);
var libFunction = lib.declare("concatStrings", // function name in C++ code
ctypes.default_abi,
ctypes.char.ptr, // return value
ctypes.char.ptr, // param1
ctypes.char.ptr // param2
);
var ret = libFunction("abc", "efg");
lib.close()
Also be aware that C++ compiler does name mangling due to function overloading so your function name might be 'concatStrings' in C++ code, but then in assembly it might be something like '_123concatStrings'. To prevent this declare your function like:
extern "C" const char * concatStrings ( const char * str1, const char * str2 );
Related
In other words, the codebase I'm trying to refactor has a lot of this (anti?) pattern:
A.js
const libC = require("/path/to/libC")
const A_init = () => {
// some code
libC.someFunc()
global_variable = libC // <- setting the require return value to a global variable!
// some code
}
exports.A_init = A_init
B.js
const B_init = () => {
// some code
libC.someOtherFunc() // instead of "requiring" libC itself, it relies on A.js's init method to se it
// some code
}
exports.B_init = B_init
Now the user of this library will get a ReferenceError if they attempt to call B_init() before calling A_init() which seems like very bad practise. I'm aware global variables like this lead to tightly coupled, difficult to manage code, my question is: Should the solution be for B.js to also simply "require" libC (and by extension, every single module in the codebase should do the same and "require" all their own dependencies)? Is there some sort of DI framework/pattern used in node to make this more elegant?
I understand eval string-to-function is impossible to use on the browsers' application programming interfaces, but there must be another strategy to use third party dependencies without node.js on v8 engine, given Cloudflare does it in-house, unless they disable the exclusive method by necessity or otherwise on their edge servers for Workers. I imagine I could gather the AST of the commonjs module, as I was able to by rollup watch, but what might the actual steps be, by tooling? I mention AMD for it seems to rely on string-to-function (to-which I've notice Mozilla MDN says nothing much about it).
I have been exploring the require.js repositories, and they either use eval or AST
function DEFNODE(type, props, methods, base) {
if (arguments.length < 4) base = AST_Node;
if (!props) props = [];
else props = props.split(/\s+/);
var self_props = props;
if (base && base.PROPS) props = props.concat(base.PROPS);
var code = "return function AST_" + type + "(props){ if (props) { ";
for (var i = props.length; --i >= 0; ) {
code += "this." + props[i] + " = props." + props[i] + ";";
}
var proto = base && new base();
if ((proto && proto.initialize) || (methods && methods.initialize))
code += "this.initialize();";
code += "}}";
//constructor
var cnstor = new Function(code)();
if (proto) {
cnstor.prototype = proto;
cnstor.BASE = base;
}
if (base) base.SUBCLASSES.push(cnstor);
cnstor.prototype.CTOR = cnstor;
cnstor.PROPS = props || null;
cnstor.SELF_PROPS = self_props;
cnstor.SUBCLASSES = [];
if (type) {
cnstor.prototype.TYPE = cnstor.TYPE = type;
}
if (methods)
for (i in methods)
if (HOP(methods, i)) {
if (/^\$/.test(i)) {
cnstor[i.substr(1)] = methods[i];
} else {
cnstor.prototype[i] = methods[i];
}
}
//a function that returns an object with [name]:method
cnstor.DEFMETHOD = function (name, method) {
this.prototype[name] = method;
};
if (typeof exports !== "undefined") exports[`AST_${type}`] = cnstor;
return cnstor;
}
var AST_Token = DEFNODE(
"Token",
"type value line col pos endline endcol endpos nlb comments_before file raw",
{},
null
);
https://codesandbox.io/s/infallible-darwin-8jcl2k?file=/src/mastercard-backbank/uglify/index.js
https://www.youtube.com/watch?v=EF7UW9HxOe4
Is it possible to make a C++ addon just to add a default object for
node.js named exports or am I Y’ing up the wrong X
'.so' shared library for C++ dlopen/LoadLibrary (or #include?)
“I have to say that I'm amazed that there is code out there that loads one native addon from another native addon! Is it done by acquiring and then calling an instance of the require() function, or perhaps by using uv_dlopen() directly?”
N-API: An api for embedding Node in applications
"[there is no ]napi_env[ just yet]."
node-api: allow retrieval of add-on file name - Missing module in Init
Andreas Rossberg - is AST parsing, or initialize node.js abstraction for native c++, enough?
v8::String::NewFromUtf8(isolate, "Index from C++!");
Rising Stack - Node Source
"a macro implicit" parameter - bridge object between
C++ and JavaScript runtimes
extract a function's parameters and set the return value.
#include <nan.h>
int build () {
NAN_METHOD(Index) {
info.GetReturnValue().Set(
Nan::New("Index from C++!").ToLocalChecked()
);
}
}
// Module initialization logic
NAN_MODULE_INIT(Initialize) {
/*Export the `Index` function
(equivalent to `export function Index (...)` in JS)*/
NAN_EXPORT(target, Index);
}
New module "App" Initialize function from NAN_MODULE_INIT (an atomic?-macro)
"__napi_something doesn't exist."
"node-addon-API module for C++ code (N-API's C code's headers)"
NODE_MODULE(App, Initialize);
Sep 17, 2013, 4:42:17 AM to v8-u...#googlegroups.com "This comes up
frequently, but the answer remains the same: scrap the idea. ;)
Neither the V8 parser nor its AST are designed for external
interfacing. In particular (1) V8's AST does not necessarily reflect
JavaScript syntax 1-to-1, (2) we change it all the time, and (3) it
depends on various V8 internals. And since all these points are
important for V8, don't expect the situation to change.
/Andreas"
V8 c++: How to import module via code to script context (5/28/22, edit)
"The export keyword may only be used in a module interface unit.
The keyword is attached to a declaration of an entity, and causes that
declaration (and sometimes the definition) to become visible to module
importers[ - except for] the export keyword in the module-declaration, which is just a re-use of the keyword (and does not actually “export” ...entities)."
SyntheticModule::virtual
ScriptCompiler::CompileModule() - "Corresponds to the ParseModule abstract operation in the ECMAScript specification."
Local<Function> foo_func = ...;//external
Local<Module> module = Module::CreateSyntheticModule(
isolate, name,
{String::NewFromUtf8(isolate, "foo")},
[](Local<Context> context, Local<Module> module) {
module->SetSyntheticModuleExport(
String::NewFromUtf8(isolate, "foo"), foo_func
);
});
Context-Aware addons from node.js' commonjs modules
export module index;
export class Index {
public:
const char* app() {
return "done!";
}
};
import index;
import <iostream>;
int main() {
std::cout << Index().app() << '\n';
}
node-addon-api (new)
native abstractions (old)
"Thanks to the crazy changes in V8 (and some in Node core), keeping native addons compiling happily across versions, particularly 0.10 to 0.12 to 4.0, is a minor nightmare. The goal of this project is to store all logic necessary to develop native Node.js addons without having to inspect NODE_MODULE_VERSION and get yourself into a macro-tangle[ macro = extern atomics?]."
Scope Isolate (v8::Isolate), variable Local (v8::Local)
typed_array_to_native.cc
"require is part of the Asynchronous Module Definition AMD API[, without "string-to-function" eval/new Function()],"
node.js makes objects, for it is written in C++.
"According to the algorithm, before finding
./node_modules/_/index.js, it tried looking for express in the
core Node.js modules. This didn’t exist, so it looked in node_modules,
and found a directory called _. (If there was a
./node_modules/_.js, it would load that directly.) It then
loaded ./node_modules/_/package.json, and looked for an exports
field, but this didn’t exist. It also looked for a main field, but
this didn’t exist either. It then fell back to index.js, which it
found. ...require() looks for node_modules in all of the parent directories of the caller."
But java?
I won't accept this answer until it works, but this looks promising:
https://developer.oracle.com/databases/nashorn-javascript-part1.html
If not to run a jar file or something, in the Worker:
https://github.com/nodyn/jvm-npm
require and build equivalent in maven, first, use "dist/index.js".
Specifically: [ScriptEngineManager][21]
https://stackoverflow.com/a/15787930/11711280
Actually: js.commonjs-require experimental
https://docs.oracle.com/en/graalvm/enterprise/21/docs/reference-manual/js/Modules/
Alternatively/favorably: commonjs builder in C (v8 and node.js)
https://www.reddit.com/r/java/comments/u7elf4/what_are_your_thoughts_on_java_isolates_on_graalvm/
Here I will explore v8/node.js src .h and .cc for this purpose
https://codesandbox.io/s/infallible-darwin-8jcl2k?file=/src/c.cpp
I'm curious why there is near machine-level C operability in Workers if not to use std::ifstream, and/or build-locally, without node.js require.
Now I'm developing a usb-serial application with its dll in Node.js.
This dll returns INVALID_HANDLE_VALUE, if it fails to open com port. So I want to handle the ret value in Node.js. In this case, How do I handle below ?
I'm not sure how do I compare the ret value and SlowBuffer.
DLL
#define INVALID_HANDLE_VALUE ((HANDLE)(LONG_PTR)-1
typedef HANDLE (*OPEN)(int);
__declspec(dllexport) HANDLE opencom(int ncom)
Node.js with node-ffi
var ffi = require('ffi');
var lib = ffi.Library('serialmw.dll', {
'opencom' : ['pointer', ['int']]
});
var hcom = null;
hcom = lib.opencom(1);
console.log(hcom); // <SlowBuffer#0xFFFFFFFFFFFFFFFF >
A SlowBuffer is just a Buffer which is just a bunch of raw binary bytes. If you want to compare two Buffers byte-for-byte, you will have to use a for-loop or something like the buffertools' compare() with both Buffers.
Using the official traceur module, is it possible to set the default options for compile and require?
For example, this code works:
var traceur = require('traceur');
console.log(
traceur.compile('{ let x = 1; }', { experimental:true }).js
);
Now if I remove traceur.compile's 2nd argument (the options object):
console.log(
traceur.compile('{ let x = 1; }').js
);
Traceur will throw an error as the blockBinding option is not enabled. Is there any way to change the default options, in order to compile files without always passing an options object?
My main concern, apart from applying the DRY principle, is getting the traceur.require function to compile files with customized options -- as far as I can see, traceur.require and traceur.require.makeDefault() do not even take an options argument.
For instance, considering this code sample:
require('traceur').require('./index');
And this piece of code:
require('traceur').require.makeDefault();
require('./index');
Is there any way to compile the required file with the experimental option enabled?
Preferably by altering the default options, as I cannot see any other viable way.
Using Node 0.10.29 and Traceur 0.0.49.
Here's a full example of what I'd like to achieve.
bootstrap.js (entry point):
var traceur = require('traceur');
traceur.options.experimental = true;
traceur.require.makeDefault();
require('./index');
index.js:
import {x} from './lib';
// using a block binding in order to check
// whether this file was compiled with experimental features enabled
{
let y = x;
console.log(y);
}
lib.js:
export var x = (() => {
if (true) {
// should be compiled with experimental features enabled too
let x = 1;
return x;
}
})();
Expected console output: 1
traceur.options.experimental=true serves as a setter which enables the experimental features in the traceur.options object, but unfortunately traceur.options does not seem to affect traceur.compile nor traceur.require as far as I can see.
The Using Traceur with Node.js Wiki page does not mention anything about compiling options. The Options for Compiling page does not mention the Traceur API in Node.js, in fact, I cannot find any documentation about the Traceur API in Node.js.
Fabrício Matté ;-) added support for giving the default options to makeDefault(), see
https://github.com/google/traceur-compiler/blob/master/src/node/require.js#L58
A separate bug with the option experimental was fixed today, 16JUL14.
After following instructions on the emscripten wiki I have managed to compile a small C library. This resulted in an a.out.js file.
I was assuming that to use functions from this library (within node.js) something like this would have worked:
var lib = require("./a.out.js");
lib.myFunction('test');
However this fails. Can anyone help or point me to some basic tutorial related to this?
Actually, all the functions are already exported. Generated JavaScript contains following lines:
var ENVIRONMENT_IS_NODE = typeof process === 'object' && typeof require === 'function';
// …
if (ENVIRONMENT_IS_NODE) {
// …
module['exports'] = Module;
}
If you got a function called my_fun in your C code, then you'll have Module._my_fun defined.
There are some problems with this approach, though.
Optimizer may remove or rename some functions, so always specify them passing -s EXPORTED_FUNCTIONS="['_main','_fun_one','_fun_two']". Function signatures in C++ are bit mangled, so it's wise to extern "C" { … } the ones which you want to export.
Furthermore, such a direct approach requires JS to C type conversions. You may want to hide it by adding yet another API layer in file added attached with --pre-js option:
var Module = {
my_fun: function(some_arg) {
javascript to c conversion goes here;
Module._my_fun(converted_arg) // or with Module.ccall
}
}
Module object will be later enhanced by all the Emscripten-generated goodies, so don't worry that it's defined here, not modified.
Finally, you will surely want to consider Embind which is a mechanism for exposing nice JavaScript APIs provided by Emscripten. (Requires disabling newest fastcomp backend.)
The problem here is that your a.out.js file is going to look like this
function myFunction() {
...
}
Not like this
function myFunction() {
...
}
exports.myFunction = myFunction;
You need to write a build script that lists the tokens you want to publically export from each C program and appends exports.<token> = <token>;\n to the end of your file for each token.