Suggestions for new components about fission HOT 11 OPEN

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.

from fission.

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 *.

from fission.

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
#4 (comment).

from fission.

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. ;)

from fission.

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.

from fission.

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

from fission.

Just pushed the first commit for Fission 2, d019e22. 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.

from fission.

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.

from fission.

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.

from fission.

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.

from fission.

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.

from fission.