Andrew Auclair

Yes, it still seems to happen with the latest. I now see that the check for "=" is in the PicocliCommands.java complete method. I attempted to debug this, but I...

Thanks! No worries. I've found that JLine3 can be a real time sink. Maybe I'll dig into it a little more. For now I think I'll have to get used...

Bit of an update. I've been playing around with this for the last hour or so and came up with the code below. With this else statement at the end...

The `/w` argument is of the form `/wnNNNN`, where `n` is the warning level you want to change the warning to and `NNNN` is the warning number. [C4619 (#pragma warning:...

You can submit a pull request with the change. That'll be the fastest way to get the issue fixed.

Should we be using `Poco::Net::UDPServer` and `Poco::Net::UDPClient` instead of a `Poco::Net::DatagramSocket` directly to avoid issues like this? Maybe not. Looks like that only supports connecting locally.

I ended up closing and reopening the socket if there was an error after calling `available()`. It still doesn't seem that great to me that `available()` could cause an error...

Some additional testing resulted in `receiveBytes` throwing a `std::bad_array_new_length` because `available` returned -1.

I think the only way this can possibly work is forcing the user to cast to `void*`. Format.cpp ```cpp case 'p': str < std::hex

That sounds good to me. I've moved to using fmtlib myself.