Problems with docs for libs

[jdjohnston]

Simplest issue is a typo in for_in_range.md: "firt" should be "first".

At the bottom of each lib doc, there's an URL for the source & one to create an issue. However each URL points to the ddorn fork. Is that intentional?

In any case, the source URLs are incorrect since libs/ is a subdir of dots/ and not in the main directory.

Thank you for AsciiDots. I've enjoyed Befunge for some years. AsciiDots is similar enough that I've got a good start, but different enough to be interesting. Next challenge would be for each dot to move independently in real time ... with synchronization, of course. :)

[ddorn]

At the bottom of each lib doc, there's an URL for the source & one to create an issue. However each URL points to the ddorn fork. Is that intentional?

This is not intentional and this should not be the case (it is very likely that I just copy pasted the wrong url), Il send a PR soon to correct that.

In any case, the source URLs are incorrect since libs/ is a subdir of dots/ and not in the main directory.

Thanks for reporting this issue, we did not update the docs when we moved libs to dots/libs.

I'm happy to hear that your enjoying Asciidots, and thank you very much for your support and issues ;)

Could you develop what you mean by dots moving in real time ? Are you thinking of making the dots movement continuous ? That could be very pleasing to watch be a bit hard to do in a terminal :P

Happy asciidoting !

[jdjohnston]

Could you develop what you mean by dots moving in real time ? Are you thinking of making the dots movement continuous ? That could be very pleasing to watch be a bit hard to do in a terminal :P

@ddorn, as you might have guessed, I was mostly joking. Seeing the multiple dots in some of the examples made me think of concurrent programming, whether multi-threaded or truly parallel. (Do they even make laptops without at least 2 cores, these days?) Given the grid the dots move over is, essentially, a shared state, it truly was mostly a joke. Maybe dots in a library sub-grid could be allowed to move independently, but coordination would still be a major challenge. Might be considered an optimization that could be disabled during debugging/visualization. Speaking of debugging, I've enjoyed using your AsciidotsDebugger.

I recently wrote a solution for Project Euler #1 in AsciiDots. My first solution followed a fairly traditional if/then/else approach. I tried to improve it by running 3 sums in parallel, but the added complexity to the grid actually slowed things down. :( If the grid had been hardware instead of a simulation, I'm almost certain the parallel sums approach would have been faster.

Actually, if your math is good enough, Project Euler 1 can be solved with a calculator & no looping. I'm better at programming than math, so I usually prefer a loop or higher-order functions, especially for comparing different programming languages.

BTW, I've added an alternate AsciiDots solution for the Rosetta Code FizzBuzz task. The old one was interesting, but also an infinite loop. Using for_in_range.dots and ~ as a queue, I was able to write one that stopped after 100 iterations. :)

Back to issues: Since last week, I've noticed a few other documentation errors or oddities. Rather than explaining each one here, would a PR be welcome?

[aaronjanse]

@jdjohnston

Since last week, I've noticed a few other documentation errors or oddities. Rather than explaining each one here, would a PR be welcome?

A PR would be very much appreciated!

And thank you for writing code samples in AsciiDots; it's exciting to see it being used in the wild.
As a side note, I should create a wiki page for code samples.