nekevss

8 ms·

1.
by nekevss 6mo ago
The specification reached stage 4 just yesterday. That was the motive behind the blog post :)
2.
by nekevss 6mo ago
I believe V8 / chrome bundles IANA time zones into the zoneinfo64 resource bundle. I'm not actually sure they hit the system tzdb at all.
3.
by nekevss 6mo ago
Yep, temporal_rs is designed with native Rust use in mind, so you should be able to use temporal_rs directly wherever you'd use jiff or chrono. That being said, the library is designed to be specification conformant and with EcmaScript
4.
by nekevss 6mo ago
Typically time zone data is updated in IANA's time zone database. That data would need to be updated in the implementation. In this case, the browser would need to update their time zone data.
5.
by nekevss 6mo ago
Super happy to see Temporal accepted! Congrats to all the champions who worked super hard on this for so long! It's been fun working on temporal_rs for the last couple years :)
6.
by nekevss 8mo ago
The library used for V8's temporal implementation is in Rust too ;)
7.
by nekevss 8mo ago
I don't know if that's totally fair to Chrome. The specification was undergoing a lot of changes at the time, and V8 decided to wait for the specification to stabilize; meanwhile, Anba kept working on the implementation for FireFo
8.
by nekevss 10mo ago
For the engine, the answer is yes, Intl and Temporal are feature flagged due to the dependencies. What I suspect they’re comparing above is the CLIs, which is completely different than the engine. I’d have to double check for the CLI. If I
9.
by nekevss 10mo ago
Yeah, the majority of the difference is from the Unicode data for Intl along with probably the timezone data for Temporal.
10.
by nekevss 10mo ago
Yeah! I found out about Brimstone just the other day! Its definitely interesting! One optimization that they have that Boa needs to implement is ropes for our string type :)
11.
by nekevss 10mo ago
Huh! TIL. I'll have to look into that, I'm curious how it works. Although, now that I think about it, that does make sense.
12.
by nekevss 10mo ago
Thanks! It's always nice to talk and answer questions about the project!
13.
by nekevss 10mo ago
The hope of the experiments is to hopefully find an API that can be used and allow for the GCs to be more swappable. At least that's my personal hope. We really have to dig into the experimentation and rewrite before knowing for certai
14.
by nekevss 10mo ago
Hi! I'm not aware of any plans to build node-like modules, but I think we have the basic support to potentially build them out ... but I could be overlooking or missing something. I'm not personally familiar with them. But definin
15.
by nekevss 10mo ago
Right now, we use a forked and modified version of the `gc`. We definitely need to update it. Admittedly, I've been hoping to work on it but got a little distracted with temporal ... I don't think I've actually heard of rsgc
16.
by nekevss 10mo ago
Huh, I just noticed thanks to this that the comment needs to be updated in the example lol it should probably say "Parse and evaluate the source code".
17.
by nekevss 10mo ago
No problem! If you have any questions, feel free to open an issue / discussion or reach out to us on Matrix / Discord.
18.
by nekevss 10mo ago
Thanks! Temporal_rs has been a really fun project to work on, and it's been great to see that it's useful for other engines! Hopefully, there will be more chances in the future for projects like temporal_rs. Beyond just temporal_r
19.
by nekevss 10mo ago
So this is a bit loaded. Short answer: it can. Long answer: first, `fetch` is a runtime feature, and Boa is first and foremost an engine. So `boa_engine` -- the core project crate -- does not support `fetch` out of the box. That being said,
20.
by nekevss 10mo ago
That may be fair. The better wording may even be specification compliant, but none of the Boa maintainers made this post (we found out about it after the fact). We, the maintainers, could probably sit down some day and try to triage the fai
21.
by nekevss 10mo ago
We do have some interop support available in our `boa_runtime` crate ( https://docs.rs/boa_runtime/latest/boa_runtime/ ) and the engine itself. Just to note, Boa is an JavaScript engine / interpreter. We&#
22.
by nekevss 10mo ago
I think it would be cool to see Servo use us. Someone on our last release thread on Reddit ( https://www.reddit.com/r/rust/comments/1odnore/boa_0210_rele... ) mentioned adding Boa to Blitz, which I think w
23.
by nekevss 10mo ago
Well the first two are runtimes built on top of JavaScriptCore and V8, respectively. So we're definitely in a different space. QuickJS/QuickJS-NG might be a better comparison, but I think they are limited in specification conforma
24.
by nekevss 10mo ago
Hi, I'm another one of the maintainers on the project. In general, we are shifting more to performance now than conformance. We currently sit at around 94% conformance, so there's not really that much more to go conformance-wise.
25.
by nekevss 1y ago
We could do a WASM FFI target. I have thought about it lol My only concern is that temporal_rs packages it's own time zone data, which may make the WASM package a little heavy, so I've been inclined to leave the polyfill up to ful
26.
by nekevss 1y ago
Thanks! It's been great to see the library actually picked up and used by other implementations!
27.
by nekevss 1y ago
Hi all, I'm one of the main developers who's been working on Boa's implementation of Temporal and temporal_rs. Feel free to ask me anything :)
28.
Implementing Temporal in Rust, the new date/time API for JavaScript(boajs.dev)
4 points by nekevss 1y ago|1 comments
29.
by nekevss 2y ago
Mentioned elsewhere in this thread, but https://test262.fyi/# is great for keeping up to date with the current engine / interpreter support :)
30.
by nekevss 2y ago
if only it was as simply a reading int64 epoch values :')

More ›