w2c2 was evaluated in a research paper which got presented at Programming Languages and Analysis for Security '24 (https://t.co/f5MhmqKDER): "Is This the Same Code? A Comprehensive Study of Decompilation Techniques for WebAssembly Binaries" https://t.co/ViV4SqI3sO
As OpenAI and Meta introduce LLM-driven searchbots, I'd like to once again remind people that neither LLMs nor chatbots are good technology for information access.
A thread, with links:
>>
@whitequark In the past @vshymanskyy had got it running with wasm3, see https://t.co/k5vN1hnTK7, but that was probably before the WASI implementation had the clock related code.
Did you find a work-around? It seems to be necessary for investigating https://t.co/c517fmP3Bk it seems
Your pie doesn't need to be original (unless you claim it so)
Imagine you bake a delicious peach pie over the weekend, and you offer a slice to your friend. They respond:
"Wait, how is this different from every other peach pie that's ever been baked? It seems really similar to another pie I had recently."
This is obviously an absurd reaction!
But this exact dynamic happens all the time in creative software projects. Someone shares a project they made, and the first reaction is: how's it different?
The problem here is a mismatch in values.
The friend has assumed that your goal is to "efficiently" reach the goal of a delicious pie, or perhaps even to create a new kind of pie. But that's not the goal at all!
Baking a pie is a creative act. It's personal, it's inherently delightful, it's an act of caring for others. It's also a craft that one can improve at over time. Just buying the "best" pie would defeat the point.
---
The next day, you find out there's a scientific conference in town: CRISP, the Conference for Research on Innovative Sweet Pastries. This is where the world's foremost experts push forward the frontier of pie-baking technique.
You show up with your delicious peach pie, and the first question from the judging panel is:
"Wait, how is this different from every other peach pie that's ever been baked? It seems really similar to another pie I had recently."
You respond: "I have no idea, I just enjoyed baking it and thought it was delicious! I don't even know what recipe I used. Why does it matter to you, huh?"
The expert says: "Well then, you're welcome to bake pies all you want at home, but your pie is not welcome at CRISP. The community cannot understand your contribution or build on your work."
You might be upset about this outcome, but you'd be wrong. In this context, the judge's criticism is totally fair.
The goal of CRISP isn't just to enjoy pies, it's to build up a community of practice. Part of being a good citizen of that community is being able to explain how your pie is different—which in turn requires learning about all the other ways of making pie. This isn't merely a higher bar than amateur weekend baking, it's a totally different frame of mind.
---
I think mixing up these two situations is the source of a lot of unfortunate confusion.
I work on prototyping new kinds of software interfaces and programming tools, and I spend time in various communities that span across the cultures of playful exploration (sharing demos on Twitter) and academic research (writing formal papers).
Often I see creative people share personal projects and get their spirits weakened by "how's it different?" The question can be well-meaning; it isn't necessarily cynical! It's just misunderstanding the goal.
On the other hand, I see people submit cool work to academic research venues and get confused by, or even chafe at, the stringent requirement of situating the work in context. I used to be pretty dismissive of Related Work sections myself, until I went through grad school and realized how valuable they are to the world.
---
So, as creators and feedback-givers, how can we avoid this confusion?
There's an answer that seems obvious: clearly set the goal up front. Are you trying to do a personal project for fun, or are you trying to make a novel research contribution? Just proactively broadcast your intent, and most people will be better at asking questions that are aligned with your goals.
Unfortunately, in my experience, things don't work out this cleanly. Many of the best new ideas start out as playful explorations, and over time snowball into a larger project that are worthy of a serious research contribution.
A strategy I've found helpful is to _start_ from a place of personal creativity. If the initial goal is playful exploration for its own sake, that creates free space to explore and quells early doubts (from both myself and others). It doesn't matter if it's new or good (yet), I'm just having fun.
Occasionally a project grows into something more. At that point it can be appropriate to apply a critical academic lens.
Starting from the other side seems a lot tougher. If you start off saying "we're going to make a big serious contribution no one's ever done before," that sets up high stakes and invites harsh critique from the start. Maybe this approach works for some projects with narrower success criteria, but it doesn't seem to work well for most of what I do.
A final thing to keep in mind: when I'm on the side of giving feedback, I always try to first understand the creator's goals. This can be a subtle art when they don't even know their own goals yet. The weekend baker may just need encouragement, not critique.
so, since i can now translate c to webassembly (my work) and webassembly to c (via w2c2), i should set up a thingy that translates wasm to c to wasm to c to wasm...
wlockchain
We're excited to announce that Bastian Müller (@turbolent) is sponsoring Ladybird with a generous contribution of $5,000!
Bastian says: "I hope that will show that individuals can and should sponsor too, not just corporations."
Thank you so much for the support, Bastian! 🙌💜
Introducing TigerSwift: Write Swift applications for Mac OS X Tiger! https://t.co/CB8GPPN8hL
Powered by https://t.co/SrObKrwYPV and https://t.co/c3Fhny17nN.
@austin_flowty You can use optional binding here:
fun safeDestroy(_ r: @AnyResource) {
if let s <- r as? @{SafeDestroy} {
s.callback()
destroy s
} else {
destroy r
}
}
Instead of using hard-coded run-time type values, just use static types
@falco_girgis Awesome!
With https://t.co/SrObKrxwFt it should be possible to use the reference Rust compiler, and also support other languages like e.g. Swift.
I could put together a demo if that would be helpful?
@dubroy For example, it would be great if e.g. TS had a way to indicate that the setState function invalidates/"consumes" the receive (or if it would be a function and not a method, that a function parameter is invalidating/"consuming")