IMHO C structs are also not the best solution for a simple cross-language
interop layer, but a function-only API with primitive argument and return
types (so additional accessor-functions are IMHO best, even if it means the
API becomes a bit messy).
Look at the OpenGL API as an example: there are no structs anywhere, only
functions with simple args, or at most pointers to 'unstructured data'. I
only really noticed that this is a nice property after creating C APIs that
use struct args. It's surprisingly hard to create bindings for this
approach even for languages that have good C interop.
If you want to hand a pointer to "raw data" from C to JS, you can use cast
the pointer to the 32-bit int (that's a bit smelly of course), hand this
'pointer-index' to JS as number, and use it as index into the global HEAP
typed-array-views (and don't forget to divide the pointer-index by the
view's datatype size.
For instance this snippet calls a C function from JS, the C function
returns a pointer-index, which is used to access the Float32 heap-view:
var ptr = Module.ccall('_saudio_emsc_pull', 'number',
['number'], [num_frames]);
if (ptr) {
var num_channels = event.outputBuffer.numberOfChannels;
for (var chn = 0; chn < num_channels; chn++) {
var chan = event.outputBuffer.getChannelData(chn);
for (var i = 0; i < num_frames; i++) {
chan[i] = HEAPF32[(ptr>>2) + ((num_channels*i)+chn)]
}
}
}
On Thursday, 27 September 2018 22:43:55 UTC+2, Nolan Darilek wrote:
>
> Cool, thanks for the pointers. I think I'll be investigating abandoning
> Rust for Nim because of its better C interop, so it looks like I can use
> these functions/interfaces more directly.
>
>
> Assuming I'm building a nicer C-style interface between not-so-nice
> lower-level C and not-so-nice-for-its-own-reasons JS, I'm assuming the
> best strategy is modeling data with C-style structs, and modeling my
> wrapper functions to accept int32s representing pointers to those structs?
>
>
> If so, how should I go from pointers to JS objects? Or should I just
> treat the pointers as opaque from JS's perspective, write functions to
> access their data, then wrap those functions into JS getters? The JS
> side of this API is mostly read, with mutations happening by passing
> data to the C/Nim API, so opaqueness/getters would probably work if
> needed.
>
>
> Thanks for the help.
>
>
> On 9/23/18 1:33 PM, Alon Zakai wrote:
> > In emscripten, for simple C APIs you can just use the emscripten.h macro
> >
> > #define EMSCRIPTEN_KEEPALIVE __attribute__((used)) __attribute__
> > ((visibility ("default")))
> >
> > If rust lets you define those LLVM attributes somehow, then just
> > applying those to a function will export it so JS can call it.
> > However, that doesn't handle string conversions etc., which you can
> > use ccall/cwrap for. With cwrap you need to declare the functions you
> > are binding, but it automates all the conversions etc.
> >
> > For C++ you can also use embind and the WebIDL binder, which automate
> > even more conversions, emulating C++ objects as JS objects, etc., but
> > for C you probably don't need those.
> >
> > Overall it does seem like most Rust interest these days is in
> > wasm32-unknown-unknown, as they're writing new Rust for JS purposes,
> > as opposed to what you're doing. I think both use cases are important
> > though - actually as Rust becomes more common in native development, I
> > think porting Rust + C combinations will become more important.
> >
> >
> > On 9/22/18, Nolan Darilek <[email protected] <javascript:>> wrote:
> >> The Rust wasm community seems to prefer wasm32-unknown-unknown these
> >> days. Unfortunately, my use case needs C libraries that will never be
> >> rewritten. I have a fairly small API surface that I'm calling from Yew
> >> (Rust front-end framework) but I'm starting to think I'd be better
> >> served by trying to export that API surface to JS and switching the UI
> >> to a more traditional framework. Is this site still a good reference
> for
> >> how to do this?
> >>
> >>
> >> https://hoverbear.org/2017/04/06/the-path-to-rust-on-the-web/
> >>
> >>
> >> Specifically, it creates a C library wrapping the exported Rust
> >> functions, then an empty `main()`. Given how fast these ecosystems
> move,
> >> I was wondering if any of this work could be automated? wasm-bindgen is
> >> for wasm32-unknown-unknown if I understand correctly, but I thought I'd
> >> check that assumption.
> >>
> >>
> >> Are there any current examples of someone building JS modules using
> Rust
> >> and Emscripten? Or has everyone in the Rust community switched
> >> exclusively to wasm32-unknown-unknown?
> >>
> >>
> >> Thanks.
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups
> >> "emscripten-discuss" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an
> >> email to [email protected] <javascript:>.
>
> >> For more options, visit https://groups.google.com/d/optout.
> >>
>
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
