Ah, so it’s more like Imgur for the fediverse. I imagine it would be possible for multiple servers to share a picts-rs instance, even if in practice it never happens.

It reads like they’re basically making an alternative to picts-rs, or am I missing some key difference?

I think what you’re favorably describing stops being “vibe-coding” and starts simply being “coding with LLM assistance”. And I suspect most people in this thread railing against vibe-coding are much less hostile to LLM assistance. In any case, I don’t think saying that people “should start accepting this fact” will convince anyone that wasn’t already, especially if you call it all “vibe coding”.

I want to disagree with you, but then I see the responses you got here and how many upvotes they got and I can’t help but think that you might be right. Still, until we get transcripts and/or recordings of conversations had at this gathering I don’t think there’s much to be gained from speculation.

IMPOSTER

amogus

I’d agree with you in general, but this streamer spends 8+ hours a day talking about political news - not exactly “play video games for a few hours”).

Learned helplessness is an insidious foe, and one that market forces have tended to side with over the past 20 years (probably for far longer than that, but as I was a mere child back then I wouldn’t claim it with as much certainty).

It’s an “easy way” for those like you and me who have more or less already built up the know-how over countless small steps, but if you’ve never known “life” outside of these corporate surveillance playgrounds I imagine it seems very scary and deserted.

I agree that in the short-term, NVidia stand to make more money as a destroyed datacenter prompts it’s owners to rebuild it. However, until the armed conflict stops, there might be a pause on datacenter construction in the region - why pay to (re)build a datacenter if it’s probably going to be blown up again? From my (admittedly limited) reading of history, most reconstruction only happens in the years following an armed conflict’s end.

I wonder if it would be ok to attend a furry convention wearing a sign that says “I’d love to pet you but I’m not brave enough to ask”.

That’s great to hear!

I’m disappointed there’s no threadiverse integration.

The basic grunt work of bringing together bluesky and mastodon feeds is pretty decently done, if a bit opinionated.

I like the concept and presentation of their feed “packages”, but for most of the feeds I’ve been proposed in the app I’m not interested in the entire package. It’s nice that you can still directly follow the actors packaged into a feed from that feed’s page.

It’s very annoying that Surf wants their/my Surf account to act as the intermediary for my mastodon account. From what I can see, this means I need to exit the app to take some action with my mastodon account. Maybe I just haven’t found the option, but if there isn’t one then it’s a hard blocker for me to use it as my main fediverse browser.

positively dripping!

A small gui to automate generating some pdfs from some CSV files.

There’s a small non-profit in my area helping people operate localized energy distribution (as producers and consumers). Each month, they receive a zip file containing the raw kiloWatt-hours produced and consumed by each participant over the past month as CSV files. So far the non-profit has been manually importing these CSVs into LibreOffice to generate graphs and tables and export the whole thing as an individualized PDF file for each participant. Now that they’re starting to help more than 2-3 operations, it’s become useful to try to automate that process.

I’ve been writing it in rust for a few reasons. First of all I wanted cross-compilation to be sure to work and at this point I’m more familiar with rust than go, secondly I read a blog post recently that evaluated rust gui solutions in terms of accessibility and IME-compatibility on windows. I started off looking for a “direct” pdf-writing library but eventually switched to using typst to generate the pdfs from templates I write. typst being written in rust has enabled me to bundle its engine into the program in a pretty-straightforward way.

I’m currently working on allowing the import of multiple sets of data so that the generated PDFs can show line plots of the electricity production and consumption over several months.

1. chunk_size := file_size / cpu_cores. Compile regex.

2. spawn cpu_cores workers:
   2.a. worker #n starts at n * chunk_size bytes. If n > 0, skip bytes until newline encountered.
   2.b worker starts feeding bytes from file/chunk into regex. When match is found, write to output (stdout or file, whichever has better performance). When newline encountered, restart regex state automata.
   2.c after having read chunk_size bytes, continue until encountering a newline to ensure the whole file is covered by the parallel search.

Optionally, keep track of byte number and attach them to the found matches when outputting, to facilitate eventually de-duplicating and/or navigating to said match in the file.

To avoid problems, have each worker output to a separate file, and only combine these output files when the workers are all finished.

As others have said, it’s going to be hard to get more speedup than this, and you will ultimately be limited by your storage’s read speed and throughput if the whole file cannot fit into memory.

Instead of

main_scene.remove_child(self)

I would “simply” do

queue_free() # you can also write `self.queue_free()` if you really prefer it

I would also emit custom signals ( play_requested, options_requested, level_requested(level_number), etc) in your “child” scenes and hook them up to functions in the Main scene that would take care of instantiating the required scene and doing a add_child(the_scene). This would mean moving most of your load() calls (and variables storing their results) into your Main scene.

There is an adage that is often repeated in the Godot community; “call down (but/and) signal up”. Here’s some more in-depth explanations of why this is generally considered a best/better practice:

• https://kidscancode.org/godot_recipes/4.x/basics/node_communication/index.html
• https://old.reddit.com/r/godot/comments/y2jovs/as_a_new_dev_what_is_meant_by_call_down_signal_up/
• https://gamedevartisan.com/tips/call-down-signal-up

As for file/folder structure, what tends to work for me is to group things by how often they are used together, more than grouping them by what they are. In your project, I could for example have a folder containing the scene and scripts for the level select, another one containing the scene(s) and script(s) for level 1, and so on.