You can switch between the two easily by imagining a lever on the back of the characters head vs front of their head - press up to push the lever higher for the back vs lower for the front. Same goes for planes etc
That works for up and down. But what about side to side? I don't know anyone who inverts left/right. If the lever was at the back of the head, won't left/right be inverted too?
Put your finger on top of the character's head. Left and right are still left and right, but forward (up on the controls because of how they're positioned) makes the character look down and backward makes the character look up.
That's like saying WASM doesn't have a direct way to allocate memory or print to the console. Of course it doesn't, it doesn't have access to anything, that's the whole point.
I think a good analogy would be between user-space and kernel-space code.
It's just weird that by this logic, JavaScript - the more high-level, less typesafe and less performant language - would be the kernel, while performance-optimized WASM code would be the userspace program.
Not the OP, but in formal definitions like Communicating Sequential Processes, concurrency means the possibility for tasks to run out of order and still be correct, as long as other synchronisation events happen
This seems like a really good idea. I like that it's just markdown files and how seemless it is with an existing project. I have a few minor suggestions
1. I would really like a way to run the endpoint by clicking something in addition to command+enter (it wasn't obvious that I could open the sidebar and then click play but I see that now)
2. It would be good to include the evaluated request body and headers in the result sidebar
3. Duplicate file in the file tree context menu - I saw it in the tab context menu but that seems unintuitive
4. Maybe allow the user to set variables inside the markdown that can be imported to other files, for example a customerId variable that different requests could use which isn't part of the environment
5. Dragging text around appears like it will be moved but when releasing the mouse nothing happens
And finally 1 question I have: is this using an underlying text editor? It looks pretty robust but it doesn't look like VSCode, maybe something else? I am wondering if it's available to use for my own project
Much appreciate the feedback! Took it to the team already. I waited to get a confirmation for your question before answering, so here it is: it's built on top of tiptap + codemirror.
Do you know how the break/return would get compiled down to? Would the yield function need to be transformed to return a status code and checked at the callsite?
It's a non-local goto, also a MetaWare language extension, out of the anonymous nested function that the for statement body becomes to (effectively) an anonymous label right after the for statement.
Another part of the High C/C++ Language Reference describes non-local labels and jumps to them. It doesn't go into great detail, but it does talk about stack unwinding, so expect something similar to how High C/C++ implemented throwing exceptions.
Not sure, but imo you could do it with basically reversing the call/return mechanism - that is, whenever the iterator function returns, it saves its state to the stack, just like if it would during a function call, and conversely, when the outside context hands back the control to the iterator, it would restore its state, analogous to how a return from an outside context would work.
That's not at all how MetaWare implemented iterator-driven for, though.
As Joe Groff said in the headlined post, MetaWare implemented it by turning the nested body of the for statement into an anonymous nested function, which is called back (through a "full function pointer") from the iterator function whenever there's a "yield()" in that latter.
So there's no "whenever the iterator function returns". It only returns when it has finished. The body of the for statement is called by and returns to the iterator function, which is in its turn called by and returns to the function that the for statement is in.
All of the "saving state to the stack" that happens is just the quite normal mechanics of function calling, with merely some special mechanics to pass around a pointer to the lexically outer function's activation record (which is why a "full function pointer" is not a plain "function pointer") as a hidden parameter so that the (anonymous) lexically inner function knows where the outer one's automatic storage duration variables are.
MetaWare also had non-local goto from within nested functions back out into lexically enclosing scopes, and since the for statement body is a nested function, it's just a question of employing that already available implementation mechanism (which in turn does the same sorts of things as throwing exceptions does, unwinding the stack through the iterator function) for break/continue/return (and of course goto) inside the for body.
I've done this for a project where the SDF functions are basically instructions, and you can build up instrictions on the CPU to send to the shader. and then the fragment shader runs them like a mini bytecode interpreter. You can tile up the screen to avoid having too many instructions per fragment. Kinda wild idea and performance may vary depend on what you're doing
The CPU builds an RPN expression (like "circle, square, union, triangle, subtract"), and the shader evaluates that in a loop.
I wasn't able to find examples of other people doing similar, but it seemed too useful to not be invented yet (:
Do you have any links to your work?
I'm writing some blog posts for my approach, but haven't finished them yet.
> You can tile up the screen to avoid having too many instructions per fragment.
I don't quite understand this part... If a given SDF needs N instructions to be evaluated, then how does tiling reduce N?
> performance may vary depend on what you're doing
Yeah, fill rate was not good enough with a straightforward approach, so I had to cache the evaluated distance values to a (float) texture atlas, then use those to render to screen. Luckily, standard bilinear filtering on distance values produces pretty decent results.
Yes sounds like the same thing! I also couldn't find anyone else doing it. Sounds super interesting what you're doing so I'd love to read your blog post when it's done if you want to drop me a message/email.
My project was using 2D SDFs for UI which meant you could use a bunch of primitive shapes and union/difference between them, and also add outlines, shadows, glows etc. This means that if you tile up the screen and use a union between two rectangles, only the tile with the overlap needs to calculate the union. It's a little more complicated in 3D with frustum culling.
I was doing it in webgl which doesn't have storage buffers and so I had to use uniforms to pass the data which is a huge limitation. Apparently webgpu could be better so I will try to figure that out one day. But it is early prototype so no links or anything yet.
It's handled through the actual GC implementation, Cheney's Algorithm to be specific, it's mentioned in the blog post but I didn't write how it actually works there.
My git repo link at the end has an actual C implementation if you'd like to have a look.
The TL;DR is that the algorithm starts by going through the roots and copying each of them to a new Arena. Each time it does it updates the root pointer to the new location and writes out a "forwarding pointer" in the old allocation such that if 2 roots go to the same object, they can check if it's already been forwarded, and replace themselves with that pointer without copying.
Once all the roots are copied, the algorithm goes iteratively through every allocation in the new Arena, digging through their pointers, doing the same copy/update/forward/dance onto the same Arena, until it reaches a fixpoint (no new copies happen). Then it frees the old Arena.
It's a really simple algorithm, I strongly suggest having a look at the wikipedia page :)
It’s called a masonry grid. Images retain their aspect ratio so they don’t need to be cropped. You can kind of simulate it with css but there’s proposals to add a proper masonry layout to css
yeah. I actually wrote the logic for the layout myself (wasn't really happy with the available libraries). may open source this if people are interested!
