toml

to not go more all in / code dive, etc. I just needed my monthly expense totals, ordered, with some clean-up. The code is so-so, but it mostly got things working in a few shots. Claude being able to iteratively run commands / issue queries while it worked was key to it getting functional, I think. I love that it runs local and spits out plain text for tables and such; to share with my wife i copy pasted some of the output to a text document then added some comments (markdown). If I hacked on it more, I'd probably re-work the architecture a bit; I think coming up with a good design about how to ingest idempotently, and then how you want to transform transactions (i.e. in place, vs setting up rules / overrides and then generating a computed transactions table) is most important. After each mini feature having the LLM document its usage in the README, and of course committing, was key. It made it very easy to ditch conversations and start new ones, and point to the README / examples (as opposed to compacting prior conversation). I think your tool at $5 is a great value; I had TONS of fun making the CLI app but it still took me a few hours of focused work in the end spread over a day, and relied on me having very basic prior experience to help steer it. I bet you can charge more while still keeping the product focused / maintenance low, and absolutely think there's a strong need for it -> While I am super tempted to get crazy with my local app and / automating calculations (etc) ultimately just seeing the money in / out, a few categories that I can sum up (groceries, eating out), and the top 15 expenses, that's really all we need to get our budget in place. Kudos on building a real product, esp. on figuring out how to keep it focused, finding the niche, and recognizing the opportunity to capitalize! EDIT: My actual deps list here. require ( github.com/BurntSushi/toml v1.5.0 github.com/charmbracelet/bubbles v0.21.0 github.com/charmbracelet/bubbletea v1.3.5 github.com/charmbracelet/huh v0.7.0 github.com/charmbracelet/lipgloss v1.1.0 github.com/charmbracelet/log v0.4.2 github.com/mattn/go-sqlite3 v1.14.22 github.com/spf13/cobra v1.10.1 )

owever, note that Go 1.3 will include a reasonably large optimization which introduces a "one-pass" NFA simulation. It's used when it can be proven that the regex will never need to backtrack. Rob Pike posted some benchmarks on golang-dev a while back, and they showed a perf improvement in the regexp package. So they at least seem to be working on things that you care about.) Speaking from a higher level, I'd say that the raw performance of regexes is probably not a huge priority. Needing wickedly fast regexes seems like a special case to me, in which case, you might just use an existing library to do it via cgo. (And indeed, the benchmark's game includes some Go benchmarks that use the PCRE C library, which has more reasonable performance.) For more details on how it all works, Russ has written an amazing series of articles on the topic: http://swtch.com/~rsc/regexp/ > Why does encoding/json still rely on reflection, making it slow compared to other approaches? Using reflection makes encoding/decoding JSON extraordinarily convenient. I do the same with TOML[1], although admittedly, performance is less of an issue there. My suspicion is that the added complexity for when you need raw speed isn't common enough to be in the standard library. megajson[2] tries to fill this hole, but it's a code generation tool, so you may find that less than ideal. [1] - https://github.com/BurntSushi/toml [2] - https://github.com/benbjohnson/megajson

offended me). Since then, I would annually get sick of `epydoc` and try out Sphinx again to see if things improved. I remember when `sphinx-apidoc` was added and thought it would solve all my problems. It didn't. For example, if I run `sphinx-apidoc` on my `pdoc` module, this is what I get in `pdoc.rst`: pdoc Module =========== .. automodule:: pdoc :members: :undoc-members: :show-inheritance: Hmm. OK? That wasn't what I was expecting, but the words "auto" seem promising. I run the necessary `make html` and look at the output: http://burntsushi.net/stuff/pdoc-sphinx (ignore the Markdown ugliness, I would be willing to live with RST). Seems plausible. But wait. My representation isn't documented! Dammit. So I look up the documentation for the `autodoc` extension. I find things like `autoattribute`[1] and an undocumented `autoinstanceattribute`[2] that look promising. But god dammit, I have to write `autoattribute` for each attribute I want to document. I googled for something that would do it for me (and looked at `sphinx-apidoc` more closely for relevant options). Maybe it exists, but I couldn't find anything. And the comments for the bug in [2] don't give me any hope either (where each attribute is delineated). Now I guess I could have written something that generates a Sphinx `rst` file with all the right `autoattribute` commands, but at this point, I'm drowning. After getting fed up with epydoc's own weird rules for documenting module and class variables, and its inability to look in `__init__` for instance variables, I had enough. To put a cherry on top of this, I've been spoiled by Go's automatic documentation[3] that you literally get for free. You can generate documentation on the fly for any Go project[4]---no config files, no running commands to make HTML, nothing. Just an import path and some simple conventions. So I threw my hands up, proclaimed that I didn't deserve to be treated the way Sphinx treated me, and wrote my own in about ~6 days. It was harder than I anticipated, but now that it's done, I'm totally loving my choice to do it. You may note that there are other ways to document instance variables like `:ivar:` that both epydoc and Sphinx support. That's just a giant hack to me and is completely and utterly incompatible with generating documentation on the fly. For example, in one of my Python modules that requires a lot of attributes[5], it's practically suicide not to have a single point of truth[6]. Solution to that? A very simple convention that I haven't seen used in epydoc or Sphinx.[7] Maybe it exists, I'm not sure. (Don't you dare tell me to append to `__doc__` dynamically!) Basically, `pdoc`'s gimmick is that it can generate API docs for any module on the fly if you run it as an HTTP server. Since it adheres to common conventions used to document module/class/instance variables, it can pick those up. Oh, and it makes it simple to reference other public members of other modules. Which I use All. The. Time. Love it. (I'm sure Sphinx has this too...) > I simply recommend that you try to understand Sphinx a little better before claiming superiority. I have to respond to this. Even with my all my ranting, I really and truly do not believe pdoc is superior. I certainly believe it is superior for me, but I understand that people have different workflows. For example, I generally don't have too much of a problem following Sphinx documentation for other projects, although they can be difficult to navigate if the author isn't conscious about providing the right links in obvious places. > (You should recognize, though, that sphinx-apidoc also requires zero setup.) See above. Am I wrong with having to write out all the `autoattribute` stuff? If I am, that does make Sphinx marginally better. Not sure if it would have stopped me, though. (Because of all the other stuff I mentioned.) [1] - http://sphinx-doc.org/ext/autodoc.html#directive-autoattribu... [2] - https://bitbucket.org/birkenfeld/sphinx/issue/904/autodocs-d... [3] - http://golang.org/pkg [4] - http://godoc.org/github.com/BurntSushi/toml [5] - http://pdoc.burntsushi.net/nfldb#nfldb.Play [6] - https://github.com/BurntSushi/nfldb/blob/master/nfldb/data-d... [7] - https://github.com/BurntSushi/nfldb/blob/master/nfldb/types....