8
1
Here's an interesting challenge...
I want you to golf code than when executed will allow your input to be converted to mimic output as though you were typing on a DVORAK keyboard layout.
The aim is to mimic the US Simplified Dvorak Keyboard (US:SDK)
In comparison, here is the standard US QWERTY layout:
The keyboard emulation must work for both uppercase and lower case letters as well as shifted keys, for example, if I tapped the q
(unshifted) key on my keyboard, the Dvorak code should pop out a '
character on the screen. If I were to tap the c
(unshifted) button I should get a j
(also unshifted) in response, C
(shifted) would get J
(shifted) and so on...
I am only concentrating of course on the white keys in the diagram above. Tabs, Caps and the other grey keys should work as per normal...
Any questions? Not for now? Good...
I will not allow external resources that already have the layout encoded already, I will not have any files brought in that can encode the layout. The code MUST be QWERTY INPUT -> (DVORAK RE-CODING) -> DVORAK OUTPUT
in nature. No silly Esolangs that are theoretical or just say something like "This program will take QWERTY input and recode it in DVORAK. This is the program." or crap like that... Take this challenge seriously... So Brainfuck coders, I welcome you.
Please note, this is NOT a string conversion program. For every QWERTY key you press, the corresponding DVORAK character must be outputted...
Shortest code wins...
1
I think you need to specify a standard QWERTY layout if you want this to be a fair challenge. I suggest using this one.
– r3mainer – 2014-03-03T12:09:01.267Point taken, implemented... – WallyWest – 2014-03-03T12:10:55.870
Is it really necessary to pop a DVORAK character when I type a QWERTY character, or is it also OK to accept a QWERTY string as input and convert it to a DVORAK string? – ProgramFOX – 2014-03-03T12:28:33.783
6@JanDvorak We are waiting for your solution
;)
– VisioN – 2014-03-03T12:29:49.640It is ESSENTIAL that the respective key on the QWERTY keyboard generates the respective DVORAK response... This is NOT string manipulation... This is Key-for-Key conversion. – WallyWest – 2014-03-03T12:30:45.920
2I don't fully understand. If string manipulation is prohibited, does it mean that stdin is out of the question? So I have to implement some low-level keyboard IO that reads keypresses? This also disqualifies brainfuck, which only reads strings from the stdin. What about stdout, can I send strings to the stdout or do I need to code a keyboard driver of sorts which simulates pressing a different key? – fejesjoco – 2014-03-03T13:03:16.020
1@fejesjoco are you referring to the last sentence? I read that as "STDIN must be read from and STDOUT written to without buffering" – John Dvorak – 2014-03-03T13:41:41.580
You can read a string from stdin and write it to stdout with buffering. You can do the same unbuffered, with characters (getchar/putchar in C), or do both for different directions. But it's essentially the same thing, it won't yield very different programs. So I don't understand why this distinction is necessary. Reading key events (where you get a scancode, not a character) is something else, which would fit the question, but it's too lowlevel, and changing key events is essentially device driver stuff... – fejesjoco – 2014-03-03T13:47:10.067
Should backspace delete a character from stdout? I think that would be the only sensible way to interpret the "this is not string manipulation" bit. – Tim Seguine – 2014-03-03T14:48:29.230
1As an aside, your questions seem to always generate a large discussion in the comment thread. Maybe it is a sign you should be using the sandbox more? – Tim Seguine – 2014-03-03T14:51:04.553
@TimSeguine Quite possibly, but all I was expecting was code that took STDIN and produced the DVORAK equivalent to STDOUT... Sighs
At least Jan Dvorak has read that perfectly... – WallyWest – 2014-03-03T23:23:45.547