Wed 02 January 2019

Katanakana Legal

Katanakana Privacy Policy

Katanakana does not track anything about you, as it's simply an app for repeated quizzing of Japanese katakana characters. This also means that there is no analytics code within the app itself - if you find something that indicates otherwise, please reach out to me and I'll take a look as soon as possible. No cookies, weird caching or other tricks to identify you. It stores no data on you beyond characters it determines you need help with.

Terms and Copyright

Unless otherwise noted, all the content on here is copyright me, Ryan McGrath. If you find that I've violated your copyright or trademark in any way, I encourage you to email me using the address at the top of this page, whereupon I'll do my best to resolve the matter quickly.

Ryan around the Web

You still can, GitHub just arbitrarily changes wiki links: https://github.com/project-slippi/Ishiiruka/wiki/Overclocking-Controllers-on-macOS-Big-Sur,-Monterey,-Ventura,-or-Sonoma

This particular feature requires me doing some work that I just don't have time for. It's not something that someone can contribute as it primarily deals with signing the driver itself. on Support for overclocking on macOS 11.0+ 2 weeks ago
Just set all your ports in that config panel to WiiU adapter, then each port would technically work.

Right now you only have one port enabled in the config, and the adapter says detected but not reading... which is why I ask this. on GCAdapterDriver not working over the apple one 2 weeks ago
This is plugged into port 1, correct? If it's detect, it should be outputting a Hz measurement... on GCAdapterDriver not working over the apple one 2 weeks ago
Screenshot your controller(s) panel from Dolphin~ on GCAdapterDriver not working over the apple one 2 weeks ago
Kk, and how are you connecting the adapter to your machine? Is there a particular USB hub/adapter you're using?

(And as dumb as it might sound, you're using the black cord right? Not the rumble cord?) on GCAdapterDriver not working over the apple one 2 weeks ago
Also - what adapter type are you attempting to connect? on GCAdapterDriver not working over the apple one 2 weeks ago
A restart, yes. :) on GCAdapterDriver not working over the apple one 2 weeks ago
I'd go ahead and do a full reboot to clear out any of those older installs - they shouldn't be conflicting, but frankly DriverKit is weird like this and I've run into cases where people have it "just work" after a full reboot.

(DriverKit doesn't fully remove a driver install until a reboot occurs) on GCAdapterDriver not working over the apple one 2 weeks ago
What's the output of sudo systemextensionsctl list when the driver is toggled on from the dropdown? on GCAdapterDriver not working over the apple one 2 weeks ago
Monterey is not a .kext-based installation method - the GCAdapterDriver homepage indicates this:

You're trying to run the .kext installer from the right, but you actually need to do the installer on the left. on GCAdapterDriver not working over the apple one 2 weeks ago
Ah, to be clear you're trying to install the .kext? Need to know your actual macOS version before we could even begin to debug - based on Finder I'm guessing it's 10.15 or less? on GCAdapterDriver not working over the apple one 2 weeks ago

There might be something there, but I'd need to revert my code back to confirm - but for what it's worth, I did experiment with a method on RequestData like the following:

impl<T> RequestData<T> {
    pub fn info(&mut self, message: impl Into<String>) {
        self.messages = self.messages.info(message);
    }
}

...which created the following error:

error[E0507]: cannot move out of `self.messages` which is behind a mutable reference
   --> libs/apex-utils/src/request.rs:37:25
    |
37  |         self.messages = self.messages.info(message);
    |                         ^^^^^^^^^^^^^ ------------- `self.messages` moved due to this method call
    |                         |
    |                         move occurs because `self.messages` has type `Messages`, which does not implement the `Copy` trait
    |
note: `Messages::info` takes ownership of the receiver `self`, which moves `self.messages`

It could be worked around by the following, which I alluded to in my last comment regarding Clone:

impl<T> RequestData<T> {
    pub fn info(&mut self, message: impl Into<String>) {
        self.messages = self.messages.clone().info(message);
    }
}

Personally speaking, I also am just not a fan of needing to pepper request.messages = throughout handlers, the assignment aspect just isn't relevant to what's usually going on - but that's more subjective so I defer to you. on Support extracting messages in one pass? a month ago