dananabread
Joined 3 years ago
Karma
5
Submissions
3
Member since
Jan 8
Recent submissions
Comment · 7 days ago
Comment · 2 years ago
Is there an intuition for this correspondence otherwise I don't think it's very helpful
Comment · 3 years ago
I'm also interested in this.
Currently trying get a small project off the ground while working full time at a large company. The goal is to get enough momentum on a project to find a good jumping off point.
The project is a multiplayer adaptation of frogger, where players are competing be the last man standing dashing across roads and rivers. The USP is allowing players to push each other around, this really adds to the competition (you can push people in front of cars, off of logs etc)
The target audience is "skibble.io users" so bored students / employees looking for something to do over zoom. So I'm building it out as a webpage with no login and as quick as possible time to game.
I have some info here https://forums.tigsource.com/index.php?topic=72732.0
And there is an old local-only prototype here https://danslocom.be/gamepages/crossy.html
Looking at the repo it seems like the N stacks generated by the compiler are placed at least 2gb apart in virtual memory, have you run into any cases where that has been overflowed during runtime? The compiler cannot know which of the stacks are going to be used more than others and in a large complex program with many stacks any one of them could fail. I imagine this being an issue depends on target application - if you know you are building a game that you know the exact size of your levels / entity counts beforehand you know this is fine but if you were doing data processing / parsing potentially malicious user input it may be a problem.
I'm also interested how the memory locality works. Here you have the bases of your stacks at a series of very sparse virtual memory intervals which will be mapped by the page table to some physical memory addresses, does having them be so sparse cause any issues?
There are some unique ideas here - lifetimes on references to growable+shrinkable stacks, "balancing" stacks in recursive functions - and I'm glad you were able to use coding agents to actually materialize them.