* dgud/wx/behaviour-spec:
  [wx] Add handle_cast to avoid behaviour warning
  [wx] Avoid missing wx_object behaviour warning
  [wx] Remove warnings Add an additional cast when casting buffer offsets, to remove warnings "cast to pointer from integer of different size"
  [wx] Add callback specs to wx_object

* rj/fix-debugger-msgs:
  Fix "OK" spelling in debugger messages and variables
  Fix debugger message with wx

OTP-9699

Simple code refactor in the debugger: renames all the occurrences of
"Ok" to "OK" in the code, variable names and strings. This improves the
consistency of the code and follows the GTK UI where "OK" is always
used.

Add missing spaces when using wx UI. The gs UI didn't need them.
Change the exclamation of the message by a dot, more formal style for a
UI message.

Currently, the external fun syntax "fun M:F/A" only supports
literals. That is, "fun lists:reverse/1" is allowed but not
"fun M:F/A".

In many real-life situations, some or all of M, F, A are
not known until run-time, and one is forced to either use
the undocumented erlang:make_fun/3 BIF or to use a
"tuple fun" (which is deprecated).

EEP-23 suggests that the parser (erl_parse) should immediately
transform "fun M:F/A" to "erlang:make_fun(M, F, A)". We have
not followed that approach in this implementation, because we
want the abstract code to mirror the source code as closely
as possible, and we also consider erlang:make_fun/3 to
be an implementation detail that we might want to remove in
the future.

Instead, we will change the abstract format for "fun M:F/A" (in a way
that is not backwards compatible), and while we are at it, we will
move the translation from "fun M:F/A" to "erlang:make_fun(M, F, A)"
from sys_pre_expand down to the v3_core pass. We will also update
the debugger and xref to use the new format.

We did consider making the abstract format backward compatible if
no variables were used in the fun, but decided against it. Keeping
it backward compatible would mean that there would be different
abstract formats for the no-variable and variable case, and tools
would have to handle both formats, probably forever.

Reference: http://www.erlang.org/eeps/eep-0023.html

By default, the debugger use to save all calls on its simulated
stack. That could facilitate finding errors, but it could also
mean that the Debugger could become very slow while executing
tail-recursive code.