I restarted Safari to no avail.
I am now getting the beachball of death.
The dashboard itself is working fine and so are other goals. All that I have tried.
It’s just my spiht goal that leaves the page partially blank and gets my CPU fans spinning.
I opened it to check if the datapoint got logged after Beemios / BeeSwift crashed when I tapped Add Datapoint in the stopwatch.
What a coincidence
Jeez look at the memory footprint! Again, i just restarted Safari.
It looks like the current version of the graph is loading fine. The svg file that @eugeniobruno linked to has been killed and replaced. Did you change any settings with the goal that affected the graph rendering (e.g. maybe t-min or something?) If there were something about the svg itself that’s causing the browser to fall on its face, that’s definitely something we want to flag and try to figure out!
Interesting, I hope somebody saved a copy of that svg file
If memory serves I have logged one single datapoint on it after I reported the bug – but in any case that was before I last tried to access the linked SVG file (and took the iOS screenshot). A good while before. I wanna say hours.
And I think before @eugeniobruno poked it.
I remember that when I last tapped „Add Datapoint“ in the stopwatch screen of Beemios that a spinner showed up and it took an unusually long time for the spinner to disappear. Not that I actively remember ever having seen a spinner there but that might just be my memory playing tricks on me.
In any case: I have definitely not changed any settings of the goal (or graph or anything really).
I think I’ve mostly figure it out, and the problems are those big numbers, but it’s not an integer overflow. Turning them into floats doesn’t work, making them smaller does:
# if the token appears to be a big integer, make it smaller
def xform(tok):
try:
if int(tok) > 2 ** 50:
return str(int(tok) / (2 ** 50))
except:
pass
return tok
crashing = open("crash.svg").read()
crashing_toks = crashing.split(" ")
maybe_not_crashing_toks = [xform(tok) for tok in crashing_toks]
open("uncrashed.svg", "w").write(" ".join(maybe_not_crashing_toks))
To confirm, you could check (closing and reopening the browser between checks) these test files. I can reproduce on win10 with FF.
Thank you all for the debugging help. My current guess is that in certain cases, the polynomial fit that we do for generating the aura fails and generates very large y coordinates. I will try to identify specific goal and datapoint examples that lead to this to fix it in the jsbrain code. These very large numbers should never have been there in the first place. Nevertheless, I will also put in place filter that clip the numbers written in the svg as above.
Something something Visual Road Editor…
This is great.
