bean-web and caching

Alen Šiljak

unread,

Apr 21, 2019, 2:26:44 PM4/21/19

to Beancount

I believe I read somewhere that bean-web reads the file once and keeps the book (whatever the term is for the parsed data file) in memory for all the queries.

If so, that is quite convenient for everyday use and offsets any performance penalties of using Python with big files.

Speaking of which, the drawback of the Google Docs is that it is not easy to search all of them for references to bean-web, otherwise I would read more about it. This way I have to do a semantic search by reading the whole introductory document and checking the links that may be relevant according to their title. Or I'm missing something?

I would also like to read more about file separation and other topics but I guess I'll have to take it slow. :)

Martin Blais

unread,

Apr 21, 2019, 2:38:43 PM4/21/19

to Beancount

On Sun, Apr 21, 2019 at 2:26 PM Alen Šiljak <alen....@gmx.com> wrote:

I believe I read somewhere that bean-web reads the file once and keeps the book (whatever the term is for the parsed data file) in memory for all the queries.
If so, that is quite convenient for everyday use and offsets any performance penalties of using Python with big files.

Yes, that was the purpose.

However, if you do modify the file, on the next page load it will automatically reparse it, which can indeed take some time.

Speaking of which, the drawback of the Google Docs is that it is not easy to search all of them for references to bean-web, otherwise I would read more about it.

It's on the cutting board for the next version. I'd switch to Fava immediately and ignore it.

This way I have to do a semantic search by reading the whole introductory document and checking the links that may be relevant according to their title. Or I'm missing something?
I would also like to read more about file separation and other topics but I guess I'll have to take it slow. :)

If you'd like to chip in to the documentation conversion, I started an automated converter to markdown here:

https://bitbucket.org/blais/beancount-jsondocs/src/default/

It's incomplete and buggy (see the converted files), but I think a couple of evening's worth of work by someone motivated could bring this to a decent level and what I'd like to do is integrate it in this work and check the whole thing in Beancount as the official versioned doc in Sphinx:

https://aumayr.github.io/beancount-docs-static/users/index.html

Alen Šiljak

unread,

Apr 21, 2019, 2:47:23 PM4/21/19

to Beancount

On Sunday, 21 April 2019 20:38:43 UTC+2, Martin Blais wrote:

On Sun, Apr 21, 2019 at 2:26 PM Alen Šiljak <alen....@gmx.com> wrote:
I believe I read somewhere that bean-web reads the file once and keeps the book (whatever the term is for the parsed data file) in memory for all the queries.
If so, that is quite convenient for everyday use and offsets any performance penalties of using Python with big files.

Yes, that was the purpose.
However, if you do modify the file, on the next page load it will automatically reparse it, which can indeed take some time.

That's good enough as I wouldn't necessarily mix the data entry with checking the reports too much.

Speaking of which, the drawback of the Google Docs is that it is not easy to search all of them for references to bean-web, otherwise I would read more about it.

It's on the cutting board for the next version. I'd switch to Fava immediately and ignore it.

True. I may have mixed them up and am actually just reading through Fava's docs.

This way I have to do a semantic search by reading the whole introductory document and checking the links that may be relevant according to their title. Or I'm missing something?
I would also like to read more about file separation and other topics but I guess I'll have to take it slow. :)

If you'd like to chip in to the documentation conversion, I started an automated converter to markdown here:
https://bitbucket.org/blais/beancount-jsondocs/src/default/

Oh, boy, that sounds good already. You must be really sick of all those anti-GDocs suggestions. :))

In any case, I'm a MarkDown fan so I'll put it on my to-do list right away. I've been ignoring the whole plain-text-accounting area for years and now find it amazing that there's so much functionality. Enough said.

It's incomplete and buggy (see the converted files), but I think a couple of evening's worth of work by someone motivated could bring this to a decent level and what I'd like to do is integrate it in this work and check the whole thing in Beancount as the official versioned doc in Sphinx:
https://aumayr.github.io/beancount-docs-static/users/index.html

That looks really good and has search functionality! Thanks.

Not sure if it this is pushing too far but have you been thinking of using Git and some of the Git hosting sites? I mean, you surely have but I'd like to read your thoughts on that.

I just installed beancount on my Linux box at home and find the whole chain somewhat archaic even though I was hooked on Hg almost a decade ago, in contrast to Git.

Martin Blais

unread,

Apr 21, 2019, 6:15:22 PM4/21/19

to Beancount

On Sun, Apr 21, 2019 at 2:47 PM Alen Šiljak <alen....@gmx.com> wrote:

On Sunday, 21 April 2019 20:38:43 UTC+2, Martin Blais wrote:
On Sun, Apr 21, 2019 at 2:26 PM Alen Šiljak <alen....@gmx.com> wrote:
I believe I read somewhere that bean-web reads the file once and keeps the book (whatever the term is for the parsed data file) in memory for all the queries.
If so, that is quite convenient for everyday use and offsets any performance penalties of using Python with big files.

Yes, that was the purpose.
However, if you do modify the file, on the next page load it will automatically reparse it, which can indeed take some time.

That's good enough as I wouldn't necessarily mix the data entry with checking the reports too much.

Speaking of which, the drawback of the Google Docs is that it is not easy to search all of them for references to bean-web, otherwise I would read more about it.

It's on the cutting board for the next version. I'd switch to Fava immediately and ignore it.

True. I may have mixed them up and am actually just reading through Fava's docs.

This way I have to do a semantic search by reading the whole introductory document and checking the links that may be relevant according to their title. Or I'm missing something?
I would also like to read more about file separation and other topics but I guess I'll have to take it slow. :)

If you'd like to chip in to the documentation conversion, I started an automated converter to markdown here:
https://bitbucket.org/blais/beancount-jsondocs/src/default/

Oh, boy, that sounds good already. You must be really sick of all those anti-GDocs suggestions. :))

Nah, don't mind.

I've seen how powerful gdocs is at work, we use it extensively (mainly sheets, docs, slides).

In any case, I'm a MarkDown fan so I'll put it on my to-do list right away. I've been ignoring the whole plain-text-accounting area for years and now find it amazing that there's so much functionality. Enough said.

It's incomplete and buggy (see the converted files), but I think a couple of evening's worth of work by someone motivated could bring this to a decent level and what I'd like to do is integrate it in this work and check the whole thing in Beancount as the official versioned doc in Sphinx:
https://aumayr.github.io/beancount-docs-static/users/index.html

That looks really good and has search functionality! Thanks.

Not sure if it this is pushing too far but have you been thinking of using Git and some of the Git hosting sites? I mean, you surely have but I'd like to read your thoughts on that.

I just installed beancount on my Linux box at home and find the whole chain somewhat archaic even though I was hooked on Hg almost a decade ago, in contrast to Git.

Despite the popularity of Git, Hg is still the better choice for organizations that need to implement their own backend.

It's not going away anytime soon.

My thoughts? Git is a PIA to use, but probably inevitable eventually.

Alen Šiljak

unread,

Apr 21, 2019, 6:30:08 PM4/21/19

to Beancount

On Monday, 22 April 2019 00:15:22 UTC+2, Martin Blais wrote:

Despite the popularity of Git, Hg is still the better choice for organizations that need to implement their own backend.
It's not going away anytime soon.
My thoughts? Git is a PIA to use, but probably inevitable eventually.

With the modern tools, it really resembles TortoiseHg. The whole staging step, and separation of Commit and Push are being hidden, i.e. in VS Code. They are still there if needed, but two step process of stage all -> commit all -> push is now almost identical to tying together commit+push and fetch+pull on Hg.