Stream: javy

Topic: general

Angel M (Feb 20 2023 at 09:24):

Hey! Sorry I'm not very used to Zulip yet :smiley:. I understand we need to create specific "topics" to enable a scoped discussion. However, I think a "General" or "Introduction" one could be useful too as a wayt to decide the different topics and help people to introduce themselves

Does is sounds good to you?

Angel M (Feb 20 2023 at 09:25):

And thanks @Surma for creating the stream

Saúl Cabrera (Feb 20 2023 at 14:38):

Hi @Angel M I've been poking around in the Zulip docs and I don't think there's a way to have a default topic; I think that the best that we get is the "stream events" topic, which perhaps we can rename to general as use that as the catch-all topic if needed?

Also, could you please invite any other interested people from VMWare to the stream? We tried to invite everyone that attended the last meeting, but we weren't able to find them in Zulip.

Angel M (Feb 20 2023 at 15:24):

Cool @Saúl Cabrera ! Yeah, having a "general" topic will work. I think of it as a way for people to interact when they don't have any specific topic. Specially, for new people

Angel M (Feb 20 2023 at 15:24):

And yes, I'm going to ping the team in case someone is not on Zulip yet :+1:

Flaki (Feb 21 2023 at 19:22):

Hello and welcome! :wave:
We could probably have a couple topics across the stream, from "entrusting" Javy to the Bytecode alliance to exploring the WinterCG "minimum web API" equivalent for our use cases and technical work on Javy (componentization, abstractions, oxidation (=Rust-ification :D)).

I'd say people should feel fairly liberal in posting messages to start new threads as Zulip allows "rehoming" messages and shifting them around across topics liberally (for the first 7 days by the author, and without limits for operators). This I find to be useful info for Zulip-newcomers to make it less daunting and to reassure them that it's okay to start new threads of discussions.

Angel M (Feb 22 2023 at 07:33):

+1 on having different streams for the identified initiatives

Angel M (Feb 22 2023 at 07:33):

@Asen Dobrinov Alexandrov here we are :smile:

Jackson (Feb 28 2023 at 19:20):

Hey everyone! We (Shopify) are looking to kick off the recurring Javy CG meetings. It would be good to discuss upcoming changes we’re thinking of and to continue the WinterCG discussions. We can all fill in an agenda beforehand, and can skip the meeting if there are no talking points. If you’re interested in an invite please react with a :wave:

Jackson (Feb 28 2023 at 19:20):

We also wanted to gauge what people felt would be a good cadence for the meetings. React with :one: for biweekly or :two: for monthly

Jackson (Feb 28 2023 at 19:21):

Last ask here is to get a sense of the best time people prefer. Please fill out your preferences here https://www.when2meet.com/?18995950-PbVmc

Thanks!

Jackson (Mar 06 2023 at 14:41):

Invites for the next meeting on March 14th 10am EST have been sent out. Please DM me if I missed you! Attached to the meeting is a link to a google doc where anyone can add agenda items for the meeting

Flaki (Mar 31 2023 at 12:51):

In case anyone here missed the very relevant discussions and notes in the #wasm > JS-guest-runtime-and-bindings (and more broadly the discussion on #wasm > Interpreted Language Guests ). I know I did :smiling_face:

Jackson (Mar 31 2023 at 13:43):

:loudspeaker: FYI we've updated the Javy license with a LLVM exception clause https://github.com/Shopify/javy/pull/291/files#diff-4673a3aba01813b595de187a7a6e9e63a3491d55821606fecd9f13a10c188a1dR204

Jackson (Apr 04 2023 at 16:25):

We have some quickjs-wasm-rs improvements that we're thinking about https://github.com/Shopify/javy/issues/295. Happy to hear any feedback! Note: :warning: These are breaking changes so be sure to pin your dependency of quickjs-wasm-rs

Jeff Charles (May 16 2023 at 18:33):

We've officially moved the Javy repository to the Bytecode Alliance organization! https://github.com/bytecodealliance/javy

Taylor Hillegeist (Jan 10 2024 at 03:00):

Hi I was attempting to package a mermaid js like app called pintora. I tried using quickjs but it ended up being pretty slow. Would using javy help? I’m targeting wasm.

Saúl Cabrera (Jan 11 2024 at 18:40):

Javy performs a couple of optimizations ahead-of-time that could help you boost the performance, but it's hard to say by how much without actually giving it a try.

Damian Reeves (Feb 12 2024 at 20:06):

I am wondering are there any publicly available examples of implementing the strategy for extension of Javy outlined here: https://github.com/bytecodealliance/javy/blob/main/docs/extending.md ... I'd like to try something like this but am not 100% concrete on the instructions. Like if I want to add Javy like functionality to my existing CLI, forking the java-cli doesn't seem to be a great path forward.

Saúl Cabrera (Feb 12 2024 at 21:18):

We don't have a concrete example today as far as I know, but that's something that we can definitely add. Forking is probably the only approach for now, iff you want to keep all the other functionality already available in Javy. If you're interested in having some of Javy's functionality, you can create your own CLI using the underlying creates (e.g. https://crates.io/crates/javy and https://crates.io/crates/javy-apis). There's a third possibility, which could be having Javy load third-party "plugins", that would allow you to extend Javy without code modifications to add any extra functionality. This is an idea and it's not implemented yet, but certainly something that we welcome contributions for.

Damian Reeves (Feb 15 2024 at 01:20):

Just double checking, if I want to have a runtime that has access to my own functions/modules this is the path forward.

Saúl Cabrera (Feb 15 2024 at 13:33):

Yeah if you're building a custom runtime, assembling it to your needs with the underlying crates is the best for now. We've updated the documentation to better reflect this https://github.com/bytecodealliance/javy/blob/main/docs/extending.md

Simon (Feb 27 2024 at 08:53):

Hi! I wonder if it is possible to get a wrap_callback to return a wrap_callback? (Nested JS functions)
For example someobj.some_function().some_other_function();

I can get it to access attributes on for example someobj.some_function().some_attribute but cant call functions there.
from_qjs_value/to_qjs_value seems to set keys properly except for wrap_callback?

Jeff Charles (Feb 27 2024 at 15:15):

I wonder if it is possible to get a wrap_callback to return a wrap_callback?

It isn't possible today unfortunately due to an unfortunate assumption made when designing the API. We have an open issue at https://github.com/bytecodealliance/javy/issues/608 discussing offering an API that would be like wrap_callback but would support returning a JSValueRef instead of a JSValue and that change _should_ enable returning a function. One workaround until this is addressed, would be to define the outer function (that is, the function returning a function) in JS and load it with context.eval_global.

Simon (Feb 27 2024 at 15:21):

Ok, Thanks! Will try to implement the work-around and keep an eye on the GH-issue.

Afshan Ahmed Khan (May 27 2024 at 13:32):

Please can you guys help me here - https://github.com/bytecodealliance/javy/issues/650

Last updated: Dec 23 2024 at 12:05 UTC