I have been searching some way to compile AssemblyScript without node.js. I have not found it and it is a tragedy because I really could use it to dynamically generate some special web assembly from other programs, for example, from a PHP program, in environments where node is not supported (like many shared hostings). I have the intuition that the compiler does not actually require node at all, that it must be written in some other language, but I have not found any way to install the compiler at all.
Do you have any idea of how to use it without node?
There is a way to do what you want, but it does not get rid of node completely.
The AssemblyScript README.md about the asc compiler lists two ways of building the compiler: the usual compilation to JavaScript, and a bootstrapping process, where you compile asc to WebAssembly by compiling it to JavaScript and then using that compiler to compile it to WebAssembly.
The caveat is that, at least initially, you still node to obtain the compiler from sources.
A second caveat is that the frontend for asc is JavaScript only, for now. You can use the WebAssembly binary only as a library, which may be actually what you want, given your use-case.
Related
I am trying to compile a project and I need to use the reqwest crate, which is dependent on the ring and mime_guess crates. When using the MinGW compiler, ring fails, but with tdm-gcc, mime_guess won't build.
Is it possible to use a fallback compiler? If yes, how?
Keep the tdm-gcc directory renamed, but first in the PATH, so that when you need to build something with it, just name it properly and any programs looking for gcc.exe can find it.
I'm working on proto-lens#400 tweaking a Haskell code generator. In one of the tests I'd like to verify that certain API has not been built. Specifically, I want to ensure that a certain type of program will not type check successfully. I'd also have a similar program with one identifier changed which should compile, to guard against a typo breaking the test. Reading Extending and using GHC as a Library I have managed to have my test write a small file and compile it using GHC as a library.
But I need the code emitted by the test to load some other modules. Specifically the output of the code generator of that project and its runtime environment with transitive dependencies. I have at best a very rough understanding of stack and hpack, which is providing the build time system. I know I can add dependencies to some package.yaml file to make them available to individual tests, but I have no clue how to access such dependencies from the GHC session set up as part of running the test. I imagine I might find some usable data in some environment variables, but I also believe such an approach might be undocumented and prone to break without warning.
How can I have a test case use GHC as a library and have it access dependencies expressed in package.yaml? Or alternatively, can I use some construct other than a regular test case to express a file with dependencies but check that the file won't compile?
I don't know if this applies to you because there are too many details going way over my head, but one way to test for type errors is to build your test suite with -fdefer-type-errors and to catch the exception at run-time (of type TypeError).
Perhaps it's just better to describe my problem.
I'm developing a Haskell library. But part of the library is written in C, and another part actually in raw LLVM. To actually get GHC to spit out the code I want I have to follow this process:
Run ghc -emit-llvm on both the code that uses the Haskell module and the "Main" module.
Run clang -emit-llvm on the C file
Now I've got three .ll files from above. I add the part of the library I've handwritten in raw LLVM and llvm-link these into one .ll file.
I then run LLVM's opt on the linked file.
Lastly, I feed the LLVM bitcode fileback into GHC (which pleasantly accepts it) and produces an executable.
This process (with appropriate optimisation settings of course) seems to be the only way I can inline code from C, removing the function call overhead. Since many of these C functions are very small this is significant.
Anyway, I want to be able to distribute the library and for users to be able to use it as painlessly as possible, whilst still gaining the optimisations from the process above. I understand it's going to be a bit more of a pain than an ordinary library (for example, you're forced to compile via LLVM) but as painlessly as possible is what I'm looking for advice for.
Any guidance will be appreciated, I don't expect a step by step answer because I think it will be complex, but just some ideas would be helpful.
This is probably not the best question but I'm still completely new to JS. I'm interested in Typescript (being an AS3 dev), but I keep reading that I need to instal node.js to compile it? why is that?
TypeScript is a language that compiles into JavaScript. The compiler that does this, appears to be written (or at least distributed) in JavaScript. And node.js is the most common way to execute JavaScript outside a browser.
The typescript compiler is simply JavaScript, which is executed by node.js to compile things.
Why is that, you ask? Well, because that's what the developers of the compiler chose to write their compiler in. It could have been any language they wanted really.
The compiler is actually written in TypeScript. Yeah, a compiler written in the language it's supposed to compile, which may seem strange. But how that works is beyond the scope of this question.
I want to make a quick fix to one of the project's .so libraries. Is it safe to just recompile the .so and replace the original? Or I have to rebuild and reinstall the whole project? Or it depends?
It depends. Shared library needs to be binary-compatible with your executable.
For example,
if you changed the behaviour of one of library's internal functions, you probably don't need to recompile.
If you changed the size of a struct (e.g. by adding a member) that's known by the application, you will need to recompile, otherwise the library and the application will think the struct is smaller than it is, and will crash when the library tries to read an extra uninitialized member that the application didn't write to.
If you change the type or the position of arguments of any functions visible from the applications, you do need to recompile, because the library will try to read more arguments off the stack than the application has put on it (this is the case with C, in C++ argument types are the part of function signature, so the app will refuse run, rather than crashing).
The rule of thumb (for production releases) is that, if you are not consciously aware that you are maintaining binary compatibility, or not sure what binary compatibility is, you should recompile.
That's certainly the intent of using dynamic libraries: if something in the library needs updating, then you just update the library, and programs that use it don't need to be changed. If the signature of the function you're changing doesn't change, and it accomplishes the same thing, then this will in general be fine.
There are of course always edge cases where a program depends on some undocumented side-effect of a function, and then changing that function's implementation might change the side-effect and break the program; but c'est la vie.
If you have not changed the ABI of the shared library, you can just rebuild and replace the library.
It depends yes.
However, I assume you have the exact same source and compiler that built the other stuff and now if you only change in a .cpp file something, it is fine.
Other things e.g. changing an interface (between the shared lib and the rest of the system) in a header file is not fine.
If you don't change your library binary interface, it's ok to recompile and redeploy only the shared library.
Good references:
How To Write Shared Libraries
The Little Manual of API Design