Suggestions for new components

[m-ender]

• Swap sign of energy
• Copy energy to mass
• Copy mass to energy
• Read and write signed integers to and from energy
• Repurpose lower case letters, as their current functionality can be recovered with '. Two options:
  1. Keep functionality, but change values to 0 to 25. It's currently a pain to set the mass to values in that range.
  2. Ditch them entirely to make room for 26 new components. In this case, one of them could be ' with an offset of -32. (I'd personally prefer this option.)
• Delay component.
• Debug component. (Covered in #2)

[C0deH4cker]

Responses inline. Will add info about my other updates later.

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

Swap sign of energy Already added via the upcoming I component. Copy energy to mass Copy mass to energy Interesting, will look into this. Read and write signed integers to and from energy I don't know what you mean by this... Repurpose lower case letters, as their current functionality can be recovered with '. Two options: Keep functionality, but change values to 0 to 25. It's currently a pain to set the mass to values in that range. Ditch them entirely to make room for 26 new components. In this case, one of them could be ' with an offset of -32. (I'd personally prefer this option.) I was already planning to do something different with a-z. Was considering making either all of them or only a-f be additional teleporters, but teleporters won't be as necessary due to some other new components. Will definitely have to think about this for a while. Delay component. Added as ,. Debug component. (Covered in #2) — Reply to this email directly or view it on GitHub.

[C0deH4cker]

Oh, and atoms no longer die when their mass goes negative. Haven't decided whether to keep this. At the very least it allows giving negative exit codes to *.

[m-ender]

Re reading integers:

I'd like two components analogous to ! and ? that don't read/write a single byte from STDIN/to STDOUT, but that parse the next integer from STDIN and write it to the energy or write the energy as an integer to STDOUT. For the Fissile numbers challenge I had to write itoa and atoi myself which was quite cumbersome. (Speaking of I/O it might be nice if ? didn't destroy atoms after returning EOF, but kept returning EOF instead.)

Re delay:

How is this implemented? Is the atom held for as many ticks as its energy?

Re lowercase:

I like teleporters, but I don't think more than 10 are necessary. I'm looking forward to what you want to replace them with though.

Re negative mass:

I liked that feature. It allows you to filter out atoms with negative energy very easily with @@ without having to branch out to the sides with one of %&SZ. You could always change * to read the exit code from the energy instead.

On Fri, Jun 5, 2015 at 12:10 PM, C0deH4cker [email protected] wrote:

Oh, and atoms no longer die when their mass goes negative. Haven't decided whether to keep this. At the very least it allows giving negative exit codes to *.

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

[m-ender]

I've just been wondering if there's (going to be) any update (soon) on this? I've been a bit busy lately myself, but I'd really like to see this move forward (and help out if I can). Fission deserves some more attention on PPCG, but I'm currently hesitant to use it extensively if it's going to change substantially in the near future. ;)

[C0deH4cker]

I haven't been active lately because I've been busy this summer with an internship. After that (and then DEFCON) are done in about two weeks, I will have free time to resume working on this project. As for communication, does Slack work for you? I can create a channel for Fission dev talk.

[C0deH4cker]

Created a Slack team for Fission development and sent you an invite

[C0deH4cker]

Just pushed the first commit for Fission 2, d019e2265e006f74de80cd9e6e39d0950fd2349a. This commit contains among other things the I command to invert the sign of an atom's energy as well as a lot of background changes for future updates.

[C0deH4cker]

I propose using i to read an integer from stdin, and o to write an integer to stdout. Will use strtoll() so that multiple formats are supported, such as 42, 0xb9, -1, etc.

[m-ender]

i and o sound good to me. strtoll() might be a bit overkill but why not. :)

One thing I've done in Hexagony and Labyrinth is to skip any prefix that is not part of an integer. E.g. if you performed i on input ab-cd-15 you'd get -15. Since you can use energy as a single if strtoll fails that might not be necessary.

[C0deH4cker]

Reviving this. A few ideas to resolve the issue of race conditions and synchronization:

• m (mutex): A recursive mutex locked as soon as an atom hits this component. To unlock the mutex, the atom that holds the lock needs to hit this component from the opposite side, which decrements the recursive lock count. I'm also considering whether the entire component should be just a single mutex, if up/down and left/right should be 2 separate mutexes, or if every single direction should have its own mutex. Depending on these cases, it might be possible for 2 different atoms to hold mutexes on the same m component by hitting it from different directions. That might be a little bit too confusing. If the entire component just has a single mutex, though, how should hitting the component from up/down after grabbing the lock by left/right be handled? Maybe the lock's recursion count should actually be a pair of integers, dx and dy, and the mutex only unlocks when dx = dy = 0.
• s (semaphore): A counting semaphore. I still need to think about how this should be implemented.

[m-ender]

I kinda like the idea of having a 2D mutex. The mutex essentially becomes a Gaussian integer, and is only unlocked when the value is zero.