Add debug component

[m-ender]

A debug component would be really useful which prints something like

Atom at (x,y) at tick t: (mass, energy)

without consuming the atom. I'm happy to implement this and send you a pull request, but I was wondering whether you would like to use a specific of the remaining reserved characters? If not, I propose ```.

[C0deH4cker]

I already have ``` implemented for something else coming in the next version of Fission, but for now, I've temporarily added the following debug components (very likely to change before it is finalized):

=: Basically printf("Atom %u at (%d, %d) with mass %lld and energy %lld hit component '%c'\n", id, pos.x, pos.y, mass, energy, hit);, but C++-ey.

(: Toggles on debug mode for the atom that hits the component. For every tick thereafter, the atom will print out the above message.

): Toggles off debug mode for the atom that hits the component.

I will probably merge the last two into one component that just toggles debug mode on and off when hit, and I'll probably change the characters used for all of these. But they are already implemented and working.

A few new changes you'll notice from that:

1. Atoms are now given monotonically increasing identifiers (unsigned integers starting at 1 for the first atom to spawn, increasing for each spawning atom after this). This is only currently used by these debug components, as a way to differentiate atoms from each other.
2. The mass and energy of atoms are now represented using 64-bit integers rather than 32-bit.

[m-ender]

I had patched my own suggestion into my local copy while working on Fissile Numbers. I think that (%d, %d) for (mass, energy) is probably more convenient to read if there are a lot of debug messages.

The atom IDs sound like a really useful addition for debugging.

Another thing I added locally, which I found really useful was the current direction, like Direction: >. I realise that UDLR or MW[] would make more sense in the context of Fission, but ><^v are just much easier to recognise at a glance.

One more thing that would be really useful for understanding program flow would be if debug mode also printed the current tick number. (I realise that Fission doesn't currently keep track of tick numbers, but if I would have had that information, resolving race conditions would have been a lot less guess work.)

[C0deH4cker]

I can definitely implement both of those changes. Btw you likely won't have to debug race conditions as much since I am adding a delay component ,.

On Jun 5, 2015, at 2:18 AM, Martin Büttner [email protected] wrote:

I had patched my own suggestion into my local copy while working on Fissile Numbers. I think that (%d, %d) for (mass, energy) is probably more convenient to read if there are a lot of debug messages.

The atom IDs sound like a really useful addition for debugging.

Another thing I added locally, which I found really useful was the current direction, like Direction: >. I realise that UDLR or MW[] would make more sense in the context of Fission, but ><^v are just much easier to recognise at a glance.

One more thing that would be really useful for understanding program flow would be if debug mode also printed the current tick number. (I realise that Fission doesn't currently keep track of tick numbers, but if I would have had that information, resolving race conditions would have been a lot less guess work.)

— Reply to this email directly or view it on GitHub.

[m-ender]

I've actually got a list of components I wanted to suggest (wanted to wait until I see your changes though) and the delay component is definitely on that list. ;)

Even with a delay component I need to figure out how long to delay the atom for though, so the tick numbers would still be nice.

On Fri, Jun 5, 2015 at 11:24 AM, C0deH4cker [email protected] wrote:

I can definitely implement both of those changes. Btw you likely won't have to debug race conditions as much since I am adding a delay component ,.

On Jun 5, 2015, at 2:18 AM, Martin Büttner [email protected] wrote:

I had patched my own suggestion into my local copy while working on Fissile Numbers. I think that (%d, %d) for (mass, energy) is probably more convenient to read if there are a lot of debug messages.

The atom IDs sound like a really useful addition for debugging.

Another thing I added locally, which I found really useful was the current direction, like Direction: >. I realise that UDLR or MW[] would make more sense in the context of Fission, but ><^v are just much easier to recognise at a glance.

One more thing that would be really useful for understanding program flow would be if debug mode also printed the current tick number. (I realise that Fission doesn't currently keep track of tick numbers, but if I would have had that information, resolving race conditions would have been a lot less guess work.)

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/C0deH4cker/Fission/issues/2#issuecomment-109252047.

[C0deH4cker]

Go ahead and suggest them now!

[C0deH4cker]

I think I've decided on how to implement debugging in Fission 2 (for now at least). I'd like to save actual characters for components that have uses besides debugging, so I won't be adding any new components to help with debugging. Instead, I'll add a new option to the Fission interpreter that allows you to input a second file, a debug info file. This is like a "shadow" of the source file, in that it should match the input file's 2D grid but with different contents. What I mean by this is that there will be some character command for printing the atom's (mass, energy) pair, let's just say X. If X is in row 4 column 3 of the debug info file, then atoms which hit the component at row 4 column 3 in the code file will print their (mass, energy). This is probably best explained with an example:

Z~]Z?L
K  A /
\!/;

That's our old friend, tac.fsn (reverse stdin). Let's use this as the debug file:

X.....
......
....

This would print the (mass, energy) of every atom that hits the top-left Z component, the branch right after popping from the stack. Of course there can be many different debug components, and they will likely trigger at different times (pre/post action). I may even add a way to combine multiple debug output options. Or I could go crazy and allow the user to pass a path of a shared library to be loaded to add its own debug components and actions. Who knows?

And obviously it won't actually be 'X' for that debug character. That's purely for demonstration. I haven't decided anything about that yet.

[m-ender]

This sounds really nice and flexible, but I think it would be a pain to set up and keep track of the debug file for larger programs. How about, instead, in debug mode, the interpreter reads two characters per cell, one for the code, one for a debug command. So your example might become either

ZX~ ] Z ? L 
K     A   / 
\ ! / ; 

or

XZ ~ ] Z ? L
 K     A   /
 \ ! / ;

It would still be fairly easy to get rid of the debug code with a single regex when the code is ready for use (or expand an existing program for debugging), but this should make it much easier to line up the code with the debug commands.