Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
phickey
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
8 ms
·
31.
▲
by
phickey
1y ago
This looks like a nice approach to making wasi-libc faster. Could you submit these changes upstream?
32.
▲
by
phickey
2y ago
This addition unlocks the ability to use Go with the component model. The component model layers on top of Wasm Modules - a module which imports and exports functions with the component model ABI can be turned into a component using e.g. `w
33.
▲
Rust Wasm32-Wasip2 Target Has Reached Tier 2 Support
(blog.rust-lang.org)
2 points
by
phickey
2y ago
|
0 comments
34.
▲
by
phickey
2y ago
One of the biggest goals of the component model is that it doesn't matter what language your component is written in. Composition can happen anytime one component exports an interface and another component imports it. https:/
35.
▲
by
phickey
2y ago
They don't advertise themselves as such, for obvious reasons, but there is at least one online CPAP dealer in the US that will sell to you without prescription verification. (Why should I wait 3 months for an appointment, drive an hour
36.
▲
Jco 1.0
(bytecodealliance.org)
7 points
by
phickey
3y ago
|
2 comments
37.
▲
by
phickey
3y ago
Some of my colleagues have built https://component-model.bytecodealliance.org/ to help get folks up to speed. The best place to ask questions is in the bytecode alliance zulip: https://bytecodealliance.zulipchat.
38.
▲
by
phickey
3y ago
> The component model is addressing this but it's sprawled out into literally rebuilding "worlds" and turning wasm modules into sort of lightweight virtual machines. I wish there was just more of a focus on getting data in
39.
▲
by
phickey
3y ago
The bytecode alliance zulip is the best place to discuss that: https://bytecodealliance.zulipchat.com/
40.
▲
by
phickey
3y ago
WASI Co-chair here: WASI is for the Web as well as beyond. The jco project ( https://github.com/BytecodeAlliance/jco ) provides an implementation of the Component Model and WASI Preview 2 for JavaScript systems. Right no
41.
▲
by
phickey
3y ago
We have already made big improvements in using SpiderMonkey on WASM, and have more work in progress that will enable SpiderMonkey to have "native"-like codegen for WASM: https://cfallin.org/blog/2023/10&#
42.
▲
by
phickey
3y ago
> WASI-Preview2's benefits are not going to be realized in a browser, it's more for the non-web world The jco project ( https://github.com/BytecodeAlliance/jco ) provides an implementation of the Component M
43.
▲
by
phickey
3y ago
WASI Co-chair here. Nothing in WASI is "somehow blocked by Google", or indeed blocked by anyone at all. Graphics support in WASI hasn't been developed simply because nobody has put energy into developing graphics support in W
44.
▲
by
phickey
3y ago
it solved it so well that nobody outside of chrome ever implemented nacl, and chrome's nacl team became their webassembly team
45.
▲
Wasmtime and Cranelift in 2023
(bytecodealliance.org)
24 points
by
phickey
3y ago
|
0 comments
46.
▲
by
phickey
3y ago
The component model is already shipping in Wasmtime, and will be stable for use in Node.js and in browsers via jco ( https://github.com/bytecodealliance/jco ) soon. WASI Preview 2 will be done in December or January, giv
47.
▲
by
phickey
3y ago
Useful things are hard to make.
48.
▲
by
phickey
3y ago
To run a JavaScript interpreter (spidermonkey, in this case) in Wasm, as well as running that same wasm in a JS engine, you want to look at `jco` https://github.com/bytecodealliance/jco The component model tooling is g
49.
▲
by
phickey
3y ago
Yes, CM resources are unforgable references.
50.
▲
by
phickey
3y ago
Wasi co-chair and Wasmtime maintainer here: we agree! Wasi Preview 1, which this article is about, was a first attempt at porting some of these Unix ideas to Wasm. We found pretty quickly that unix isn't the right abstraction for Wasm.
51.
▲
by
phickey
3y ago
Related: one of my colleagues created [wasm-smith]( https://github.com/bytecodealliance/wasm-tools/tree/main/cra... ) for fuzzing wasmparser and Wasmtime.
52.
▲
Will JavaScript Become the Most Popular WebAssembly Language?
(thenewstack.io)
2 points
by
phickey
3y ago
|
0 comments
53.
▲
by
phickey
3y ago
You can use jco to both compile a JavaScript module into a WebAssembly Component (with spidermonkey running as wasm inside), and to generate a Javascript embedding for that component. This solves all of your problems except for untrusted co
54.
▲
by
phickey
3y ago
`jco componentize` turns a JavaScript module into a WebAssmebly component: https://github.com/bytecodealliance/jco
55.
▲
by
phickey
4y ago
Additionally, googlers are championing memory control https://github.com/WebAssembly/memory-control/blob/main/prop... , which provides memory protection, as well as memory 64, which is already done in chr
56.
▲
by
phickey
4y ago
Wasmtime modules have an internal arc, and are unloaded from memory when there are no more references.
57.
▲
by
phickey
4y ago
The wit-bindgen work required would be a significant undertaking (a week? more?) by someone who already has some expertise in wit & python. Maybe the wasmlabs folks are up for taking it on. In general the Wasm Component ecosystem is sti
58.
▲
by
phickey
4y ago
Wasmtime's `wasmtime-py` embedding in python has support for Wasm Components: https://github.com/bytecodealliance/wasmtime-py#components (disclosure, I helped create it) The remaining piece of the puzzle would be
59.
▲
by
phickey
4y ago
I am a hiker and a ham and I disagree with this advice. I carried a ham radio while hiking for years and they were never a useful safety device. Here in the PNW, anywhere I was prominent enough to reach a repeater or another ham on the call
60.
▲
by
phickey
4y ago
there’s a good write up on this somewhere that you’ll have to forgive me not being able to find tonight on mobile. In general, we want the wat syntax to mirror the binary format very closely, but that’s often at odds with a surface syntax t
More ›