Because forking is new coding /s (What we see is natural entropy of systems. Wannabe codies fork a repo… and instead of contributing to original one they make their own copy. What will happen if you repeat this a few times? ;)
Well I wanted to implement light transport papers without having to deal with cpp. I think tinygrad, and more specifically tinyJIT are super useful abstractions. This is def not available in ts
That is a legit way of working on contribution. You fork, you work on the fork - if it's not junk then you issue a pull request. What's the deal with belittling and holier-than-thou moralizing?
I have nothing against forking ofc. I like it. But I really don’t like laziness when there is no contribution to original project - instead those codies make the project as their, in fact it is just a (poor) fork. The result is the mess. My first comment was about this behaviour.
Claude didn't follow your "Every line must earn its keep. Prefer readability over cleverness. We believe that if carefully designed, 10 lines can have the impact of 1000." from https://github.com/quantbagel/gtinygrad/blob/master/AGENTS.m... given how bloated this demo is.
Why is this a fork of tinygrad and not just something that imports it?
Because forking is new coding /s (What we see is natural entropy of systems. Wannabe codies fork a repo… and instead of contributing to original one they make their own copy. What will happen if you repeat this a few times? ;)
Well I wanted to implement light transport papers without having to deal with cpp. I think tinygrad, and more specifically tinyJIT are super useful abstractions. This is def not available in ts
My question was more why a fork instead of doing the conventional "import tinygrad" into your own project.
I don't think there is anywhere you are modifying tinygrad itself is there?
That is a legit way of working on contribution. You fork, you work on the fork - if it's not junk then you issue a pull request. What's the deal with belittling and holier-than-thou moralizing?
I have nothing against forking ofc. I like it. But I really don’t like laziness when there is no contribution to original project - instead those codies make the project as their, in fact it is just a (poor) fork. The result is the mess. My first comment was about this behaviour.
Forking is nice when it’s nice.
Claude didn't follow your "Every line must earn its keep. Prefer readability over cleverness. We believe that if carefully designed, 10 lines can have the impact of 1000." from https://github.com/quantbagel/gtinygrad/blob/master/AGENTS.m... given how bloated this demo is.
https://blog.evjang.com/2019/11/jaxpt.html is a better demo of how to render the Cornell Box on a TPU using differentiable path tracing.
The agents.md is from the upstream tinygrad repo: https://github.com/tinygrad/tinygrad/blob/master/AGENTS.md
> Never mix functionality changes with whitespace changes.
Whoa.. the cursor rule I didn't know I needed!
so cool! id love to read a blog post about this.