I am not aware of any bug in this code. It works, and the selection persists. Of course it is a silly project.
Classic FizzBuzz is just too simple a task to show off any language features, so the task was souped up so that it draws a 10x10 grid of the results, and lets you pick one of the 100 cells to highlight.
It persists this selection for a day to show how one can save up to 1kb of state information trivially inside the browser's cookie system, which is simpler to use than the IndexDB database (which is also available to use if you wish).
1Kb is enough to store a reasonable amount of data, and since Beads has a built-in graph database (not as fancy as Neo4J), you can store a subtree into the cookie with one line, and no encoding/decoding necessary, as that is performed by the runtime library for you (a nicety).
The convenience of working with a graph database internally, instead of the typical collection of data structures that one sees in older languages such as scalars, tuples, lists, dictionaries, queues, and pointers, is an advantage that only becomes apparent after some use of the language; i encourage you to take it for a spin.
That's neat, but imho start with the plain fizzbuzz first. Everyone has it in their lexicon so it acts as a first-pass Rosetta stone for what the language syntax is like. Adding extra bits implies you need those to get the job done.
I just updated the program to allow arbitrary arrays of words and factors for division, so now it is a fizz-buzz-jazz version of the program, and it gets even shorter once you go to table driven data.
var ss = ""
var color = ALICE_BLUE
loop across:WORDS index:wordx
if mod(b.cell_seq, PRIMES[wordx]) == 0
WORDS[wordx] &=> ss
color = COLORS[wordx]
if ss == ""
// plain cell
ss = to_str(b.cell_seq)
Classic FizzBuzz is just too simple a task to show off any language features, so the task was souped up so that it draws a 10x10 grid of the results, and lets you pick one of the 100 cells to highlight.
It persists this selection for a day to show how one can save up to 1kb of state information trivially inside the browser's cookie system, which is simpler to use than the IndexDB database (which is also available to use if you wish).
1Kb is enough to store a reasonable amount of data, and since Beads has a built-in graph database (not as fancy as Neo4J), you can store a subtree into the cookie with one line, and no encoding/decoding necessary, as that is performed by the runtime library for you (a nicety).
The convenience of working with a graph database internally, instead of the typical collection of data structures that one sees in older languages such as scalars, tuples, lists, dictionaries, queues, and pointers, is an advantage that only becomes apparent after some use of the language; i encourage you to take it for a spin.