โ๏ธ Not subscribed yet? Subscribe to the Newsletter
Future of Coding Weekly 2024/11 Week 1
2024-11-03 22:33
๐ฅ Operational Version Control ๐ฎ The Future of Coding ๐ก Subsequently
Our Work
๐ฅ spreadsheet / paint-program hybrid via Kevin Greer
I created this spreadsheet / paint-program hybrid. That may sound weird, but it actually makes sense when you see how it works (I think). Here are two videos showing it's basic features and 2D and 3D turtle graphics support
๐ฌ Kevin Greer
I'm working on a server/website so that people can publish and share their creations. Feedback and suggestions appreciated.
๐ฅ Dialogues on natural code via Lu Wilson
hello again it's me.
i gave a talk last week on why i am a machine ๐ค
๐ฆ Guyren Howe (@unclouded) on X via Guyren Howe
๐ฆ Guyren Howe (@unclouded) on X: LLMs are a distillation of everything ever written.
We are a distillation of all the successful responses to the experiences that drove our ancestorsโ evolution.
I think the distillations methods are kinda similar. But are not experiences. This is how we differ.
Devlog Together
๐ฌ Kartik Agaram
A couple of days ago I noticed a bug that's been in all my apps since I started programming with LรVE at the start of 2022. Start searching for text, type nothing into the pattern to search for, then find again repeatedly. Crash. Caused by misusing a Unicode library, even though this bug needs no special chars to trigger.
Now I've pulled the bugfix into 54 forks ๐ฎโ๐จ
๐ฅ Quinebook via Tom Larkworthy
I've built a single file notebook export format in Observable userspace. Convert an Observable notebook into a single file. Self-replicating notebooks. You don't even need a local webserver to run them, they work in a file://
context. You can put them on a webserver if you want. This is complement the userspace notebook source๐ฌ #devlog-together@2024-10-20. I still have some more work on this to consider it fully working (e.g. FileAttachment support), but today I finally reached the milestone that the exporter can export an operational version of itself.
Thinking Together
๐ฎ๐ฅ The future of coding via Jonathan Edwards
My talk on the future of coding
Content
๐ก๐ฅ Subsequently at LIVE via Ivan Reese
Marcel Goethals presenting Subsequently at LIVE
Operational Version Control by Jonathan Edwards via Kartik Agaram
Graphics
๐ฌ Patrick Dubroy
Hello! I'm curious if anyone here has a good idea about interleaving works between a compute shader and a fragment shader.
Some relevant details:
- My app is built with Rust and wgpu, and I'm running on an M1 Macbook Pro.
- I have a single encoder with a compute pipeline and a render pipeline.
- The compute shader writes to a storage buffer defined like this:
@group(0) @binding(2) var<storage, read_write> output: array<vec4<f32>>;
- The fragment shader reads from the same buffer. Basically, each fragment is just one element of the
vec4<f32>
. The fragment shader is very simple, and doesn't touch anything else in the storage buffer.
I've added timestamp queries to the pipeline, and what I'm seeing is this:
Duration #1: 47.800208ms Duration #2: 47.809876ms Frame time: 51.2545ms
Duration #1
is computed from the compute shader timestamps (the duration between the beginning and end of the compute pass) and Duration #2
is the time for the render pass, computed the same way.
Frame time
is measured on the CPU.
I expected the duration of the compute shader and fragment shader to add up to the frame time (approximately). But it doesn't and I'm confused about why! Could it be due to interleaving of the compute pass and render pass? If so, I'm curious how the synchronization works. How does the GPU figure out the dependencies between the write (a compute shader invocation) and the reader (fragment shader invocation)?
I don't have any explicit synchronization, but I'm also not seeing any tearing or anything that would indicate that there is a data race between the shaders.
Music
๐ฅ Ravescript - Make Music With Code! - Ep. #7 via Alex McLean
Present Company
๐ฅ Virtual Meetup 6 โข October 30, 2024 via Ivan Reese
Here's the recording of the Future of Coding virtual meetup 6. We had a demo of Automat.org from @Marek Rogalski, a demo of Inkling from myself, and a demo of Kendra.io's dashboard builder from @Daniel Harris. Good stuff all around! See you next month.
๐จ๐ฝโ๐ป By ๐ @marianoguerra@hachyderm.io ๐ฆ @warianoguerra
๐ฌ Not a member yet? Check the Future of Coding Community
โ๏ธ Not subscribed yet? Subscribe to the Newsletter / Archive / RSS
๐๏ธ Prefer podcasts? check the Future of Coding Podcast