aaronryank / cubically Goto Github PK

The following code should print "27", however it prints "2745":
?3{%3?0%4}!%5

This is caused by the internal ? failing and setting if_else to 0. When this occurs, the ! after the main conditional sees that ! is 0 and executes.

If a command requires no arguments, it'd be cleaner and shorter if the code could call the commands implicitly without needing arguments.

Example: $%7 would load a number as input, then output that number to the screen. Currently, this must be accomplished with $7%7, even though the argument supplied to $ doesn't matter and it will always load input to "face" 7 (the input "face"). $7%7 would still behave identically to $%7, and $77%7 would load input twice before outputting only the second input that was loaded.

Why is there no way to specify the argument of any function from input?

For example, F1 always turns the front face 1, but there's no way to specify F(whatever-is-in-7).

You could add a dereference character, we'll say X, where FX7 is interpreted as F(whatever-is-in-7). That would be more difficult, but more versatile.

I propose that you just add a new character that reads an argument from stdin, say: '#', so F# would read a 0-9 from stdin.

In fact I wrote a patch for this too, and I will submit the pull request shortly.

It would be really cool if there was an interactive mode that printed the cube state everytime that input was requested from the user.

In fact, I just wrote such a patch, and it is in a pull request I will submit shortly.

The interpreter has a lot of hardcoding, it needs to be rewritten, opening an issue so that I'm constantly bugged to do this (should make me get around to it faster)

This would be nice - especially if there was a way to do it in a portable way. Possibly use libportable (add a functionality to it to test if STDOUT is a terminal)

This is due to getwc trying to read a multibyte char from a string that was fmemopen'ed from a single-byte string.

Possible fixes:

• Find or implement a fmemopen equivalent for wide chars
• Make Cubically non-portable by writing the string to /tmp/.cubically-input-(random string)

I noticed while playing with a 4-size cube that the inner four cubelets never change, because the RUFetc instructions aren't really scalable outside of a 3x3x3 cube.

I don't think it is a critical issue right now, but I was curious if you had a plan for how to deal with that in the future?

This is everything I plan to add to Cubically v4.0:

• Easier looping behavior
• Simple string printing
• More face turns and shortcuts
• 26 variables
• Further optimizations in rubiks.c
• Random arguments
• The Windows command
• Comments