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'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.
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
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?
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.
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
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
It's no different except now you've set parent's height to 100% of its parent, which is the html tag. But the html tag is height: auto so there is a circular dependency. if you put html { height: 100% }, or set parent's height to an explicit height then its fine
This is the reason for the perceived difference between width and height. The rules are the same but the box's default width and height are different
There is a quirk where a box's size is a percentage of the parent block, but the parent block's size is calculated from its child (there would be a circular dependency), in which case there are special rules. But even these are the same for width and height. Usually you can just put an explicit height on the parent. https://drafts.csswg.org/css-sizing/#cyclic-percentage-contr...
It’s not syntax help thats useful about visual programming it’s the 2-way communication between the programmer and the running program, and also being able to refer to other parts of a program spatially rather than by a name.
Most kinds of software don’t need these things but if you’re writing code that generates graphics or audio signals then you do, because you get to manipulate your program and see/hear effects in real-time, and also seeing how different parts of your program connects together is more important than giving names to them (where there may not be a useful name you can give them anyway)
Theoretically you might be able achieve these things with only a textual representation and it could be best of both worlds
If you have a couple of different sizes of texts you can render out each character into a sprite map and render a quad per character which is probably the fastest and works for most 2D UIs. You can prerender ahead of time or have some runtime code that renders the characters with a given font using the 2D canvas api. You will need also need to store the characters sizes somewhere unless it’s a monospace font
If you need to scale the text arbitrarily or render it in 3D space you can look at multi channel signed distance fields (MSDF) which also renders out each character but encodes some extra data which makes them scalable. It has pretty good results
Yes Dart with Flutter and swift UI both had to add language features just to support if and loop expressions. But people writing immediate mode guis have been doing the exact same thing using standard language features for years. There's no reason you can't mix React-ive style components with an immediate style API. I do this in a GUI library I've written in D. The downside is you get slightly less type safety, but I'm happy to pay that cost
Yes this is exactly right. What I’ve done in the past is use Django to return HTML with JSX mixed in, and have a super lightweight SPA frontend that just hydrates the react components on each load. You can also use form state to communicate back and forth with the server, where sending a response doesn’t refresh the entire page, just a react render diff.
With this you get the best of both worlds where your backend can do the heavy lifting where everything it needs to decide on the view is all in one place, and your frontend just comprises of really really generic JS components.
I have a library I’ve been playing around with for 2 years now, I should package it up
D’s way is far superior because as the caller you don’t have to worry about whether you’re calling a method or an external function, it looks the same. Not sure it would be possible to tack this onto a dynamic language like JavaScript though