Is there a proper way to compile a .asn file spec to Golang code ? I made it with C and Rust, but can't find anything for Golang (while it also supports a subset of ASN.1 spec in the standard library).
I think you mean: is there a tool that generates Golang code from ASN.1 specs ?
A Google search only shows one: https://www.obj-sys.com/products/asn1c/index.php
The encoding/asn1 go package is for very specific uses and will not help you (unless you decide to write your own compiler and use encoding/asn1 at runtime)
Related
Is it possible to use .witx definition files for Go code generation to use with TinyGo's WebAssembly WASI (WebAssembly System Interface) support?
Specifically, I want to create a Fastly Compute#Edge SDK for Go. These SDKs exist for JavaScript, AssemblyScript, Rust, Swift, and Zig, but not Go yet. This requires WebAssembly with WASI support which TinyGo has, but I haven't found any information on using WITX files yet.
Fastly says the following:
To execute your Wasm applications on Compute#Edge (and the local testing server), you need to use our Compute#Edge hostcalls, which are defined at https://github.com/fastly/Viceroy/tree/main/lib/compute-at-edge-abi. These .witx files define the functionality of Compute#Edge. Use them with your chosen language's WASI tooling to generate stubs or interfaces for your custom SDK to implement.
The .witx files are here:
compute-at-edge.witx
typenames.witx
Wasm by Example indicates that TinyGo can be used to target WASM with WASI support:
Let's compile our main.go into a Wasm module that targets WASI!
This can be down with the -wasm-abi=generic and -target=wasi flags when you run the TinyGo compiler:
tinygo build -wasm-abi=generic -target=wasi -o main.wasm main.go
Which should output (-o) a main.wasm file that we can run in a WebAssembly runtime that supports WASI!
It seems that a Go code generator that reads .wtix files and generates Go code is needed. Does one exist?
If not, it seems like the three approaches would be:
Extend a common code generator with Go support, likely written in a different language. For example, WITX-CodeGen exists without Go support yet and is written in Rust. This would be like using the Java-based OpenAPI Generator to create Go REST API server stubs using OpenAPI Spec.
Create a Go-based .witx code generator.
This could be like the Go-based OAPI CodeGen for OpenAPI Spec.
Create the Go definitions manually, which would likely be a pre-cursor for either of the code gen approaches.
I am trying to compile C++ code to wasm and then embed it in other C++ code with wee8 (v8's wasm-api). Currently I'm getting a Segfault on instantiating the module:
auto instance = wasm::Instance::make(store, module.get(), imports);
Note that I have no problem embedding code that I write as .wat and convert to .wasm, so the problem is specifically with embedding code compiled with emcc.
I am guessing that what I'm missing is WASI support in wee8? Does it exist? How can I enable it? Alternatively: can I ask emcc not to generate any WASI calls?
Here is a minimal example which results in:
Process finished with exit code 139 (interrupted by signal 11: SIGSEGV)
In cpp42.cpp:
int main() {
return 42;
}
Compiling this to wasm with:
emcc -O3 cpp42.cpp -o cpp42.wasm
Inspecting the compiled wasm module with wabt's wasm2wat shows that it contains the following import
(import "wasi_snapshot_preview1" "proc_exit" (func (;0;) (type 0)))
Which I suspect to be the cause of the problem.
Then embedding with wee8 like in the examples in the repo and like I do with other wasm files causes the segfault mentioned above.
Just as another check: running
wasmer cpp42.wasm
echo $?
> 42
Works without a problem.
I can answer part of your question:
I'm missing is WASI support in wee8? Does it exist?
No, wee8 does not implement WASI. Adding such support is theoretically possible, but not currently scheduled to get done.
You can implement it yourself in your wee8 embedder, and make it available to loaded modules via imports. Most (or all?) of it could probably be a reusable (among many engine implementations) library, potentially offered and maintained by the WASI project itself. (I don't know whether such a library exists already.)
You didn't say what imports object you're currently passing; it needs to be an array of wasm::Extern* pointers that's at least as long as the imports of the module, and ordered equivalently (i.e. imports[i] will be the module's ith import).
(I agree that the Wasm C/C++ API is very barebones currently. Unless/until that is changed, you'll have to build any convenience mechanisms yourself. It's all possible with the information that's available, it's just clearly less convenient than instantiating Wasm modules from JavaScript.)
Using -buildmode=archive produces mylib.a. I'm not fully understanding the steps required to then use this library in another Go program.
I've tried instead generating -buildmode=c-archive which produces a header file and archive, but the headerfile is not designed to be imported using cgo (there is conflicts with imported types).
Research online has yielded the conclusion that -buildmode=c-archive is specifically not designed for cgo use for this reason.
My query is what is -buildmode=archive actually used for if it cannot be included?
I'm not fully understanding the steps required to then use this library in another Go program.
It can be tricky. Need to look into each compiler toolchain for linking them correctly, i.e. gcc/clang etc. and find how, and if it's even possible to link them and use them.
What is -buildmode=archive actually used for if it cannot be included?
From the docs: https://pkg.go.dev/cmd/go
-buildmode=archive
Build the listed non-main packages into .a files. Packages named
main are ignored.
That's what it does, what you do with it, it's up to you, there's tons of information online, for example: https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
VPP provides the I/S for developing custom plugins that can be hooked into a graph of nodes. I've only seen examples for such plugins written in the C language, and was wondering whether other language, Go for instance, can also be used to write such plugins.
I have no idea what "VPP" is but nonetheless the answer is: "maybe"; here's why:
Go code is able to interface with C libraries via its facility known as cgo.
cgo is a multiple-faceted thing: it allows you to "export" certain Go functions in a certain way so that they can be called from the C side, and it allows you to call functions from the C side. It also allows you to write bits of inline C code to provide glue for the C side, when necessary.
Since some time Go building toolset (at least its "reference" implementation) provides for compiling Go code into a static or dynamic library with C-compatible API.
See this.
With these things in mind, in theory, it should be possible to do what you're after.
Note some possible obstacles:
Most of the time, if a "platform" allows you to write a "plugin" in C, it presupposes your plugin will make extensive use of the platform's own API.
This usually means your plugin is supposed to include certain header files provided by the platform.
The platform might also require your plugin to link against some platform-provided library (usually shared), or libraries.
cgo can do all of the above, but you will need to scrutinize the API provided by the platform and maybe write Go helpers to make its usage more natural for the Go code.
Building/linking issues (usually the locations of the header files and the libs) may also be a thing to solve.
What's a smart way to generate and validate a protocol buffer spec? Is there any library (binding?) for the protoc file format, maybe java or python?
Just to be clear, I know that after my code generates a protocol buffer specification it will be fed to protoc for generating language-specific binding code. It's straightforward for me to invoke protoc to validate a generated spec (just check exit code etc.), but I thought maybe there's a better way.
The only vaguely related thing I could find is Cannot parse a protocol buffers file in python when using the correct .proto file
Thanks in advance.
I would probably just invoke the protoc binary and check the exit code, because that command line interface is likely to be more stable across versions than a library interface.
However, all the relevant functionality is available in libprotoc.so. As a starting point, you can see the protoc main program here, which is beautifully short: https://github.com/google/protobuf/blob/master/src/google/protobuf/compiler/main.cc
I expect you could pretty much copy that to your own project and link against libprotoc.so.