How to convert Scala.js application to CommonJS module? - commonjs

Is there any standard way to use Scala.js application as a libriary in CommonJS environment? And if not, can I patch generated js file for that purpose?

Scala.js 0.6.13 and onward
Put this in your build file:
scalaJSModuleKind := ModuleKind.CommonJSModule
Scala.js 0.6.5 to 0.6.12
Put this in your build file (explanation see below):
scalaJSOutputWrapper := ("var __ScalaJSEnv = { exportsNamespace: exports };", "")
Scala.js 0.5.4 to 0.6.4
You can tell Scala.js where to send the stuff it exports. To make a CommonJS module, simply prepend this:
var __ScalaJSEnv = {
exportsNamespace: exports
};
to the .js file produced by fastOptJS/fullOptJS.
Pre Scala.js 0.5.4
Please upgrade :)

Related

Can't find py_module_initializer! when building python module in rust

Very new to Rust.
I'm trying to build a python module in Rust using rust-cypthon. Currently, I can access cpython types but can't call py_module_initializer! which I believe is required to make the module run in python.
When compiling the code, changing the extension to .so and putting the file in with my python scripts and importing, I get this error:
ImportError: dynamic module does not define init function (initpyext_rust_onboard)
Cargo.toml
[lib]
crate-type = ["cdylib"]
[dependencies]
csv = "1.1.1"
serde = "1.0.99"
serde_derive="1.0"
serde_json= "1.0"
serde_yaml = "0.7.1"
[dependencies.cpython]
version = '0.3.0'
default-features = false
features = ["python27-sys", "extension-module-2-7"]
Dependencies imported to lib.rs
#[macro_use]
extern crate serde;
extern crate serde_derive;
#[macro_use]extern crate cpython;
use std::fs::File;
use std::collections::HashMap;
use std::borrow::Cow;
use std::error::Error;
use cpython::{Python, PyObject, PyResult, PyString, PyFloat};
use csv::DeserializeRecordsIter;
When compiling the code, changing the extension to .so and putting the file in with my python scripts
What are you renaming it from? The rust-cpython documentation says
On Mac OS, you will need to rename the output from *.dylib to *.so. On Windows, you will need to rename the output from *.dll to *.pyd.
and on Linux you shouldn't be renaming anything.
The problem is probably that you are not actually building a shared object. You have
[lib]
crate-type = ["dylib"]
but the rust-cpython readme says
[lib]
crate-type = ["cdylib"]
Mind the c! cdylib and dylib are different things in rust.
According to the cpython homepage, you need to enable the extension-module module feature, so try with:
[dependencies.cpython]
version = '0.3.0'
default-features = false
features = ["python27-sys", "extension-module-2-7"]

QBS build system, can't initialize environment with vcvars64.bat

I'm trying to implement my own module to build C++ on Windows with clang-cl toolchain as there's no built-in support in QBS right now.
I chose to use lld-link instead of microsoft linker, so I have to supply it with all the MS library include paths manually. With these paths hardcoded, I manage to build my apps fine. But I'd like to make my module more flexible and use %LIB% environment variable set by vcvars32.bat|vcvars64.bat
As far as I understand, this could (should?) be done inside module's setupBuildEnvironment script. Here's what I try to read the %LIB% and fail:
import qbs.Environment
import qbs.Process
Module
{
setupBuildEnvironment:
{
var p = new Process();
p.exec("vcvars64.bat", [], true);
// makes no difference
// p.exec("cmd", ["/c", "vcvars64.bat"], true);
var lib = p.getEnv("LIB");
// this fails too
// var lib = Environment.getEnv("LIB");
console.info("LIB = " + lib);
p.close();
}
...
}
This gives me LIB = so I'm getting nowhere. My guess is that the process is already terminated at the moment of querying the variable (p.getEnv("LIB")), hence the empty result. The QBS docs for Process.getEnv() state nothing in this regard.
What is the correct QBS way to initialize environment with vcvars64.bat, and more broadly, what is the correct way to get environment of a process inside setupBuildEnvironment?
[update]
Well, embarassingly, this was easy to work around by creating a simple batch and getting rid of setupBuildEnvironment script altogether:
#echo off
call vcvars64 && qbs
But I'd like to avoid batch scripting as much as possible, so the question still stands.
The vars batch files just dump some information onto the console. That does not set an environment on the calling process in any way. You would need to parse the process output. I suggest you take a look at the MsvcProbe item in the qbs sources to see how that is implemented for MSVC. You might be able to adapt the code for clang-cl.

Ember Cli - Transpiling vendor ES6 dependency in ember-cli-build?

I'm writing an Ember.js application using Ember Cli, and I want to include a non-bower dependency - basically a dependency from my vendor folder.
The instructions on doing so is telling me to add the following line into my ember-cli-build.js file:
app.import('vendor/dependency-to-include.js');
That would work fine with a normal ES5 flavored dependency, but what if I want to add a dependency written in ES6?
Right now it just delivers it to the browser untouched, which produces an error like:
Uncaught SyntaxError: Unexpected reserved word
because my ES6 flavored dependency uses the following syntax:
import Util from './util
I'm guessing that I need to tell ember-cli-build to transpile this particular dependency before passing it on to the browser, but how do I go about doing that?
Thanks
For transpiling imported dependencies you need to run the imported file(s) through the broccoli addon broccoli-babel-transpiler. For a basic example, checkout this file: https://github.com/thefrontside/ember-impagination/blob/2fa38d26ef1b27a3db7df109faa872db243e5e4c/index.js. You can adapt this addon to an in-repo addon for your project.
See this link for the background discussion and #rwjblue and #cowboyd on the actual fix: https://github.com/ember-cli/ember-cli/issues/2949
Are you currently including Babel within your project? I would have thought that it checks your vendor directory the same as it does everything else and converts the ES6 code to ES5.
The other option would be to just convert the file to ES5 manually whenever you need to include a vendor file with ES6 syntax. Not necessarily ideal, but if it's a static file then it's something you'll need to do once and then forget about.

error: unknown file type '.hpp' in distutils extension module

I'm trying to generate Python bindings for some C++ code using SWIG.
It created some blah_wrap.cxx and blah.py files.
I then created this setup.py
from distutils.core import setup, Extension
ext = Extension('_ev3',
sources=[
'ev3_serial_wrap.cxx',
'ev3_serial.hpp'
'ev3_motor_wrap.cxx',
'ev3_motor.hpp'
'ev3_i2c_wrap.cxx',
'ev3_i2c.hpp'
'ev3_analog_wrap.cxx',
'ev3_analog.hpp'
],
language='c++',
)
setup (name = 'evpy',
version = '0.1',
author = "Pepijn de Vos",
description = """
An EV3 API.
""",
ext_modules = [ext],
packages=['evpy'],
)
But then I get
$ python3 setup.py build
running build
running build_py
running build_ext
building '_ev3' extension
error: unknown file type '.hpp' (from 'ev3_analog.hpp')
.hpp is a pretty standard C++ extensions right? Why not .cpp? I don't know, the author of the original code put the implementation in his header files.
You can use the parameter "include_dirs". See the documentation for Extension here:
http://docs.python.org/2/extending/building.html
http://docs.python.org/2/distutils/apiref.html#distutils.core.Extension
Are you sure header files are supposed to go in the sources argument, and not in another like headers?
Basically, .h and .hpp do the same jobs, try to change the extension to .h, your python script might not know .hpp files (which is not a shame)...

How to include syntax extensions in your _oasis file? I'm trying to use deriving-ocsigen.syntax in my project

Here is my current _oasis file:
OASISFormat: 0.3
Name: testing syntax
Version: 0.1
Synopsis: testing
Authors: Johnathan Doeman
License: GPL-3
Executable testmain
Path: ./
BuildTools: ocamlbuild
BuildDepends: batteries, deriving-ocsigen, deriving-ocsigen.syntax
MainIs: main.ml
Note that ocsigen-deriving seems to be properly installed on my system. I am able to use it in the toplevel after the correct #requires. I'm also using oasis version 0.3.
There may be a better way in Oasis 0.3, which I haven't switched to yet, but previously you had to include this in your _tags file (outside the part auto-generated by oasis):
<*.ml>: syntax_camlp4o
Have you tried to put this information into _tags file?
AFAIR after `oasis setup' oasis rewrites only a part of _tags file, user-written part it lets as-is.
It's not (yet) supported; see https://forge.ocamlcore.org/tracker/index.php?func=detail&aid=1050&group_id=54&atid=291