- Version: 2.5
- macOS: Sierra
Hi, thanks for maintaining the great project 👍
I've recently tried using phoenix and encountered an issue and any Key.on call result in sudden-death of phoenix process with console log like seen in #34.
Possible cause
After digging a bit, the improvement made in cc5dafc seems to be insufficient in my case.
Concretely speaking, TISCopyCurrentKeyboard"Layout"InputSource should be used instead of TISCopyCurrent"ASCIICapable"KeyboardInputSource and TISCopyCurrentKeyboardInput.
Otherwise the layout data becomes null and CFDataGetBytePtr (layoutData) results in a bad access.
Known work-around
Switch your input mode to the one provided by macOS - "ABC"(Alphabet input mode, not sure how it looks like in users in locales other than jpn though):

And then run phoenix as usual. The issue will go away.
Steps to reproduce
If you've like to reproduce the issue, you can install Google IME for Japanese and switch to either:
- the Hiragana-input mode or
- the ABC(Alphabet)-input mode
and then run phoenix with single configuration containing just Key.on(...) in it. It will immediately quit without any noticeable error message, except a dump seen in #34.
You can check different values for layoutData and keyboardLayout obtained by TISCopyCurrentKeyboardInputSource variants using the checker app in my gist.
With my ASCII keyboard w/ Google IME(for Japanese input) switched to the Hiragana-input mode rather than alphabet-input mode, what I get with the checker app is:
$ make && ./InputSourceChecker
make: Nothing to be done for `all'.
From TISCopyCurrentKeyboardLayoutInputSource: InputSourceID=com.apple.keylayout.ABC LocalizedName=ABC layoutData=<not null> keyboardLayout=<not null>
From TISCopyCurrentASCIICapableKeyboardInputSource: InputSourceID=com.google.inputmethod.Japanese.Roman LocalizedName=Alphanumeric (Google) layoutData=<null> keyboardLayout=<null>
From TISCopyCurrentKeyboardInputSource: InputSourceID=com.google.inputmethod.Japanese.Roman LocalizedName=Alphanumeric (Google) layoutData=<null> keyboardLayout=<null>
Hi, thanks for maintaining the great project 👍
I've recently tried using phoenix and encountered an issue and any
Key.oncall result in sudden-death of phoenix process with console log like seen in #34.Possible cause
After digging a bit, the improvement made in cc5dafc seems to be insufficient in my case.
Concretely speaking,
TISCopyCurrentKeyboard"Layout"InputSourceshould be used instead ofTISCopyCurrent"ASCIICapable"KeyboardInputSourceandTISCopyCurrentKeyboardInput.Otherwise the layout data becomes null and
CFDataGetBytePtr (layoutData)results in a bad access.Known work-around
Switch your input mode to the one provided by macOS - "ABC"(Alphabet input mode, not sure how it looks like in users in locales other than jpn though):
And then run phoenix as usual. The issue will go away.
Steps to reproduce
If you've like to reproduce the issue, you can install Google IME for Japanese and switch to either:
and then run phoenix with single configuration containing just
Key.on(...)in it. It will immediately quit without any noticeable error message, except a dump seen in #34.You can check different values for layoutData and keyboardLayout obtained by TISCopyCurrentKeyboardInputSource variants using the checker app in my gist.
With my ASCII keyboard w/ Google IME(for Japanese input) switched to the Hiragana-input mode rather than alphabet-input mode, what I get with the checker app is: