Script to populate one graph using the data from another?

[Essentiae]

Hi all, 

Does anyone have a script they use to populate one graph with data from another. I'm finding that some of my graphs are getting messy because I'm forgetting to double up on my datapoints sometimes and so things are just completely inaccurate in some places. (E.g., sometimes when I track time on a work project, I forget to track that as time worked and just sent in a Project ^ 1:45 datapoint, etc.)

Does anyone have anything they've put together in order to allow one goal to draw info (reliably) from another?

(Also, feature request?)

Thanks!

Essy

[David MacIver]

I have this script which doesn't do quite that but could easily be adapted to do so if you want a starting point: https://github.com/DRMacIver/feedthebee/blob/master/truncatedgoals.py

--
You received this message because you are subscribed to the Google Groups "Akratics Anonymous" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akratics+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel Reeves]

Conceivably this idea --
https://trello.com/c/QIrEJypM/609-metamind-meta-goals-fuer-alles --
could be generalized to allow for the kind of thing Essy has in mind.
I'm pretty excited about the metaminding idea for a bunch of reasons.
Also, I'd love to get scripts like this up on github.com/beeminder

--
http://dreev.es -- search://"Daniel Reeves"
Goal tracking + Commitment contracts == http://beeminder.com

[Adam Mesha]

I almost got a script like this working but got stymied because the timestamps from the Beeminder API are whack (or they were when I was working on this a few months ago), so I just ended up manually entering the datapoints rather than continuing to bug beeminder support about it (since I was able to able to update the goal only once a week or so with no problem, and it was only one goal).

--

[David MacIver]

I have also noticed that the timestamps in the beeminder API are weird FWIW. They seem to always point to 16:00 on the day of the datapooint, regardless of when it was manually entered. I just ignored this problem and submitted the datapoints at the timestamps they came out of the API with.

[Daniel Reeves]

Straw poll! Would it be bad if we silently fixed this or should we
bump the API version number when we do, in case there are programs out
there working around the brokenness that will themselves break when we
fix it?

(Fixing the underlying reasons for the timestamp mess was a big part
of our maniac week that ended today, btw. Time-lapse videos to
follow!)

[Alice]

silently fixing this is moderately likely to break things, but I think you should do it anyway, since things are broken and reducing technical debt quickly is valuable

[Adam Mesha]

I personally am not relying on the broken behavior in any way, so as far as I'm concerned you can just fix it.

[David MacIver]

I'd vote for just fixing it, personally. I'm not relying on the broken behaviour.