|
39413
|
octoPy by @sircheetodust | Stardance
|
sircheetodust
|
1
|
6.0
|
69
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-29T00:01:36Z", "hours": 6.0, "multiplier": 11.27, "payout": 69, "blessing": "neutral", "text": "This is OctoPy A chip-8 emulator fully written in python that I made while waiting for one of my other projects to finish rating(IT DOESNT EVEN HAVE ONE, ITS BEEN A WEEK, SOMEONE HALP). This project was my first emulator so I am proud to present it. It features a CPU with all of the chip-8s instructions programmed into it. It also has a pygame GUI interface, where you can choose ROMS, test the emulator, and even use your own ROMs(make sure they are for the chip8, this isnt a SCHIP or XOChip). This project had its own fair share of issues, such as the FX0A opcode just freezing the emulator entirely, or when games tried to play sound, your eardrums explode. I fixed all of these and finally finished this project. Please leave feedback!", "repo": "https://github.com/thecheetoman/octoPy", "demo": "https://github.com/thecheetoman/octoPy/releases/tag/v1.0"}]...
|
[{"post_id": 36733, "ts": "202 [{"post_id": 36733, "ts": "2026-07-28T23:57:31Z", "hours": 0.4281, "text": "Readme is useful i wrote the readme and created a gh release"}, {"post_id": 36666, "ts": "2026-07-28T21:27:44Z", "hours": 2.3717, "text": "i am going to eat a tire I might be only compiling this windows. pygbag is not cooperating at all. After this imma work on readme and get ready to ship. Here is a screenshot of the farthest I got it working."}, {"post_id": 36214, "ts": "2026-07-28T04:36:48Z", "hours": 0.9808, "text": "Emulator accuracy improvements Today I ran multiple test ROMS through my emulator. It passed most of the quirks and flags tests. It had issues with they FX0A instruction though. My previous CPU handled this in a way that the code will stop execution forever, not good. So I fixed that(took way too long) and ran the tests again. I can now say I have made my own emulator!"}, {"post_id": 35543, "ts": "2026-07-27T01:38:33Z", "hours": 0.8592, "text": "Dev log #3 Today i finished a boot UI. from here you can choose a game rom and play it. You can also hit esc and return to the menu. I also included test roms just in case someone wants to test the emulator. Emulator doesnt pass some of the tests though so i gotta work on that =("}, {"post_id": 34943, "ts": "2026-07-26T01:58:28Z", "hours": 0.6817, "text": "Got the emulator working I finally got the emulator working. Here is a quick clip of me playing pong, forgive my nonexistent skills at pong"}, {"post_id": 34380, "ts": "2026-07-25T01:29:25Z", "hours": 0.9022, "text": "Dev log #1 This is a short project that I hope to finish in a few days… Today I researched how the Chip-8 works, got some test ROMS, and wrote my CPU. Next I hope to make a GUI that i can even export to web. Im not sure what image to put here so here is js a pic of code"}]...
|
Title: octoPy by @sircheetodust | Stardance
Devlo Title: octoPy by @sircheetodust | Stardance
Devlogs:
Dev log #1 This is a short project that I hope to finish in a few days… Today I researched how the Chip-8 works, got some test ROMS, and wrote my CPU. Next I hope to make a GUI that i can even export to web. Im not sure what image to put here so here is js a pic of code
Got the emulator working I finally got the emulator working. Here is a quick clip of me playing pong, forgive my nonexistent skills at pong
Dev log #3 Today i finished a boot UI. from here you can choose a game rom and play it. You can also hit esc and return to the menu. I also included test roms just in case someone wants to test the emulator. Emulator doesnt pass some of the tests though so i gotta work on that =(
Emulator accuracy improvements Today I ran multiple test ROMS through my emulator. It passed most of the quirks and flags tests. It had issues with they FX0A instruction though. My previous CPU handled this in a way that the code will stop execution forever, not good. So I fixed that(took way too long) and ran the tests again. I can now say I have made my own emulator!
i am going to eat a tire I might be only compiling this windows. pygbag is not cooperating at all. After this imma work on readme and get ready to ship. Here is a screenshot of the farthest I got it working.
Readme is useful i wrote the readme and created a gh release
Ships:
This is OctoPy A chip-8 emulator fully written in python that I made while waiting for one of my other projects to finish rating(IT DOESNT EVEN HAVE ONE, ITS BEEN A WEEK, SOMEONE HALP). This project was my first emulator so I am proud to present it. It features a CPU with all of the chip-8s instructions programmed into it. It also has a pygame GUI interface, where you can choose ROMS, test the emulator, and even use your own ROMs(make sure they are for the chip8, this isnt a SCHIP or XOChip). This project had its own fair share of issues, such as the FX0A opcode just freezing the emulator entirely, or when games tried to play sound, your eardrums explode. I fixed all of these and finally finished this project. Please leave feedback!...
|
1793105679.2637389
|
1793192079.2637389
|
|
67103
|
My awesome macropad! by @mladen | Stardance
|
mladen
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My awesome macropad! by @mladen | Stardance
|
1793105680.427344
|
1793710480.427344
|
|
67105
|
My awesome macropad! by @sukhdeepsomal33 | Stardan My awesome macropad! by @sukhdeepsomal33 | Stardance...
|
sukhdeepsomal33
|
0
|
3.5
|
0
|
[]
|
[{"post_id": 75799, "ts": "202 [{"post_id": 75799, "ts": "2026-10-01T05:31:04Z", "hours": 2.8558, "text": "I have finally finished making my pcb for my macropad. Now I just need to figure out if there are any errors in the tracing. Once that is done, the case will be left to make as well as the code."}, {"post_id": 75719, "ts": "2026-09-30T21:02:24Z", "hours": 0.6489, "text": "I have just started making my macropad schematic. I have finished adding all the components I need in the schematic and I have started wiring most of the components. I will finish wiring after having a short break and will review my schematic to make sure I can move on to routing everything in my pcb design. I plan on making a unique and clean macropad that would look nice next to my setup."}]...
|
Title: My awesome macropad! by @sukhdeepsomal33 | Title: My awesome macropad! by @sukhdeepsomal33 | Stardance
Devlogs:
I have just started making my macropad schematic. I have finished adding all the components I need in the schematic and I have started wiring most of the components. I will finish wiring after having a short break and will review my schematic to make sure I can move on to routing everything in my pcb design. I plan on making a unique and clean macropad that would look nice next to my setup.
I have finally finished making my pcb for my macropad. Now I just need to figure out if there are any errors in the tracing. Once that is done, the case will be left to make as well as the code....
|
1793105681.3086123
|
1793710481.3086123
|
|
67106
|
My own site! by @Lakshyazzz | Stardance
|
Lakshyazzz
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My own site! by @Lakshyazzz | Stardance
|
1793105682.201702
|
1793710482.201702
|
|
67107
|
My very own WebOS by @abdelrahman_992010 | Stardan My very own WebOS by @abdelrahman_992010 | Stardance...
|
abdelrahman_992010
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My very own WebOS by @abdelrahman_992010 | Title: My very own WebOS by @abdelrahman_992010 | Stardance...
|
1793105683.0631468
|
1793710483.0631468
|
|
37175
|
My first slack bot! by @Ayon | Stardance
|
Ayon
|
1
|
1.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-19T13:18:58Z", "hours": 1.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I made an assistant bot that can tell current weather, give weather forecast, random quote. The challenging part was formatting. So, I used ChatGPT to suggest formatting of the responses. Deployed on HackClub Nest. Now it is working just fine.", "repo": "https://github.com/amiayon8/myassistant-slack", "demo": "https://hackclub.slack.com/archives/C0BJAR0QEV8"}]...
|
[{"post_id": 31168, "ts": "202 [{"post_id": 31168, "ts": "2026-07-19T10:39:51Z", "hours": 0.4331, "text": "Done random quotes and ping! Now my bot is ready to ship"}, {"post_id": 31149, "ts": "2026-07-19T10:03:13Z", "hours": 0.6186, "text": "Done current weather and weather forecast commands. Working well. Not yet deployed as my Nest Request isn’t approved yet"}]...
|
Title: My first slack bot! by @Ayon | Stardance
D Title: My first slack bot! by @Ayon | Stardance
Devlogs:
Done current weather and weather forecast commands. Working well. Not yet deployed as my Nest Request isn’t approved yet
Done random quotes and ping! Now my bot is ready to ship
Ships:
I made an assistant bot that can tell current weather, give weather forecast, random quote. The challenging part was formatting. So, I used ChatGPT to suggest formatting of the responses. Deployed on HackClub Nest. Now it is working just fine....
|
1793105683.924303
|
1793192083.924303
|
|
67108
|
LighterOS by @Rik | Stardance
|
Rik
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: LighterOS by @Rik | Stardance
|
1793105684.8147666
|
1793710484.8147666
|
|
67109
|
My own site! by @Bobxandersen | Stardance
|
Bobxandersen
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My own site! by @Bobxandersen | Stardance
|
1793105685.7047405
|
1793710485.7047405
|
|
35763
|
Future Oracle by @jacksonkyronox | Stardance
|
jacksonkyronox
|
1
|
0.0
|
1
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-17T13:02:04Z", "hours": 0.0, "multiplier": 1.56, "payout": 1, "blessing": "neutral", "text": "Hey there ! I , Gauransh , made a web app that has hardly anything to do with our daily life and making things easy . However , considering the fact that most of the people on this platform are teenagers just like me , I can guarantee that they pursue clarity in future , than anything else . But facts are facts . You can’t see the future . Neither can I ! But my project can tell people what their life “may” look like if they keep working hard , and that too , in just the right direction . You enter some info about you , press enter , and suddenly you are in a room with a window from where you can see the Shibuya crossing . A small table , a cup of coffee , your laptop on , and Copilot is debugging your code . Now that may not have anything useful , but it provides something . And yes , that is clarity . That does clarify what your future will look like if you are honest enough with what you should do , and know how you can be one step forward after each day towards your goals !! I hope you all like it . Love you all !! Gauransh Sharma .", "repo": "https://github.com/jacksonkyronox-sudo/Inspo-Possibilities-.-", "demo": "https://inspo-possibilities.vercel.app/"}]...
|
[{"post_id": 29547, "ts": "202 [{"post_id": 29547, "ts": "2026-07-16T15:35:35Z", "hours": 0.3836, "text": "Hey everyone! Gauranth this side — this is my first project here, and it’s built around something most teens do more than they’d admit. You know that moment right before sleep when you’re not tired yet? Or when the day’s chaos settles and you’re just… satisfied with what you got done? I spend that time closing my eyes and picturing what my future looks like if I keep taking small steps toward my goals. Turns out my friends do this too. Maybe you do. So I built something for that exact moment. You enter a few details about where you’re headed, and it hands you back a glimpse of that possible future — a small nudge to keep the momentum going. It runs on an API key under the hood, nothing fancy, just enough to make the magic work. This is my first project here, so reviews genuinely matter to me. Tear it apart if you need to — I want to make it better. Love you guys!"}]...
|
Title: Future Oracle by @jacksonkyronox | Stardanc Title: Future Oracle by @jacksonkyronox | Stardance
Devlogs:
Hey everyone! Gauranth this side — this is my first project here, and it’s built around something most teens do more than they’d admit. You know that moment right before sleep when you’re not tired yet? Or when the day’s chaos settles and you’re just… satisfied with what you got done? I spend that time closing my eyes and picturing what my future looks like if I keep taking small steps toward my goals. Turns out my friends do this too. Maybe you do. So I built something for that exact moment. You enter a few details about where you’re headed, and it hands you back a glimpse of that possible future — a small nudge to keep the momentum going. It runs on an API key under the hood, nothing fancy, just enough to make the magic work. This is my first project here, so reviews genuinely matter to me. Tear it apart if you need to — I want to make it better. Love you guys!
Ships:
Hey there ! I , Gauransh , made a web app that has hardly anything to do with our daily life and making things easy . However , considering the fact that most of the people on this platform are teenagers just like me , I can guarantee that they pursue clarity in future , than anything else . But facts are facts . You can’t see the future . Neither can I ! But my project can tell people what their life “may” look like if they keep working hard , and that too , in just the right direction . You enter some info about you , press enter , and suddenly you are in a room with a window from where you can see the Shibuya crossing . A small table , a cup of coffee , your laptop on , and Copilot is debugging your code . Now that may not have anything useful , but it provides something . And yes , that is clarity . That does clarify what your future will look like if you are honest enough with what you should do , and know how you can be one step forward after each day towards your goals !! I hope you all like it . Love you all !! Gauransh Sharma ....
|
1793105686.549272
|
1793192086.549272
|
|
67110
|
Blog by @xeo | Stardance
|
xeo
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Blog by @xeo | Stardance
|
1793105687.3986924
|
1793710487.3986924
|
|
23619
|
Wallipheus by @Wally | Stardance
|
Wally
|
1
|
2.32
|
4
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-25T12:54:55Z", "hours": 2.0, "multiplier": 2.28, "payout": 4, "blessing": "neutral", "text": "Made a Slack app for my personal channel, it can welcome new members, set a reminder, give cat fun facts, greet people, and has a daily reminder with a message that can be changed with a command, the ReadMe contains all the command names and what they do", "repo": "https://github.com/wally-ben/wallipheus", "demo": "https://hackclub.enterprise.slack.com/archives/C0AECK065AP"}]...
|
[{"post_id": 15801, "ts": "202 [{"post_id": 15801, "ts": "2026-06-25T18:01:03Z", "hours": 0.3242, "text": "Cleaned up the ReadMe file and fixed a problem where the Cat Command wasn’t working"}, {"post_id": 15558, "ts": "2026-06-25T09:17:07Z", "hours": 0.4958, "text": "Added a daily reminder at 9 am with a message that can be changed using /wallipheus-daily"}, {"post_id": 15362, "ts": "2026-06-24T23:45:44Z", "hours": 0.4456, "text": "Added a reminder command, it currently only takes in the amount of minutes and a message but I plan on adding the option to have a daily reminder"}, {"post_id": 15151, "ts": "2026-06-24T16:47:18Z", "hours": 0.2503, "text": "Added a Welcome message for #the-wally-cave, and started working on a reminder system"}, {"post_id": 15102, "ts": "2026-06-24T15:18:28Z", "hours": 0.7103, "text": "Followed the guide and made a Slack app with 3 commands, wallipheus-greet, wallipheus-ping, and wallipheus-cat. Will be adding more commands that use other APIs."}]...
|
Title: Wallipheus by @Wally | Stardance
Devlogs:
Title: Wallipheus by @Wally | Stardance
Devlogs:
Followed the guide and made a Slack app with 3 commands, wallipheus-greet, wallipheus-ping, and wallipheus-cat. Will be adding more commands that use other APIs.
Added a Welcome message for #the-wally-cave, and started working on a reminder system
Added a reminder command, it currently only takes in the amount of minutes and a message but I plan on adding the option to have a daily reminder
Added a daily reminder at 9 am with a message that can be changed using /wallipheus-daily
Cleaned up the ReadMe file and fixed a problem where the Cat Command wasn’t working
Ships:
Made a Slack app for my personal channel, it can welcome new members, set a reminder, give cat fun facts, greet people, and has a daily reminder with a message that can be changed with a command, the ReadMe contains all the command names and what they do...
|
1793105688.2808204
|
1793192088.2808204
|
|
67114
|
soul knight by @xev123_ | Stardance
|
xev123_
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: soul knight by @xev123_ | Stardance
|
1793105689.4074612
|
1793710489.4074612
|
|
36848
|
Jahysite by @jahyue | Stardance
|
jahyue
|
1
|
2.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-21T12:09:14Z", "hours": 2.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I was able to make my own site! its a matrixy terminal theme which really took some time to accomplish but im very proud of what ive done its very minimal and i dont have much projects but itll grow over time", "repo": "https://github.com/jahyue/jahysite", "demo": "https://jahyue.github.io/jahysite/"}]...
|
[{"post_id": 31479, "ts": "202 [{"post_id": 31479, "ts": "2026-07-19T21:38:10Z", "hours": 1.595, "text": "I just finished the site i gave it a bit more of a matrix andd terminal theme and i really like the look i gave it"}, {"post_id": 30912, "ts": "2026-07-18T21:48:56Z", "hours": 0.2606, "text": "I was able to make a barebones website with a very very very very short intro about me with some socials and showing off my projects all i need now is some better design and some stuff"}]...
|
Title: Jahysite by @jahyue | Stardance
Devlogs:
I Title: Jahysite by @jahyue | Stardance
Devlogs:
I was able to make a barebones website with a very very very very short intro about me with some socials and showing off my projects all i need now is some better design and some stuff
I just finished the site i gave it a bit more of a matrix andd terminal theme and i really like the look i gave it
Ships:
I was able to make my own site! its a matrixy terminal theme which really took some time to accomplish but im very proud of what ive done its very minimal and i dont have much projects but itll grow over time...
|
1793105690.2393098
|
1793192090.2393098
|
|
67115
|
BLARE by @mehmet_eren | Stardance
|
mehmet_eren
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: BLARE by @mehmet_eren | Stardance
|
1793105691.720077
|
1793710491.720077
|
|
31086
|
BlackOS by @khabibullayev | Stardance
|
khabibullayev
|
1
|
1.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-06T07:18:51Z", "hours": 1.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "What did you make? I built BlackOS, a conceptual web-based operating system. It features an interactive boot screen, a functional login system, and a desktop environment with draggable windows. What was challenging? Managing the virtual file system (VFS) and ensuring the window management logic stayed smooth while keeping the interface responsive. What are you proud of? I’m proud of the custom boot animation and the modular architecture, which makes it easy to add new built-in apps like the terminal and calculator. What should people know so they can test your project? The system is open to everyone—no password required. You can drag windows around, use the terminal to browse the VFS, and explore the settings.", "repo": "https://github.com/nullPulse-cmoke/BlackOS", "demo": "https://quiet-beignet-5838c1.netlify.app/"}]...
|
[{"post_id": 23326, "ts": "202 [{"post_id": 23326, "ts": "2026-07-06T06:36:17Z", "hours": 0.5208, "text": "Working on the desktop environment for BlackOS. Currently implementing the Finder and terminal logic, as well as setting up the authorization system and VFS. Next up is refining the UI to match the macOS aesthetic."}]...
|
Title: BlackOS by @khabibullayev | Stardance
Devl Title: BlackOS by @khabibullayev | Stardance
Devlogs:
Working on the desktop environment for BlackOS. Currently implementing the Finder and terminal logic, as well as setting up the authorization system and VFS. Next up is refining the UI to match the macOS aesthetic.
Ships:
What did you make? I built BlackOS, a conceptual web-based operating system. It features an interactive boot screen, a functional login system, and a desktop environment with draggable windows. What was challenging? Managing the virtual file system (VFS) and ensuring the window management logic stayed smooth while keeping the interface responsive. What are you proud of? I’m proud of the custom boot animation and the modular architecture, which makes it easy to add new built-in apps like the terminal and calculator. What should people know so they can test your project? The system is open to everyone—no password required. You can drag windows around, use the terminal to browse the VFS, and explore the settings....
|
1793105693.284974
|
1793192093.284974
|
|
67116
|
AROST.cast by @LynnieLooLyeLoo | Stardance
|
LynnieLooLyeLoo
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: AROST.cast by @LynnieLooLyeLoo | Stardance
|
1793105694.1838648
|
1793710494.1838648
|
|
31577
|
PickleWatch by @karthikeya | Stardance
|
karthikeya
|
2
|
34.45
|
308
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-09-10T03:58:34Z", "hours": 27.0, "multiplier": 16.51, "payout": 246, "blessing": "neutral", "text": "I updated it to now RallyLab. I did this because initially i had an app to find open pickleball courts near me in Tampa. It worked, but I realized you really only use a court finder once. You check it, drive there, and that’s it. So I’ve been rebuilding it into RallyLab. The idea is simple: put your phone on the bench and let it listen to your match. Instead of recording the match, the new app -RallyLab- just detects racket hits and the words you say like serves etc to detect who got the point. The audio gets processed 128 samples at a time and immediately overwritten, so there is no recording or audio file. I am going to spend more time on this and make it a full on product people can use.", "repo": "https://github.com/Coder-13-11/PickleWatch", "demo": "https://pickle-watch.vercel.app"}, {"ship_num": 2, "ts": "2026-07-10T15:13:48Z", "hours": 7.0, "multiplier": 8.97, "payout": 62, "blessing": "neutral", "text": "PickleWatch, an App for Pickleball Athletes So basically the problem is there’s like 8 pickleball courts around Tampa and you never know which ones are actually free or if they’re packed until you drive there and it’s a whole thing. So I made an app that tells you before you leave your house. It’s a website (kinda like an app, you can add it to your home screen) that shows all 8 courts and how busy each one probably is right now. It’s not just guessing randomly either — I made it learn the normal pattern for each court (like Northlakes gets crazy busy around 6pm on weekdays but High 5 is more of a lunchtime thing) and then it mixes that with actual people checking in. Like if you show up and tap “I’m here” and say how busy it is, that updates everyone’s app in real time for like 90 minutes and then it fades away. The real time part is honestly the coolest part, I used this thing called Supabase which is like a free database that can push updates instantly. I tested it by opening two browser windows side by side and checking in on one and watching it show up on the other one immediately, no refreshing or anything. Other stuff it does: Rally button — pick a time and it makes a message you can send to your group chat on WhatsApp asking who wants to play Polls — like if people can’t decide where to play you make a poll and everyone votes and you can see it update live Friends — add your friends and it’ll show you when they check in somewhere, plus little avatar bubbles showing who’s at a court right now No login or password or anything, you just type your name once and that’s it. Didn’t want to deal with accounts for something this small. Everything’s free too — Supabase has a free plan and I’m hosting it on Vercel which is also free, so it’s not costing me anything to run.", "repo": "https://github.com/Coder-13-11/PickleWatch", "demo": "https://pickle-watch.vercel.app"}]...
|
[{"post_id": 79042, "ts": "202 [{"post_id": 79042, "ts": "2026-10-12T14:04:26Z", "hours": 0.45, "text": "Update: fixed bugs and improved the sound detection algorithm so it accurately captures the hits, I am still wondering on how to make this really accurate so any suggestions would be helpful."}, {"post_id": 65180, "ts": "2026-09-10T03:56:43Z", "hours": 15.4464, "text": "🟢 Quick Update on Picklewatch 🟢. I updated it to now RallyLab. I did this because initially i had an app to find open pickleball courts near me in Tampa. It worked, but I realized you really only use a court finder once. You check it, drive there, and that’s it. So I’ve been rebuilding it into RallyLab. The idea is simple: put your phone on the bench and let it listen to your match. Instead of recording the match, the new app -RallyLab- just detects racket hits and the words you say like serves etc to detect who got the point. The audio gets processed 128 samples at a time and immediately overwritten, so there is no recording or audio file. The hit detector is working pretty well now. I tested it with simulated gym noise, talking, shoe squeaks, and another court playing nearby, and 9/11 conditions got an F1 of at least 0.93. I also added badminton, tennis, pickleball, squash, and table tennis, along with their different scoring rules. There are also 393 tests passing. The biggest thing I’m working on now is automatic score tracking. I originally planned to have players tap who won each rally, but nobody is going to do that during a game. Since players already say the score out loud, I’m using that instead. Speech recognition by itself is only around 73% accurate, but because there are only a few legal scores that can follow each score, an HMM + Viterbi decoder can bring that up to around 96–100%. I said its almost ready but I am trying to make it realible for an athlete to trust. Then I found a weird problem. The server’s score is always said first, so the microphone can know the score is 5-3 but can’t know which team is serving. That leaves two possibilities at exactly 50/50. I’m working on speaker ID now, but I’m using it as a probability instead of a hard rule so one mistake doesn’t ruin everything. Next is getting the score system into the UI, finishing speaker ID, figuring out the iOS audio situation, and testing it in a real gym. So far all my testing has been simulated. If it can’t handle six courts playing at once, then I have a much bigger problem. Maybe in the future, once i get the grant from hackclub to buy a licence for playstore, the app might fucntion more efficiently than a web app."}, {"post_id": 44219, "ts": "2026-08-09T20:42:41Z", "hours": 5.1753, "text": "Revamped the UI, check it out!"}, {"post_id": 32595, "ts": "2026-07-21T21:27:26Z", "hours": 6.0836, "text": "Fixed and Patched Bugs in PickleWatch!"}, {"post_id": 25968, "ts": "2026-07-10T14:41:36Z", "hours": 7.2303, "text": "Love Pickleball?? Check this out! I just made an app that tracks nearby pickleball courts and estimates how many people are on them, so the user can save time and play more efficiently when they get there. I have also created a feature for polls and for adding your crew to the friends list, so you can decide when to play the sport at your convenience. Please take a look at my screenshots below"}]...
|
Title: PickleWatch by @karthikeya | Stardance
Dev Title: PickleWatch by @karthikeya | Stardance
Devlogs:
Love Pickleball?? Check this out! I just made an app that tracks nearby pickleball courts and estimates how many people are on them, so the user can save time and play more efficiently when they get there. I have also created a feature for polls and for adding your crew to the friends list, so you can decide when to play the sport at your convenience. Please take a look at my screenshots below
Fixed and Patched Bugs in PickleWatch!
Revamped the UI, check it out!
🟢 Quick Update on Picklewatch 🟢. I updated it to now RallyLab. I did this because initially i had an app to find open pickleball courts near me in Tampa. It worked, but I realized you really only use a court finder once. You check it, drive there, and that’s it. So I’ve been rebuilding it into RallyLab. The idea is simple: put your phone on the bench and let it listen to your match. Instead of recording the match, the new app -RallyLab- just detects racket hits and the words you say like serves etc to detect who got the point. The audio gets processed 128 samples at a time and immediately overwritten, so there is no recording or audio file. The hit detector is working pretty well now. I tested it with simulated gym noise, talking, shoe squeaks, and another court playing nearby, and 9/11 conditions got an F1 of at least 0.93. I also added badminton, tennis, pickleball, squash, and table tennis, along with their different scoring rules. There are also 393 tests passing. The biggest thing I’m working on now is automatic score tracking. I originally planned to have players tap who won each rally, but nobody is going to do that during a game. Since players already say the score out loud, I’m using that instead. Speech recognition by itself is only around 73% accurate, but because there are only a few legal scores that can follow each score, an HMM + Viterbi decoder can bring that up to around 96–100%. I said its almost ready but I am trying to make it realible for an athlete to trust. Then I found a weird problem. The server’s score is always said first, so the microphone can know the score is 5-3 but can’t know which team is serving. That leaves two possibilities at exactly 50/50. I’m working on speaker ID now, but I’m using it as a probability instead of a hard rule so one mistake doesn’t ruin everything. Next is getting the score system into the UI, finishing speaker ID, figuring out the iOS audio situation, and testing it in a real gym. So far all my testing has been simulated. If it can’t handle six courts playing at once, then I have a much bigger problem. Maybe in the future, once i get the grant from hackclub to buy a licence for playstore, the app might fucntion more efficiently than a web app.
Update: fixed bugs and improved the sound detection algorithm so it accurately captures the hits, I am still wondering on how to make this really accurate so any suggestions would be helpful.
Ships:
PickleWatch, an App for Pickleball Athletes So basically the problem is there’s like 8 pickleball courts around Tampa and you never know which ones are actually free or if they’re packed until you drive there and it’s a whole thing. So I made an app that tells you before you leave your house. It’s a website (kinda like an app, you can add it to your home screen) that shows all 8 courts and how busy each one probably is right now. It’s not just guessing randomly either — I made it learn the normal pattern for each court (like Northlakes gets crazy busy around 6pm on weekdays but High 5 is more of a lunchtime thing) and then it mixes that with actual people checking in. Like if you show up and tap “I’m here” and say how busy it is, that updates everyone’s app in real time for like 90 minutes and then it fades away. The real time part is honestly the coolest part, I used this thing called Supabase which is like a free database that can push updates instantly. I tested it by opening two browser windows side by side and checking in on one and watching it show up on the other one immediately, no refreshing or anything. Other stuff it does: Rally button — pick a time and it makes a message you can send to your group chat on WhatsApp asking who wants to play Polls — like if people can’t decide where to play you make a poll and everyone votes and you can see it update live Friends — add your friends and it’ll show you when they check in somewhere, plus little avatar bubbles showing who’s at a court right now No login or password or anything, you just type your name once and that’s it. Didn’t want to deal with accounts for something this small. Everything’s free too — Supabase has a free plan and I’m hosting it on Vercel which is also free, so it’s not costing me anything to run.
I updated it to now RallyLab. I did this because initially i had an app to find open pickleball courts near me in Tampa. It worked, but I realized you really only use a court finder once. You check it, drive there, and that’s it. So I’ve been rebuilding it into RallyLab. The idea is simple: put your phone on the bench and let it listen to your match. Instead of recording the match, the new app -RallyLab- just detects racket hits and the words you say like serves etc to detect who got the point. The audio gets processed 128 samples at a time and immediately overwritten, so there is no recording or audio file. I am going to spend more time on this and make it a full on product people can use....
|
1793105695.0294683
|
1793192095.0294683
|
|
67117
|
A low power pocket calendar by @MJMorris | Stardan A low power pocket calendar by @MJMorris | Stardance...
|
MJMorris
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: A low power pocket calendar by @MJMorris | Title: A low power pocket calendar by @MJMorris | Stardance...
|
1793105696.1684153
|
1793710496.1684153
|
|
57434
|
My first slack bot! by @skyskysun | Stardance
|
skyskysun
|
1
|
0.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-09-06T01:35:30Z", "hours": 0.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I made first slack bot. Pretty easy, as i have not added any fun commands and just sticked with the basic bots, as I am working on the hackpad most of the time and got no time for the slack bot.", "repo": "https://github.com/RealSkyskysun/skybot1slack", "demo": "https://app.slack.com/client/E09V59WQY1E/C0P5NE354"}]...
|
[{"post_id": 61364, "ts": "202 [{"post_id": 61364, "ts": "2026-09-04T07:33:07Z", "hours": 0.3117, "text": "Setting up the basic slackbot, just started stardance, hope everything goes well"}]...
|
Title: My first slack bot! by @skyskysun | Stardan Title: My first slack bot! by @skyskysun | Stardance
Devlogs:
Setting up the basic slackbot, just started stardance, hope everything goes well
Ships:
I made first slack bot. Pretty easy, as i have not added any fun commands and just sticked with the basic bots, as I am working on the hackpad most of the time and got no time for the slack bot....
|
1793105697.038757
|
1793192097.038757
|
|
67118
|
Alarm Clock by @jovanovicv529 | Stardance
|
jovanovicv529
|
0
|
2.34
|
0
|
[]
|
[{"post_id": 76173, "ts": "202 [{"post_id": 76173, "ts": "2026-10-02T15:59:08Z", "hours": 1.455, "text": "Done with the case! Switched to fusion since I know it better"}, {"post_id": 75735, "ts": "2026-09-30T21:52:16Z", "hours": 0.8889, "text": "Done with the pcb for now, I’ll probably add some more components later. I know KiCAD a lot better since the last project."}]...
|
Title: Alarm Clock by @jovanovicv529 | Stardance
Title: Alarm Clock by @jovanovicv529 | Stardance
Devlogs:
Done with the pcb for now, I’ll probably add some more components later. I know KiCAD a lot better since the last project.
Done with the case! Switched to fusion since I know it better...
|
1793105697.925749
|
1793710497.925749
|
|
31183
|
Wrapped by @advayc | Stardance
|
advayc
|
1
|
2.81
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-08T22:23:13Z", "hours": 2.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "i built spotify wrapped but for your imsg data. by running a curl command in your terminal, itll open a website for you to view your imessage data from either the past year or in total. the most challenging part was honestly uiux of the website, as well as making sure it works properly without golang, installed. i think im post proud of the system to scrape the data from the files on your mac computer. to test it out have to be on macos and might need golang installed.", "repo": "https://github.com/advayc/wrapped", "demo": "https://github.com/advayc/wrapped/releases/tag/v1.0.0"}]...
|
[{"post_id": 35650, "ts": "202 [{"post_id": 35650, "ts": "2026-07-27T07:10:44Z", "hours": 0.8139, "text": "make executable"}, {"post_id": 25007, "ts": "2026-07-08T22:20:23Z", "hours": 1.0931, "text": "UIUX polish and rewrite the readme, git commits are lowk all over the place though"}, {"post_id": 23332, "ts": "2026-07-06T06:53:20Z", "hours": 0.4006, "text": "bug fixes, running opencode agent to fix an issue with msg data scraping (getting the wrong number)"}, {"post_id": 23325, "ts": "2026-07-06T06:26:27Z", "hours": 1.0044, "text": "built it out fully inspired off a seperate script i saw online in python. but i figured it would be cool if i could build it out in go, how it works: run one curl command in your terminal it uses go run under the hood, so nothing is saved the script reads your ~/Library/Messages/chat.db + Address Book contacts to resolve names pick a timeframe via then it analyzes everything, the total messages, reply times, streaks, double texts, etc builds a self-contained HTML slideshow using scraped data"}]...
|
Title: Wrapped by @advayc | Stardance
Devlogs:
bu Title: Wrapped by @advayc | Stardance
Devlogs:
built it out fully inspired off a seperate script i saw online in python. but i figured it would be cool if i could build it out in go, how it works: run one curl command in your terminal it uses go run under the hood, so nothing is saved the script reads your ~/Library/Messages/chat.db + Address Book contacts to resolve names pick a timeframe via then it analyzes everything, the total messages, reply times, streaks, double texts, etc builds a self-contained HTML slideshow using scraped data
bug fixes, running opencode agent to fix an issue with msg data scraping (getting the wrong number)
UIUX polish and rewrite the readme, git commits are lowk all over the place though
make executable
Ships:
i built spotify wrapped but for your imsg data. by running a curl command in your terminal, itll open a website for you to view your imessage data from either the past year or in total. the most challenging part was honestly uiux of the website, as well as making sure it works properly without golang, installed. i think im post proud of the system to scrape the data from the files on your mac computer. to test it out have to be on macos and might need golang installed....
|
1793105698.7722757
|
1793192098.7722757
|
|
9826
|
Anything AI by @THEbluefirestudios | Stardance
|
THEbluefirestudios
|
1
|
5.0
|
46
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-11T13:39:14Z", "hours": 5.0, "multiplier": 9.67, "payout": 46, "blessing": "neutral", "text": "An LLM wrapper that uses multiple open source AIs to make something that is as good as big AI like Claude, and ChatGPT", "repo": "https://github.com/THEbluefirestudios/anything-ai", "demo": "https://github.com/THEbluefirestudios/anything-ai/releases"}]...
|
[{"post_id": 6166, "ts": "2026 [{"post_id": 6166, "ts": "2026-06-10T11:30:10Z", "hours": 1.5317, "text": "Damn man…. so much for adding chat history and long term memory…. Today I spent 1 and a half hours adding them, the memory is stored in Anything AI\\memory and chats are stored in Anything AI\\chats . I also switched the sorter AI to deepseek-ai/DeepSeek-R1-Distill-Llama-70B coz llama was hallucinating a LOT, ill be releasing another beta soon….."}, {"post_id": 5522, "ts": "2026-06-09T10:24:06Z", "hours": 1.0064, "text": "I’m regretting making a TUI instead of a GUI. I made it so because i wanted to save time and focus on the important stuff, and cause i was lazy, but it turned out to be a mistake. Today I spent nearly an hour trying to fix terminal formatting issues like shown in the attached screenshot (sorry for low resolution) , it got so bad that I just ended making my own input() function instead. Truly an experience, anyways, Anything has entered beta! The full proper official ship will come soon!"}, {"post_id": 4827, "ts": "2026-06-08T10:42:23Z", "hours": 0.6256, "text": "Now I have created the logo for Anything AI, so it will be definitely out soon! I hope this project gets high ratings! Lapse: https://lapse.hackclub.com/timelapse/kOucepr-Hpub"}, {"post_id": 4808, "ts": "2026-06-08T09:52:08Z", "hours": 0.4364, "text": "YESS, attach file works! It currently supports .txt, .csv, .docx, .pptx, .xlsx and code files like .py, .kt, .java, .cpp and, obviously image files, the ones supported by PIL :). Anything AI will be finished soon!"}, {"post_id": 4792, "ts": "2026-06-08T09:00:53Z", "hours": 0.6258, "text": "Today I’m working on adding more modalities to my AI, more specifically, giving it the ability to read text, documents and code files alongside the already implemented image file. To do this I’m migrating from pick_image_file() to just pick_file() As of now, the pick_file() function is done and i need to add functions for parsing the returned filepath to data the AI can read. I also ran out of free credits on Hugging Face so i created an extra account. :("}, {"post_id": 4139, "ts": "2026-06-07T10:35:45Z", "hours": 0.3117, "text": "OK, so terminal commands work! I also fixed the jank bug that caused issues with displaying text after addingf an image to a prompt. Things seem to be going well! I’m gonna make myself a bowl of maggi now >. <"}, {"post_id": 4122, "ts": "2026-06-07T09:55:20Z", "hours": 0.3342, "text": "Ok so, I know this is a project I started before Stardance on May 25 2026 and have worked for hours on this, and its almost ship ready, I’ve added everything I want like multimodal input, file generation, etc. As of now, I’m giving it the ability to run terminal commands and do some bugfixing before shipping it as an .exe"}]...
|
Title: Anything AI by @THEbluefirestudios | Starda Title: Anything AI by @THEbluefirestudios | Stardance
Devlogs:
Ok so, I know this is a project I started before Stardance on May 25 2026 and have worked for hours on this, and its almost ship ready, I’ve added everything I want like multimodal input, file generation, etc. As of now, I’m giving it the ability to run terminal commands and do some bugfixing before shipping it as an .exe
OK, so terminal commands work! I also fixed the jank bug that caused issues with displaying text after addingf an image to a prompt. Things seem to be going well! I’m gonna make myself a bowl of maggi now >. <
Today I’m working on adding more modalities to my AI, more specifically, giving it the ability to read text, documents and code files alongside the already implemented image file. To do this I’m migrating from pick_image_file() to just pick_file() As of now, the pick_file() function is done and i need to add functions for parsing the returned filepath to data the AI can read. I also ran out of free credits on Hugging Face so i created an extra account. :(
YESS, attach file works! It currently supports .txt, .csv, .docx, .pptx, .xlsx and code files like .py, .kt, .java, .cpp and, obviously image files, the ones supported by PIL :). Anything AI will be finished soon!
Now I have created the logo for Anything AI, so it will be definitely out soon! I hope this project gets high ratings! Lapse: https://lapse.hackclub.com/timelapse/kOucepr-Hpub
I’m regretting making a TUI instead of a GUI. I made it so because i wanted to save time and focus on the important stuff, and cause i was lazy, but it turned out to be a mistake. Today I spent nearly an hour trying to fix terminal formatting issues like shown in the attached screenshot (sorry for low resolution) , it got so bad that I just ended making my own input() function instead. Truly an experience, anyways, Anything has entered beta! The full proper official ship will come soon!
Damn man…. so much for adding chat history and long term memory…. Today I spent 1 and a half hours adding them, the memory is stored in Anything AI\memory and chats are stored in Anything AI\chats . I also switched the sorter AI to deepseek-ai/DeepSeek-R1-Distill-Llama-70B coz llama was hallucinating a LOT, ill be releasing another beta soon…..
Ships:
An LLM wrapper that uses multiple open source AIs to make something that is as good as big AI like Claude, and ChatGPT...
|
1793105699.6747031
|
1793192099.6747031
|
|
36016
|
My very own WebOS by @RajanKC | Stardance
|
RajanKC
|
2
|
17.0
|
72
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-08-07T17:15:25Z", "hours": 14.0, "multiplier": 5.0, "payout": 72, "blessing": "neutral", "text": "OS-Web is a lightweight, open-source web operating system built with HTML, CSS, and JavaScript. It brings a desktop-style experience to your browser with apps, a taskbar, and a simple interface that you can explore, customize, and improve.", "repo": "https://github.com/RajanKCKC/OSWeb", "demo": "https://rajankckc.github.io/OSWeb/"}, {"ship_num": 2, "ts": "2026-07-20T16:04:47Z", "hours": 3.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "Shipped WebOS. Built a basic browser desktop clone with HTML, CSS, and JS. It has a taskbar, a welcome window, windows you can drag around with working close buttons, and a simple notes app that opens when clicked.", "repo": "https://github.com/RajanKCKC/OSWeb", "demo": "https://rajankckc.github.io/OSWeb/"}]...
|
[{"post_id": 42760, "ts": "202 [{"post_id": 42760, "ts": "2026-08-07T17:14:29Z", "hours": 1.3003, "text": "Add Password Strength Meter app with UI, functionality, and integrate into main interface"}, {"post_id": 42077, "ts": "2026-08-06T17:12:25Z", "hours": 1.4725, "text": "Add Github User Finder app with UI, functionality, and integrate into main interface"}, {"post_id": 41382, "ts": "2026-08-05T15:43:36Z", "hours": 0.6836, "text": "Add QR Code Generator app with UI, functionality, and integrate into main interface"}, {"post_id": 40757, "ts": "2026-08-04T14:28:26Z", "hours": 1.1311, "text": "Add Tic Tac Toe app with UI, functionality, and integrate into main interface"}, {"post_id": 40211, "ts": "2026-08-03T16:49:51Z", "hours": 1.1114, "text": "Add ToDo app with UI, functionality, and integrate into main interface"}, {"post_id": 39521, "ts": "2026-08-02T15:07:58Z", "hours": 0.6947, "text": "Add Quiz app with UI, functionality, and integrate into main interface"}, {"post_id": 38986, "ts": "2026-08-01T16:44:01Z", "hours": 0.6003, "text": "Add Map app with UI, functionality, and integrate into main interface"}, {"post_id": 38296, "ts": "2026-07-31T16:45:57Z", "hours": 0.5333, "text": "Add Notes app with UI and integrate into main interface"}, {"post_id": 37658, "ts": "2026-07-30T15:28:48Z", "hours": 1.0669, "text": "Add Calendar app with UI, functionality, and integrate into main interface"}, {"post_id": 37116, "ts": "2026-07-29T16:30:18Z", "hours": 1.4522, "text": "Add Calculator, Paint app, and Welcome page with associated styles and functionality"}, {"post_id": 36450, "ts": "2026-07-28T16:05:34Z", "hours": 0.7019, "text": "Add Paint app with UI elements and window controls"}, {"post_id": 35564, "ts": "2026-07-27T02:56:29Z", "hours": 0.4669, "text": "Add welcome page and style adjustments for improved layout"}, {"post_id": 35318, "ts": "2026-07-26T17:14:11Z", "hours": 0.4792, "text": "Add Google app functionality with UI elements and window controls"}, {"post_id": 34668, "ts": "2026-07-25T16:03:57Z", "hours": 0.5169, "text": "Fix minimize button IDs for Notes and Solitaire, and implement taskbar item management"}, {"post_id": 34124, "ts": "2026-07-24T16:48:43Z", "hours": 0.3206, "text": "Add minimize functionality to Notes, Minecraft, and Solitaire windows"}, {"post_id": 33446, "ts": "2026-07-23T12:27:23Z", "hours": 0.9111, "text": "Implement maximize functionality for app windows and update styles"}, {"post_id": 33062, "ts": "2026-07-22T17:11:41Z", "hours": 0.3669, "text": "Add Solitaire app functionality with UI elements and window controls"}, {"post_id": 32436, "ts": "2026-07-21T16:45:42Z", "hours": 0.5339, "text": "Add Minecraft app icon and window functionality with styles"}, {"post_id": 31856, "ts": "2026-07-20T15:59:49Z", "hours": 0.7336, "text": "Update README, enhance UI, and improve functionality"}, {"post_id": 31326, "ts": "2026-07-19T16:58:18Z", "hours": 1.2972, "text": "Add Notes app functionality with UI elements and styles"}, {"post_id": 30614, "ts": "2026-07-18T10:26:52Z", "hours": 0.7039, "text": "Added Draggable windows and Window Control buttons"}, {"post_id": 30144, "ts": "2026-07-17T14:14:23Z", "hours": 0.3836, "text": "Added Task bar and window"}, {"post_id": 29931, "ts": "2026-07-17T03:17:13Z", "hours": 0.3103, "text": "Added Welcome screen"}]...
|
Title: My very own WebOS by @RajanKC | Stardance
Title: My very own WebOS by @RajanKC | Stardance
Devlogs:
Added Welcome screen
Added Task bar and window
Added Draggable windows and Window Control buttons
Add Notes app functionality with UI elements and styles
Update README, enhance UI, and improve functionality
Add Minecraft app icon and window functionality with styles
Add Solitaire app functionality with UI elements and window controls
Implement maximize functionality for app windows and update styles
Add minimize functionality to Notes, Minecraft, and Solitaire windows
Fix minimize button IDs for Notes and Solitaire, and implement taskbar item management
Add Google app functionality with UI elements and window controls
Add welcome page and style adjustments for improved layout
Add Paint app with UI elements and window controls
Add Calculator, Paint app, and Welcome page with associated styles and functionality
Add Calendar app with UI, functionality, and integrate into main interface
Add Notes app with UI and integrate into main interface
Add Map app with UI, functionality, and integrate into main interface
Add Quiz app with UI, functionality, and integrate into main interface
Add ToDo app with UI, functionality, and integrate into main interface
Add Tic Tac Toe app with UI, functionality, and integrate into main interface
Add QR Code Generator app with UI, functionality, and integrate into main interface
Add Github User Finder app with UI, functionality, and integrate into main interface
Add Password Strength Meter app with UI, functionality, and integrate into main interface
Ships:
Shipped WebOS. Built a basic browser desktop clone with HTML, CSS, and JS. It has a taskbar, a welcome window, windows you can drag around with working close buttons, and a simple notes app that opens when clicked.
OS-Web is a lightweight, open-source web operating system built with HTML, CSS, and JavaScript. It brings a desktop-style experience to your browser with apps, a taskbar, and a simple interface that you can explore, customize, and improve....
|
1793105700.798776
|
1793192100.798776
|
|
19371
|
Planetarium by @The_Craw | Stardance
|
The_Craw
|
1
|
2.44
|
29
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-16T10:24:58Z", "hours": 2.0, "multiplier": 12.05, "payout": 29, "blessing": "neutral", "text": "A custom-made leaderboard, made with my own unofficial stardance API system. Tracks projects over time, for followers, time used, and devlogs. This project is confirmed to have been used by the Fraud Squad to catch users who have faked their time.", "repo": "https://github.com/Jonah-Crawford/Planetarium", "demo": "https://planetarium.ultimatecraw.xyz/"}]...
|
[{"post_id": 16815, "ts": "202 [{"post_id": 16815, "ts": "2026-06-27T09:33:43Z", "hours": 0.4414, "text": "Simple additions like adding a ‘super star’ column to track exceptional projects have been added. The webpage is still quite slow though 😅"}, {"post_id": 9866, "ts": "2026-06-16T10:12:57Z", "hours": 1.335, "text": "Final devlog, shipping as the basic leaderboard is done!"}, {"post_id": 9828, "ts": "2026-06-16T08:42:16Z", "hours": 0.6761, "text": "I’m not going to lie, ChatGPT did the CSS because I don’t know how to. This is why it looks vibecoded, which makes it stinky. I apologise."}, {"post_id": 9495, "ts": "2026-06-15T20:56:36Z", "hours": 0.3767, "text": "Did someone say new leaderboard? That’s right, Craw’s Stardance Leaderboard now works with Craw’s Stardance API! This leaderboard updates every 6 hours, rather than every week, and can show history data! Want to see the fastest growing projects? Easy peasy with Planetarium."}]...
|
Title: Planetarium by @The_Craw | Stardance
Devlo Title: Planetarium by @The_Craw | Stardance
Devlogs:
Did someone say new leaderboard? That’s right, Craw’s Stardance Leaderboard now works with Craw’s Stardance API! This leaderboard updates every 6 hours, rather than every week, and can show history data! Want to see the fastest growing projects? Easy peasy with Planetarium.
I’m not going to lie, ChatGPT did the CSS because I don’t know how to. This is why it looks vibecoded, which makes it stinky. I apologise.
Final devlog, shipping as the basic leaderboard is done!
Simple additions like adding a ‘super star’ column to track exceptional projects have been added. The webpage is still quite slow though 😅
Ships:
A custom-made leaderboard, made with my own unofficial stardance API system. Tracks projects over time, for followers, time used, and devlogs. This project is confirmed to have been used by the Fraud Squad to catch users who have faked their time....
|
1793105702.040497
|
1793192102.040497
|
|
67119
|
My awesome macropad! by @shaishav2908 | Stardance
|
shaishav2908
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My awesome macropad! by @shaishav2908 | Sta Title: My awesome macropad! by @shaishav2908 | Stardance...
|
1793105702.9415386
|
1793710502.9415386
|
|
67121
|
AI STUDY BUDDY by @Millicentkudawoo | Stardance
|
Millicentkudawoo
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: AI STUDY BUDDY by @Millicentkudawoo | Stard Title: AI STUDY BUDDY by @Millicentkudawoo | Stardance...
|
1793105705.1418996
|
1793710505.1418996
|
|
5038
|
AI Slack bot by @YoussefTech | Stardance
|
YoussefTech
|
1
|
1.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-03T15:16:02Z", "hours": 1.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I made an AI assistant slack bot that you can use for free, it uses the HackClub AI API. To test it out, go to any channel on the HackClub slack workspace and type /asb-ask to prompt the AI, it will take a sec to respond, just give it some time 😁. Available commands: /asb-ping - Check if the bot is working and the latency /asb-joke - Fetch a random joke from the Official Joke API /asb-calc [expression] - Calculate a mathematical expression /asb-ask [question] - Ask the AI a question /asb-whoami - Info about the bot and its developer /asb-quote - Random quote", "repo": "https://github.com/yousseftechdev/AISlackBot", "demo": "https://hackclub.slack.com/archives/C0B8W2LQYD8/p1780861946621539"}]...
|
[{"post_id": 1481, "ts": "2026 [{"post_id": 1481, "ts": "2026-06-03T15:06:54Z", "hours": 0.3664, "text": "Added /asb-whoami command that prints info about the bot and its developer Added /asb-quote command to print a random quote Updated README.md"}, {"post_id": 1395, "ts": "2026-06-03T12:32:18Z", "hours": 0.3936, "text": "Well adding the AI part was easy, I used the HackClub AI API, I picked a free model because I don’t want every user of the bot to input their own API key, though that might be a cool idea for later updates, I placed a system instruction in the beginning of the prompt explaining to the AI model that it’s a slack bot so it doesn’t try to use tables or fancy formatting: SYSTEM INSTRUCTION: You are a slack bot, so follow slack formatting rules and markdown conventions when responding, no tables. The bot is now up and running and I’m trying to find extra features to add to increase the time on this project"}, {"post_id": 1382, "ts": "2026-06-03T11:44:19Z", "hours": 0.5392, "text": "Just finished the guide for the “Make a Slack Bot” mission, I liked it, but i feel like it was too easy, the guide said 1.5h but it only took me 20 minutes for the code and 10 minutes to make it live 24/7 on the Nest container"}]...
|
Title: AI Slack bot by @YoussefTech | Stardance
D Title: AI Slack bot by @YoussefTech | Stardance
Devlogs:
Just finished the guide for the “Make a Slack Bot” mission, I liked it, but i feel like it was too easy, the guide said 1.5h but it only took me 20 minutes for the code and 10 minutes to make it live 24/7 on the Nest container
Well adding the AI part was easy, I used the HackClub AI API, I picked a free model because I don’t want every user of the bot to input their own API key, though that might be a cool idea for later updates, I placed a system instruction in the beginning of the prompt explaining to the AI model that it’s a slack bot so it doesn’t try to use tables or fancy formatting: SYSTEM INSTRUCTION: You are a slack bot, so follow slack formatting rules and markdown conventions when responding, no tables. The bot is now up and running and I’m trying to find extra features to add to increase the time on this project
Added /asb-whoami command that prints info about the bot and its developer Added /asb-quote command to print a random quote Updated README.md
Ships:
I made an AI assistant slack bot that you can use for free, it uses the HackClub AI API. To test it out, go to any channel on the HackClub slack workspace and type /asb-ask to prompt the AI, it will take a sec to respond, just give it some time 😁. Available commands: /asb-ping - Check if the bot is working and the latency /asb-joke - Fetch a random joke from the Official Joke API /asb-calc [expression] - Calculate a mathematical expression /asb-ask [question] - Ask the AI a question /asb-whoami - Info about the bot and its developer /asb-quote - Random quote...
|
1793105705.9930873
|
1793192105.9930873
|
|
67122
|
StarQuest by @ByAman_Dev | Stardance
|
ByAman_Dev
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: StarQuest by @ByAman_Dev | Stardance
|
1793105707.1554081
|
1793710507.1554081
|
|
38297
|
pear-agent by @aomona | Stardance
|
aomona
|
1
|
12.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-22T12:48:44Z", "hours": 12.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I built PEAR Agent, a framework for creating agents that plan tasks, wait for human approval, execute them, and replan when something changes. The most challenging part was designing a system that could support different use cases while keeping the workflow predictable and safe. I am proud that the original idea has become a working, documented framework that is now ready for beta testing. To test it, visit the GitHub repository, follow the setup instructions in the documentation, and run one of the example applications. It is still in beta, so there may be some small bugs or rough edges.", "repo": "https://github.com/aomona/pear-agent", "demo": "https://pear-agent.aomona.me/"}]...
|
[{"post_id": 32935, "ts": "202 [{"post_id": 32935, "ts": "2026-07-22T12:37:31Z", "hours": 12.0619, "text": "Most of the features I wanted for PEAR Agent are now complete. It is ready for a beta release, and I have also finished the main documentation. From here, I will focus on fixing small bugs and improving the overall polish."}]...
|
Title: pear-agent by @aomona | Stardance
Devlogs: Title: pear-agent by @aomona | Stardance
Devlogs:
Most of the features I wanted for PEAR Agent are now complete. It is ready for a beta release, and I have also finished the main documentation. From here, I will focus on fixing small bugs and improving the overall polish.
Ships:
I built PEAR Agent, a framework for creating agents that plan tasks, wait for human approval, execute them, and replan when something changes. The most challenging part was designing a system that could support different use cases while keeping the workflow predictable and safe. I am proud that the original idea has become a working, documented framework that is now ready for beta testing. To test it, visit the GitHub repository, follow the setup instructions in the documentation, and run one of the example applications. It is still in beta, so there may be some small bugs or rough edges....
|
1793105707.9983454
|
1793192107.9983454
|
|
67123
|
My own site! by @blue_pumpkin | Stardance
|
blue_pumpkin
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My own site! by @blue_pumpkin | Stardance
|
1793105708.8751805
|
1793710508.8751805
|
|
39241
|
My own site! by @ArtemD | Stardance
|
ArtemD
|
1
|
3.43
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-26T02:00:17Z", "hours": 2.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I made my own, personal website. It started on 7.24.2026, when Jenin hosted a Hackatime + Personal Site Workshop. He walked me and everyone else in the workshop through the basics of making a website and we even built our own website! He told everyone to ship it that day but I decided not to, because I had an issue of the image not loading, and I just wanted to improve the website, to make it better. The next day I took all the knowledge I had and started building the website. I firstly changed the theme from orange and white to black and white to make the website look professional. Then, I fixed the issue of the image not loading by changing the scr method I used to src, which took me a long time to figure out, but was honestly a funny reason for the bug. Further, I extended the navigation bar, added a shadow to the image, changed the website’s main font to Georgia, added an answer for the question ‘why should you join Hack Club’, which I made, added a text box with a shadow to it, and a button which has a cool lift up animation when you hover over it, for which I have to credit another website called ‘ https://www.w3schools.com/css/ ’. Honestly, the most challenging part of building the whole thing was the button. I did use a website I already gave credit to for making the button, but it wasn’t as simple as just pasting in code. After I, again, pasted the code, I tried to load the button to my main html file, but it just would work. I tried using a button method and putting a class=“button” into it, but that did not seem to work. I then figured out to used div (by looking at how I constructed the navigation bar), but the button came out too wide. I tried to fix that by changing the width in the css file I believe, but then it got stuck to the left corner. And after many attempts of getting that button working, I finally gave up and just searched my problem online. And the solution was just writing 3 lines of code, which was about 10 times less than the lines of code I wrote trying to fix the issue myself. Another challenge I faced is making the shadows for the image and text box. Long story short, I basically did the same thing as with the button (try to solve the problem -> break my brain -> give up -> search up the solution -> be shocked of writing just a couple of lines of code), I additionally want to give credit to the same website I mentioned earlier for providing the methods needed to make the shadow. Interestingly, after I fixed the two issues, I began being able to fix other problems I had on the website myself, which made me just a little bit proud of myself. Speaking of being proud, I feel very, I mean extremely proud when I open the website and look at it. I just can’t believe I made that. In addition to feeling proud, I should mention that the hyperlinks named ‘Call’, ‘Text’, and ‘Message’ Hack Club do not work on desktops. I made those buttons throughout the workshop with Jenin, and he said that these buttons will function only on phones.", "repo": "https://github.com/artemplaygames247-rgb/my-personal-website", "demo": "https://artemplaygames247-rgb.github.io/my-personal-website/"}]...
|
[{"post_id": 41716, "ts": "202 [{"post_id": 41716, "ts": "2026-08-06T03:02:00Z", "hours": 1.4333, "text": "I fixed the website to follow all of the criteria. Here is specifically what I’ve implemented since the last devlog: All of the buttons and images (except links) now lift up when you hover over them using the scale() function Made the ‘Join Hack Club’ button move and rotate slightly when you hover over it, which looks very interesting honestly Changed the ‘Join Hack Club’ button’s settings to have sharp edges and a grey shadow, which is also sharp Created a dark-brown shadow for the ‘EXPERIENCE’ heading Removed the ‘Call Hack Club’, ‘Text Hack Club’ and ‘Message Hack Club’ buttons and implemented a working “Email Hack Club’s Support” button (I found the email on the official Hack Club website) Here is what I’m planning to do/have done/have in mind for the next version of my website: Build the ‘About me’, ‘Hack Club’ and some other buttons which redirect to other pages. The ‘Hack Club’ buttons will have the ‘Join Stardance’, ‘Programs of Hack Club’, ‘Join Stardance’, “Hack Club’s clubs” and “Email Hack Club’s support” hyperlinks inside that page. I am already drawing a blueprint for the pages and how will they look like. Craft a settings menu with options like ‘Music’ (On/Off), ‘Dark/White’ website’s theme and maybe other options that will come across my mind Notes: I am very happy about my website. I tried to be creative, and I’m sure I was this time. Additionally, I will look for errors and fix any that come on my path."}, {"post_id": 34920, "ts": "2026-07-26T00:43:58Z", "hours": 1.615, "text": "I improved my website by a lot. I changed the theme of the website from orange-yellow to black-white I made four sections in the navigation bar I added more hyperlinks I made a shadow for the F1 Ferrari car, and changed the image itself (The reason it would not load last time is because I used the scr function instead of the correct src one, and scr did not exist) I changed the description of the image to a more professional one, changing itself and its style I added a header and text which explains why should you join Hack Club, and used a text box, a new concept I made a ‘Join Hack Club’ button that looks cool when you hover over it. Credits to https://www.w3schools.com/css/ I literally love my website now. It looks modern, professional, neat, well structured, and many more adjectives.."}, {"post_id": 34216, "ts": "2026-07-24T18:49:42Z", "hours": 0.7319, "text": "I made a very simple website with the help Jenin - in the ‘Hackatime + Personal Site’ workshop. But the image I have doesn’t seem to load, and I overall think the website is too raw, so I’ll keep working on it. Here’s what I have on the website right now: Navigation bar Title Paragraphs Clickable hyperlinks Image Description for the image"}]...
|
Title: My own site! by @ArtemD | Stardance
Devlog Title: My own site! by @ArtemD | Stardance
Devlogs:
I made a very simple website with the help Jenin - in the ‘Hackatime + Personal Site’ workshop. But the image I have doesn’t seem to load, and I overall think the website is too raw, so I’ll keep working on it. Here’s what I have on the website right now: Navigation bar Title Paragraphs Clickable hyperlinks Image Description for the image
I improved my website by a lot. I changed the theme of the website from orange-yellow to black-white I made four sections in the navigation bar I added more hyperlinks I made a shadow for the F1 Ferrari car, and changed the image itself (The reason it would not load last time is because I used the scr function instead of the correct src one, and scr did not exist) I changed the description of the image to a more professional one, changing itself and its style I added a header and text which explains why should you join Hack Club, and used a text box, a new concept I made a ‘Join Hack Club’ button that looks cool when you hover over it. Credits to https://www.w3schools.com/css/ I literally love my website now. It looks modern, professional, neat, well structured, and many more adjectives..
I fixed the website to follow all of the criteria. Here is specifically what I’ve implemented since the last devlog: All of the buttons and images (except links) now lift up when you hover over them using the scale() function Made the ‘Join Hack Club’ button move and rotate slightly when you hover over it, which looks very interesting honestly Changed the ‘Join Hack Club’ button’s settings to have sharp edges and a grey shadow, which is also sharp Created a dark-brown shadow for the ‘EXPERIENCE’ heading Removed the ‘Call Hack Club’, ‘Text Hack Club’ and ‘Message Hack Club’ buttons and implemented a working “Email Hack Club’s Support” button (I found the email on the official Hack Club website) Here is what I’m planning to do/have done/have in mind for the next version of my website: Build the ‘About me’, ‘Hack Club’ and some other buttons which redirect to other pages. The ‘Hack Club’ buttons will have the ‘Join Stardance’, ‘Programs of Hack Club’, ‘Join Stardance’, “Hack Club’s clubs” and “Email Hack Club’s support” hyperlinks inside that page. I am already drawing a blueprint for the pages and how will they look like. Craft a settings menu with options like ‘Music’ (On/Off), ‘Dark/White’ website’s theme and maybe other options that will come across my mind Notes: I am very happy about my website. I tried to be creative, and I’m sure I was this time. Additionally, I will look for errors and fix any that come on my path.
Ships:
I made my own, personal website. It started on 7.24.2026, when Jenin hosted a Hackatime + Personal Site Workshop. He walked me and everyone else in the workshop through the basics of making a website and we even built our own website! He told everyone to ship it that day but I decided not to, because I had an issue of the image not loading, and I just wanted to improve the website, to make it better. The next day I took all the knowledge I had and started building the website. I firstly changed the theme from orange and white to black and white to make the website look professional. Then, I fixed the issue of the image not loading by changing the scr method I used to src, which took me a long time to figure out, but was honestly a funny reason for the bug. Further, I extended the navigation bar, added a shadow to the image, changed the website’s main font to Georgia, added an answer for the question ‘why should you join Hack Club’, which I made, added a text box with a shadow to it, and a button which has a cool lift up animation when you hover over it, for which I have to credit another website called ‘ https://www.w3schools.com/css/ ’. Honestly, the most challenging part of building the whole thing was the button. I did use a website I already gave credit to for making the button, but it wasn’t as simple as just pasting in code. After I, again, pasted the code, I tried to load the button to my main html file, but it just would work. I tried using a button method and putting a class=“button” into it, but that did not seem to work. I then figured out to used div (by looking at how I constructed the navigation bar), but the button came out too wide. I tried to fix that by changing the width in the css file I believe, but then it got stuck to the left corner. And after many attempts of getting that button working, I finally gave up and just searched my problem online. And the solution was just writing 3 lines of code, which was about 10 times less than the lines of code I wrote trying to fix the issue myself. Another challenge I faced is making the shadows for the image and text box. Long story short, I basically did the same thing as with the button (try to solve the problem -> break my brain -> give up -> search up the solution -> be shocked of writing just a couple of lines of code), I additionally want to give credit to the same website I mentioned earlier for providing the methods needed to make the shadow. Interestingly, after I fixed the two issues, I began being able to fix other problems I had on the website myself, which made me just a little bit proud of myself. Speaking of being proud, I feel very, I mean extremely proud when I open the website and look at it. I just can’t believe I made that. In addition to feeling proud, I should mention that the hyperlinks named ‘Call’, ‘Text’, and ‘Message’ Hack Club do not work on desktops. I made those buttons throughout the workshop with Jenin, and he said that these buttons will function only on phones....
|
1793105709.7381
|
1793192109.7381
|
|
67124
|
Untitled project by @Ilikebananasforever | Stardan Untitled project by @Ilikebananasforever | Stardance...
|
Ilikebananasforever
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Untitled project by @Ilikebananasforever | Title: Untitled project by @Ilikebananasforever | Stardance...
|
1793105710.8362389
|
1793710510.8362389
|
|
7750
|
Updato by @NellowTCS | Stardance
|
NellowTCS
|
1
|
5.0
|
78
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-06T04:27:18Z", "hours": 5.0, "multiplier": 14.89, "payout": 78, "blessing": "neutral", "text": "Updato is a decentralized update system for web apps. A GitHub Action publishes builds to a CDN branch, a Cloudflare Worker handles version checks, and a client library hot-swaps files in the browser with no reload. It’s on npm as @nellowtcs /updato. It works end to end. Push code, Action builds it, Worker picks it up, client swaps files live. No server, no database. Also there’s a live demo, a docs site, and a real npm package now. It became a real project somewhere along the way. CSS hot-swapping was a whole thing. Ended up using CSSStyleSheet.replaceSync with adoptedStyleSheets to make it work without flashing or breaking CSP. Also npm told me my package name was too similar to “upath” which is just not true but whatever, scoped it and moved on. The live demo ( https://nellowtcs.me/updato/ ) is a clock app that checks for updates from the Worker. You can also install it with npm i @nellowtcs/updato and the docs are at https://nellowtcs.me/updato/docs .", "repo": "https://github.com/NellowTCS/updato", "demo": "https://nellowtcs.me/updato/"}]...
|
[{"post_id": 3282, "ts": "2026 [{"post_id": 3282, "ts": "2026-06-06T04:21:10Z", "hours": 0.6542, "text": "devlog: shipped updato is published. it’s on npm. it has a version number and everything. the publish switched the build from vite to tsdown. vite was fine for dev but tsdown gives you dual esm/cjs output with proper .mjs/.cjs extensions and matching declaration files out of the box. the package exports map has real conditional exports now — separate import and require entries with their own types. it’s the kind of package.json that doesn’t make people file issues. scoped it to @nellowtcs/updato because apparently updato was too close to upath for npm’s similarity check. it is not similar. at all. but scoped names are better practice anyway so whatever, npm wins this round. the release workflow strips private , scripts , and devDependencies from package.json before publish. originally did that with an inline node script, swapped it to a one-liner jq pipe because why run a whole runtime to delete three keys. 1.0.0 → 1.0.1 released 1.0.0. immediately released 1.0.1 because of the name conflict. so it goes. the important thing is npm i @nellowtcs/updato works and the types resolve and the imports are correct. tested it, it’s real. what actually shipped all of it: github action that publishes builds to a cdn branch cloudflare worker that serves version checks from KV client library on npm with hot-swap, two update modes, optional metrics live demo at nellowtcs.me/updato docs site at nellowtcs.me/updato/docs ci pipeline for all of it a readme that actually explains what this thing does what’s left one item on the todo list: custom domain for the worker. that’s a “maybe” and it’s been a “maybe” for a while. it can stay a maybe. closing this started as a dumb idea about pushing updates without a server. it is now a real system with five directories and a package on npm and documentation with a sidebar. i don’t know when it became a real project but it did and now it’s done. first release. final (nah, probably not) devlog."}, {"post_id": 3255, "ts": "2026-06-06T03:05:19Z", "hours": 1.6772, "text": "devlog: docs, workflows, and the finish line this is the “make it real” commit. everything that was on the todo list under “before you can call this a real project” happened in one sitting. docs site built a full docs site using docmd. lives in Docs/ with its own package. seven pages covering everything: home/landing page, quickstart guide, core concepts explainer, and individual reference pages for the client library, github action, worker, hot-swap internals, manifest format, and download metrics. the client library page has full config tables, event references, api docs for every public method, and the UpdateNotification component. the action page documents every input and shows what the cdn branch looks like after a deploy. the worker page covers both endpoints, version comparison logic, caching, and rate limiting. the hot-swap page explains how each asset type gets replaced: scripts via dom replacement with data-hot-file tagging for subsequent updates, css via CSSStyleSheet.replaceSync and adoptedStyleSheets (which is CSP-safe), and images via base64 data uris. used the “sky” theme with system dark mode toggle. search, sitemap plugin, code highlighting, all enabled. github pages deployment new workflow at .github/workflows/static.yml . builds the client library, builds the demo, builds the docs, then assembles them into a single pages-root/ directory. demo goes under /demo/ , docs go at the root. deploys to gh-pages with peaceiris/actions-gh-pages. npm publish workflow .github/workflows/release-npm.yml . triggers on github release publish or manual dispatch with a dry-run option. builds the client library, strips private , scripts , and devDependencies from package.json, copies in the readme and license, then publishes with --provenance . also removed \"private\": true from Build/package.json so npm will actually accept it. security audit workflow daily cron job plus on-push when lockfiles change. runs npm audit --audit-level=high across every package (root, Build, Worker, Action, Demo, Docs). all the audit steps have || true so the workflow reports issues without failing the build, which felt like the right balance for now. separate test workflow split the test job out of ci.yml into its own .github/workflows/test.yml . same matrix across node 20 and 22, runs jest in all three packages. keeps the ci workflow focused on lint and build. todo status checked off docs. what’s left: update the readme with better examples, maybe attach the worker to a custom domain, and publish to npm. the npm workflow is ready, just need to actually pull the trigger."}, {"post_id": 3067, "ts": "2026-06-05T23:24:18Z", "hours": 1.5717, "text": "devlog: the three commits i forgot to write about got in a flow state and forgot to devlog. here’s the catch-up. multi-branch support + notification ui the whole system was hardcoded to a branch called cdn . now you can pass a branch parameter everywhere. the worker accepts it as a query param (defaults to cdn ), the client sends it with check requests, and download urls use the right branch. manifest cache keys in kv include the branch name so different environments don’t collide. the idea is you could have cdn-staging and cdn-production in the same repo and point different app builds at different ones. added branch validation in the worker too since someone’s going to try passing something weird eventually. also built an UpdateNotification class in update-ui.ts . it’s a drop-in banner component that handles the whole flow. you pick top or bottom, set it dismissable or not, and call notification.show(result) when there’s an update. clicking the button downloads and applies. if the download fails it resets. styling is all inline so there’s no css file to import. updated both examples to use it. the example-app.html went from a hand-rolled banner with window.__pendingUpdate to just notification.show(result) . much cleaner. module scripts + download metrics the action now scans html files for <script type=\"module\"> tags and includes a modules array in the manifest. the client passes this through to hot-swap so module scripts get replaced with type=\"module\" set on the new element. the regex for finding them is a little fragile but it works for standard vite/webpack output. also switched the action bundler from @vercel/ncc to esbuild . ncc was fine but esbuild is faster and i was already using it elsewhere. added an opt-in DownloadMetrics class that records timing data per file download (start, end, duration, size, url) in localStorage. pass it into the config and it starts tracking. you can export as json or clear it. useful for debugging slow updates but not the kind of thing you want on by default. tests + ci wrote jest tests for all three packages. action tests mock @actions/core , @actions/github , and @actions/exec . covers input parsing, repo context, package.json version reading, recursive file listing, module script detection, and clone url construction. had to export a bunch of internal functions to make them testable. client tests use jsdom with mocked fetch. covers hot-swap (regular scripts, module scripts, stylesheets, images, unknown types), the metrics class, and the main updato class (version tracking, cache management, update checking, downloads, event callbacks). worker tests cover validation helpers, the full fetch handler (missing params, invalid params, successful checks, unknown endpoints, OPTIONS, method rejection), manifest validation with every field failure case, and the rate limiter with fake timers. ci workflow at .github/workflows/ci.yml . runs on push and pr to main, matrix across node 20 and 22. lints, runs all tests, builds all three packages. todo status checked off: multi-branch, notification ui, module types, metrics, tests, ci. what’s left is docs, a demo, and release automation. the core functionality is done."}, {"post_id": 2861, "ts": "2026-06-05T18:37:02Z", "hours": 0.8061, "text": "devlog: the “just rename it” update (and a bunch of other stuff) the name thing changed name: Updato to name: Updato Action in action.yml. that’s it. that’s the fix. spent hours filing a support ticket, got a polite “no” from github, and the solution was adding one word. sometimes software development is humbling. hot-swap got its own file ripped the hot-swap logic out of updato.ts and gave it a proper home in hot-swap.ts . while i was in there i figured i might as well make it actually good. it now supports images too. png, jpg, gif, svg, webp, ico, bmp, avif. it finds matching <img> , <source> , and favicon <link> elements by basename and swaps their src/href to a base64 data uri. so if your update is just a new logo, no reload needed. also switched the element matching from substring ( src*=\"${file}\" ) to basename comparison, which is way less fragile. before, a file called app.js could’ve accidentally matched webapp.js . now it actually compares the filename part properly. the css swap switched from btoa() to encodeURIComponent() which handles unicode better. small thing but the kind of thing that would’ve been a weird bug later. everything returns a typed HotSwapResult now instead of just a boolean. so the caller knows what got swapped, what type it was, and which file it was for. manifest validation added a real validator in Worker/src/manifest.ts . before, the worker was just casting response.json() as Manifest and hoping for the best with a couple of if-checks. now there’s a validateManifest() function that checks every field properly and returns typed errors. each error tells you which field failed and why. this runs both when fetching fresh manifests from github and when reading cached ones from kv. if a cached manifest is corrupted it just falls through and re-fetches. rate limiting new file: Worker/src/rate-limit.ts . uses cloudflare kv to track requests per ip. 60 requests per 60 second window, which is generous enough for normal usage but should keep anyone from hammering it. uses CF-Connecting-IP for the real client ip, falls back to X-Forwarded-For . returns a proper 429 with a Retry-After header when you hit the limit. the kv entries auto-expire so they don’t pile up forever. I half wanted to make the 429 return silly messages, but I gotta be serious apparently sometimes :/ had to add a kv namespace binding in wrangler.toml for this. the worker was fully stateless before, now it has a little bit of state. felt like a big architectural decision for what’s basically a counter but whatever, it’s the right call. kv caching for manifests while i was adding kv for rate limiting i figured i might as well use it for manifest caching too. previously every /check request was hitting github’s raw content cdn directly. now it caches the manifest in kv with a configurable ttl (defaults to 300 seconds). means fewer github api calls and faster responses for repeat checks. worker got lint + prettier too copied the eslint + prettier setup from Build into Worker. also added projectService and tsconfigRootDir to both eslint configs so typescript-eslint can actually find the tsconfigs. this was one of those “why is eslint yelling at me” rabbit holes. todo cleanup checked off rate limiting and manifest validation. removed the already-completed items that were cluttering the list. it’s getting shorter."}, {"post_id": 2619, "ts": "2026-06-05T07:31:58Z", "hours": 0.3933, "text": "devlog: hot-swap and cleanup two things happened here and they’re very different vibes. hot-swap so previously applyUpdate() was just… reload the page. which works, obviously, but it’s not exactly elegant. if you’re updating a css file there’s no reason to nuke the entire page state. now it actually tries to be smart about it. when you call applyUpdate() , it looks at each file’s extension and attempts to swap it in-place: for .js files, it finds the matching <script> tag by src and replaces it with a new one containing the updated content for .css files, it finds the matching <link> stylesheet and swaps it with a base64 data url version of the new css if none of the files can be hot-swapped (like if there’s no matching dom element, or it’s a file type it doesn’t know about), it falls back to the classic window.location.reload() . so nothing breaks, it just tries the nice path first. the base64 css thing is a little cursed honestly. but it works and avoids needing to host the file anywhere. the browser just reads it inline. i might revisit this later if it causes issues with large stylesheets but for now it’s fine. eslint + prettier added eslint and prettier to the Build package because the code was starting to look inconsistent and it was bothering me. set up a flat config with typescript-eslint, browser globals, the usual. named the prettier script make-pretty because i thought it was funny. and idk, it’s how i do it ig prettier immediately reformatted a bunch of stuff in updato.ts . removed some unnecessary quote wrapping on \"Accept\" , collapsed a few multi-line expressions that didn’t need to be multi-line, cleaned up trailing commas. nothing behavioral, just formatting. also committed the lockfile. should’ve done that earlier but here we are. todo progress checked off hot-swap support and the linting setup. removed the version bump script todo since that was already done in the last round. the list is getting shorter. slowly."}, {"post_id": 2606, "ts": "2026-06-05T06:58:58Z", "hours": 0.3131, "text": "the one big devlog so updato exists now. figured i should write down what actually happened before i forget why i made half these decisions. what even is this updato is a decentralized update system for browser apps. the whole idea is: you push code, your app knows there’s a new version, and it updates itself. no app store, no server infrastructure you have to maintain. just github and a cloudflare worker. it’s three pieces: a github action that takes your build output and pushes it to a cdn branch on your repo. every version gets its own folder, plus there’s always a latest/ copy. it writes a manifest.json with metadata about what’s current. a cloudflare worker that acts as the middleman. your app asks it “hey is there an update?” and it goes and reads your manifest off github, compares versions, and tells the client yes or no. stateless, basically free to run. a js client library that you drop into your app. it talks to the worker, downloads new files if there’s an update, caches them in localStorage, and reloads when you’re ready. two modes because i couldn’t pick one there’s commit mode and version mode. commit mode means every push is a new version and the “version” is just the commit sha. version mode uses semver from your package.json. commit mode is nice for apps where you just want continuous deployment. version mode is for when you want to be more intentional about it. honestly i went back and forth on whether to support both. decided it was easy enough to keep and the action just reads a flag. the action lives in Action/ . typescript, compiled with ncc. it clones your cdn branch into a temp directory (or inits a fresh one if the branch doesn’t exist yet), copies your dist folder into latest/ and versions/{version}/ , writes the manifest, commits, and pushes. the commit messages are kinda nice actually, they show what version replaced what: deploy: abc123 (was def456) . one thing i’m quietly proud of is that it handles the “branch doesn’t exist yet” case gracefully. first run just works. the worker lives in Worker/ . pretty small. two endpoints: /check and /manifest . /check takes a repo and your current version, fetches the manifest from github, does the comparison, and returns whether there’s an update. wrote my own semver parser because i didn’t want to pull in a dependency for what’s basically three number comparisons. it’s probably fine. it validates the repo format with a regex so you can’t pass in weird stuff. set up wrangler.toml with a production and staging env. the client lives in Build/ . this is the part that actually runs in people’s apps. it’s a class called Updato (creative naming, i know). you init it with your repo, mode, and current version. then you can check for updates, download them, and apply them. downloads get cached in localStorage with version tags so stale cache gets cleaned up automatically. built with vite, outputs both esm and umd so you can import it or just drop a script tag. tooling i added after wrote a bump-version.js script that bumps the version across all four package.jsons (root + the three workspace packages), commits, tags, and pushes. one command to do a release, basically. also a little print-cdn-commit.js that tells you what the latest cdn branch commit is, which is useful for debugging. there’s a TODO.md with a bunch of stuff i want to do eventually. hot-swap support, rate limiting in the worker, tests, linting, npm publishing. the usual “i’ll get to it” list. current status it works. the action runs, the worker deploys, the client checks and downloads. trying to publish the action to the github marketplace but the name “Updato” is apparently reserved by a ghost account that doesn’t exist. so that’s cool. working on that."}]...
|
Title: Updato by @NellowTCS | Stardance
Devlogs:
Title: Updato by @NellowTCS | Stardance
Devlogs:
the one big devlog so updato exists now. figured i should write down what actually happened before i forget why i made half these decisions. what even is this updato is a decentralized update system for browser apps. the whole idea is: you push code, your app knows there’s a new version, and it updates itself. no app store, no server infrastructure you have to maintain. just github and a cloudflare worker. it’s three pieces: a github action that takes your build output and pushes it to a cdn branch on your repo. every version gets its own folder, plus there’s always a latest/ copy. it writes a manifest.json with metadata about what’s current. a cloudflare worker that acts as the middleman. your app asks it “hey is there an update?” and it goes and reads your manifest off github, compares versions, and tells the client yes or no. stateless, basically free to run. a js client library that you drop into your app. it talks to the worker, downloads new files if there’s an update, caches them in localStorage, and reloads when you’re ready. two modes because i couldn’t pick one there’s commit mode and version mode. commit mode means every push is a new version and the “version” is just the commit sha. version mode uses semver from your package.json. commit mode is nice for apps where you just want continuous deployment. version mode is for when you want to be more intentional about it. honestly i went back and forth on whether to support both. decided it was easy enough to keep and the action just reads a flag. the action lives in Action/ . typescript, compiled with ncc. it clones your cdn branch into a temp directory (or inits a fresh one if the branch doesn’t exist yet), copies your dist folder into latest/ and versions/{version}/ , writes the manifest, commits, and pushes. the commit messages are kinda nice actually, they show what version replaced what: deploy: abc123 (was def456) . one thing i’m quietly proud of is that it handles the “branch doesn’t exist yet” case gracefully. first run just works. the worker lives in Worker/ . pretty small. two endpoints: /check and /manifest . /check takes a repo and your current version, fetches the manifest from github, does the comparison, and returns whether there’s an update. wrote my own semver parser because i didn’t want to pull in a dependency for what’s basically three number comparisons. it’s probably fine. it validates the repo format with a regex so you can’t pass in weird stuff. set up wrangler.toml with a production and staging env. the client lives in Build/ . this is the part that actually runs in people’s apps. it’s a class called Updato (creative naming, i know). you init it with your repo, mode, and current version. then you can check for updates, download them, and apply them. downloads get cached in localStorage with version tags so stale cache gets cleaned up automatically. built with vite, outputs both esm and umd so you can import it or just drop a script tag. tooling i added after wrote a bump-version.js script that bumps the version across all four package.jsons (root + the three workspace packages), commits, tags, and pushes. one command to do a release, basically. also a little print-cdn-commit.js that tells you what the latest cdn branch commit is, which is useful for debugging. there’s a TODO.md with a bunch of stuff i want to do eventually. hot-swap support, rate limiting in the worker, tests, linting, npm publishing. the usual “i’ll get to it” list. current status it works. the action runs, the worker deploys, the client checks and downloads. trying to publish the action to the github marketplace but the name “Updato” is apparently reserved by a ghost account that doesn’t exist. so that’s cool. working on that.
devlog: hot-swap and cleanup two things happened here and they’re very different vibes. hot-swap so previously applyUpdate() was just… reload the page. which works, obviously, but it’s not exactly elegant. if you’re updating a css file there’s no reason to nuke the entire page state. now it actually tries to be smart about it. when you call applyUpdate() , it looks at each file’s extension and attempts to swap it in-place: for .js files, it finds the matching <script> tag by src and replaces it with a new one containing the updated content for .css files, it finds the matching <link> stylesheet and swaps it with a base64 data url version of the new css if none of the files can be hot-swapped (like if there’s no matching dom element, or it’s a file type it doesn’t know about), it falls back to the classic window.location.reload() . so nothing breaks, it just tries the nice path first. the base64 css thing is a little cursed honestly. but it works and avoids needing to host the file anywhere. the browser just reads it inline. i might revisit this later if it causes issues with large stylesheets but for now it’s fine. eslint + prettier added eslint and prettier to the Build package because the code was starting to look inconsistent and it was bothering me. set up a flat config with typescript-eslint, browser globals, the usual. named the prettier script make-pretty because i thought it was funny. and idk, it’s how i do it ig prettier immediately reformatted a bunch of stuff in updato.ts . removed some unnecessary quote wrapping on "Accept" , collapsed a few multi-line expressions that didn’t need to be multi-line, cleaned up trailing commas. nothing behavioral, just formatting. also committed the lockfile. should’ve done that earlier but here we are. todo progress checked off hot-swap support and the linting setup. removed the version bump script todo since that was already done in the last round. the list is getting shorter. slowly.
devlog: the “just rename it” update (and a bunch of other stuff) the name thing changed name: Updato to name: Updato Action in action.yml. that’s it. that’s the fix. spent hours filing a support ticket, got a polite “no” from github, and the solution was adding one word. sometimes software development is humbling. hot-swap got its own file ripped the hot-swap logic out of updato.ts and gave it a proper home in hot-swap.ts . while i was in there i figured i might as well make it actually good. it now supports images too. png, jpg, gif, svg, webp, ico, bmp, avif. it finds matching <img> , <source> , and favicon <link> elements by basename and swaps their src/href to a base64 data uri. so if your update is just a new logo, no reload needed. also switched the element matching from substring ( src*="${file}" ) to basename comparison, which is way less fragile. before, a file called app.js could’ve accidentally matched webapp.js . now it actually compares the filename part properly. the css swap switched from btoa() to encodeURIComponent() which handles unicode better. small thing but the kind of thing that would’ve been a weird bug later. everything returns a typed HotSwapResult now instead of just a boolean. so the caller knows what got swapped, what type it was, and which file it was for. manifest validation added a real validator in Worker/src/manifest.ts . before, the worker was just casting response.json() as Manifest and hoping for the best with a couple of if-checks. now there’s a validateManifest() function that checks every field properly and returns typed errors. each error tells you which field failed and why. this runs both when fetching fresh manifests from github and when reading cached ones from kv. if a cached manifest is corrupted it just falls through and re-fetches. rate limiting new file: Worker/src/rate-limit.ts . uses cloudflare kv to track requests per ip. 60 requests per 60 second window, which is generous enough for normal usage but should keep anyone from hammering it. uses CF-Connecting-IP for the real client ip, falls back to X-Forwarded-For . returns a proper 429 with a Retry-After header when you hit the limit. the kv entries auto-expire so they don’t pile up forever. I half wanted to make the 429 return silly messages, but I gotta be serious apparently sometimes :/ had to add a kv namespace binding in wrangler.toml for this. the worker was fully stateless before, now it has a little bit of state. felt like a big architectural decision for what’s basically a counter but whatever, it’s the right call. kv caching for manifests while i was adding kv for rate limiting i figured i might as well use it for manifest caching too. previously every /check request was hitting github’s raw content cdn directly. now it caches the manifest in kv with a configurable ttl (defaults to 300 seconds). means fewer github api calls and faster responses for repeat checks. worker got lint + prettier too copied the eslint + prettier setup from Build into Worker. also added projectService and tsconfigRootDir to both eslint configs so typescript-eslint can actually find the tsconfigs. this was one of those “why is eslint yelling at me” rabbit holes. todo cleanup checked off rate limiting and manifest validation. removed the already-completed items that were cluttering the list. it’s getting shorter.
devlog: the three commits i forgot to write about got in a flow state and forgot to devlog. here’s the catch-up. multi-branch support + notification ui the whole system was hardcoded to a branch called cdn . now you can pass a branch parameter everywhere. the worker accepts it as a query param (defaults to cdn ), the client sends it with check requests, and download urls use the right branch. manifest cache keys in kv include the branch name so different environments don’t collide. the idea is you could have cdn-staging and cdn-production in the same repo and point different app builds at different ones. added branch validation in the worker too since someone’s going to try passing something weird eventually. also built an UpdateNotification class in update-ui.ts . it’s a drop-in banner component that handles the whole flow. you pick top or bottom, set it dismissable or not, and call notification.show(result) when there’s an update. clicking the button downloads and applies. if the download fails it resets. styling is all inline so there’s no css file to import. updated both examples to use it. the example-app.html went from a hand-rolled banner with window.__pendingUpdate to just notification.show(result) . much cleaner. module scripts + download metrics the action now scans html files for <script type="module"> tags and includes a modules array in the manifest. the client passes this through to hot-swap so module scripts get replaced with type="module" set on the new element. the regex for finding them is a little fragile but it works for standard vite/webpack output. also switched the action bundler from @vercel/ncc to esbuild . ncc was fine but esbuild is faster and i was already using it elsewhere. added an opt-in DownloadMetrics class that records timing data per file download (start, end, duration, size, url) in localStorage. pass it into the config and it starts tracking. you can export as json or clear it. useful for debugging slow updates but not the kind of thing you want on by default. tests + ci wrote jest tests for all three packages. action tests mock @actions/core , @actions/github , and @actions/exec . covers input parsing, repo context, package.json version reading, recursive file listing, module script detection, and clone url construction. had to export a bunch of internal functions to make them testable. client tests use jsdom with mocked fetch. covers hot-swap (regular scripts, module scripts, stylesheets, images, unknown types), the metrics class, and the main updato class (version tracking, cache management, update checking, downloads, event callbacks). worker tests cover validation helpers, the full fetch handler (missing params, invalid params, successful checks, unknown endpoints, OPTIONS, method rejection), manifest validation with every field failure case, and the rate limiter with fake timers. ci workflow at .github/workflows/ci.yml . runs on push and pr to main, matrix across node 20 and 22. lints, runs all tests, builds all three packages. todo status checked off: multi-branch, notification ui, module types, metrics, tests, ci. what’s left is docs, a demo, and release automation. the core functionality is done.
devlog: docs, workflows, and the finish line this is the “make it real” commit. everything that was on the todo list under “before you can call this a real project” happened in one sitting. docs site built a full docs site using docmd. lives in Docs/ with its own package. seven pages covering everything: home/landing page, quickstart guide, core concepts explainer, and individual reference pages for the client library, github action, worker, hot-swap internals, manifest format, and download metrics. the client library page has full config tables, event references, api docs for every public method, and the UpdateNotification component. the action page documents every input and shows what the cdn branch looks like after a deploy. the worker page covers both endpoints, version comparison logic, caching, and rate limiting. the hot-swap page explains how each asset type gets replaced: scripts via dom replacement with data-hot-file tagging for subsequent updates, css via CSSStyleSheet.replaceSync and adoptedStyleSheets (which is CSP-safe), and images via base64 data uris. used the “sky” theme with system dark mode toggle. search, sitemap plugin, code highlighting, all enabled. github pages deployment new workflow at .github/workflows/static.yml . builds the client library, builds the demo, builds the docs, then assembles them into a single pages-root/ directory. demo goes under /demo/ , docs go at the root. deploys to gh-pages with peaceiris/actions-gh-pages. npm publish workflow .github/workflows/release-npm.yml . triggers on github release publish or manual dispatch with a dry-run option. builds the client library, strips private , scripts , and devDependencies from package.json, copies in the readme and license, then publishes with --provenance . also removed "private": true from Build/package.json so npm will actually accept it. security audit workflow daily cron job plus on-push when lockfiles change. runs npm audit --audit-level=high across every package (root, Build, Worker, Action, Demo, Docs). all the audit steps have || true so the workflow reports issues without failing the build, which felt like the right balance for now. separate test workflow split the test job out of ci.yml into its own .github/workflows/test.yml . same matrix across node 20 and 22, runs jest in all three packages. keeps the ci workflow focused on lint and build. todo status checked off docs. what’s left: update the readme with better examples, maybe attach the worker to a custom domain, and publish to npm. the npm workflow is ready, just need to actually pull the trigger.
devlog: shipped updato is published. it’s on npm. it has a version number and everything. the publish switched the build from vite to tsdown. vite was fine for dev but tsdown gives you dual esm/cjs output with proper .mjs/.cjs extensions and matching declaration files out of the box. the package exports map has real conditional exports now — separate import and require entries with their own types. it’s the kind of package.json that doesn’t make people file issues. scoped it to @nellowtcs/updato because apparently updato was too close to upath for npm’s similarity check. it is not similar. at all. but scoped names are better practice anyway so whatever, npm wins this round. the release workflow strips private , scripts , and devDependencies from package.json before publish. originally did that with an inline node script, swapped it to a one-liner jq pipe because why run a whole runtime to delete three keys. 1.0.0 → 1.0.1 released 1.0.0. immediately released 1.0.1 because of the name conflict. so it goes. the important thing is npm i @nellowtcs/updato works and the types resolve and the imports are correct. tested it, it’s real. what actually shipped all of it: github action that publishes builds to a cdn branch cloudflare worker that serves version checks from KV client library on npm with hot-swap, two update modes, optional metrics live demo at nellowtcs.me/updato docs site at nellowtcs.me/updato/docs ci pipeline for all of it a readme that actually explains what this thing does what’s left one item on the todo list: custom domain for the worker. that’s a “maybe” and it’s been a “maybe” for a while. it can stay a maybe. closing this started as a dumb idea about pushing updates without a server. it is now a real system with five directories and a package on npm and documentation with a sidebar. i don’t know when it became a real project but it did and now it’s done. first release. final (nah, probably not) devlog.
Ships:
Updato is a decentralized update system for web apps. A GitHub Action publishes builds to a CDN branch, a Cloudflare Worker handles version checks, and a client library hot-swaps files in the browser with no reload. It’s on npm as @nellowtcs /updato. It works end to end. Push code, Action builds it, Worker picks it up, client swaps files live. No server, no database. Also there’s a live demo, a docs site, and a real npm package now. It became a real project somewhere along the way. CSS hot-swapping was a whole thing. Ended up using CSSStyleSheet.replaceSync with adoptedStyleSheets to make it work without flashing or breaking CSP. Also npm told me my package name was too similar to “upath” which is just not true but whatever, scoped it and moved on. The live demo ( https://nellowtcs.me/updato/ ) is a clock app that checks for updates from the Worker. You can also install it with npm i @nellowtcs/updato and the docs are at https://nellowtcs.me/updato/docs ....
|
1793105711.6892698
|
1793192111.6892698
|
|
67125
|
edk2-rk3576 by @gahingwoo | Stardance
|
gahingwoo
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: edk2-rk3576 by @gahingwoo | Stardance
|
1793105712.8575861
|
1793710512.8575861
|
|
67126
|
Coda - portable music player by @neset | Stardance
|
neset
|
0
|
1.4
|
0
|
[]
|
[{"post_id": 75727, "ts": "202 [{"post_id": 75727, "ts": "2026-09-30T21:29:01Z", "hours": 1.4, "text": "i designed the board, including connections for a raspberry pi zero 2 w for computing, a dac, a small screen, a rotary encoder w click and 3 buttons. next: print pcb acquire components solder/assemble program iterate"}]...
|
Title: Coda - portable music player by @neset | St Title: Coda - portable music player by @neset | Stardance
Devlogs:
i designed the board, including connections for a raspberry pi zero 2 w for computing, a dac, a small screen, a rotary encoder w click and 3 buttons. next: print pcb acquire components solder/assemble program iterate...
|
1793105713.7389839
|
1793710513.7389839
|
|
30517
|
my APOD site by @SpacerCoder | Stardance
|
SpacerCoder
|
1
|
1.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-05T10:56:57Z", "hours": 1.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I made a website where you can select any date, without getting an error, and then get the nasa image/video of the day from that time. The challenging part was routing the API call properly, according to the date. I am most proud of how clean the UI is, and how smooth the operation is. It works perfectly as intended! To test this project, click on Try project, and go ahead and select any date and see the description for that image/video!", "repo": "https://github.com/SwiftProGrammer178611/myAPODsite", "demo": "https://swiftprogrammer178611.github.io/myAPODsite/"}]...
|
[{"post_id": 22298, "ts": "202 [{"post_id": 22298, "ts": "2026-07-04T18:06:01Z", "hours": 1.0211, "text": "Finished adding my own little spin. You can pick a date, and see what the picture of the day was from that date from the API form NASA"}, {"post_id": 21978, "ts": "2026-07-04T06:15:17Z", "hours": 0.4544, "text": "setup my APOD site after some errors with deleting files I didn’t need to 😅"}]...
|
Title: my APOD site by @SpacerCoder | Stardance
D Title: my APOD site by @SpacerCoder | Stardance
Devlogs:
setup my APOD site after some errors with deleting files I didn’t need to 😅
Finished adding my own little spin. You can pick a date, and see what the picture of the day was from that date from the API form NASA
Ships:
I made a website where you can select any date, without getting an error, and then get the nasa image/video of the day from that time. The challenging part was routing the API call properly, according to the date. I am most proud of how clean the UI is, and how smooth the operation is. It works perfectly as intended! To test this project, click on Try project, and go ahead and select any date and see the description for that image/video!...
|
1793105714.6737027
|
1793192114.6737027
|
|
67127
|
StudyFlow by @geeky | Stardance
|
geeky
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: StudyFlow by @geeky | Stardance
|
1793105715.5382733
|
1793969715.5382733
|
|
30527
|
Bulldog by @CheezzyBoii | Stardance
|
CheezzyBoii
|
2
|
3.0
|
1
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-16T20:12:10Z", "hours": 2.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "My simple slackbot named bulldog acctualy working this time please take a look", "repo": "https://github.com/CheezzyBoii/Bulldog", "demo": "https://hackclub.enterprise.slack.com/archives/C0BFQ5WMUGN"}, {"ship_num": 2, "ts": "2026-07-07T02:52:57Z", "hours": 1.0, "multiplier": 1.46, "payout": 1, "blessing": "neutral", "text": "Nice slack bot with the nice name Bulldog damn he is tuff.", "repo": "https://github.com/CheezzyBoii/Bulldog", "demo": "https://hackclub.enterprise.slack.com/archives/C0BFQ5WMUGN"}]...
|
[{"post_id": 29692, "ts": "202 [{"post_id": 29692, "ts": "2026-07-16T19:25:25Z", "hours": 0.6619, "text": "Addes /bulldog-yes-no it uses the api https://yesno.wtf to get a yes or no gif for the user"}, {"post_id": 24319, "ts": "2026-07-07T20:31:34Z", "hours": 1.5517, "text": "I worked on bulldog for 1 hour and 31 minutes adding a new slash command /bulldog-image which returns a random dog image. I thought that the read me needed to be updated to be actually useful and some other stuff."}, {"post_id": 23882, "ts": "2026-07-07T02:32:47Z", "hours": 1.0364, "text": "Just make the initial commit for my slack bot project"}]...
|
Title: Bulldog by @CheezzyBoii | Stardance
Devlog Title: Bulldog by @CheezzyBoii | Stardance
Devlogs:
Just make the initial commit for my slack bot project
I worked on bulldog for 1 hour and 31 minutes adding a new slash command /bulldog-image which returns a random dog image. I thought that the read me needed to be updated to be actually useful and some other stuff.
Addes /bulldog-yes-no it uses the api https://yesno.wtf to get a yes or no gif for the user
Ships:
Nice slack bot with the nice name Bulldog damn he is tuff.
My simple slackbot named bulldog acctualy working this time please take a look...
|
1793105716.3668957
|
1793192116.3668957
|
|
67129
|
My awesome macropad! by @methegoat | Stardance
|
methegoat
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My awesome macropad! by @methegoat | Starda Title: My awesome macropad! by @methegoat | Stardance...
|
1793105717.2678373
|
1793710517.2678373
|
|
6590
|
Flower by @IvyMycelia | Stardance
|
IvyMycelia
|
2
|
104.2
|
1193
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-07T02:27:02Z", "hours": 27.0, "multiplier": 19.07, "payout": 503, "blessing": "neutral", "text": "The compiler is written in Flower itself and currently targets C, so this release was mostly geared towards making the type system have actual Flower semantics instead of a thin little blanket over whatever the backend happened to be doing. The big additions in v1.4 were: transparent type aliases real null nullable types as ?T == T | null semantic unions like int | string explicit narrowing with is explicit extraction with as That support now works across locals, parameters, return types, struct fields, and stable field-expression chains. The work had to touch parser logic, typecheck, narrowing, lowering, codegen, bootstrap, and then all the weird regressions those changes politely dragged into the room. It was.. a process for sure What I’m most proud of is that v1.4 pushed Flower toward a clearer identity that wasn’t defined by C as much anymore. This release also brought the docs back in line with the compiler, which was LONGGGGG overdue. If you want to test it, the main things to look at are the Better Types examples and the self-hosting flow. The compiler should bootstrap cleanly, the test suite should pass, and the examples now cover aliases, nullable values, semantic unions, inference, and struct/field narrowing behavior. For those who will be testing it, DO NOTE that I develop exclusively on my MacBook which is a UNIX system! I do not have the ability to properly develop and provide releases for Linux-specificalities or non-POSIX systems. I’m extremely sorry for this, but alternatively watch the provided video to see Flower in action :) If you’re not able to test it, watch this short (crappy) video instead: https://youtube.com/shorts/DyPtIru6cjY?feature=share", "repo": "https://github.com/IvyMycelia/flower", "demo": "https://github.com/IvyMycelia/flower/releases"}, {"ship_num": 2, "ts": "2026-06-18T16:00:30Z", "hours": 38.0, "multiplier": 18.19, "payout": 690, "blessing": "neutral", "text": "Flower is a self-hosted programming language for writing simple, explicit systems code without the abstraction bloat and OOP-heavy direction a lot of modern languages have. The compiler is written in Flower itself, currently targets C, and follows a straightforward pipeline: lexing, parsing, module loading, typechecking, and code generation. Over the past few months, Flower grew from a small lexer/parser/codegen experiment in C into a way bigger language project than I couldv’e imagined. This wasn’t my first attempt at a language, but it has been my favorite! I implemented compiler-enforced module semantics, stronger type-aware codegen, real boolean support, real string support, and a small standard library foundation. Strings now have equality, .length, indexing, and explicit casts to and from @char , while modules support exported prop declarations, aliases as namespaces, and private-by-default top-level declarations. The hardest part was bootstrap stability. I ran into idempotency failures, parser edge cases, compiler corruption scares, and plenty of my own bad logic. A lot of the challenge was getting new features to work not just once, but consistently enough for the compiler to rebuild itself cleanly. One bootstrap it succeeds, and then the next I’m scrambling to figure out why the new binary executable has a corrupted parser despite just working (Still haven’t fixed that yet! It.. was really confusing and I’ve got no clue why it happened lol). I’m proud that I kept pushing through that and ended up with something much more fun to use than where I started — I mean, I don’t even have to write that much C anymore!! If people want to test Flower, the important thing to know is that it is self-hosted and still experimental, but it does work. The repo includes a bootstrap path, a test suite, and example programs covering types, control flow, memory, imports, strings, and bools. The current release is focused on making the core language feel real and usable before moving on to a larger standard library and a future non-C backend, so don’t be surprised if a C file is shoved in your face!", "repo": "https://github.com/IvyMycelia/flower", "demo": "https://github.com/IvyMycelia/flower/releases"}]...
|
[{"post_id": 79537, "ts": "202 [{"post_id": 79537, "ts": "2026-10-14T14:44:10Z", "hours": 10.3042, "text": "Integers, Integers, Integers Hello!! Been a while :) Lately I have been working on v1.6. I call it the “Usefullness” update — rhymes with Grug — because it adds a ton of long awaited features and various convenience implementations Flower DESPERATELY needs. For example, currently the progress has to do with v1.6.1, or Fixed-Width Integers . When it comes to systems programming and in-general efficiency, having various integer sizes is important as it provides an additional layer of manual control over memory and sizes. I know I would have to add them eventualy, so why not put them at the start of the Usefulness update?? I’m sure they’ll come in handy later on. What Actually Changed? Well, for starters, there’s now fixed-width integers (yay)! They’re built in types, so you declare them as you would with any other atom / primitive: type Byte = u8 type Choice = Byte | u16 type OptionalByte = ?Byte struct Packet { pair: Byte[2], size: Choice, owner: OptionalByte } A whole bunch of commits and integer-specific changes regarding indices, arity, unions, nullables, etc etc etc have been made, and they all won’t fit here so instead, take a look at the current branch ! What’s In Store? Plenty more features, you can assure yourself! There’s maybe 6 or 7 — I swear — or so commits left for this specific addition, and after that a lot more features laid out in the roadmap for 1.6! As always, thanks for sticking around and watching the fiasco that is this project become more and more estranged with every hour. Love y’all!! Ivy <3"}, {"post_id": 75225, "ts": "2026-09-29T15:04:00Z", "hours": 9.9331, "text": "Integer Types, Parser Fixes, and Segfaults! Phew — this one was biiiiiggg. Flower is pretty much just a glorified C transpiler, which is NOT what I want for it! In order to move on, the data has to be handled explicitly by the FloC. So essentially, I implemented i8 , u8 , i16 , u16 , i32 , u32 , i64 , and u64 . For now, int canonically refers to an i32 value. A New Era? With these new literals, the old hoist-sized representation had to go. The decimal source text is preserved, meaning values such as 18446744073709551615 remain after parsing without causing any overflow. Types are picked up from declarations, assignments, function arguments, return values, field writes, array-element writes, * breath in * and binary expressions! Oof, that was a mouthful. That, of course, resulted in proper errors for things like: 256 assigned to u8 −1 assigned to an unsigned type values beyond u64 unconstrained literals outside the default i32 range I Hate Memory During printing, every width is handled. Integer conditions retain existing zero / nonzero behavior, and literal types print their values rather than a character. Halfway through, I ran into sudden segfaults and memory leaks. I was taken aback, because I didn’t even change anything parser related yet. Turns out, I forgot an assignment in a declaration, which apparently the parser wasn’t able to handle (whoops!). Anyways, I fixed it by propagating errors through the compilation process, so the compiler doesn’t try to typecheck or code gen if the parser reports back errors, and instead will print them out. And that’s it! Not that’s it, but that’s all I’m going to explain for now. More specifics available on the GitHub, of course. Speaking of GitHub thank you so much to S1monr3dst0ne07 on GitHub for fixing some memory leaks in the previous version of Flower — I forgot to prune allocations before returning from a function :p Love y’all!! <3 P.S.: So glad I gave up on documentation, I was genuinely dreading workong on the project and that’s why I’ve been ianctive for a long time :c"}, {"post_id": 53525, "ts": "2026-08-24T03:18:35Z", "hours": 9.7706, "text": "Hey, it’s been a while! I’ve been finding it difficult to stay motivated for this project, especially with how the new payout system works and just my in-general inability to keep commitment despite having a lot of passion. That said, I am going back to working on this diligently, and I think to start I’m going to cut down on the documentation by making perhaps one or two changes, and then going right back to the compiler work. Documentation writing has not been the most fun for me, especially with how long it takes and how it’s so difficult to not only write language reference that works, but also keeping the same whimsy Flower should have. Thank you to everyone who’s been following this journey, and I can’t wait to see y’all later!!! With Love, - Ivy <3"}, {"post_id": 26743, "ts": "2026-07-11T18:25:46Z", "hours": 9.1964, "text": "Devlog: v1.5.1 – v1.5.5 Following all of the changes Flower has undergone, I felt it was time for some much-needed documentation. On paper this was supposed to be fairly quick, simple, and not require much brain power. Unfortunately for me I got a bit too over-zealous, and included things I thought should work, but in reality hadn’t. For example, in a lot of the code snippets I’d have something like: for i in range 0..10: print(i) end Printing non-string values was not yet supported in Flower. To fix this, I took a small detour back to v1.4 and implemented support for it — mostly in a single codegen case: if ast.data._print.value_type.base == TOKEN_FLOAT or ast.data._print.value_type.base == TOKEN_DOUBLE: fprintf(out, \"printf(\\\"%%f\\\", \") gen_expr(ast.data._print.value, out, src) fprintf(out, \");\\n\") end Afterwards I added more smoke-tests in examples/io/print.flo . Every few runs, however, I’d get a segfault. This was especially odd because it wasn’t simply an error but rather a silent memory bug. Eventually I found out where it was originating — thanks, ASan! Turns out after the new type system changes, I had forgotten to initialize some values to null / 0 in for loop handlers and a few other places. I just added typeInfo.data = null / 0 where applicable and it fixed the issue! What is v1.5, and why is this devlog so long? To answer the latter first.. I lowkey just forgot to post a devlog for the first two docs I made. That’s it. For the former question, v1.5 is supposed to be explicitly a documentation pass. First thing I worked on was structure. I cleaned up the docs layout, moved things toward a more consistent lowercase docs/ tree — I had been trying for so long to do that and I just finally got it to work — and wrote down the documentation process itself so new pages aren’t just floating about. The point was to try and make the docs feel like a book instead of a folder full of unrelated notes. I wrote and checked the language pages for types, functions, and control flow by reading the compiler itself, not by trusting my (poor) memory. That meant checking parser rules, typecheck behavior, codegen boundaries, and example files before writing anything solid. Types especially needed this, given how Flower now has enough real type machinery that the docs can quickly go from being coherent to completely incorrect: nullable sugar, semantic unions, explicit casts after narrowing, alias behavior, current member limits, and the difference between what the language wants to become and what the compiler supports currently. Functions and control flow had a similar issue. I had to document prop , return rules, direct call forms, logical conditions, range-based for , and the rough edges like break and continue not yet being enforced cleanly as loop-only. That kind of thing is small until someone learns the language from the docs and hits the edge head-first (been there, done that). What Now? I’m just going to keep writing docs. Maybe do one devlog for every new doc, or a batch of docs, who knows! I certainly don’t :p"}, {"post_id": 23761, "ts": "2026-07-06T21:49:25Z", "hours": 0.6008, "text": "Devlog: Syncing Flower’s Docs Back to Reality Just a doc cleanup lol. No code change or compiler updates. Probably did more than needed for now but oh well! The mismatch was REALLY bad. The old docs preserve old assumptions, and someone reading them could walk away with a version of Flower that no longer really exists (or, in some cases, doesn’t exist yet or never ever existed)! What changed I updated the docs that had drifted the most from reality (relatable): README.md now reflects the current type-system shape ROADMAP.md treats v1.4 as accomplished the v1.4.0 milestone doc now includes more of the outcome, not just the original plan contributor docs no longer have stale semantics structure.md is more accurate to what Flower currently is, and what still needs a fuller rewrite later Yea, that’s it."}, {"post_id": 23618, "ts": "2026-07-06T18:01:45Z", "hours": 1.6556, "text": "Devlog: Finishing Nullable Field Narrowing At this point, Flower could already narrow semantic unions through field access in the is / as case, and nullable field checks were supposed to be the obvious follow-through: if maybe_box.value != null: label: string = maybe_box.value as string end Instead, I had forgotten to remove a LOT of stale code, and thus part of it was still behaving like only plain local variables could ever be narrowed. There was also a second, smaller mismatch hiding, where null in type position was not lining up with the compiler’s actual internal null representation. ?string and string | null weren’t leading to a congruent output and at times were wobblier than they should be. So the fix was mostly cleanup, but the meaningful kind: make null in type syntax lower the same way the compiler expects remove the stale var-only branches in nullable narrowing let stable field paths like maybe_box.value and holder.box.value narrow properly The funny part is that this felt bigger initially than it actually was once fixed. Nothing fundamentally new had to be invented, I just had to stop the old code from interfering with the newer code, which once I figured out how to do so it was quite quick. I spent an embarrassingly long time figuring it out…"}, {"post_id": 22284, "ts": "2026-07-04T17:48:44Z", "hours": 1.8161, "text": "Devlog: Letting Union Narrowing Follow Field Access Before v1.4.13 , union narrowing only really worked when the thing being narrowed had a variable name due to almost every similarity check relying on name_start and name_length . This was dumb, because semantic unions already knew how to test tags and extract members. Codegen was not the issue, but rather the annoying part was that the typechecker could remember this: if value is int: n: int = value as int end but not this: if box.value is int: n: int = box.value as int end So I still had to do a little temp-variable ritual: tmp: Value = box.value if tmp is int: n: int = tmp as int end Which was gross. Not necessarily catastrophic, just gross and annoying. I wanted needed convenience What changed The compiler was remembering narrowings by variable name, not by expression shape, so box.value looked obvious in source (to me, at least), but to the typechecker it was basically some random expression and not something it could reliably recognize again later. A variable name already had a stable identity, whereas field access chain did not. So the change was to let narrowable expressions represent more than just AST_VAR_REF . For now, that only means stable dot-access chains. The typechecker can record a narrowing for an expression like: box.value and then recognize the same expression later when a cast shows up. So this works directly now: if box.value is int: n: int = box.value as int end Same for the other union members, like string . The detour My first example accidentally wandered into a different feature: if maybe_box.value != null: That exposed a real nullable-field-guard gap, but that is not what this was supposed to be about. Very rude of the test case to have ambition hmph >:( Where this leaves it Semantic union narrowing now persists past field access — at least for stable dot-access chains — and the temp-local is no longer needed. Butttt now I gotta work on nullable-field-guards, ugh (hehe)"}, {"post_id": 21926, "ts": "2026-07-04T03:34:19Z", "hours": 0.4592, "text": "Devlog: Direct Semantic Union Parameters Now instead of having to do this workaround: type Value = int | string func accept(value: Value): bool You can just pass semantic unions directly: func accept(value: int | string): bool That was it. All I had to do was remove a stale type_error clause in register_params and allow binding variables. Then I updated the two relevant accept functions in /examples."}, {"post_id": 21751, "ts": "2026-07-03T20:51:30Z", "hours": 4.9086, "text": "Devlog: Making ?T Actually Mean T | null Before v1.4.10 , ?T was treated as its own nullable system and not really integrated with the rest of the semantic unions. This was unideal, because it created a separation of logic which was cumbersome to maintain. The idea was to make the following be the default: ?int == int | null ?string == string | null ?@int == @int | null Prior to the refactor, nullable types were still mostly pointer-oriented. That worked when ?T basically meant “maybe this pointer is null,” but it did not really fit anymore once semantic unions became actual runtime values. If Flower has T | null , then ?T should use that instead of being its own special thing. This is a more pragmatic choice, as it keeps the compiler easier to manage and update later on. What changed Typecheck now lowers ?T into the same semantic-union machinery used by normal unions. That means nullable values now go through the same general path as union values: null checks use union-aware narrowing narrowed nullable values can be extracted with as codegen emits tagged union storage assignments pack into the right union member So this now works as an actual nullable flow: maybe: ?@int = raw if maybe == null: return false end real: @int = maybe as @int The annoying part is that Flower has to track two things at once: the type the programmer is allowed to see after narrowing, and the actual union shape that remains underneath it. After the guard, maybe behaves like an @int . But codegen still has to remember it came from @int | null , because apparently the compiler cannot simply “vibe” its way through storage layout. Tragic! The bugs that annoyed the heck out of me Most of the work was not surface syntax. The syntax was just standing nearby looking innocent. The actual bugs were in the places where Flower knew “this is non-null now,” but then forgot how to lower, such as: narrowed nullable values falling back to raw C casts like (int*)(maybe) false branches of == null / != null narrowing to the wrong side (this was my fault lol) null getting packed into the wrong union member That last one was the rude one. For ?@int , generated C could end up doing something like: . tag = 1 , . m0 = NULL instead of packing into the actual null member. So the value looked almost right, but the tag/member pairing was wrong. Then later null checks would fail, because the compiler had technically put null somewhere. Just not the correct somewhere. Very helpful. The fix was separating two questions I had accidentally merged: is this type compatible with this union? which exact union member should this value occupy? Those look related, but they are not the same question. Flower was using the first answer for the second problem, and then acting surprised when everything became soup. Where this leaves Better Types ?T now lowers through the same path as T | null , which means null checks, narrowing, extraction, and storage all line up with the semantic union model. This should make later work cleaner, such as nullable inference, nicer union ergonomics, maybe pattern-like narrowing eventually. Not easy. I am not saying easy near a compiler. That is how they hear you. You do not want them to hear you .."}, {"post_id": 19626, "ts": "2026-07-01T00:18:08Z", "hours": 0.4472, "text": "Devlog: Teaching Flower to Understand Guard Clauses gave Flower branch-local inference. Last update, I added support for branch-local inference, so the compiler could understand things like: if maybe == null: return false else: real: @int = maybe end and: if value is int: return false else: s: string = value as string end That was an improvement, but it still meant narrowing stopped at the end of the branch. That meant stuff like returninging in some conditions still did not really work as naturally as it should: if maybe == null: return false end real: @int = maybe or: if value is string: return false end n: int = value as int In v1.4.9 I fixed that. What changed Now narrowing propagates past very obvious guard clauses. If one branch definitely returns and the other falls through, the compiler now carries the interpretation forward after the if . This means that the compiler can now understand: after if x == null: return ... , x is non-null after if x is string: return ... , a two-member semantic union can narrow to its remaining member I kept this intentionally conservative for now. The compiler is not doing full control-flow analysis yet. It is only recognizing the simplest and most explicit early-exit shape. How it works The main addition was a small semantic check for “does this branch definitely return?” Right now that means: direct return if where both branches definitely return Once the compiler knows one side exits and the other survives, it applies the branch’s narrowing to the following statements. Yea.. that’s it lol."}, {"post_id": 19014, "ts": "2026-06-30T05:39:45Z", "hours": 1.2028, "text": "Devlog: Adding Obvious Branch-Local Inference to Flower Before this, narrowing mostly worked in the obvious “true branch” cases: if maybe != null: real: @int = maybe end and: if value is string: s: string = value as string end But the else branch was still kind of standing there empty-headed, even when the meaning was extremely obvious. Like, if this happens: if maybe == null: return false else: real: @int = maybe end then inside the else , maybe is clearly not null. So now it doesn’t!! What changed Flower now does branch-local narrowing in else for small, explicit cases. That means these now work: if maybe == null: return false else: real: @int = maybe end and: if value is int: return false else: s: string = value as string end It is only applying inference when the condition says something directly and the opposite branch has one obvious meaning. Nullable narrowing For nullable pointer-like values, Flower now understands both sides of simple null checks: if x != null narrows x to non-null in the if body if x == null narrows x to non-null in the else body the opposite side can narrow to null when that is the only meaning left Semantic union narrowing The same idea applies to semantic unions, but a bit more ‘held back.’ Essentially, if Flower sees: if value is int: then the if branch narrows to int , like before. Now, if the union only has one other possible member, the else branch can narrow too. So for: int | string the else after if value is int can be treated as string . This is not full control-flow wizardry, since it doesn’t reason across deep boolean chains, early-returns, or giant branches yet. It is deliberately small and local, because I do not want Flower “helping” so much that I need a detective board to figure out what type something is."}, {"post_id": 18478, "ts": "2026-06-29T17:18:49Z", "hours": 0.8039, "text": "Devlog: Letting Semantic Unions Work In Functions After getting semantic unions working in local declarations, the next problem was fairly obvious (and in my roadmap hehe). This did not work before: func make_value(): int | string return 7 end func accept_value(value: int | string): bool return value is int end Which was annoying, because int | string was already a real union type at this point. Flower could use it in locals, it could pack assigned values, it could check variants. But if I returned 7 from a function declared as int | string , or passed 7 into a parameter expecting int | string , the compiler did not know how to carry that union-lowering information across the boundary. This has been one of the easier changes I’ve made in a long while. It compiled properly first try (if you ignore a tiny misspell I made which I fixed really quickly), and there were no prior hidden bugs that surfaced. This.. is too suspicious. What changed The compiler now carries semantic union info through: function parameters function returns imported alias calls If a function expects: int | string and I call: accept_value(7) typecheck records that 7 needs to be packed as the int member of that union. Same for returns: func make_value(): int | string return 7 end That matters because codegen cannot guess later due to the separation of responsibilities I’ve laid out. By the time Flower is emitting C, it needs to know which tag to set and which member to write. Lowering it properly Codegen already knew how to pack union values for declarations and assignments. The missing part was doing the same thing for call arguments and return statements. So now a value can be packed into a tagged union when it is: stored locally passed into a function returned from a function Alias calls got handled too, so things like: remote.accept(11) remote.make_string() do not become their own weird little cursed island. Why this mattered Without this, semantic unions only worked as long as I never organized my code. They worked in local tests, but not in helper functions, imported providers, or normal inputs and outputs. Now union values can actually move around the program instead of being trapped in the one scope where they were declared — and for me, forgotten! Very exciting, the union can leave the house. They grow up so fast ⁎⁍̴̛ ₃ ⁍̴̛⁎"}, {"post_id": 18151, "ts": "2026-06-29T05:17:03Z", "hours": 3.3186, "text": "Devlog: Semantic Unions Become Actual Values (Part I) In v1.4.6 , I made semantic unions actual runtime values instead of just parsed/typechecked shapes. Before this, Flower could understand: type Value = int | string as a type. It could point at it and say, “yes, that is a union,” but that was mostly theoretical. The goal was to make this work-work for realsies: type Value = int | string value: Value = 7 if value is int: n: int = value as int end value = \"Ivy\" if value is string: s: string = value as string end That meant Flower needed more than TypeInfo.is_union = true . It needed a full path from syntax, to type proof, to lowered storage, to runtime extraction. Otherwise unions would just be fancy typechecker thingy-ma-bobbies, which is not very useful when the backend still emits C. What changed Instead of treating a union as a vague “one of these types, probably,” Flower now lowers it into a tagged structure. Conceptually, this: type Value = int | string becomes something like: struct Value { int tag ; union { int as_int ; flower_string as_string ; } data ; }; Not the final sacred form forever, but that is the shape of it: a tag saying which variant is active, plus storage for the possible members. Since Flower emits C right now, the lowering is C-shaped. I am not fully sure how I want this to look in ASM yet, but I do know it would be way more technical, and uglier. This required a few things to play nicely with one another: if value is int creates a union proof the guarded branch stores narrowing information value as int is only allowed after proof assignments pack values into the right tagged member explicit casts extract the right member from storage Otherwise the compiler is just writing checks its own backend cannot cash. The part that makes it ACTUALLY semantic For pointer narrowing, if value is T mostly refines how the compiler treats an existing value. For semantic unions, the check also becomes a runtime tag test. So this: if value is int: means: check the active tag of value , then inside this branch, treat it as the int variant. Then this becomes valid: n: int = value as int because the branch already proved the active variant. Without that proof, value as int should not be casually allowed. Flower is supposed to be explicit, not psychic, and I am not confident enough yet to implement a proper intuitive implicit checker without summoning something cursed. Assignment and extraction This: value: Value = 7 now packs 7 into the int member and sets the tag to the int variant. Then this: value = \"Ivy\" does the same thing, but for the string member. So a semantic union is not just some bytes, but rather a tagged runtime object where Flower knows which member is active. Then explicit casts like: value as string can lower into extracting the string member, but only when the typechecker has accepted that the operation is safe in that control-flow path. Why this checkpoint matters Flower can now store variant values, prove which variant is active, and require explicit extraction instead of relying on random magic I threw together. The flower has grown another concerning little organ."}, {"post_id": 16395, "ts": "2026-06-26T17:55:41Z", "hours": 2.0825, "text": "Devlog: is Checks v1.4.5 added is checks, mostly so code like this can work: if maybe_ptr is @int: real_ptr: @int = maybe_ptr end The idea is (fairly) simple: if the condition proves maybe_ptr is an @int , the inside of the branch should be allowed to treat it like one. Flower did not know how to do that before. It knew what a variable was declared as, but it did not really learn anything from control flow yet. Now it can, at least for the pointer/nullable-ish cases I care about first. This touched the parser, AST, typechecker, narrowing logic, and codegen. So, naturally, the “small feature” went everywhere. I’d actually consider this one of the bigger refactors so far, mostly because it added a new TypeAtom structure. Before this, types were still a bit too attached to the places they appeared, and all fell under the TypeInfo . That worked for simpler declarations, but is checks needed type syntax to have something the compiler could pass around to use for comparisons, validations, and narrowing. The parser had to recognize the new expression shape. The AST had to store the left side and the tested type. The typechecker had to make sure the test was allowed and not totally garbage. Then the narrowing logic had to say, “inside this branch, this variable has the proven type of x and therefore we won’t flag you for being an idiot.” That last part was where the bug goblin lived. I’m calling them a goblin because they were sneaky (and I also think it’s quite a funny and cute name). For a while, Flower had applied narrowing from the if body instead of the if condition, which meant the compiler saw this: if maybe_ptr is @int: real_ptr: @int = maybe_ptr end and somehow still failed on the assignment inside the branch. Very helpful. Thank you, compiler. EVen though it’s obviously 100% my fault, I made the compiler, but oh well!! Once I changed the narrowing step to inspect the actual condition expression, it started behaving like it should. The typechecker could see maybe_ptr is @int , attach that narrowed type to the branch scope, and allow maybe_ptr to be used as @int inside the guarded block. For now this explicitness is how I want it. There may come a time in the near future where I decide some implicity is ok, but we’ll see ;) is checks are the first real step towards control-flow-aware typing in Flower. Not full union support yet, but definitely the beginning of that road soon to come. Right now it mostly helps with nullable and pointer-like cases. Later, the same idea can support richer unions, better narrowing, and more type-driven control flow without making the programmer manually restate everything the compiler should already know. Also, it bootstrapped cleanly twice — which.. is obviously the bare minimum, but still!!"}, {"post_id": 15458, "ts": "2026-06-25T04:05:50Z", "hours": 2.4619, "text": "v1.4.4 Devlog: Giving Flower Real Semantic Union Types I made it so that semantic unions are now in Flower’s parser and type system — but not yet its codegen. The goal was to support types like: value: int | string next: @Node | null type Result = int | string What’s new The parser now understands | inside type positions and builds semantic union type information instead of relying on those old plain aliases or backend-shaped hacks. On the typecheck side, unions are now carried through normal type copying and alias resolution. That means named aliases like: type MaybeName = string | null make sense after resolution, instead of collapsing into nonsense. The typechecker also now accepts union-compatible usage in the places that matter for a foundation: variable initialization assignment parameter passing return checking alias resolution So if a value matches one union member, it is accepted. This is sorta implicit behavior, but I think it gets a pass due to its somewhat explicit nature? What it does not do yet This version was intentionally strict about using unions as values. You cannot yet directly: index a semantic union access a field on a semantic union use arithmetic / comparison operators on one print one directly Instead, Flower now requires an explicit cast before using a union value that way. That may sound harsh, but it is the right restriction.. for now. There is not any narrowing yet, so pretending unions were fully usable would just make the language lie and spit out 2,000 errors. Where this leaves v1.4 Flower now has: transparent type aliases null as a real type-system concept pointer-first nullable types semantic union type representation The next step is the part that will make unions actually usable rather than merely legal: narrowing with is better explicit extraction with as eventually making ?T truly become T | null instead of remaining pointer-first for now No fun screenshot this time :p just frontend work for now… Ivy, signing off <3"}, {"post_id": 14511, "ts": "2026-06-23T17:31:39Z", "hours": 1.8206, "text": "Devlog: Adding Pointer-First Nullable Types to Flower I worked on giving Flower its first real nullable type surface without being overambitious and pretending the compiler is ready for full optional-everything semantics yet. The new syntax now works like this: ptr: ?@int = null text: ?@char = null That means there is now an explicit way to say “this pointer-like value may be absent,” instead of relying entirely on raw pointer habits from C (If you couldn’t tell by now, I despise C). What changed The main work was split across lexer, parser, and typecheck. I added: ? as a type marker in type positions is_nullable tracking in TypeInfo type rules for nullable pointer/reference values explicit compatibility for: assigning null into nullable pointer-like types comparing nullable values against null casting between @T and ?@T I also kept the scope intentionally narrow: this implementation is pointer-first nullable support , not full nullable scalars. So ?@int makes sense right now, but ?int is still deferred until I make a better semantic union / optional representation for plain values. Why this matters It would have been easy to overreach here and claim “nullable types are done,” but that would have been a big phat lie. Pointer-like nullability lowers naturally enough with the current backend and current compiler model. Scalar nullability, however, does not. Once you let int or bool become nullable, you need a more real representation for “has value / no value,” and that belongs in the later union work, not here. Result explicit absence compiler-owned semantics better future unions stronger type meaning without hidden magic The next real step after this is not more patching around null — I consider that done for now — but instead giving Flower the deeper machinery needed for nullable non-pointer values and semantic unions later in v1.4 so it doesn’t come back to bite me in my butt."}, {"post_id": 13935, "ts": "2026-06-22T21:20:58Z", "hours": 0.355, "text": "Devlog: Formalizing Flower’s Null Foundation Flower already had some of the pieces for null , but they were a bit scattered. The goal here was to make it explicit, consistent, and safe before moving on to nullable syntax like ?T or full union-based nullability later in v1.4 . Another shorter devlog, but still important and distinct enough for me to think “Hmm devlog time? Yes, devlog time!” What changed The main work was in typechecking. I added to the compiler’s idea of what null is, how it is represented internally, and what kinds of values are actually allowed to accept it. Rather than letting null-related behavior stay implicit across a few checks, null now follows a clearer rule set: null has one centralized internal type representation pointer-like values can explicitly accept null null comparisons and assignments now go through the same semantic path Why this matters This isn’t all that important on its own, but it matters a lot for where Flower is going next. If null is not defined well, then later features like: ?T better unions smarter narrowing more expressive type flow all become more error-prone (or so I assume given my track record) than I want need them to be. Validation I also expanded the example coverage so null : it now has dedicated behavior checks around assignment, passing values around, and comparison behavior."}, {"post_id": 13918, "ts": "2026-06-22T20:30:15Z", "hours": 1.0089, "text": "Devlog: Fixing Flower’s Compiler Process So It Stops Fighting the Host This wasn’t really about language design at all buttttt it is much more embarrassing , AND more important: Flower’s compiler process itself was too fragile. The immediate issue showed up on Linux, specifically NixOS (thanks shipwrights <3). The build flow was assuming too much: a previously existing bin/Flower could be reused safely bash would exist at the expected path clang would always be available the checked-in compiler binary would be runnable on whatever machine the repo landed on That worked well enough on my machine until it didn’t. On NixOS — and by extension probably any other machine without the prexisting binaries I had — it broke: make targets were inconsistent, the shell script failed on interpreter assumptions, and the compiler binary itself could be the wrong format for the host. What changed The fix was to separate “the compiler source exists” from “the current compiler binary is usable on this machine.” The build process now starts by compiling a fresh host-native bootstrap compiler from bin/Flower.c , instead of trusting whatever happens to already exist in bin/Flower . That means the flow is now: bin/Flower.c -> host-native bootstrap compiler -> new Flower compiler -> self-check instead of: maybe existing bin/Flower -> hopefully works -> maybe bootstrap Ok well that’s kinda a lie; it still relies on hopes and dreams to bootstrap sometimes. BUT it’s MUCH safer! And now everyone gets to experience crippling bootstrap anxiety, instead of being met with a failure before the actual compiler gets to.. well, do its thign! I also cleaned up the surrounding tooling: switched the bootstrap script to portable sh restored a clearer build / bootstrap / rebuild / test / clean structure made the compiler use CC and CFLAGS from the environment instead of hardcoding clang What this actually improves Flower is still not universally cross-platform yet. The compiler driver still has POSIX-shaped assumptions in places, and the emitted C can still depend on host APIs depending on what the program uses. I’m not yet at the point of wanting to make it completely universal, especially given how I’m only one person and with v2.0 coming up soon it’d — in my humblest of opinions — be a waste of time. I am honestly grateful for people reviewing my code and otherwise viewing it catching onto details I have overlooked. My goal is to not make a ‘just-barely working on my machine’ project; I enjoy sharing development with others, and it hurts knowing people can’t appreciate code, whether it be mine or others’, due to something as simple as hard-coded sh flags."}, {"post_id": 13822, "ts": "2026-06-22T17:23:16Z", "hours": 3.7814, "text": "Devlog: Making Flower’s Type Aliases Transparent This version was simple to develop on paper (and even in practice it wasn’t too bad, only around 4 or so hours!): type Count = int type Total = Count type Name = string and then have those aliases behave like the real type everywhere: n: Count = 12 total: Total = identity(n) name: Name = \"Ivy\" if name != \"Ivy\": return false end if name.length != 3: return false end That meant aliases could not just be parsed and stored, but rather had to be transparent to the compiler’s semantic checks. What changed I added type alias declarations to the AST, parser, and type environment, then added the ability to resolve aliases in typechecking before comparing types. That included: return type checks variable initializers function call arguments binary comparisons string-specific comparison logic struct field access The important rule here is that aliases are semantic, not codegen-facing. Count should behave as int , Name should behave as string , and chained aliases like Total -> Count -> int should collapse correctly. In the future, especially post v2.0 , this could change and custom types might become real — but for now, they’re just aliases. The bug that exploded bootstrap The first real failure was not in aliases themselves, but in function argument checking. Inside check_call_args(...) , the compiler was resolving the argument expression into expected_type instead of arg_type . That overwrote the parameter type, left the actual argument type uninitialized, and caused the second bootstrap stage to explode into over a thousand misleading errors. This was not a pre-existing issue, it was instead from human error (my error) during the initial implementation where I accidentally put the wrong variable. Once that was fixed, the remaining failures were much more helpful than the bright flash of red and “Typecheck failed with 1224 error(s)” message! Where this leaves v1.4 With the first step toward “better types” done, aliases are no longer just syntax. That gives v1.4 a solid base for whatever comes next in the type system without having to fake around raw names. During this whole dev session, I did discover that a whole lot more of the source code was left using legacy work-arounds: int instead of bool , name_start; name_length and @char instead of string . In all fairness, some of these aren’t exactly the easiest to refactor. However, I will probably hold off on refactoring the codebase until either right before v2.0 , or right after. Just know it’s on my radar ;)"}, {"post_id": 11351, "ts": "2026-06-18T15:46:42Z", "hours": 1.4231, "text": "Devlog: Cleaning Up v1.3 For Release After many hours of work, bool and `string finally became real, and it was time to cleanup the mess I left behind from the version’s development. Mainly the only thing worked on was some cleanup: roadmap now reflects actual v1.3 features and implementations updated README and contribution documents to match the current compiler pipeline cleaned up string examples so they have the full intended v1.3 style instead of some leftover testing usage pushed the compiler’s version to 1.3.0 updated help / usage text so it matches the new output-path and auto-run behavior Prior to this, if I had just merged and shipped, the release wouldv’e been messy: README, Contributing, example files, and guidance commands were all mixing older details which made it confusing — even for me — when trying to explore the language and what it has to offer. For a bootstrapped compiler especially, making sure everything is cleaned up and polished is something that should not be ignored. I’m definitely guilty of overlooking this, but I’ve outlayed a whole plan for v1.3 unlike past versions, and part of it was setting up a proper versioning system and polishing its release as it goes. This format will be adopted in future versions, since it’s just way cleaner and nicer to look at. Future work At this point, v1.3 is done and has implemented, at minimum, a concrete foundation for post-v2 bools and strings. Next will likely be more subtle improvements, and features that are currently reliant explicitly on C rather than Flower-hosted code. In order for v2.0 , Flower will have to be effectively independent from C if it wants to emit machine code. Currently I am planning on adding features such as Type Aliases and maybe a stdlib prior to that, but anything can change!! Thanks for being here for all of v1.3 <3"}, {"post_id": 11116, "ts": "2026-06-18T05:51:28Z", "hours": 1.7269, "text": "Devlog: Giving Flower an Internal cstr Foundation Even after Flower got a real string type, the compiler itself was still leaning directly on C-style string helpers for its own internal work. That meant a lot of Flower source was still semantically depending on libc behavior: !strncmp(...) strcmp(...) strlen(...) strcpy(...) strncpy(...) strdup(...) strrchr(...) That is not where I want the language to stay. What changed I added a new internal module: import \"src/stdlib/cstr.flo\" as cstr and gave it compiler-facing helpers like: prop func len(s: @char): int prop func eq(a: @char, b: @char): bool prop func eq_n(a: @char, b: @char, n: int): bool prop func copy(dst: @char, src: @char): @char prop func copy_n(dst: @char, src: @char, n: int): @char prop func dup(src: @char): @char prop func find_last(src: @char, ch: char): @char This helper module is essentially the precursor to a future strings.flo library that can be distributed. But for now, it uses a basic API layer purely meant for in-house usage. Then I migrated compiler internals over to that module across: src/parser.flo src/module.flo src/lexer.flo src/typecheck.flo src/codegen.flo src/globals.flo src/main.flo So instead of using C-string behavior directly everywhere, the compiler now goes through Flower-owned helpers first. The Compiler Strikes Back This was one of those changes that sounds mechanical until it absolutely is not. A big trap was that old code often relied on C comparison functions returning 0 on equality, so patterns looked like this: not strncmp(...) But cstr.eq_n(...) returns an actual bool , which means blindly rewriting those calls gives inverted logic. So this: if ps.alias_lengths[i] == tok.length and not cstr.eq_n(...): was completely wrong. It had to become: if ps.alias_lengths[i] == tok.length and cstr.eq_n(...): That bug showed up in alias parsing first, which made it especially cursed, because it caused normal namespace-style calls like cstr.eq(...) to stop parsing correctly and crash the bootstrap path in confusing ways. I spent way longer than I wish to admit on trying to figure out why it wasn’t playing nice. But, once I figured it out, it was a really quick fix (I literally just cmd + f ’d not cstr and replaced it with cstr lol). Are we done yet..? This does not mean Flower is free from the C backend yet. It does mean something important, though: compiler logic is starting to depend on Flower-defined helper semantics instead of scattered raw libc calls. That is a much better stage for the future backend story, because when C eventually stops being the primary lowering target, the compiler will already have more of its own vocabulary. In other words, this was less about “remove C” and more about “stop letting C define the language’s internal habits.” Nah just kidding, I really wanted that bloated “builtin_c_call” stuff gone. Unfortunately I only managed to skim it, but that’s closer than before! Result After fixing the migration mistakes and the alias/parser fallout, the compiler bootstrapped successfully again. Flower now has an internal cstr layer, and compiler string handling is a little more its own."}, {"post_id": 11068, "ts": "2026-06-18T03:16:30Z", "hours": 1.2611, "text": "Devlog: Fixing Flower’s Output Driver and Starting the String Stdlib This checkpoint was really two different kinds of progress that ended up helping each other a lot. The first part was not glamorous, but it was necessary: Flower’s compile driver was tripping over its own default output naming. This was a known issue that I had been putting off, but for some reason it really annoyed me this time so I decided enough and to fix it. If no explicit output path was provided, the compiler would generate output.c , then strip the .c and try to emit a binary named output . That worked fine right up until the repo itself already had an output/ directory. At that point, linking failed because the compiler was trying to create a file where a directory already existed. Worse — because it annoyed me more — the driver logic was also mixing up “the generated program exited non-zero” with “compilation failed.” That became especially annoying during bootstrap, because the generated compiler binary would run without CLI arguments, print its own usage error, and then cause bootstrap to report failure even though codegen and C compilation had both succeeded. So I finally got off my butt and cleaned that up. Driver Cleanup The default output path now goes to: output/out.c which naturally produces: output/out as the binary. That avoids the old output filename collision. I also separated compile success from auto-run behavior: explicit output path: compile only default output path: compile, then auto-run if appropriate That means bootstrap no longer “fails” just because the compiled compiler exits non-zero with missing arguments, and demo/test files can still run automatically when that is actually useful. This sounds like a small driver fix, but honestly it removed a lot of noise from string work — and more — immediately. String Stdlib Beginnings Once that output weirdness was under control, I could finish doing what I just started and actually wanted: making string behavior live in Flower instead of endlessly leaning on ad hoc C calls (Call back to last devlog, absolute ball knowledge!!). So I added the first real reusable helpers in src/stdlib/string.flo : is_empty(s) starts_with(s, prefix) ends_with(s, suffix) find_char(s, ch) These are intentionally simple. They mostly exist to prove that the current string support is now strong enough for normal library code to be written on top of it. Not incredibly useful, at least at the level the compiler needs, but at least I could translate some AP Comp Sci A into Flower hehe A string feature does not really feel “real” until I can build helpers with the language itself instead of only teaching the compiler more special cases. The day I remove the builtin C handlers is the day I’m at peace… Validation To exercise that new library surface, I changed string_pass.flo to now act as a small pass file for the experimental library. Its job is not to be impressive. Its job is to answer a more important question: can I import string helpers, call them from normal Flower code, and get expected results through the full compile pipeline? At this point, yes. Where this leaves things This checkpoint did not remove all C string dependencies from the compiler. In fact, it removed essentially none! That is still a separate step, one that may even be in v1.3.7 ;) But it did establish two important things: Flower’s output/driver behavior is now much less annoying. We can start growing a real string library in Flower itself. That is a good place to be, because the next string work can build outward from a stable driver and an actual library surface instead of piling more special behavior into the compiler."}, {"post_id": 11013, "ts": "2026-06-18T01:18:51Z", "hours": 1.0825, "text": "Devlog: Adding String Indexing to Flower This one was fairly quick, and was about making one very normal-looking thing actually work: name: string = \"Ivy\" as string first: char = name[0] That sounds small, but once string became a real Flower type, indexing could no longer piggyback on the old “arrays and pointers only” behavior. The compiler needed to understand that string[index] is its own case. What changed I taught the typechecker to treat string subscripts as char . That means: string[index] now resolves to char the index expression must be an integer string indexing is readonly for now So this is valid: first: char = name[0] but this is not: name[0] = 'X' I wanted reads first, writes later. That keeps the rules simple while the string representation is still compiler-owned. I’m not sure how writes would work with a C backend, due to how ‘strings’ are allocated. Perhaps a feature for post-v2.0? Lowering it to C Since Flower strings currently lower to a struct with .data and .length , codegen needed a special path for string subscripts. Normal arrays and pointers still lower like: arr [ index ] but strings now lower like: name . data [ index ] That keeps the generated C valid without changing how regular subscripts work elsewhere in the language. So something conceptually like: This checkpoint also forced one strict-but-correct rule that required me to update a WHOLE SINGLE LINE (hehe): arg[i] = tolower(arg[i] as char) to arg[i] = tolower(arg[i] as char) as char Because tolower(...) is effectively treated as returning int , assigning it back into a char subscript needs an explicit cast. I kept that strictness on purpose. I do not want Flower silently narrowing values just because C would let it. Validation I expanded the string example coverage to check: string indexing returns the expected chars string[index] works alongside string <-> @char casts bootstrap still succeeds repeated bootstrap succeeds tests still pass Which, after all the recent bootstrap chaos, was very nice to see. Where this leaves v1.3 Now we can: store strings compare strings print strings inspect length index into them as char This should make it much easier to replace the builtin C functions with a Flower library in the near-near future."}, {"post_id": 10953, "ts": "2026-06-17T23:26:21Z", "hours": 3.3353, "text": "Devlog: Finishing Flower’s String Interop Bridge The last round got string into Flower as a real type. This round was about making that foundation actually work lol. The big problem was that once string became real, plain string literals started living in an in-between state: Flower wanted them to mean “Flower string,” but the compiler’s own source still has plenty of places that really mean “raw C string,” like: RED: @char = \"\\033[0;31m\" if not strcmp(arg, \"help\") or not strcmp(arg, \"h\"): ... end Those cases worked before only because everything was basically pretending string literals were already @char . Once that stopped being true, bootstrap started throwing a fit (my spoiled child). What changed The main fix was to make string literal lowering contextual instead of all-or-nothing. If a literal is being used as a real Flower string , it stays a string . If a literal is being used in a C interop position, it gets lowered as a C string instead. That meant tightening a few compiler rules so this kind of thing works cleanly again: name: string = \"Ivy\" as string raw: @char = name as @char if strcmp(raw, \"Ivy\") == 0: print(name) end I also fixed top-level declarations so globals like: RED: @char = \"\\033[0;31m\" no longer generate nonsense like: char * RED = (( flower_string ){ ... }); which, unsurprisingly, C does not appreciate. The subtle compiler bug The nastiest issue wasn’t even the globals. It was that builtin C calls like strcmp , strncmp , printf , snprintf , and friends are not real Flower functions. That meant the typechecker could hit one of them inside a larger expression, fail early, and stop walking the rest of the tree. So something like: if not strcmp(arg, \"help\") or not strcmp(arg, \"h\"): could partially resolve one side, then leave the other side unprocessed. Very cool. Very stable. Definitely what I wanted. The fix was to add a temporary builtin C-call bridge so the compiler can recognize these calls well enough to keep type resolution and literal lowering consistent during bootstrap. I’m not happy with this fix by any means, but due to the limitations of emitting C, it was the only solution I found that made sense at the time. Tests and examples Once that stopped exploding, I finally wired string testing into the normal types suite instead of leaving it commented out and pretending I’d “get back to it later.” The string tests now cover: string <-> @char casts string equality / inequality .length empty strings printing strings literal use in current interop cases And the full test suite passed with string included as a first-class part of Types on its first try . Now that’s what I like to see :D What this means This does not mean Flower’s long-term answer is “hardcode libc into the compiler forever.” It means Flower now has a temporary interop bridge that keeps self-hosting stable while string is worked on. The actual language semantics stay in Flower; the backend-specific weirdness is just being tolerated for now so progress does not stall. In the near, I’ll probably replace all of the necessary C libs with minimal Flower-equivalents. Where this leaves v1.3 At this point, the string foundation feels much sturdier. Not “done forever,” not backend-agnostic, and definitely not free of cursed bootstrap energy — but it works. The next work is no longer rescue work. It is actual forward work: string operations, stdlib basics, and eventually replacing this temporary C bridge with something cleaner when Flower grows past the C backend."}, {"post_id": 9012, "ts": "2026-06-15T01:03:21Z", "hours": 2.7858, "text": "Devlog: Building Flower’s String Type Foundation The core goal was to make this work in a meaningful, compiler-owned way: name: string = \"Ivy\" as string raw: @char = name as @char other: string = raw as string if name == other: print(\"same\\n\") end print(name.length) That meant Flower needed more than a typedef in generated C. It needed actual type rules, actual lowering rules, and I needed enough hairs on my head to not be bald after the amount of scares that occurred. What changed The first step was giving string real compiler support without going too far too fast. I added support for: explicit casts between string and @char string equality / inequality string.length runtime helpers in generated C for: flower_string_from_cstr(...) flower_string_eq(...) flower_print_string(...) That gave Flower a usable string foundation while still keeping literals conservative for self-hosting. Right now, string literals are not fully “native string values everywhere” yet; the compiler still uses explicit casts like \"Ivy\" as string as the safe bridge. The reason for this “safe bridge” is because when I got too ambitious, the compiler would break since everywhere @char was used with a string literal it’d break due to no implicity being allowed. I had to comment out the following new changes and keep the legacy support so it’d compile: else if ast.kind == AST_STRING_LIT: // fprintf(out, \"flowe_string_from_cst(\") // fprintf(out, \"%.*s\", ast.data._string.str_length, src + ast.data._string.str_start) // fprintf(out, \")\") // LEGACY CODE HERE and else if expr.kind == AST_STRING_LIT: // set_plain_type(out, TOKEN_STRING) // LEGACY CODE HERE return 1 The part that broke The most annoying issue was not string equality or .length . It was print . Originally, non-string print(...) was basically lowered like this: printf ( expr ); That only works when expr is already a C format string. So something like: print(name.length) generated invalid C: printf ( name . length ); The fix was to make print(...) type-aware. Typecheck now records the operand type, and codegen lowers print differently for string , @char , char , floats/doubles, and integer-like values. That sounds small, but it matters a lot: once string became real, print could no longer get away with pretending every printable value was already a C string. An Unsolved Bootstrap Mystery Somehow Flower’s bootstrap process was breaking, and it will probably break again. Despite the bootstrap requiring it to compile itself, somehow afterwords the binary could become corrupted. l-2: ~/Documents/GitHub/FloC % make bootstrap === Building new version === Compiled ./bin/Flower_new.c → ./bin/Flower_new === Testing new compiler === Compiled ./bin/Flower_test.c → ./bin/Flower_test Verified bootstrap build complete l-2: ~/Documents/GitHub/FloC % make bootstrap === Building new version === Luckily, I always make sure to keep a backup Flower bin stored under /bin/Flower_backup so I used that to compile the new binary and then it worked. Where this leaves v1.3 What still remains is the bigger ergonomic question: how fully native string literals should behave, and how to migrate the compiler’s own source to that world without setting bootstrap on fire again. I’m not sure yet how I want to approach this question, or what the goals for it should even be, but I guess I’ll have to find out soon enough! That is the next fight. But at least now, it is a fight on solid ground."}, {"post_id": 8529, "ts": "2026-06-14T05:55:45Z", "hours": 3.8414, "text": "Devlog: Making Bool Real Without Breaking Bootstrap The original goal, asper usual, was straightforward: before moving on to string , Flower needed bool to actually mean something semantically. Up to this point, boolean-ish behavior mostly worked by accident. Comparisons, conditions, returns, and general expression checking were still loose enough that the compiler could get away with treating a lot of things as “close enough,” especially since the C backend ultimately lowers bool to int anyway. That was not going to hold once v1.3 started leaning on richer typing. So this was about drawing a clean line between Flower semantics and C lowering. The Goal In Flower: bool should be its own real type comparisons and logical operators should produce bool arithmetic should not quietly accept bool implicit conversion should stay narrow and predictable explicit casting should remain available through as In C: bool can still lower to int That distinction ended up being the easy part. What Changed The typechecker now treats bool as a proper language type instead of an int-shaped placeholder. Condition checks were tightened so if , while , and not use condition-compatible rules. Arithmetic paths now reject boolean operands, and return / initializer / argument checking now runs through more explicit conversion rules. I also kept implicit widening one-directional: int -> float -> double while leaving narrowing conversions as explicit casts. The actual implementation of booleans and their typing, enforcement, and semantics was a breeze. It’s what came after that got me. What Actually Broke As usual, bootstrap had opinions. The stricter type work exposed older weaknesses that were easy to miss before (This is my coping): function argument checks needed array-to-pointer decay alias and module call lookup paths were too narrow unresolved calls could prevent nested expressions from being fully type-resolved that, in turn, broke some dot-access lowering and caused bad . vs -> emission in generated C So part of this checkpoint turned into compiler stabilization work rather than just bool semantics due to my crappy ‘temporary’ logic, error handling — or lack thereof, and impeccable ability to miss very important details. I’m an amazing programmer, if you couldn’t tell :p Result Flower now has a much firmer semantic base for bool, and the compiler is back to bootstrapping cleanly with those rules in place. That matters because this was really the floor for the next part of v1.3: string . And.. maybe I’ll fix the bootstrap process so it doesn’t blow up in my face again. Oh yea, forgot to mention that. The bootstrapper bootstrapped itself into this very broken parser state that refused to go away so I had to stash my changes, checkout the prior merge (detached), and then recompile manually and fix the parser. Toodles!"}, {"post_id": 6924, "ts": "2026-06-11T16:28:33Z", "hours": 1.3047, "text": "Devlog: Fixing the Typechecker After Bool Enforcement Getting bool into Flower exposed a reallyyyy annoying problem: the typechecker had a couple of tiny logic mistakes (I’m so good at this) which caused the bootstrap to blow up in my face and I ahd no idea why. At first the errors looked unrelated. The compiler started reporting huge numbers of mismatches across main.flo , lexer.flo , module.flo , typecheck.flo , and codegen.flo . I was so confused as to why out of nowhere 903 lines were reporting various typechecking errors when they shouldn’t be. As it turns out, types_match() was the culprit. The function had been inverted in a few places: Mismatched base types and pointer depths were returning success, while normal matching primitive types were falling through to failure. That made the new compiler think ordinary initializers, assignments, comparisons, and returns were all invalid. Once that was fixed, the remaining failures turned out to be a second real compiler bug: pointer arithmetic over arrays was decaying in the wrong direction. Expressions like: mods.modules + j env.structs + env.struct_count arr + 1 should produce pointer types. Instead, the typechecker was reducing pointer depth when arrays decayed, which made perfectly normal indexed access and table walking look type-invalid. So this dev session ended up doing three important things: fixed types_match(...) so actual matches succeed and actual mismatches fail preserved decimal compatibility for float / double matching fixed array-to-pointer decay in pointer arithmetic so compiler internals and examples resolve correctly again What made this especially annoying is that the symptoms looked much larger than the cause. A couple of bad returns in the typechecker created hundreds of downstream errors, and because Flower is self-hosting, that meant the compiler started rejecting its own source. After correcting those core issues, both bootstrap and the example test suite started working again. That is the real value of issues like this: not just “fewer errors,” but restoring (MY) trust in the compiler and its ability to enforce Flower’s rules and report issues. With that stable again, the path forward is much clearer: continue bool work from a solid base, then move on to the remaining numeric and string improvements without the whole compiler collapsing under one bad predicate."}, {"post_id": 6207, "ts": "2026-06-10T12:52:51Z", "hours": 4.0928, "text": "Devlog: Making Flower’s Bool Support Real Enough to Survive Bootstrap The goal sounded small at first: add proper boolean support, while still lowering booleans to integers in C. In practice, this turned into an overarching type-system problem (typical!). Flower had reached a point where bool could not just be a naming trick over 1 and 0 . The compiler itself needed to understand when an expression was semantically boolean, when it was integer, and when older bootstrap-era shortcuts were no longer valid. A lot of those shortcuts had survived because the backend lowers bool to int anyway. But self-hosting exposed a major issue: source-level typing and C lowering are not the same thing. Things like these started breaking: val: int = parser_peek(ps).kind == TOKEN_TRUE and helper predicates that returned comparison expressions from int -typed functions. So the checkpoint became: keep C lowering simple, but make Flower’s typechecker treat booleans as a real source-level type. The main changes were: parser -> typecheck -> codegen true / false now parse into AST_BOOL_LIT bool literals are still emitted as 0 / 1 in C logical and comparison expressions now resolve to bool arithmetic rejects bool operands if , while , and not now validate condition-compatible expressions variable initializers, assignments, and returns now check types more strictly One of the more annoying bugs turned out not to be “about bools” at all. When code like this failed inside the compiler: defined_structs[i].length emitted_imports[i].path the real problem was that for i in 0..count was never registering i in the type environment, so indexed access looked broken when really the loop variable itself had no known type. Once loop indices were typed as int , those field-access failures disappeared (yay!!). The result is a much better place to build from: bool is now semantically distinct in Flower it still lowers cleanly to integer values in generated C bootstrap works again the compiler is stricter without collapsing under its own source That makes the next step much easier: real string support, instead of trying to build strings on top of a type system that still half-thinks everything is an int ."}, {"post_id": 5369, "ts": "2026-06-09T03:37:15Z", "hours": 5.4503, "text": "Devlog: Giving Flower Real Module Support v1.2.x was the point where Flower’s impors had to stop being “you can import stuff.. and there’s a fake layer of security” to a prop er (get it?) module system. Before this work, imports and aliases mostly behaved like naming conveniences. You could write: import \"math.flo\" as math math.add(1, 2) but the compiler was still too loose about what that really meant . Alias names were in emitted C symbol names, top-level declarations were not private, and prop existed more as syntax than as a real feature. That was fine for early bootstrap work, but it was not strong enough for the next stage of the language. So the main goal of v1.2.x became: make imported aliases act like real namespaces make prop define the public interface of a module make top-level declarations private by default lay groundwork for field visibility rules like hidden and readonly Module Semantics Instead of Alias Tricks One of the biggest changes was separating Flower semantics from C lowering. Previously, imported aliases were drifting toward becoming part of emitted symbol identity. A local alias should just be a source-level name bound to a module, not the backend symbol. So now each module has its own lowered symbol prefix, and alias lookup happens semantically during compilation. That means: import \"math.flo\" as math math.add(1, 2) is resolved as “look up exported add in module math.flo ,” not “invent a C symbol from the local alias text as math_add() .” That change also forced a cleanup of emitted names so they stopped leaking absolute filesystem paths. Generated symbols now use project-relative module prefixes instead of machine-specific paths. prop Became Real Another major part of this was making prop actually do something. Instead of treating it as a thin wrapper around only functions, the compiler now recognizes prop as a real top-level export marker. That means the module’s public interface is defined by what it explicitly exports, while non- prop declarations remain internal. This moved Flower closer to the model I wanted all along: explicit modules, explicit public APIs, no heavy object system (OOP), no fake privacy delegated to the C backend. Dot Access, Pointers, and the Annoying Middle Part This work also exposed a weakness in the compiler’s dot-access resolution. Flower source always uses . , while the C backend must decide whether a given access becomes . or -> . That mostly worked already, but nested pointer-heavy field chains exposed cases where the type tracker was not propagating enough information, which caused bad fallback behavior during self-hosting. So before field visibility could be trusted, I had to harden nested dot-access resolution. Not fun, but necessary. As it turns out, I was missing several AST kinds which caused the logic to fall through. Very tedious work, but it was well-worth it in the end! Field Flags Groundwork With module ownership and access resolution in better shape, I added the first field visibility modifiers: hidden readonly frozen Originally I debated having these as bitwise operations, but I decided it’d be best to stay within the current update’s scope, so sometime in the future I’ll refactor. Right now, hidden and readonly are the meaningful additions: hidden blocks external field access readonly blocks external assignment frozen is groundwork for later. It is parsed, stored, and carried through the compiler, but full assignment-once enforcement is still deferred. Unsure how I’ll go about it, but that’s an issue for future me :p"}, {"post_id": 4525, "ts": "2026-06-07T21:22:43Z", "hours": 3.6428, "text": "Devlog: Replacing Flower’s Old Function Syntax with func name(...): type This feature started out as what I thought would be a straightforward syntax cleanup. Flower’s old function syntax looked like this: int add(a: int, b: int): return a + b end and exported functions looked like this: prop int test(): return 1 end It worked, technically, but it had started to annoy me more. The biggest issue was that function declarations did not visually match the direction Flower was already heading in, and instead felt much more C-like than I wanted. prop func create(...): Person func main(): int This style says “this is a function” up front, gives a clean place for modifiers like prop , and keeps the return type attached to the signature rather than awkwardly leading it. The goal was simple: func name(...): type instead of: type name(...): Simple in theory. not so much when the compiler is written in the language being refactored. The Problem Flower’s parser assumes top-level function definitions start with a type. Old parser logic was built around that: int main(): means: parse a type, an identifier, params, and a body That assumption was scattered through a few different places: normal function definitions prop function declarations forward declarations examples and docs the compiler’s own source Now, in retrospect, this was actually one of the easier changes. It didn’t take a whole lot of planning nor brain power, and I was able to change it pretty quickly. Luckily for me, I’ve built codegen to rely purely on ast values rather than shaping. The New Shape The new syntax is: func add(a: int, b: int): int return a + b end and exported functions now look like: prop func test(): int return 1 end This is nicer because: func makes declarations immediately recognizable prop composes more cleanly with func return types now live where people expect them to future syntax has more room to grow without feeling backwards It also feels more in line with Flower’s broader goals: explicit, readable, and not complex. The Refactor Previously, parse_func_def looked for a return type first: type name(...): Now it expects: func name(...): type So the order changed to: expect func parse function name parse parameter list expect : parse return type parse body until end That part was conceptually easy. The more annoying part was updating all the places that assumed if it isn’t a var decl and it looks like a func, it’s a func. That fallback had to go (Good riddance!). Instead, top-level parsing needed to become more explicit: prop func → exported function func → normal function forward func → forward declaration The old one worked, but it relied on vague “anything else is probably a function” rules. The Bootstrap Mistake At one point, I made a bootstrap build so I could use a Flower_new binary to compile the refactored compiler. Unfortunately, I had made a mistake in parse_forward : advancing before peek checks. Feel free to check out the bootstrapper to see why this was an issue ;) This meant my “new compiler to compile the new compiler” was built from a broken parser. The workaround was cursed, but it worked : check out the commit before the refactor fix the bug compile a new binary switch to the refactor branch use the binary to compile the new version Since the compiled binary was ignored by Git, this was actually fairly simple. Not the most elegant bootstrap story, but it got the compiler to, well, compile."}, {"post_id": 3962, "ts": "2026-06-07T03:08:31Z", "hours": 8.2967, "text": "Devlog: Making Flower’s Type Tracking “Enough” for Stdlib / String Work The original motivation was simple and — supposedly — quick; I wanted to move on to v1.1.1 , “stdlib basics,” especially string utilities. But Flower’s current compiler did not really know what types expressions had. It mostly had pointer_depth on declarations, which was enough to generate * in C types and sometimes guess whether field access should become . or -> . That worked for very simple cases: p: @Vector2 = new Vector2 p.x = 5 But it broke down for nested access: outer.inner.value outer.inner_ptr.value The compiler could see the syntax chain, but it did not know whether inner was a value field or pointer field. Since Flower source only uses . , the C backend needs to decide whether each hop becomes . or -> . That meant stdlib work was blocked. If I want something like: if strings.equal(string_a, string_b): print(\"same\\n\") end then Flower needs to understand that string_a.length , string_a.data , etc. are real typed fields, not just random syntax to dump into C. Originally I thought I could just simply create a Symbol Table to get that to work. Unfortunately, that plan soon failed as it introduced a mariad of issues relating to the import system. At the time, this frustrated me because I knew the import system sucked, but I didn’t want to fix it until a later version. Eventually, I settled on a specific plan which did actually end up changing how imports are handled.. kinda. The Plan The design I landed on was to add a typecheck/type-tracking stage between parsing and codegen: lexer -> parser -> typecheck -> codegen The parser should stay mostly syntax-only. It builds AST nodes like “dot access,” so I didn’t really change it. The typecheck pass now collects declarations into a TypeEnv : struct TypeEnv { structs: StructInfo[1024], struct_count: int, vars: VarInfo[8192], var_count: int, funcs: FuncInfo[8192], func_count: int, error_count: int } Then it walks expressions and annotates dot access nodes with an access kind: ACCESS_UNKNOWN: int = 0 ACCESS_DOT: int = 1 ACCESS_ARROW: int = 2 So codegen no longer has to fully guess. It can do: if ast.data._dot_access.access_kind == ACCESS_ARROW: fprintf(out, \"->%.*s\", ...) else if ast.data._dot_access.access_kind == ACCESS_DOT: fprintf(out, \".%.*s\", ...) else: // fallback end That fallback is important because Flower is self-hosted-ish right now. The compiler is written in Flower, and the compiler’s own source code is full of field access. If the new typechecker is too strict too early, it breaks the compiler while trying to compile the compiler. Very elegant. Very cursed. Just how I like it ;) Import-Aware Type Tracking At first, typechecking only saw the main file, so I added a module loading pass. Instead of codegen discovering and parsing imports late, the compiler now loads modules earlier: load main module load imports recursively collect declarations from all modules typecheck all modules codegen all modules That required a new module structure: struct Module { path: @char, src: @char, tokens: @TokenStream, ast: @AST } struct ModuleSet { modules: Module[128], count: int } Unfortunately, it didn’t go as smoothly as I wanted. Near the end when I was sure everything would work, I ran into an Idempotency failure due to the new handling of system imports. I.. just manually passed it :p"}]...
|
Title: Flower by @IvyMycelia | Stardance
Devlogs: Title: Flower by @IvyMycelia | Stardance
Devlogs:
Devlog: Making Flower’s Type Tracking “Enough” for Stdlib / String Work The original motivation was simple and — supposedly — quick; I wanted to move on to v1.1.1 , “stdlib basics,” especially string utilities. But Flower’s current compiler did not really know what types expressions had. It mostly had pointer_depth on declarations, which was enough to generate * in C types and sometimes guess whether field access should become . or -> . That worked for very simple cases: p: @Vector2 = new Vector2 p.x = 5 But it broke down for nested access: outer.inner.value outer.inner_ptr.value The compiler could see the syntax chain, but it did not know whether inner was a value field or pointer field. Since Flower source only uses . , the C backend needs to decide whether each hop becomes . or -> . That meant stdlib work was blocked. If I want something like: if strings.equal(string_a, string_b): print("same\n") end then Flower needs to understand that string_a.length , string_a.data , etc. are real typed fields, not just random syntax to dump into C. Originally I thought I could just simply create a Symbol Table to get that to work. Unfortunately, that plan soon failed as it introduced a mariad of issues relating to the import system. At the time, this frustrated me because I knew the import system sucked, but I didn’t want to fix it until a later version. Eventually, I settled on a specific plan which did actually end up changing how imports are handled.. kinda. The Plan The design I landed on was to add a typecheck/type-tracking stage between parsing and codegen: lexer -> parser -> typecheck -> codegen The parser should stay mostly syntax-only. It builds AST nodes like “dot access,” so I didn’t really change it. The typecheck pass now collects declarations into a TypeEnv : struct TypeEnv { structs: StructInfo[1024], struct_count: int, vars: VarInfo[8192], var_count: int, funcs: FuncInfo[8192], func_count: int, error_count: int } Then it walks expressions and annotates dot access nodes with an access kind: ACCESS_UNKNOWN: int = 0 ACCESS_DOT: int = 1 ACCESS_ARROW: int = 2 So codegen no longer has to fully guess. It can do: if ast.data._dot_access.access_kind == ACCESS_ARROW: fprintf(out, "->%.*s", ...) else if ast.data._dot_access.access_kind == ACCESS_DOT: fprintf(out, ".%.*s", ...) else: // fallback end That fallback is important because Flower is self-hosted-ish right now. The compiler is written in Flower, and the compiler’s own source code is full of field access. If the new typechecker is too strict too early, it breaks the compiler while trying to compile the compiler. Very elegant. Very cursed. Just how I like it ;) Import-Aware Type Tracking At first, typechecking only saw the main file, so I added a module loading pass. Instead of codegen discovering and parsing imports late, the compiler now loads modules earlier: load main module load imports recursively collect declarations from all modules typecheck all modules codegen all modules That required a new module structure: struct Module { path: @char, src: @char, tokens: @TokenStream, ast: @AST } struct ModuleSet { modules: Module[128], count: int } Unfortunately, it didn’t go as smoothly as I wanted. Near the end when I was sure everything would work, I ran into an Idempotency failure due to the new handling of system imports. I.. just manually passed it :p
Devlog: Replacing Flower’s Old Function Syntax with func name(...): type This feature started out as what I thought would be a straightforward syntax cleanup. Flower’s old function syntax looked like this: int add(a: int, b: int): return a + b end and exported functions looked like this: prop int test(): return 1 end It worked, technically, but it had started to annoy me more. The biggest issue was that function declarations did not visually match the direction Flower was already heading in, and instead felt much more C-like than I wanted. prop func create(...): Person func main(): int This style says “this is a function” up front, gives a clean place for modifiers like prop , and keeps the return type attached to the signature rather than awkwardly leading it. The goal was simple: func name(...): type instead of: type name(...): Simple in theory. not so much when the compiler is written in the language being refactored. The Problem Flower’s parser assumes top-level function definitions start with a type. Old parser logic was built around that: int main(): means: parse a type, an identifier, params, and a body That assumption was scattered through a few different places: normal function definitions prop function declarations forward declarations examples and docs the compiler’s own source Now, in retrospect, this was actually one of the easier changes. It didn’t take a whole lot of planning nor brain power, and I was able to change it pretty quickly. Luckily for me, I’ve built codegen to rely purely on ast values rather than shaping. The New Shape The new syntax is: func add(a: int, b: int): int return a + b end and exported functions now look like: prop func test(): int return 1 end This is nicer because: func makes declarations immediately recognizable prop composes more cleanly with func return types now live where people expect them to future syntax has more room to grow without feeling backwards It also feels more in line with Flower’s broader goals: explicit, readable, and not complex. The Refactor Previously, parse_func_def looked for a return type first: type name(...): Now it expects: func name(...): type So the order changed to: expect func parse function name parse parameter list expect : parse return type parse body until end That part was conceptually easy. The more annoying part was updating all the places that assumed if it isn’t a var decl and it looks like a func, it’s a func. That fallback had to go (Good riddance!). Instead, top-level parsing needed to become more explicit: prop func → exported function func → normal function forward func → forward declaration The old one worked, but it relied on vague “anything else is probably a function” rules. The Bootstrap Mistake At one point, I made a bootstrap build so I could use a Flower_new binary to compile the refactored compiler. Unfortunately, I had made a mistake in parse_forward : advancing before peek checks. Feel free to check out the bootstrapper to see why this was an issue ;) This meant my “new compiler to compile the new compiler” was built from a broken parser. The workaround was cursed, but it worked : check out the commit before the refactor fix the bug compile a new binary switch to the refactor branch use the binary to compile the new version Since the compiled binary was ignored by Git, this was actually fairly simple. Not the most elegant bootstrap story, but it got the compiler to, well, compile.
Devlog: Giving Flower Real Module Support v1.2.x was the point where Flower’s impors had to stop being “you can import stuff.. and there’s a fake layer of security” to a prop er (get it?) module system. Before this work, imports and aliases mostly behaved like naming conveniences. You could write: import "math.flo" as math math.add(1, 2) but the compiler was still too loose about what that really meant . Alias names were in emitted C symbol names, top-level declarations were not private, and prop existed more as syntax than as a real feature. That was fine for early bootstrap work, but it was not strong enough for the next stage of the language. So the main goal of v1.2.x became: make imported aliases act like real namespaces make prop define the public interface of a module make top-level declarations private by default lay groundwork for field visibility rules like hidden and readonly Module Semantics Instead of Alias Tricks One of the biggest changes was separating Flower semantics from C lowering. Previously, imported aliases were drifting toward becoming part of emitted symbol identity. A local alias should just be a source-level name bound to a module, not the backend symbol. So now each module has its own lowered symbol prefix, and alias lookup happens semantically during compilation. That means: import "math.flo" as math math.add(1, 2) is resolved as “look up exported add in module math.flo ,” not “invent a C symbol from the local alias text as math_add() .” That change also forced a cleanup of emitted names so they stopped leaking absolute filesystem paths. Generated symbols now use project-relative module prefixes instead of machine-specific paths. prop Became Real Another major part of this was making prop actually do something. Instead of treating it as a thin wrapper around only functions, the compiler now recognizes prop as a real top-level export marker. That means the module’s public interface is defined by what it explicitly exports, while non- prop declarations remain internal. This moved Flower closer to the model I wanted all along: explicit modules, explicit public APIs, no heavy object system (OOP), no fake privacy delegated to the C backend. Dot Access, Pointers, and the Annoying Middle Part This work also exposed a weakness in the compiler’s dot-access resolution. Flower source always uses . , while the C backend must decide whether a given access becomes . or -> . That mostly worked already, but nested pointer-heavy field chains exposed cases where the type tracker was not propagating enough information, which caused bad fallback behavior during self-hosting. So before field visibility could be trusted, I had to harden nested dot-access resolution. Not fun, but necessary. As it turns out, I was missing several AST kinds which caused the logic to fall through. Very tedious work, but it was well-worth it in the end! Field Flags Groundwork With module ownership and access resolution in better shape, I added the first field visibility modifiers: hidden readonly frozen Originally I debated having these as bitwise operations, but I decided it’d be best to stay within the current update’s scope, so sometime in the future I’ll refactor. Right now, hidden and readonly are the meaningful additions: hidden blocks external field access readonly blocks external assignment frozen is groundwork for later. It is parsed, stored, and carried through the compiler, but full assignment-once enforcement is still deferred. Unsure how I’ll go about it, but that’s an issue for future me :p
Devlog: Making Flower’s Bool Support Real Enough to Survive Bootstrap The goal sounded small at first: add proper boolean support, while still lowering booleans to integers in C. In practice, this turned into an overarching type-system problem (typical!). Flower had reached a point where bool could not just be a naming trick over 1 and 0 . The compiler itself needed to understand when an expression was semantically boolean, when it was integer, and when older bootstrap-era shortcuts were no longer valid. A lot of those shortcuts had survived because the backend lowers bool to int anyway. But self-hosting exposed a major issue: source-level typing and C lowering are not the same thing. Things like these started breaking: val: int = parser_peek(ps).kind == TOKEN_TRUE and helper predicates that returned comparison expressions from int -typed functions. So the checkpoint became: keep C lowering simple, but make Flower’s typechecker treat booleans as a real source-level type. The main changes were: parser -> typecheck -> codegen true / false now parse into AST_BOOL_LIT bool literals are still emitted as 0 / 1 in C logical and comparison expressions now resolve to bool arithmetic rejects bool operands if , while , and not now validate condition-compatible expressions variable initializers, assignments, and returns now check types more strictly One of the more annoying bugs turned out not to be “about bools” at all. When code like this failed inside the compiler: defined_structs[i].length emitted_imports[i].path the real problem was that for i in 0..count was never registering i in the type environment, so indexed access looked broken when really the loop variable itself had no known type. Once loop indices were typed as int , those field-access failures disappeared (yay!!). The result is a much better place to build from: bool is now semantically distinct in Flower it still lowers cleanly to integer values in generated C bootstrap works again the compiler is stricter without collapsing under its own source That makes the next step much easier: real string support, instead of trying to build strings on top of a type system that still half-thinks everything is an int .
Devlog: Fixing the Typechecker After Bool Enforcement Getting bool into Flower exposed a reallyyyy annoying problem: the typechecker had a couple of tiny logic mistakes (I’m so good at this) which caused the bootstrap to blow up in my face and I ahd no idea why. At first the errors looked unrelated. The compiler started reporting huge numbers of mismatches across main.flo , lexer.flo , module.flo , typecheck.flo , and codegen.flo . I was so confused as to why out of nowhere 903 lines were reporting various typechecking errors when they shouldn’t be. As it turns out, types_match() was the culprit. The function had been inverted in a few places: Mismatched base types and pointer depths were returning success, while normal matching primitive types were falling through to failure. That made the new compiler think ordinary initializers, assignments, comparisons, and returns were all invalid. Once that was fixed, the remaining failures turned out to be a second real compiler bug: pointer arithmetic over arrays was decaying in the wrong direction. Expressions like: mods.modules + j env.structs + env.struct_count arr + 1 should produce pointer types. Instead, the typechecker was reducing pointer depth when arrays decayed, which made perfectly normal indexed access and table walking look type-invalid. So this dev session ended up doing three important things: fixed types_match(...) so actual matches succeed and actual mismatches fail preserved decimal compatibility for float / double matching fixed array-to-pointer decay in pointer arithmetic so compiler internals and examples resolve correctly again What made this especially annoying is that the symptoms looked much larger than the cause. A couple of bad returns in the typechecker created hundreds of downstream errors, and because Flower is self-hosting, that meant the compiler started rejecting its own source. After correcting those core issues, both bootstrap and the example test suite started working again. That is the real value of issues like this: not just “fewer errors,” but restoring (MY) trust in the compiler and its ability to enforce Flower’s rules and report issues. With that stable again, the path forward is much clearer: continue bool work from a solid base, then move on to the remaining numeric and string improvements without the whole compiler collapsing under one bad predicate.
Devlog: Making Bool Real Without Breaking Bootstrap The original goal, asper usual, was straightforward: before moving on to string , Flower needed bool to actually mean something semantically. Up to this point, boolean-ish behavior mostly worked by accident. Comparisons, conditions, returns, and general expression checking were still loose enough that the compiler could get away with treating a lot of things as “close enough,” especially since the C backend ultimately lowers bool to int anyway. That was not going to hold once v1.3 started leaning on richer typing. So this was about drawing a clean line between Flower semantics and C lowering. The Goal In Flower: bool should be its own real type comparisons and logical operators should produce bool arithmetic should not quietly accept bool implicit conversion should stay narrow and predictable explicit casting should remain available through as In C: bool can still lower to int That distinction ended up being the easy part. What Changed The typechecker now treats bool as a proper language type instead of an int-shaped placeholder. Condition checks were tightened so if , while , and not use condition-compatible rules. Arithmetic paths now reject boolean operands, and return / initializer / argument checking now runs through more explicit conversion rules. I also kept implicit widening one-directional: int -> float -> double while leaving narrowing conversions as explicit casts. The actual implementation of booleans and their typing, enforcement, and semantics was a breeze. It’s what came after that got me. What Actually Broke As usual, bootstrap had opinions. The stricter type work exposed older weaknesses that were easy to miss before (This is my coping): function argument checks needed array-to-pointer decay alias and module call lookup paths were too narrow unresolved calls could prevent nested expressions from being fully type-resolved that, in turn, broke some dot-access lowering and caused bad . vs -> emission in generated C So part of this checkpoint turned into compiler stabilization work rather than just bool semantics due to my crappy ‘temporary’ logic, error handling — or lack thereof, and impeccable ability to miss very important details. I’m an amazing programmer, if you couldn’t tell :p Result Flower now has a much firmer semantic base for bool, and the compiler is back to bootstrapping cleanly with those rules in place. That matters because this was really the floor for the next part of v1.3: string . And.. maybe I’ll fix the bootstrap process so it doesn’t blow up in my face again. Oh yea, forgot to mention that. The bootstrapper bootstrapped itself into this very broken parser state that refused to go away so I had to stash my changes, checkout the prior merge (detached), and then recompile manually and fix the parser. Toodles!
Devlog: Building Flower’s String Type Foundation The core goal was to make this work in a meaningful, compiler-owned way: name: string = "Ivy" as string raw: @char = name as @char other: string = raw as string if name == other: print("same\n") end print(name.length) That meant Flower needed more than a typedef in generated C. It needed actual type rules, actual lowering rules, and I needed enough hairs on my head to not be bald after the amount of scares that occurred. What changed The first step was giving string real compiler support without going too far too fast. I added support for: explicit casts between string and @char string equality / inequality string.length runtime helpers in generated C for: flower_string_from_cstr(...) flower_string_eq(...) flower_print_string(...) That gave Flower a usable string foundation while still keeping literals conservative for self-hosting. Right now, string literals are not fully “native string values everywhere” yet; the compiler still uses explicit casts like "Ivy" as string as the safe bridge. The reason for this “safe bridge” is because when I got too ambitious, the compiler would break since everywhere @char was used with a string literal it’d break due to no implicity being allowed. I had to comment out the following new changes and keep the legacy support so it’d compile: else if ast.kind == AST_STRING_LIT: // fprintf(out, "flowe_string_from_cst(") // fprintf(out, "%.*s", ast.data._string.str_length, src + ast.data._string.str_start) // fprintf(out, ")") // LEGACY CODE HERE and else if expr.kind == AST_STRING_LIT: // set_plain_type(out, TOKEN_STRING) // LEGACY CODE HERE return 1 The part that broke The most annoying issue was not string equality or .length . It was print . Originally, non-string print(...) was basically lowered like this: printf ( expr ); That only works when expr is already a C format string. So something like: print(name.length) generated invalid C: printf ( name . length ); The fix was to make print(...) type-aware. Typecheck now records the operand type, and codegen lowers print differently for string , @char , char , floats/doubles, and integer-like values. That sounds small, but it matters a lot: once string became real, print could no longer get away with pretending every printable value was already a C string. An Unsolved Bootstrap Mystery Somehow Flower’s bootstrap process was breaking, and it will probably break again. Despite the bootstrap requiring it to compile itself, somehow afterwords the binary could become corrupted. l-2: ~/Documents/GitHub/FloC % make bootstrap === Building new version === Compiled ./bin/Flower_new.c → ./bin/Flower_new === Testing new compiler === Compiled ./bin/Flower_test.c → ./bin/Flower_test Verified bootstrap build complete l-2: ~/Documents/GitHub/FloC % make bootstrap === Building new version === Luckily, I always make sure to keep a backup Flower bin stored under /bin/Flower_backup so I used that to compile the new binary and then it worked. Where this leaves v1.3 What still remains is the bigger ergonomic question: how fully native string literals should behave, and how to migrate the compiler’s own source to that world without setting bootstrap on fire again. I’m not sure yet how I want to approach this question, or what the goals for it should even be, but I guess I’ll have to find out soon enough! That is the next fight. But at least now, it is a fight on solid ground.
Devlog: Finishing Flower’s String Interop Bridge The last round got string into Flower as a real type. This round was about making that foundation actually work lol. The big problem was that once string became real, plain string literals started living in an in-between state: Flower wanted them to mean “Flower string,” but the compiler’s own source still has plenty of places that really mean “raw C string,” like: RED: @char = "\033[0;31m" if not strcmp(arg, "help") or not strcmp(arg, "h"): ... end Those cases worked before only because everything was basically pretending string literals were already @char . Once that stopped being true, bootstrap started throwing a fit (my spoiled child). What changed The main fix was to make string literal lowering contextual instead of all-or-nothing. If a literal is being used as a real Flower string , it stays a string . If a literal is being used in a C interop position, it gets lowered as a C string instead. That meant tightening a few compiler rules so this kind of thing works cleanly again: name: string = "Ivy" as string raw: @char = name as @char if strcmp(raw, "Ivy") == 0: print(name) end I also fixed top-level declarations so globals like: RED: @char = "\033[0;31m" no longer generate nonsense like: char * RED = (( flower_string ){ ... }); which, unsurprisingly, C does not appreciate. The subtle compiler bug The nastiest issue wasn’t even the globals. It was that builtin C calls like strcmp , strncmp , printf , snprintf , and friends are not real Flower functions. That meant the typechecker could hit one of them inside a larger expression, fail early, and stop walking the rest of the tree. So something like: if not strcmp(arg, "help") or not strcmp(arg, "h"): could partially resolve one side, then leave the other side unprocessed. Very cool. Very stable. Definitely what I wanted. The fix was to add a temporary builtin C-call bridge so the compiler can recognize these calls well enough to keep type resolution and literal lowering consistent during bootstrap. I’m not happy with this fix by any means, but due to the limitations of emitting C, it was the only solution I found that made sense at the time. Tests and examples Once that stopped exploding, I finally wired string testing into the normal types suite instead of leaving it commented out and pretending I’d “get back to it later.” The string tests now cover: string <-> @char casts string equality / inequality .length empty strings printing strings literal use in current interop cases And the full test suite passed with string included as a first-class part of Types on its first try . Now that’s what I like to see :D What this means This does not mean Flower’s long-term answer is “hardcode libc into the compiler forever.” It means Flower now has a temporary interop bridge that keeps self-hosting stable while string is worked on. The actual language semantics stay in Flower; the backend-specific weirdness is just being tolerated for now so progress does not stall. In the near, I’ll probably replace all of the necessary C libs with minimal Flower-equivalents. Where this leaves v1.3 At this point, the string foundation feels much sturdier. Not “done forever,” not backend-agnostic, and definitely not free of cursed bootstrap energy — but it works. The next work is no longer rescue work. It is actual forward work: string operations, stdlib basics, and eventually replacing this temporary C bridge with something cleaner when Flower grows past the C backend.
Devlog: Adding String Indexing to Flower This one was fairly quick, and was about making one very normal-looking thing actually work: name: string = "Ivy" as string first: char = name[0] That sounds small, but once string became a real Flower type, indexing could no longer piggyback on the old “arrays and pointers only” behavior. The compiler needed to understand that string[index] is its own case. What changed I taught the typechecker to treat string subscripts as char . That means: string[index] now resolves to char the index expression must be an integer string indexing is readonly for now So this is valid: first: char = name[0] but this is not: name[0] = 'X' I wanted reads first, writes later. That keeps the rules simple while the string representation is still compiler-owned. I’m not sure how writes would work with a C backend, due to how ‘strings’ are allocated. Perhaps a feature for post-v2.0? Lowering it to C Since Flower strings currently lower to a struct with .data and .length , codegen needed a special path for string subscripts. Normal arrays and pointers still lower like: arr [ index ] but strings now lower like: name . data [ index ] That keeps the generated C valid without changing how regular subscripts work elsewhere in the language. So something conceptually like: This checkpoint also forced one strict-but-correct rule that required me to update a WHOLE SINGLE LINE (hehe): arg[i] = tolower(arg[i] as char) to arg[i] = tolower(arg[i] as char) as char Because tolower(...) is effectively treated as returning int , assigning it back into a char subscript needs an explicit cast. I kept that strictness on purpose. I do not want Flower silently narrowing values just because C would let it. Validation I expanded the string example coverage to check: string indexing returns the expected chars string[index] works alongside string <-> @char casts bootstrap still succeeds repeated bootstrap succeeds tests still pass Which, after all the recent bootstrap chaos, was very nice to see. Where this leaves v1.3 Now we can: store strings compare strings print strings inspect length index into them as char This should make it much easier to replace the builtin C functions with a Flower library in the near-near future.
Devlog: Fixing Flower’s Output Driver and Starting the String Stdlib This checkpoint was really two different kinds of progress that ended up helping each other a lot. The first part was not glamorous, but it was necessary: Flower’s compile driver was tripping over its own default output naming. This was a known issue that I had been putting off, but for some reason it really annoyed me this time so I decided enough and to fix it. If no explicit output path was provided, the compiler would generate output.c , then strip the .c and try to emit a binary named output . That worked fine right up until the repo itself already had an output/ directory. At that point, linking failed because the compiler was trying to create a file where a directory already existed. Worse — because it annoyed me more — the driver logic was also mixing up “the generated program exited non-zero” with “compilation failed.” That became especially annoying during bootstrap, because the generated compiler binary would run without CLI arguments, print its own usage error, and then cause bootstrap to report failure even though codegen and C compilation had both succeeded. So I finally got off my butt and cleaned that up. Driver Cleanup The default output path now goes to: output/out.c which naturally produces: output/out as the binary. That avoids the old output filename collision. I also separated compile success from auto-run behavior: explicit output path: compile only default output path: compile, then auto-run if appropriate That means bootstrap no longer “fails” just because the compiled compiler exits non-zero with missing arguments, and demo/test files can still run automatically when that is actually useful. This sounds like a small driver fix, but honestly it removed a lot of noise from string work — and more — immediately. String Stdlib Beginnings Once that output weirdness was under control, I could finish doing what I just started and actually wanted: making string behavior live in Flower instead of endlessly leaning on ad hoc C calls (Call back to last devlog, absolute ball knowledge!!). So I added the first real reusable helpers in src/stdlib/string.flo : is_empty(s) starts_with(s, prefix) ends_with(s, suffix) find_char(s, ch) These are intentionally simple. They mostly exist to prove that the current string support is now strong enough for normal library code to be written on top of it. Not incredibly useful, at least at the level the compiler needs, but at least I could translate some AP Comp Sci A into Flower hehe A string feature does not really feel “real” until I can build helpers with the language itself instead of only teaching the compiler more special cases. The day I remove the builtin C handlers is the day I’m at peace… Validation To exercise that new library surface, I changed string_pass.flo to now act as a small pass file for the experimental library. Its job is not to be impressive. Its job is to answer a more important question: can I import string helpers, call them from normal Flower code, and get expected results through the full compile pipeline? At this point, yes. Where this leaves things This checkpoint did not remove all C string dependencies from the compiler. In fact, it removed essentially none! That is still a separate step, one that may even be in v1.3.7 ;) But it did establish two important things: Flower’s output/driver behavior is now much less annoying. We can start growing a real string library in Flower itself. That is a good place to be, because the next string work can build outward from a stable driver and an actual library surface instead of piling more special behavior into the compiler.
Devlog: Giving Flower an Internal cstr Foundation Even after Flower got a real string type, the compiler itself was still leaning directly on C-style string helpers for its own internal work. That meant a lot of Flower source was still semantically depending on libc behavior: !strncmp(...) strcmp(...) strlen(...) strcpy(...) strncpy(...) strdup(...) strrchr(...) That is not where I want the language to stay. What changed I added a new internal module: import "src/stdlib/cstr.flo" as cstr and gave it compiler-facing helpers like: prop func len(s: @char): int prop func eq(a: @char, b: @char): bool prop func eq_n(a: @char, b: @char, n: int): bool prop func copy(dst: @char, src: @char): @char prop func copy_n(dst: @char, src: @char, n: int): @char prop func dup(src: @char): @char prop func find_last(src: @char, ch: char): @char This helper module is essentially the precursor to a future strings.flo library that can be distributed. But for now, it uses a basic API layer purely meant for in-house usage. Then I migrated compiler internals over to that module across: src/parser.flo src/module.flo src/lexer.flo src/typecheck.flo src/codegen.flo src/globals.flo src/main.flo So instead of using C-string behavior directly everywhere, the compiler now goes through Flower-owned helpers first. The Compiler Strikes Back This was one of those changes that sounds mechanical until it absolutely is not. A big trap was that old code often relied on C comparison functions returning 0 on equality, so patterns looked like this: not strncmp(...) But cstr.eq_n(...) returns an actual bool , which means blindly rewriting those calls gives inverted logic. So this: if ps.alias_lengths[i] == tok.length and not cstr.eq_n(...): was completely wrong. It had to become: if ps.alias_lengths[i] == tok.length and cstr.eq_n(...): That bug showed up in alias parsing first, which made it especially cursed, because it caused normal namespace-style calls like cstr.eq(...) to stop parsing correctly and crash the bootstrap path in confusing ways. I spent way longer than I wish to admit on trying to figure out why it wasn’t playing nice. But, once I figured it out, it was a really quick fix (I literally just cmd + f ’d not cstr and replaced it with cstr lol). Are we done yet..? This does not mean Flower is free from the C backend yet. It does mean something important, though: compiler logic is starting to depend on Flower-defined helper semantics instead of scattered raw libc calls. That is a much better stage for the future backend story, because when C eventually stops being the primary lowering target, the compiler will already have more of its own vocabulary. In other words, this was less about “remove C” and more about “stop letting C define the language’s internal habits.” Nah just kidding, I really wanted that bloated “builtin_c_call” stuff gone. Unfortunately I only managed to skim it, but that’s closer than before! Result After fixing the migration mistakes and the alias/parser fallout, the compiler bootstrapped successfully again. Flower now has an internal cstr layer, and compiler string handling is a little more its own.
Devlog: Cleaning Up v1.3 For Release After many hours of work, bool and `string finally became real, and it was time to cleanup the mess I left behind from the version’s development. Mainly the only thing worked on was some cleanup: roadmap now reflects actual v1.3 features and implementations updated README and contribution documents to match the current compiler pipeline cleaned up string examples so they have the full intended v1.3 style instead of some leftover testing usage pushed the compiler’s version to 1.3.0 updated help / usage text so it matches the new output-path and auto-run behavior Prior to this, if I had just merged and shipped, the release wouldv’e been messy: README, Contributing, example files, and guidance commands were all mixing older details which made it confusing — even for me — when trying to explore the language and what it has to offer. For a bootstrapped compiler especially, making sure everything is cleaned up and polished is something that should not be ignored. I’m definitely guilty of overlooking this, but I’ve outlayed a whole plan for v1.3 unlike past versions, and part of it was setting up a proper versioning system and polishing its release as it goes. This format will be adopted in future versions, since it’s just way cleaner and nicer to look at. Future work At this point, v1.3 is done and has implemented, at minimum, a concrete foundation for post-v2 bools and strings. Next will likely be more subtle improvements, and features that are currently reliant explicitly on C rather than Flower-hosted code. In order for v2.0 , Flower will have to be effectively independent from C if it wants to emit machine code. Currently I am planning on adding features such as Type Aliases and maybe a stdlib prior to that, but anything can change!! Thanks for being here for all of v1.3 <3
Devlog: Making Flower’s Type Aliases Transparent This version was simple to develop on paper (and even in practice it wasn’t too bad, only around 4 or so hours!): type Count = int type Total = Count type Name = string and then have those aliases behave like the real type everywhere: n: Count = 12 total: Total = identity(n) name: Name = "Ivy" if name != "Ivy": return false end if name.length != 3: return false end That meant aliases could not just be parsed and stored, but rather had to be transparent to the compiler’s semantic checks. What changed I added type alias declarations to the AST, parser, and type environment, then added the ability to resolve aliases in typechecking before comparing types. That included: return type checks variable initializers function call arguments binary comparisons string-specific comparison logic struct field access The important rule here is that aliases are semantic, not codegen-facing. Count should behave as int , Name should behave as string , and chained aliases like Total -> Count -> int should collapse correctly. In the future, especially post v2.0 , this could change and custom types might become real — but for now, they’re just aliases. The bug that exploded bootstrap The first real failure was not in aliases themselves, but in function argument checking. Inside check_call_args(...) , the compiler was resolving the argument expression into expected_type instead of arg_type . That overwrote the parameter type, left the actual argument type uninitialized, and caused the second bootstrap stage to explode into over a thousand misleading errors. This was not a pre-existing issue, it was instead from human error (my error) during the initial implementation where I accidentally put the wrong variable. Once that was fixed, the remaining failures were much more helpful than the bright flash of red and “Typecheck failed with 1224 error(s)” message! Where this leaves v1.4 With the first step toward “better types” done, aliases are no longer just syntax. That gives v1.4 a solid base for whatever comes next in the type system without having to fake around raw names. During this whole dev session, I did discover that a whole lot more of the source code was left using legacy work-arounds: int instead of bool , name_start; name_length and @char instead of string . In all fairness, some of these aren’t exactly the easiest to refactor. However, I will probably hold off on refactoring the codebase until either right before v2.0 , or right after. Just know it’s on my radar ;)
Devlog: Fixing Flower’s Compiler Process So It Stops Fighting the Host This wasn’t really about language design at all buttttt it is much more embarrassing , AND more important: Flower’s compiler process itself was too fragile. The immediate issue showed up on Linux, specifically NixOS (thanks shipwrights <3). The build flow was assuming too much: a previously existing bin/Flower could be reused safely bash would exist at the expected path clang would always be available the checked-in compiler binary would be runnable on whatever machine the repo landed on That worked well enough on my machine until it didn’t. On NixOS — and by extension probably any other machine without the prexisting binaries I had — it broke: make targets were inconsistent, the shell script failed on interpreter assumptions, and the compiler binary itself could be the wrong format for the host. What changed The fix was to separate “the compiler source exists” from “the current compiler binary is usable on this machine.” The build process now starts by compiling a fresh host-native bootstrap compiler from bin/Flower.c , instead of trusting whatever happens to already exist in bin/Flower . That means the flow is now: bin/Flower.c -> host-native bootstrap compiler -> new Flower compiler -> self-check instead of: maybe existing bin/Flower -> hopefully works -> maybe bootstrap Ok well that’s kinda a lie; it still relies on hopes and dreams to bootstrap sometimes. BUT it’s MUCH safer! And now everyone gets to experience crippling bootstrap anxiety, instead of being met with a failure before the actual compiler gets to.. well, do its thign! I also cleaned up the surrounding tooling: switched the bootstrap script to portable sh restored a clearer build / bootstrap / rebuild / test / clean structure made the compiler use CC and CFLAGS from the environment instead of hardcoding clang What this actually improves Flower is still not universally cross-platform yet. The compiler driver still has POSIX-shaped assumptions in places, and the emitted C can still depend on host APIs depending on what the program uses. I’m not yet at the point of wanting to make it completely universal, especially given how I’m only one person and with v2.0 coming up soon it’d — in my humblest of opinions — be a waste of time. I am honestly grateful for people reviewing my code and otherwise viewing it catching onto details I have overlooked. My goal is to not make a ‘just-barely working on my machine’ project; I enjoy sharing development with others, and it hurts knowing people can’t appreciate code, whether it be mine or others’, due to something as simple as hard-coded sh flags.
Devlog: Formalizing Flower’s Null Foundation Flower already had some of the pieces for null , but they were a bit scattered. The goal here was to make it explicit, consistent, and safe before moving on to nullable syntax like ?T or full union-based nullability later in v1.4 . Another shorter devlog, but still important and distinct enough for me to think “Hmm devlog time? Yes, devlog time!” What changed The main work was in typechecking. I added to the compiler’s idea of what null is, how it is represented internally, and what kinds of values are actually allowed to accept it. Rather than letting null-related behavior stay implicit across a few checks, null now follows a clearer rule set: null has one centralized internal type representation pointer-like values can explicitly accept null null comparisons and assignments now go through the same semantic path Why this matters This isn’t all that important on its own, but it matters a lot for where Flower is going next. If null is not defined well, then later features like: ?T better unions smarter narrowing more expressive type flow all become more error-prone (or so I assume given my track record) than I want need them to be. Validation I also expanded the example coverage so null : it now has dedicated behavior checks around assignment, passing values around, and comparison behavior.
Devlog: Adding Pointer-First Nullable Types to Flower I worked on giving Flower its first real nullable type surface without being overambitious and pretending the compiler is ready for full optional-everything semantics yet. The new syntax now works like this: ptr: ?@int = null text: ?@char = null That means there is now an explicit way to say “this pointer-like value may be absent,” instead of relying entirely on raw pointer habits from C (If you couldn’t tell by now, I despise C). What changed The main work was split across lexer, parser, and typecheck. I added: ? as a type marker in type positions is_nullable tracking in TypeInfo type rules for nullable pointer/reference values explicit compatibility for: assigning null into nullable pointer-like types comparing nullable values against null casting between @T and ?@T I also kept the scope intentionally narrow: this implementation is pointer-first nullable support , not full nullable scalars. So ?@int makes sense right now, but ?int is still deferred until I make a better semantic union / optional representation for plain values. Why this matters It would have been easy to overreach here and claim “nullable types are done,” but that would have been a big phat lie. Pointer-like nullability lowers naturally enough with the current backend and current compiler model. Scalar nullability, however, does not. Once you let int or bool become nullable, you need a more real representation for “has value / no value,” and that belongs in the later union work, not here. Result explicit absence compiler-owned semantics better future unions stronger type meaning without hidden magic The next real step after this is not more patching around null — I consider that done for now — but instead giving Flower the deeper machinery needed for nullable non-pointer values and semantic unions later in v1.4 so it doesn’t come back to bite me in my butt.
v1.4.4 Devlog: Giving Flower Real Semantic Union Types I made it so that semantic unions are now in Flower’s parser and type system — but not yet its codegen. The goal was to support types like: value: int | string next: @Node | null type Result = int | string What’s new The parser now understands | inside type positions and builds semantic union type information instead of relying on those old plain aliases or backend-shaped hacks. On the typecheck side, unions are now carried through normal type copying and alias resolution. That means named aliases like: type MaybeName = string | null make sense after resolution, instead of collapsing into nonsense. The typechecker also now accepts union-compatible usage in the places that matter for a foundation: variable initialization assignment parameter passing return checking alias resolution So if a value matches one union member, it is accepted. This is sorta implicit behavior, but I think it gets a pass due to its somewhat explicit nature? What it does not do yet This version was intentionally strict about using unions as values. You cannot yet directly: index a semantic union access a field on a semantic union use arithmetic / comparison operators on one print one directly Instead, Flower now requires an explicit cast before using a union value that way. That may sound harsh, but it is the right restriction.. for now. There is not any narrowing yet, so pretending unions were fully usable would just make the language lie and spit out 2,000 errors. Where this leaves v1.4 Flower now has: transparent type aliases null as a real type-system concept pointer-first nullable types semantic union type representation The next step is the part that will make unions actually usable rather than merely legal: narrowing with is better explicit extraction with as eventually making ?T truly become T | null instead of remaining pointer-first for now No fun screenshot this time :p just frontend work for now… Ivy, signing off <3
Devlog: is Checks v1.4.5 added is checks, mostly so code like this can work: if maybe_ptr is @int: real_ptr: @int = maybe_ptr end The idea is (fairly) simple: if the condition proves maybe_ptr is an @int , the inside of the branch should be allowed to treat it like one. Flower did not know how to do that before. It knew what a variable was declared as, but it did not really learn anything from control flow yet. Now it can, at least for the pointer/nullable-ish cases I care about first. This touched the parser, AST, typechecker, narrowing logic, and codegen. So, naturally, the “small feature” went everywhere. I’d actually consider this one of the bigger refactors so far, mostly because it added a new TypeAtom structure. Before this, types were still a bit too attached to the places they appeared, and all fell under the TypeInfo . That worked for simpler declarations, but is checks needed type syntax to have something the compiler could pass around to use for comparisons, validations, and narrowing. The parser had to recognize the new expression shape. The AST had to store the left side and the tested type. The typechecker had to make sure the test was allowed and not totally garbage. Then the narrowing logic had to say, “inside this branch, this variable has the proven type of x and therefore we won’t flag you for being an idiot.” That last part was where the bug goblin lived. I’m calling them a goblin because they were sneaky (and I also think it’s quite a funny and cute name). For a while, Flower had applied narrowing from the if body instead of the if condition, which meant the compiler saw this: if maybe_ptr is @int: real_ptr: @int = maybe_ptr end and somehow still failed on the assignment inside the branch. Very helpful. Thank you, compiler. EVen though it’s obviously 100% my fault, I made the compiler, but oh well!! Once I changed the narrowing step to inspect the actual condition expression, it started behaving like it should. The typechecker could see maybe_ptr is @int , attach that narrowed type to the branch scope, and allow maybe_ptr to be used as @int inside the guarded block. For now this explicitness is how I want it. There may come a time in the near future where I decide some implicity is ok, but we’ll see ;) is checks are the first real step towards control-flow-aware typing in Flower. Not full union support yet, but definitely the beginning of that road soon to come. Right now it mostly helps with nullable and pointer-like cases. Later, the same idea can support richer unions, better narrowing, and more type-driven control flow without making the programmer manually restate everything the compiler should already know. Also, it bootstrapped cleanly twice — which.. is obviously the bare minimum, but still!!
Devlog: Semantic Unions Become Actual Values (Part I) In v1.4.6 , I made semantic unions actual runtime values instead of just parsed/typechecked shapes. Before this, Flower could understand: type Value = int | string as a type. It could point at it and say, “yes, that is a union,” but that was mostly theoretical. The goal was to make this work-work for realsies: type Value = int | string value: Value = 7 if value is int: n: int = value as int end value = "Ivy" if value is string: s: string = value as string end That meant Flower needed more than TypeInfo.is_union = true . It needed a full path from syntax, to type proof, to lowered storage, to runtime extraction. Otherwise unions would just be fancy typechecker thingy-ma-bobbies, which is not very useful when the backend still emits C. What changed Instead of treating a union as a vague “one of these types, probably,” Flower now lowers it into a tagged structure. Conceptually, this: type Value = int | string becomes something like: struct Value { int tag ; union { int as_int ; flower_string as_string ; } data ; }; Not the final sacred form forever, but that is the shape of it: a tag saying which variant is active, plus storage for the possible members. Since Flower emits C right now, the lowering is C-shaped. I am not fully sure how I want this to look in ASM yet, but I do know it would be way more technical, and uglier. This required a few things to play nicely with one another: if value is int creates a union proof the guarded branch stores narrowing information value as int is only allowed after proof assignments pack values into the right tagged member explicit casts extract the right member from storage Otherwise the compiler is just writing checks its own backend cannot cash. The part that makes it ACTUALLY semantic For pointer narrowing, if value is T mostly refines how the compiler treats an existing value. For semantic unions, the check also becomes a runtime tag test. So this: if value is int: means: check the active tag of value , then inside this branch, treat it as the int variant. Then this becomes valid: n: int = value as int because the branch already proved the active variant. Without that proof, value as int should not be casually allowed. Flower is supposed to be explicit, not psychic, and I am not confident enough yet to implement a proper intuitive implicit checker without summoning something cursed. Assignment and extraction This: value: Value = 7 now packs 7 into the int member and sets the tag to the int variant. Then this: value = "Ivy" does the same thing, but for the string member. So a semantic union is not just some bytes, but rather a tagged runtime object where Flower knows which member is active. Then explicit casts like: value as string can lower into extracting the string member, but only when the typechecker has accepted that the operation is safe in that control-flow path. Why this checkpoint matters Flower can now store variant values, prove which variant is active, and require explicit extraction instead of relying on random magic I threw together. The flower has grown another concerning little organ.
Devlog: Letting Semantic Unions Work In Functions After getting semantic unions working in local declarations, the next problem was fairly obvious (and in my roadmap hehe). This did not work before: func make_value(): int | string return 7 end func accept_value(value: int | string): bool return value is int end Which was annoying, because int | string was already a real union type at this point. Flower could use it in locals, it could pack assigned values, it could check variants. But if I returned 7 from a function declared as int | string , or passed 7 into a parameter expecting int | string , the compiler did not know how to carry that union-lowering information across the boundary. This has been one of the easier changes I’ve made in a long while. It compiled properly first try (if you ignore a tiny misspell I made which I fixed really quickly), and there were no prior hidden bugs that surfaced. This.. is too suspicious. What changed The compiler now carries semantic union info through: function parameters function returns imported alias calls If a function expects: int | string and I call: accept_value(7) typecheck records that 7 needs to be packed as the int member of that union. Same for returns: func make_value(): int | string return 7 end That matters because codegen cannot guess later due to the separation of responsibilities I’ve laid out. By the time Flower is emitting C, it needs to know which tag to set and which member to write. Lowering it properly Codegen already knew how to pack union values for declarations and assignments. The missing part was doing the same thing for call arguments and return statements. So now a value can be packed into a tagged union when it is: stored locally passed into a function returned from a function Alias calls got handled too, so things like: remote.accept(11) remote.make_string() do not become their own weird little cursed island. Why this mattered Without this, semantic unions only worked as long as I never organized my code. They worked in local tests, but not in helper functions, imported providers, or normal inputs and outputs. Now union values can actually move around the program instead of being trapped in the one scope where they were declared — and for me, forgotten! Very exciting, the union can leave the house. They grow up so fast ⁎⁍̴̛ ₃ ⁍̴̛⁎
Devlog: Adding Obvious Branch-Local Inference to Flower Before this, narrowing mostly worked in the obvious “true branch” cases: if maybe != null: real: @int = maybe end and: if value is string: s: string = value as string end But the else branch was still kind of standing there empty-headed, even when the meaning was extremely obvious. Like, if this happens: if maybe == null: return false else: real: @int = maybe end then inside the else , maybe is clearly not null. So now it doesn’t!! What changed Flower now does branch-local narrowing in else for small, explicit cases. That means these now work: if maybe == null: return false else: real: @int = maybe end and: if value is int: return false else: s: string = value as string end It is only applying inference when the condition says something directly and the opposite branch has one obvious meaning. Nullable narrowing For nullable pointer-like values, Flower now understands both sides of simple null checks: if x != null narrows x to non-null in the if body if x == null narrows x to non-null in the else body the opposite side can narrow to null when that is the only meaning left Semantic union narrowing The same idea applies to semantic unions, but a bit more ‘held back.’ Essentially, if Flower sees: if value is int: then the if branch narrows to int , like before. Now, if the union only has one other possible member, the else branch can narrow too. So for: int | string the else after if value is int can be treated as string . This is not full control-flow wizardry, since it doesn’t reason across deep boolean chains, early-returns, or giant branches yet. It is deliberately small and local, because I do not want Flower “helping” so much that I need a detective board to figure out what type something is.
Devlog: Teaching Flower to Understand Guard Clauses gave Flower branch-local inference. Last update, I added support for branch-local inference, so the compiler could understand things like: if maybe == null: return false else: real: @int = maybe end and: if value is int: return false else: s: string = value as string end That was an improvement, but it still meant narrowing stopped at the end of the branch. That meant stuff like returninging in some conditions still did not really work as naturally as it should: if maybe == null: return false end real: @int = maybe or: if value is string: return false end n: int = value as int In v1.4.9 I fixed that. What changed Now narrowing propagates past very obvious guard clauses. If one branch definitely returns and the other falls through, the compiler now carries the interpretation forward after the if . This means that the compiler can now understand: after if x == null: return ... , x is non-null after if x is string: return ... , a two-member semantic union can narrow to its remaining member I kept this intentionally conservative for now. The compiler is not doing full control-flow analysis yet. It is only recognizing the simplest and most explicit early-exit shape. How it works The main addition was a small semantic check for “does this branch definitely return?” Right now that means: direct return if where both branches definitely return Once the compiler knows one side exits and the other survives, it applies the branch’s narrowing to the following statements. Yea.. that’s it lol.
Devlog: Making ?T Actually Mean T | null Before v1.4.10 , ?T was treated as its own nullable system and not really integrated with the rest of the semantic unions. This was unideal, because it created a separation of logic which was cumbersome to maintain. The idea was to make the following be the default: ?int == int | null ?string == string | null ?@int == @int | null Prior to the refactor, nullable types were still mostly pointer-oriented. That worked when ?T basically meant “maybe this pointer is null,” but it did not really fit anymore once semantic unions became actual runtime values. If Flower has T | null , then ?T should use that instead of being its own special thing. This is a more pragmatic choice, as it keeps the compiler easier to manage and update later on. What changed Typecheck now lowers ?T into the same semantic-union machinery used by normal unions. That means nullable values now go through the same general path as union values: null checks use union-aware narrowing narrowed nullable values can be extracted with as codegen emits tagged union storage assignments pack into the right union member So this now works as an actual nullable flow: maybe: ?@int = raw if maybe == null: return false end real: @int = maybe as @int The annoying part is that Flower has to track two things at once: the type the programmer is allowed to see after narrowing, and the actual union shape that remains underneath it. After the guard, maybe behaves like an @int . But codegen still has to remember it came from @int | null , because apparently the compiler cannot simply “vibe” its way through storage layout. Tragic! The bugs that annoyed the heck out of me Most of the work was not surface syntax. The syntax was just standing nearby looking innocent. The actual bugs were in the places where Flower knew “this is non-null now,” but then forgot how to lower, such as: narrowed nullable values falling back to raw C casts like (int*)(maybe) false branches of == null / != null narrowing to the wrong side (this was my fault lol) null getting packed into the wrong union member That last one was the rude one. For ?@int , generated C could end up doing something like: . tag = 1 , . m0 = NULL instead of packing into the actual null member. So the value looked almost right, but the tag/member pairing was wrong. Then later null checks would fail, because the compiler had technically put null somewhere. Just not the correct somewhere. Very helpful. The fix was separating two questions I had accidentally merged: is this type compatible with this union? which exact union member should this value occupy? Those look related, but they are not the same question. Flower was using the first answer for the second problem, and then acting surprised when everything became soup. Where this leaves Better Types ?T now lowers through the same path as T | null , which means null checks, narrowing, extraction, and storage all line up with the semantic union model. This should make later work cleaner, such as nullable inference, nicer union ergonomics, maybe pattern-like narrowing eventually. Not easy. I am not saying easy near a compiler. That is how they hear you. You do not want them to hear you ..
Devlog: Direct Semantic Union Parameters Now instead of having to do this workaround: type Value = int | string func accept(value: Value): bool You can just pass semantic unions directly: func accept(value: int | string): bool That was it. All I had to do was remove a stale type_error clause in register_params and allow binding variables. Then I updated the two relevant accept functions in /examples.
Devlog: Letting Union Narrowing Follow Field Access Before v1.4.13 , union narrowing only really worked when the thing being narrowed had a variable name due to almost every similarity check relying on name_start and name_length . This was dumb, because semantic unions already knew how to test tags and extract members. Codegen was not the issue, but rather the annoying part was that the typechecker could remember this: if value is int: n: int = value as int end but not this: if box.value is int: n: int = box.value as int end So I still had to do a little temp-variable ritual: tmp: Value = box.value if tmp is int: n: int = tmp as int end Which was gross. Not necessarily catastrophic, just gross and annoying. I wanted needed convenience What changed The compiler was remembering narrowings by variable name, not by expression shape, so box.value looked obvious in source (to me, at least), but to the typechecker it was basically some random expression and not something it could reliably recognize again later. A variable name already had a stable identity, whereas field access chain did not. So the change was to let narrowable expressions represent more than just AST_VAR_REF . For now, that only means stable dot-access chains. The typechecker can record a narrowing for an expression like: box.value and then recognize the same expression later when a cast shows up. So this works directly now: if box.value is int: n: int = box.value as int end Same for the other union members, like string . The detour My first example accidentally wandered into a different feature: if maybe_box.value != null: That exposed a real nullable-field-guard gap, but that is not what this was supposed to be about. Very rude of the test case to have ambition hmph >:( Where this leaves it Semantic union narrowing now persists past field access — at least for stable dot-access chains — and the temp-local is no longer needed. Butttt now I gotta work on nullable-field-guards, ugh (hehe)
Devlog: Finishing Nullable Field Narrowing At this point, Flower could already narrow semantic unions through field access in the is / as case, and nullable field checks were supposed to be the obvious follow-through: if maybe_box.value != null: label: string = maybe_box.value as string end Instead, I had forgotten to remove a LOT of stale code, and thus part of it was still behaving like only plain local variables could ever be narrowed. There was also a second, smaller mismatch hiding, where null in type position was not lining up with the compiler’s actual internal null representation. ?string and string | null weren’t leading to a congruent output and at times were wobblier than they should be. So the fix was mostly cleanup, but the meaningful kind: make null in type syntax lower the same way the compiler expects remove the stale var-only branches in nullable narrowing let stable field paths like maybe_box.value and holder.box.value narrow properly The funny part is that this felt bigger initially than it actually was once fixed. Nothing fundamentally new had to be invented, I just had to stop the old code from interfering with the newer code, which once I figured out how to do so it was quite quick. I spent an embarrassingly long time figuring it out…
Devlog: Syncing Flower’s Docs Back to Reality Just a doc cleanup lol. No code change or compiler updates. Probably did more than needed for now but oh well! The mismatch was REALLY bad. The old docs preserve old assumptions, and someone reading them could walk away with a version of Flower that no longer really exists (or, in some cases, doesn’t exist yet or never ever existed)! What changed I updated the docs that had drifted the most from reality (relatable): README.md now reflects the current type-system shape ROADMAP.md treats v1.4 as accomplished the v1.4.0 milestone doc now includes more of the outcome, not just the original plan contributor docs no longer have stale semantics structure.md is more accurate to what Flower currently is, and what still needs a fuller rewrite later Yea, that’s it.
Devlog: v1.5.1 – v1.5.5 Following all of the changes Flower has undergone, I felt it was time for some much-needed documentation. On paper this was supposed to be fairly quick, simple, and not require much brain power. Unfortunately for me I got a bit too over-zealous, and included things I thought should work, but in reality hadn’t. For example, in a lot of the code snippets I’d have something like: for i in range 0..10: print(i) end Printing non-string values was not yet supported in Flower. To fix this, I took a small detour back to v1.4 and implemented support for it — mostly in a single codegen case: if ast.data._print.value_type.base == TOKEN_FLOAT or ast.data._print.value_type.base == TOKEN_DOUBLE: fprintf(out, "printf(\"%%f\", ") gen_expr(ast.data._print.value, out, src) fprintf(out, ");\n") end Afterwards I added more smoke-tests in examples/io/print.flo . Every few runs, however, I’d get a segfault. This was especially odd because it wasn’t simply an error but rather a silent memory bug. Eventually I found out where it was originating — thanks, ASan! Turns out after the new type system changes, I had forgotten to initialize some values to null / 0 in for loop handlers and a few other places. I just added typeInfo.data = null / 0 where applicable and it fixed the issue! What is v1.5, and why is this devlog so long? To answer the latter first.. I lowkey just forgot to post a devlog for the first two docs I made. That’s it. For the former question, v1.5 is supposed to be explicitly a documentation pass. First thing I worked on was structure. I cleaned up the docs layout, moved things toward a more consistent lowercase docs/ tree — I had been trying for so long to do that and I just finally got it to work — and wrote down the documentation process itself so new pages aren’t just floating about. The point was to try and make the docs feel like a book instead of a folder full of unrelated notes. I wrote and checked the language pages for types, functions, and control flow by reading the compiler itself, not by trusting my (poor) memory. That meant checking parser rules, typecheck behavior, codegen boundaries, and example files before writing anything solid. Types especially needed this, given how Flower now has enough real type machinery that the docs can quickly go from being coherent to completely incorrect: nullable sugar, semantic unions, explicit casts after narrowing, alias behavior, current member limits, and the difference between what the language wants to become and what the compiler supports currently. Functions and control flow had a similar issue. I had to document prop , return rules, direct call forms, logical conditions, range-based for , and the rough edges like break and continue not yet being enforced cleanly as loop-only. That kind of thing is small until someone learns the language from the docs and hits the edge head-first (been there, done that). What Now? I’m just going to keep writing docs. Maybe do one devlog for every new doc, or a batch of docs, who knows! I certainly don’t :p
Hey, it’s been a while! I’ve been finding it difficult to stay motivated for this project, especially with how the new payout system works and just my in-general inability to keep commitment despite having a lot of passion. That said, I am going back to working on this diligently, and I think to start I’m going to cut down on the documentation by making perhaps one or two changes, and then going right back to the compiler work. Documentation writing has not been the most fun for me, especially with how long it takes and how it’s so difficult to not only write language reference that works, but also keeping the same whimsy Flower should have. Thank you to everyone who’s been following this journey, and I can’t wait to see y’all later!!! With Love, - Ivy <3
Integer Types, Parser Fixes, and Segfaults! Phew — this one was biiiiiggg. Flower is pretty much just a glorified C transpiler, which is NOT what I want for it! In order to move on, the data has to be handled explicitly by the FloC. So essentially, I implemented i8 , u8 , i16 , u16 , i32 , u32 , i64 , and u64 . For now, int canonically refers to an i32 value. A New Era? With these new literals, the old hoist-sized representation had to go. The decimal source text is preserved, meaning values such as 18446744073709551615 remain after parsing without causing any overflow. Types are picked up from declarations, assignments, function arguments, return values, field writes, array-element writes, * breath in * and binary expressions! Oof, that was a mouthful. That, of course, resulted in proper errors for things like: 256 assigned to u8 −1 assigned to an unsigned type values beyond u64 unconstrained literals outside the default i32 range I Hate Memory During printing, every width is handled. Integer conditions retain existing zero / nonzero behavior, and literal types print their values rather than a character. Halfway through, I ran into sudden segfaults and memory leaks. I was taken aback, because I didn’t even change anything parser related yet. Turns out, I forgot an assignment in a declaration, which apparently the parser wasn’t able to handle (whoops!). Anyways, I fixed it by propagating errors through the compilation process, so the compiler doesn’t try to typecheck or code gen if the parser reports back errors, and instead will print them out. And that’s it! Not that’s it, but that’s all I’m going to explain for now. More specifics available on the GitHub, of course. Speaking of GitHub thank you so much to S1monr3dst0ne07 on GitHub for fixing some memory leaks in the previous version of Flower — I forgot to prune allocations before returning from a function :p Love y’all!! <3 P.S.: So glad I gave up on documentation, I was genuinely dreading workong on the project and that’s why I’ve been ianctive for a long time :c
Integers, Integers, Integers Hello!! Been a while :) Lately I have been working on v1.6. I call it the “Usefullness” update — rhymes with Grug — because it adds a ton of long awaited features and various convenience implementations Flower DESPERATELY needs. For example, currently the progress has to do with v1.6.1, or Fixed-Width Integers . When it comes to systems programming and in-general efficiency, having various integer sizes is important as it provides an additional layer of manual control over memory and sizes. I know I would have to add them eventualy, so why not put them at the start of the Usefulness update?? I’m sure they’ll come in handy later on. What Actually Changed? Well, for starters, there’s now fixed-width integers (yay)! They’re built in types, so you declare them as you would with any other atom / primitive: type Byte = u8 type Choice = Byte | u16 type OptionalByte = ?Byte struct Packet { pair: Byte[2], size: Choice, owner: OptionalByte } A whole bunch of commits and integer-specific changes regarding indices, arity, unions, nullables, etc etc etc have been made, and they all won’t fit here so instead, take a look at the current branch ! What’s In Store? Plenty more features, you can assure yourself! There’s maybe 6 or 7 — I swear — or so commits left for this specific addition, and after that a lot more features laid out in the roadmap for 1.6! As always, thanks for sticking around and watching the fiasco that is this project become more and more estranged with every hour. Love y’all!! Ivy <3
Ships:
Flower is a self-hosted programming language for writing simple, explicit systems code without the abstraction bloat and OOP-heavy direction a lot of modern languages have. The compiler is written in Flower itself, currently targets C, and follows a straightforward pipeline: lexing, parsing, module loading, typechecking, and code generation. Over the past few months, Flower grew from a small lexer/parser/codegen experiment in C into a way bigger language project than I couldv’e imagined. This wasn’t my first attempt at a language, but it has been my favorite! I implemented compiler-enforced module semantics, stronger type-aware codegen, real boolean support, real string support, and a small standard library foundation. Strings now have equality, .length, indexing, and explicit casts to and from @char , while modules support exported prop declarations, aliases as namespaces, and private-by-default top-level declarations. The hardest part was bootstrap stability. I ran into idempotency failures, parser edge cases, compiler corruption scares, and plenty of my own bad logic. A lot of the challenge was getting new features to work not just once, but consistently enough for the compiler to rebuild itself cleanly. One bootstrap it succeeds, and then the next I’m scrambling to figure out why the new binary executable has a corrupted parser despite just working (Still haven’t fixed that yet! It.. was really confusing and I’ve got no clue why it happened lol). I’m proud that I kept pushing through that and ended up with something much more fun to use than where I started — I mean, I don’t even have to write that much C anymore!! If people want to test Flower, the important thing to know is that it is self-hosted and still experimental, but it does work. The repo includes a bootstrap path, a test suite, and example programs covering types, control flow, memory, imports, strings, and bools. The current release is focused on making the core language feel real and usable before moving on to a larger standard library and a future non-C backend, so don’t be surprised if a C file is shoved in your face!
The compiler is written in Flower itself and currently targets C, so this release was mostly geared towards making the type system have actual Flower semantics instead of a thin little blanket over whatever the backend happened to be doing. The big additions in v1.4 were: transparent type aliases real null nullable types as ?T == T | null semantic unions like int | string explicit narrowing with is explicit extraction with as That support now works across locals, parameters, return types, struct fields, and stable field-expression chains. The work had to touch parser logic, typecheck, narrowing, lowering, codegen, bootstrap, and then all the weird regressions those changes politely dragged into the room. It was.. a process for sure What I’m most proud of is that v1.4 pushed Flower toward a clearer identity that wasn’t defined by C as much anymore. This release also brought the docs back in line with the compiler, which was LONGGGGG overdue. If you want to test it, the main things to look at are the Better Types examples and the self-hosting flow. The compiler should bootstrap cleanly, the test suite should pass, and the examples now cover aliases, nullable values, semantic unions, inference, and struct/field narrowing behavior. For those who will be testing it, DO NOTE that I develop exclusively on my MacBook which is a UNIX system! I do not have the ability to properly develop and provide releases for Linux-specificalities or non-POSIX systems. I’m extremely sorry for this, but alternatively watch the provided video to see Flower in action :) If you’re not able to test it, watch this short (crappy) video instead: https://youtube.com/shorts/DyPtIru6cjY?feature=share...
|
1793105718.1508975
|
1793192118.1508975
|
|
67130
|
My awesome macropad! by @Hosanna | Stardance
|
Hosanna
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My awesome macropad! by @Hosanna | Stardanc Title: My awesome macropad! by @Hosanna | Stardance...
|
1793105719.7413356
|
1793710519.7413356
|
|
67131
|
Walk by @stefan_iftode | Stardance
|
stefan_iftode
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Walk by @stefan_iftode | Stardance
|
1793105720.6176574
|
1793710520.6176574
|
|
30625
|
studpid ai chatting program by @yagmur | Stardance
|
yagmur
|
1
|
13.0
|
72
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-16T13:48:36Z", "hours": 13.0, "multiplier": 5.36, "payout": 72, "blessing": "neutral", "text": "get your key here!! the premise of what i’ve done is very simple. make something that makes models on ai.hackclub.com very easy to use. (by that choice it also includes openrouter) i wanted it to be a lightweight terminal application instead of a hefty website with five bajillion frameworks and stupid simple to use: install the python package set your api key select your model start chatting as this is the first ship it is bare bones, hopefully in the future ill make it more tui-ish and add streaming and other nice settings", "repo": "https://github.com/yagmurpog/stupid-llm-chat", "demo": "https://pypi.org/project/dumbassllmchattingprogram"}]...
|
[{"post_id": 29487, "ts": "202 [{"post_id": 29487, "ts": "2026-07-16T13:42:34Z", "hours": 1.4344, "text": "welp it is ready"}, {"post_id": 29386, "ts": "2026-07-16T09:41:43Z", "hours": 1.8694, "text": "after a bit of polish, its ready for shipping!!!! atleast for linux not sure about windows and mac…………."}, {"post_id": 27684, "ts": "2026-07-13T13:56:00Z", "hours": 2.5444, "text": "wrote my own dumbass wrapper for openrouter because for some damn reason openrouter’s doesn’t work on windows"}, {"post_id": 24272, "ts": "2026-07-07T18:47:38Z", "hours": 1.1189, "text": "here’s the foundtains for saving config and chats and stuff. it was going well until i found out that responses from the model arent easily dumpable aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"}, {"post_id": 23295, "ts": "2026-07-06T05:09:23Z", "hours": 3.4983, "text": "so choosing python for this job was kind of a stupid idea, there is no framework that does what i want it to do. (static webapp) i wasted a crap ton of time trying different stuff only to scrap it all and turn it back into a tui program"}, {"post_id": 22256, "ts": "2026-07-04T17:08:33Z", "hours": 1.4936, "text": "heres a lil demo"}, {"post_id": 22109, "ts": "2026-07-04T11:58:09Z", "hours": 1.4847, "text": "yup, its just an interface to chat with models on ai.hackclub.com, currently its just a tui program, maybe i’ll turn it into a web app (no idea how i’m going to do that) or make an gui with tkinter"}]...
|
Title: studpid ai chatting program by @yagmur | St Title: studpid ai chatting program by @yagmur | Stardance
Devlogs:
yup, its just an interface to chat with models on ai.hackclub.com, currently its just a tui program, maybe i’ll turn it into a web app (no idea how i’m going to do that) or make an gui with tkinter
heres a lil demo
so choosing python for this job was kind of a stupid idea, there is no framework that does what i want it to do. (static webapp) i wasted a crap ton of time trying different stuff only to scrap it all and turn it back into a tui program
here’s the foundtains for saving config and chats and stuff. it was going well until i found out that responses from the model arent easily dumpable aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
wrote my own dumbass wrapper for openrouter because for some damn reason openrouter’s doesn’t work on windows
after a bit of polish, its ready for shipping!!!! atleast for linux not sure about windows and mac………….
welp it is ready
Ships:
get your key here!! the premise of what i’ve done is very simple. make something that makes models on ai.hackclub.com very easy to use. (by that choice it also includes openrouter) i wanted it to be a lightweight terminal application instead of a hefty website with five bajillion frameworks and stupid simple to use: install the python package set your api key select your model start chatting as this is the first ship it is bare bones, hopefully in the future ill make it more tui-ish and add streaming and other nice settings...
|
1793105721.4852715
|
1793192121.4852715
|
|
67133
|
playground by @javedmevati680 | Stardance
|
javedmevati680
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: playground by @javedmevati680 | Stardance
|
1793105722.6228719
|
1793710522.6228719
|
|
30372
|
Auto Subscriber by @atomic925 | Stardance
|
atomic925
|
1
|
4.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-04T21:46:14Z", "hours": 4.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "Auto subscriber- a python bot that automatically subscribes to youtube channels with many other features. FEATURES: a dark/light mode the ability to turn on and off notifications of a channel the ability to subscribe to multiple channels at once the ability to automatically close the chrome window after subscribing a sleek ui made in custom tkinter", "repo": "https://github.com/atomic92511/Auto-Subscriber", "demo": "https://drive.google.com/file/d/1mg0eNU8AlKM2RM_k_09XeQIZXhQWhj4A/view?usp=sharing"}]...
|
[{"post_id": 22191, "ts": "202 [{"post_id": 22191, "ts": "2026-07-04T15:02:43Z", "hours": 0.5239, "text": "Auto Subscriber - Python Bot, added the ability to subscribe to multiple accounts at once, here I subbed to hackclubhq and veritasium in a matter of seconds, and now instead of the bot typing the code letter by letter, it uses pyclip to automatically copy and paste it all and it saves up to 30 seconds"}, {"post_id": 21883, "ts": "2026-07-04T01:51:02Z", "hours": 0.8222, "text": "Auto Subscriber - python bot, I added a new customization where it auto closes the chrome window so you dont have to manually do it. it also now displays what number subscriber you were of the last channel you subscribed to"}, {"post_id": 21818, "ts": "2026-07-03T23:05:01Z", "hours": 0.5297, "text": "Auto subscriber - python bot, I have added a sleek new gui design and changed from tkinter to customtkinter there are now 2 customizations, which both work"}, {"post_id": 21762, "ts": "2026-07-03T21:08:01Z", "hours": 0.3728, "text": "Auto subscriber - python bot added a gui and im pretty much done, but I want to add some more customizations"}, {"post_id": 21744, "ts": "2026-07-03T20:40:27Z", "hours": 1.3239, "text": "Auto subscriber python bot - does automatically subscribe but I want to add a little more like a gui to select the channel"}, {"post_id": 21626, "ts": "2026-07-03T17:44:25Z", "hours": 0.3917, "text": "Auto Subscriber - Got PyAutoGui working and am now able to open youtube and go to a channel"}]...
|
Title: Auto Subscriber by @atomic925 | Stardance
Title: Auto Subscriber by @atomic925 | Stardance
Devlogs:
Auto Subscriber - Got PyAutoGui working and am now able to open youtube and go to a channel
Auto subscriber python bot - does automatically subscribe but I want to add a little more like a gui to select the channel
Auto subscriber - python bot added a gui and im pretty much done, but I want to add some more customizations
Auto subscriber - python bot, I have added a sleek new gui design and changed from tkinter to customtkinter there are now 2 customizations, which both work
Auto Subscriber - python bot, I added a new customization where it auto closes the chrome window so you dont have to manually do it. it also now displays what number subscriber you were of the last channel you subscribed to
Auto Subscriber - Python Bot, added the ability to subscribe to multiple accounts at once, here I subbed to hackclubhq and veritasium in a matter of seconds, and now instead of the bot typing the code letter by letter, it uses pyclip to automatically copy and paste it all and it saves up to 30 seconds
Ships:
Auto subscriber- a python bot that automatically subscribes to youtube channels with many other features. FEATURES: a dark/light mode the ability to turn on and off notifications of a channel the ability to subscribe to multiple channels at once the ability to automatically close the chrome window after subscribing a sleek ui made in custom tkinter...
|
1793105723.4735982
|
1793192123.4735982
|
|
67134
|
My awesome macropad! by @ez_schnee | Stardance
|
ez_schnee
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My awesome macropad! by @ez_schnee | Starda Title: My awesome macropad! by @ez_schnee | Stardance...
|
1793105724.366658
|
1793710524.366658
|
|
32326
|
Bounce Game by @OggyW0ppy | Stardance
|
OggyW0ppy
|
1
|
9.0
|
22
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-15T05:31:40Z", "hours": 9.0, "multiplier": 2.33, "payout": 22, "blessing": "neutral", "text": "I made a collision demo with a ball bouncing around your window with walls that you can place. One of the most challenging parts of this was not actually the collision physics, but getting the right libraries to make a screen and draw stuff on that screen the way I wanted to. I am actually pretty impressed with the graphics I managed to make because I normally leave projects with their bad, simple graphics until the end. If you want to play it check out my github repo and download the jar file.", "repo": "https://github.com/OggyWoppy36/symmetrical-bassoon", "demo": "https://github.com/OggyWoppy36/symmetrical-bassoon/releases"}]...
|
[{"post_id": 27231, "ts": "202 [{"post_id": 27231, "ts": "2026-07-12T16:48:07Z", "hours": 1.1128, "text": "DEVLOG 3.5 I didn’t really add much just cleared up some code and made the pause system better (I tried to add a blur effect and failed so its just a text box now :P). However I plan to try some new things rather than working forever on this test project, as it is incredibly cumbersome to work in Java. I want to learn python, which I have minimal experience in (even though its the most popular language, I know). End."}, {"post_id": 27008, "ts": "2026-07-12T04:35:31Z", "hours": 3.3883, "text": "DEVLOG 3 - Project Repo Additions greatly improved graphics ball has shading boxes have a design and shading changed wall placement style (ROTATION!) created new class for the selection selection box is always visible change width/height with scroll wheel and holding alt/shift change rotation by scrolling normally checks if colliding with ball to prevent illegal placements left click to place wall game updates 5 steps per frame this helps prevent glitches through thin walls added some comments in the code to make it clearer Plans Try to improve lighting / shadows currently colors and shadow positions are preset also means more vector math!!! add an objective currently planning to make a puzzle to guide a ball into an endzone with minimal walls/bounces"}, {"post_id": 26370, "ts": "2026-07-11T03:44:04Z", "hours": 3.2878, "text": "DEVLOG 2 Additions added the ability to place your own walls can speed up/slow down ball with left/right added github repo added compatibility to rotate walls, collision not updated yet added anti aliasing Plans change wall placing mechanism to allow rotation allow new balls to be added some main goal of the game?"}, {"post_id": 24470, "ts": "2026-07-08T01:30:49Z", "hours": 1.6522, "text": "DEVLOG 1 using java to make a game (flame me all you want) -started with making a ball bounce along the screen -added separate collision shape object to allow rectangular walls to be put anywhere -added ball class to allow multiple balls at once -added pause functionality (no visual indication yet however, only movement stops) -plan to add dynamic wall placement as the game is running using the mouse"}]...
|
Title: Bounce Game by @OggyW0ppy | Stardance
Devl Title: Bounce Game by @OggyW0ppy | Stardance
Devlogs:
DEVLOG 1 using java to make a game (flame me all you want) -started with making a ball bounce along the screen -added separate collision shape object to allow rectangular walls to be put anywhere -added ball class to allow multiple balls at once -added pause functionality (no visual indication yet however, only movement stops) -plan to add dynamic wall placement as the game is running using the mouse
DEVLOG 2 Additions added the ability to place your own walls can speed up/slow down ball with left/right added github repo added compatibility to rotate walls, collision not updated yet added anti aliasing Plans change wall placing mechanism to allow rotation allow new balls to be added some main goal of the game?
DEVLOG 3 - Project Repo Additions greatly improved graphics ball has shading boxes have a design and shading changed wall placement style (ROTATION!) created new class for the selection selection box is always visible change width/height with scroll wheel and holding alt/shift change rotation by scrolling normally checks if colliding with ball to prevent illegal placements left click to place wall game updates 5 steps per frame this helps prevent glitches through thin walls added some comments in the code to make it clearer Plans Try to improve lighting / shadows currently colors and shadow positions are preset also means more vector math!!! add an objective currently planning to make a puzzle to guide a ball into an endzone with minimal walls/bounces
DEVLOG 3.5 I didn’t really add much just cleared up some code and made the pause system better (I tried to add a blur effect and failed so its just a text box now :P). However I plan to try some new things rather than working forever on this test project, as it is incredibly cumbersome to work in Java. I want to learn python, which I have minimal experience in (even though its the most popular language, I know). End.
Ships:
I made a collision demo with a ball bouncing around your window with walls that you can place. One of the most challenging parts of this was not actually the collision physics, but getting the right libraries to make a screen and draw stuff on that screen the way I wanted to. I am actually pretty impressed with the graphics I managed to make because I normally leave projects with their bad, simple graphics until the end. If you want to play it check out my github repo and download the jar file....
|
1793105725.3748727
|
1793192125.3748727
|
|
67135
|
my APOD site by @rk9312038 | Stardance
|
rk9312038
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: my APOD site by @rk9312038 | Stardance
|
1793105727.1543312
|
1793710527.1543312
|
|
37016
|
Finn's Domain of Knowledge by @Tacocat12 | Sta Finn's Domain of Knowledge by @Tacocat12 | Stardance...
|
Tacocat12
|
1
|
5.4
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-19T20:00:54Z", "hours": 2.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I made a personal website that shows off projects I made, projects I am working on, and some info about me. I met all the requirements and only used AI for spell check on my blog and main page.", "repo": "https://github.com/tacocat991763/my-site", "demo": "https://tacocat991763.github.io/my-site/"}]...
|
[{"post_id": 37650, "ts": "202 [{"post_id": 37650, "ts": "2026-07-30T15:18:04Z", "hours": 3.4042, "text": "I have now revamped the UI and added more personalized backgrounds to the main page, next I will be working on the blog"}, {"post_id": 31421, "ts": "2026-07-19T19:31:29Z", "hours": 1.1797, "text": "SO MANY ERRORS. I have been debugging for 30 minutes of this hour. GitHub pages DID NOT want to collaborate but finally I got it sort of working. It doesn’t work anywhere other than GitHub pages but it does work. Anyway… I am going to go keep coding."}, {"post_id": 30916, "ts": "2026-07-18T22:00:15Z", "hours": 0.8814, "text": "My first version!"}]...
|
Title: Finn's Domain of Knowledge by @Tacocat1 Title: Finn's Domain of Knowledge by @Tacocat12 | Stardance
Devlogs:
My first version!
SO MANY ERRORS. I have been debugging for 30 minutes of this hour. GitHub pages DID NOT want to collaborate but finally I got it sort of working. It doesn’t work anywhere other than GitHub pages but it does work. Anyway… I am going to go keep coding.
I have now revamped the UI and added more personalized backgrounds to the main page, next I will be working on the blog
Ships:
I made a personal website that shows off projects I made, projects I am working on, and some info about me. I met all the requirements and only used AI for spell check on my blog and main page....
|
1793105728.0110064
|
1793192128.0110064
|
|
67136
|
Rocket with parachute deployment by @aIbert | Star Rocket with parachute deployment by @aIbert | Stardance...
|
aIbert
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Rocket with parachute deployment by @aIbert Title: Rocket with parachute deployment by @aIbert | Stardance...
|
1793105729.160663
|
1793710529.160663
|