Future of Coding Weekly 2024/11 Week 1

[marianoguerra]

• [ ] Change Month and Week Number

• [ ] focWeekExport "2023-01-19" "2023-01-26"

• [ ] Update Search Index

• [ ] Download New Attachments

• [ ] Update links

• [ ] Check that comment links work (push weekly dump with channel summaries)

• [ ] Check to mention right person for moved messages

• [ ] Summary

• [ ] Hashtags

• [ ] Set title in newsletter

• https://tinyletter.com/

• https://tinyletter.com/marianoguerra/letters/

• http://localhost:8000/history/

• https://marianoguerra.github.io/future-of-coding-weekly/

• https://stackedit.io/app#

[marianoguerra]

🎥 Operational Version Control 🔮 The Future of Coding 💡 Subsequently

Our Work

🎥 spreadsheet / paint-program hybrid via Kevin Greer

🧵 conversation

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

[marianoguerra]

💬 Kevin Greer

🧵 conversation

I'm working on a server/website so that people can publish and share their creations. Feedback and suggestions appreciated.

[marianoguerra]

🎥 Dialogues on natural code via Lu Wilson

🧵 conversation

hello again it's me.

i gave a talk last week on why i am a machine 🤖

[marianoguerra]

🐦 Guyren Howe (@unclouded) on X via Guyren Howe

🧵 conversation

🐦 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.

[marianoguerra]

Devlog Together

💬 Kartik Agaram

🧵 conversation

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 😮‍💨

[marianoguerra]

🎥 Quinebook via Tom Larkworthy

🧵 conversation

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.

[marianoguerra]

Thinking Together

🔮🎥 The future of coding via Jonathan Edwards

🧵 conversation

My talk on the future of coding

[marianoguerra]

Content

💡🎥 Subsequently at LIVE via Ivan Reese

🧵 conversation

Marcel Goethals presenting Subsequently at LIVE

[marianoguerra]

Operational Version Control by Jonathan Edwards via Kartik Agaram

🧵 conversation

[marianoguerra]

Graphics

💬 Patrick Dubroy

🧵 conversation

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.

[marianoguerra]

Music

🎥 Ravescript - Make Music With Code! - Ep. #7 via Alex McLean

🧵 conversation

[marianoguerra]

Present Company

🎥 Virtual Meetup 6 • October 30, 2024 via Ivan Reese

🧵 conversation

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.