Stack Build within Haskell - haskell-stack

I want to be able to call stack from within haskell to build a project for me. Nothing in the documentation explains this and going through src/main/Main.hs has been difficult to understand what function is the correct to use.
CLI version of what I want to run with imported stack functions:
stack build --fast
Explicitly not using calls to bash.

Related

How can I inspect x86/x64 code generated by V8 from WebAssembly?

https://webassembly.studio/ allows inspection of WebAssembly (WASM) files and the corresponding SpiderMonkey-generated x86 code. I'd like to similarly inspect instructions generated by V8's WASM compilers (Liftoff and TurboFan).
I'm entirely unfamiliar with V8's codebase/API (I compiled & linked it and followed some tutorials, though). There seems to be a v8::CompiledWasmModule class available, but it does not seem to expose access to generated x86/x64 instructions by either Liftoff or TurboFan.
WebAssembly - adding a new opcode describes the process of adding a WASM opcode to V8. Seemingly appropriate functions for WASM compilation/execution are available in the mentioned classes. Though, these seem rather deeply layered within the V8 codebase and would be difficult to access were I to link V8 as a library. Also, I'm unsure if this corresponds to Liftoff or TurboFan.
Could anybody familiar with the V8 codebase give me some pointers as to how I can access Liftoff and/or TurboFan's WebAssembly compilation module, as to obtain x86/x64 code?
To inspect generated code, you can run the d8 shell with the --print-wasm-code flag. You'll need either a debug build, or a release build with the v8_enable_disassembler = true GN arg.
There's no existing way to retrieve generated code via V8's API; so if that's what you want, then you'd have to add it. Keep in mind that V8 is not designed to be a standalone compiler, which means generated code assumes that it's going to run "inside V8", so if you wanted to use it for anything else, you'd have to make significant modifications.

How is javascript compiled by v8?

Take the hello-world as an example.
I have couple of questions:
What does v8::Isolate do? Does it create an new thread
What does v8::Isolate::Scope do?
What does v8::HandleScope do?
What does v8::Local<v8::Context> do?
What does v8::Script::Compile do? Does it compile the js code directly to machine code?
Thanks your for your help!
See the official wiki:
An isolate is a VM instance with its own heap.
A local handle is a pointer to an object. All V8 objects are accessed using handles, they are necessary because of the way the V8 garbage collector works.
A handle scope can be thought of as a container for any number of handles. When you've finished with your handles, instead of deleting each one individually you can simply delete their scope.
A context is an execution environment that allows separate, unrelated, JavaScript code to run in a single instance of V8. You must explicitly specify the context in which you want any JavaScript code to be run.
These concepts are discussed in greater detail in the Embedder's Guide.
Once you've read the existing documentation, if anything is still unclear, please ask more specific questions.
Regarding (5): In current versions of V8, v8::Script::Compile compiles bytecode for V8's interpreter. In earlier versions, it compiled unoptimized machine code. The difference is an internal implementation detail that you don't need to worry about :-)

What is reason not to use stack --nix when I using nix?

I am on NixOS but I think this question should apply to any platform that use nix.
I found by trial that stack can be used with couple options to build a project but I don't fully understand difference among them,
stack
stack --system-ghc
stack --nix
Question :
If I am using nix (NixOS in my case), is there any reason I will want to not use --nix argument?
What is the nix way to deal with haskell project, should cabal (cabal2nix) be used in stead of stack?
I found that stack is rebuilding lots of libraries that already installed by nix, what is the reason of that?
As I understand it, the --nix option to stack uses a nix-shell to manage non-Haskell dependencies (instead of requiring them to be in the "global" environment that stack is run from). This is probably a good idea if you want to use the stack tool on nix. Stack also usually installs its own GHC: the --system-ghc option prevents this, and asks it to use the GHC in the "global" environment from which it is run. I believe that with --nix, stack will ask Nix to handle GHC versioning as well, so on a Nix system, I would recommend building with --nix and without --system-ghc
At least in my opinion, it is better to avoid the stack tooling when working with Nix. This is because stack, even when run with --nix, does not inform Nix about the Haskell packages that it wants to build: it builds them all itself inside ~/.stack, and doesn't share them with the Nix store. If your project builds with the latest nixpkgs versions of Haskell packages, or with relatively few simple overrides on those, cabal2nix is a great solution that will make sure that Haskell libraries only get built once (by Nix). If you want to make sure that you are building your project with the same package versions as stack would, I would recommend stackage2nix or stack2nix. I personally have been using the nixpkgs-stackage overlay, which is related to stackage2nix: this gives you both LTS package sets in nixpkgs, and nixpkgs.haskell.packages.stackage.lib.callStackage2nix, which you can use in your default.nix/shell.nix like so: callStackage2nix (baseNameOf ./.) (cleanSource ./.).${(baseNameOf ./.)}, with whatever definition of cleanSource fits your project (this can use filterSource to remove some files which shouldn't really be considered part of the project, like autosaves, build directories, etc.).
With this setup, instead of using the stack tooling, for interactive work on the project you should use nix-shell to set up an environment where Nix has built all of the dependencies of your project and "installed" them. Then you can just use cabal-install to build just your project, without any dependency issues or (re)building dependencies.
As mentioned above, stack does not coordinate with Nix, and tries to build every Haskell dependency itself in ~/.stack. If you want to keep all of your Haskell packages in the Nix store (which I would recommend) while following the same build plans as Stack, you will need to use one of the linked tools, or something similar.

`stack install` for library targets

I'd like to have similar functionality as stack install (e.g. the --copy-bins flag) does for executables, but for libraries.
Currently, I have to stack build and then manually find the libHS*-<version>-<fingerprint>.a files in .stack-work. That is problematic/uncomfy for two reason:
I have to rely on the internal folder structure of stack (reliable enough, though)
I have to manually get rid of the fingerprint and the version
Well, I could work around both, I guess, but I'd like to know if this might already be available/sensible to implement.
Some background, which may or may not be relevant to the question rather than to its motivation:
I am playing around with https://hackage.haskell.org/package/dynamic-loader-0.0/docs/System-Plugins-DynamicLoader.html and want to provide as realistic an example as I can, so I plan to compile a package's object code into a *.a (containing the compilation of multiple modules) which I want to link in at runtime.
What I want to do works already for trivial single module files, where I only need to use loadModule. Currently I'm tinkering around with loadPackage.

Where does `haskell-mode` look for libraries? (`stack`, GHC for OSX)

I'm using Emacs 24.5 and the latest GHC for OSX (let's call it GFO),
$ which stack
/Applications/ghc-7.10.3.app/Contents/bin/stack
$ which ghc
/Applications/ghc-7.10.3.app/Contents/bin/ghc
When compiling (C-c C-l) a module which requires libraries that are not in the GFO distribution, e.g. vector, transformers, I obviously get a series of Could not find module ...
Now, I know that these packages are available in the system (in ~/.stack/snapshots/x86_64-osx/lts-5.15/7.10.3/lib/x86_64-osx-ghc-7.10.3/), because another project compiled them (via stack build).
QUESTION
Where do I change the behaviour of haskell-mode when loading a module? Otherwise, what's the exact command that is issued with C-c C-l, and how do I make it aware of the additional context introduced by stack?
Thank you in advance

Resources