henryhale

great work over there.

allow users to pin or star tools for quick access - it would be nice to have.

interesting - i love it.

I think it can sometimes be caused by me just being haphazard about re-exporting them, but other times I'm not sure.

I think so too. I guess that's how your project is structured and duplicates maybe inevitable.

The graph shows exactly how the project is organized. Right - "duplicates confuse things" - this would suggest eliminating "files that re-export functions/classes" or passing an option (-i) for ignoring specific paths would help. Otherwise, this issue is noted for further analysis.

Thanks for trying depgraph.

give depgraph a try - https://github.com/henryhale/depgraph - i'd like to learn about how i could improve it.

I have been working on depgraph (https://github.com/henryhale/depgraph) for a while now. It is truly local with several output options(json, mermaid, jsoncanvas). Mutliple languages are supported (js, go, c) - expanding the list slowly but sure.

why not abstract that away so that `track()` can do it all? It would be alot easier to work with.

I don't get how this would be more "ai friendly" than other frameworks, that kind of propositions should be backed by more concrete proof.

Most if not all llms are producing Markdown instead of HTML as the primary output. Markdown has a simpler syntax that basically uses fewer tokens compared to HTML Similarly, Ripple appears to express a complex structure in simple terms compared to React or HTML or whatever. No wonder most AI dev tools operate in React with web previews abstracting away the setup process.

Higher abstractions appear to be cost efficient(both training & inference time - output generation). All that is required is to provide the model with a document containing rules about ripplejs(in this case) and go from there...more like llms.txt or agent.md or simply documentation. Any DSL would fit in a single file and easily consumed by a model.