Hi Jakob,
Thanks so much for your highly detailed response! I am building from source
so I should be able to change the feature flags, but I'll try setting the
v8 flag you mentioned first since that seems to be the less intrusive
option.
Thanks for the warning about the stringref proposal! I do understand that
it has stagnated as of late and does not look like it will be accepted in
its current state. The project that I'm working on is a novelty programming
language that compiles to WebAssembly, and the current implementation of
strings in the language relies on the stringref proposal for simplicity'
sake -- though the plan is to move to a bespoke utf8 implementation once
garbage collection is implemented. It would definitely be nice if
WebAssembly, as a compilation target, had native support for a string type
that doesn't rely on JS string builtins for cases such as this one, where
the wasm is not intended to only be run in the browser. But until we reach
some sort of consensus on that it looks like we'll just have to roll our
own.
Thanks again for your help!
Cheers,
Alex
On Friday, September 27, 2024 at 5:56:39 AM UTC-4 Jakob Kummerow wrote:
> Generally speaking, libwee8 supports whatever V8 supports.
> That said, the state of the stringref implementation in V8 is that (like
> all early-stage proposals) it's behind an off-by-default flag:
> --experimental-wasm-stringref, and libwee8 doesn't have a way to enable
> such flags at runtime.
> If you build your own libwee8, you can hack it by moving the "stringref"
> entry in src/wasm/wasm-feature-flags.h from the STAGING list to the
> SHIPPED list below it.
> If you don't want to or can't modify libwee8's sources but you do know
> that you're always linking against libwee8 (and not some other engine's
> implementation of the Wasm C API), then I think you can use the regular V8
> API to call v8::V8::SetFlagsFromString("--experimental-wasm-stringref") early
> in your startup sequence (before calling the Wasm C API's Engine::make()).
>
> All of that is admittedly far from perfect.
>
> Please also keep in mind that the stringref proposal is currently not on
> track towards finding community consensus. While we (V8) have no plans to
> delete our implementation of it, we also cannot make any promises that we
> will continue to keep it indefinitely if the proposal doesn't advance. At
> the very least, if/when the proposal does pick up steam again, there will
> likely be some changes to the behavior of certain features, and when
> picking those up we will quite likely not worry about backwards
> compatibility with earlier versions of the proposal. In summary: while I
> understand that strings are very useful and the stringref proposal would be
> great to have (especially in non-browser scenarios where the alternative
> "JS String Builtins" proposal, which the community currently favors, is
> unavailable), I feel compelled to caution you that basing any larger
> project on an assumption that stringref will be available is a highly risky
> decision at this time. On the other hand, if you manage to present a
> sufficiently compelling use case, you might just be able to influence the
> community's stance...
>
>
> On Fri, Sep 27, 2024 at 2:05 AM Alex Dovzhanyn <[email protected]>
> wrote:
>
>> Hello all, I am wondering if there is support for WASM stringrefs in
>> libwee8? And if so, it that behind a flag during the build? I am noticing
>> that I'm able to call:
>>
>> auto wasmModule = wasm::Module::make(store.get(), binary);
>>
>> with no issues when I'm not using stringrefs, but as soon as I add a
>> (table $stringrefs 100 stringref)
>>
>> into the module, the wasm::Module::make seems to fail.
>>
>> Any pointers would be greatly appreciated! Thanks in advance.
>>
>> Best,
>> Alex
>>
>> --
>>
>
--
--
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/v8-users/6756eaa9-455e-4e6f-b1ba-651f2098c94an%40googlegroups.com.
