-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Library functionality: toUpperCase, etc #5
Comments
FYI, the J2Wasm team has reported a list of features for which they're planning to call imported JS functions for now:
I don't mind going with (1) for now. I think we may want a better answer eventually, but it's probably fine to postpone that until post-MVP. We could also consider adding a Regarding possible engine-side optimization, there's an interesting difference between |
With a single operand, the behavior there should probably be more like
Another aspect here might be that
This is something that has been on my mind for quite some time as well. Basically two aspects I think that would improve Wasm<->JS interop via imports significantly: 1) A mechanism to call instance / prototype methods as in your example, and 2) the ability to |
Isn't |
The prototype lookup is indeed annoying. Could we instead import |
I am also intrigued about the use of |
Sorry I'm confused by how Or are you referring to scenario where the import is bound to a free JavaScript function that makes String API calls?
Being said that, I was considering to use string.concat for the builder implementation which I assumed would require ropes but it also sounded like they are already available per Jakub's comment so I'm little bit lost there: https://docs.google.com/document/d/1w2jLY7LuMG1grm_u7avtoAqYW1tcvPt4zc5_yNwTRyQ/edit?disco=AAAAelBHHaE |
@gkdn If I understand you correctly, you aren't actually importing Calling a JS function from WebAssembly passes Regarding |
Correct. In the current implementation in V8, Wasm's |
@wingo I wasn't sure if you were responding to #5 (comment) which I sent with the intention to reply around previous comment ( But yes if it can help V8 to optimize, we can do the |
@jakobkummerow String.fromCodePoint is showing up at hot code path. Should we start look into detecting and replacing them or introducing new APIs? |
There is also a related discussion to be had about the fact JS has access to a lot of Unicode data via RegExp however if languages want to access this data they basically have to compile a bunch of individual regexpes from what they're doing. Like if a language already has Unicode support then compiling that to WASM would require either:
both have pretty big downsides. For the first the unicode data is pretty large AND it might lead to divergence of versions between the compiled WASM and whatever the host has. For the second a a lot of round-tripping between JS and WASM would be involved even for trivial operations like checking a unicode property. Given that round-tripping seems to be less than optimal even for something as basic as It would probably be good if there were unicode related instructions to perform the same functionality directly such as:
|
From wingo/stringrefs#35, if we think about a browser deployment environment, we would like to avoid a situation in which two parts of a running system are implementing
toUpperCase
on a JavaScript string. If WebAssembly needs this or related string functionality, it should be able to use what's already in the browser.So what's the story here? A couple options:
String.prototype
orIntl.prototype
functions that you needString
,Intl
, and so on.string.to_upper
instruction. Lots more, probably.I have to say, I see (1) as an OK short-term answer and (2) as a nice end result. I wouldn't do (3) but who knows!
The text was updated successfully, but these errors were encountered: