This follows the recommendation from Pythons documentation for
PyModule_GetDict where it says:
It is recommended extensions use other PyModule_* and PyObject_*
functions rather than directly manipulate a module’s __dict__.
This value determines the size of the per-module memory area. Setting
this value to -1 as it was before this change means that the module has
global state and therefore does not support subinterpreters.
However, subinterpreters are used to run the Python scripts, so the
weechat module has to support subinterpreters. Therefore we should set
this value to 0 as no per-module memory is required.
This seems to fix the crash reported in #2046 without the need for the
workaround added in commit 85c7494dc (it does for me when testing with
Python 3.12.0 at least).
This change came up as a suggestion in cpython's issue tracker where it
was pointed out that using modules with m_size set to -1 is not
supported in subinterpreters. See these two comments:
https://github.com/python/cpython/issues/116510#issuecomment-2377915771https://github.com/python/cpython/issues/116510#issuecomment-2389485369
It's not completely clear to me what is required for a module to support
subinterpreters and re-initialization (which is required for setting
m_size to 0), but https://peps.pythondiscord.com/pep-0489/ says:
A simple rule of thumb is: Do not define any static data, except
built-in types with no mutable or user-settable class attributes.
The only static data we define is of type int and str, so I think it
should be fine.
This fixes the following CMake warning:
CMake Warning (dev) at src/gui/curses/normal/CMakeLists.txt:73 (add_custom_command):
Exactly one of PRE_BUILD, PRE_LINK, or POST_BUILD must be given. Assuming
POST_BUILD to preserve backward compatibility.
Policy CMP0175 is not set: add_custom_command() rejects invalid arguments.
Run "cmake --help-policy CMP0175" for policy details. Use the cmake_policy
command to set the policy and suppress this warning.
This warning is for project developers. Use -Wno-dev to suppress it.
This fixes a crash which would happen if you scrolled the script buffer
and then did a search which got fewer search results than the index of
the selected line before the search. E.g. press page down to go to the
second page and then search for `test`.
It turns out that Debian has reverted the commit in Perl that broke the
locale in their 5.38 branch, so it did not have the issue. However, the
workaround we added to fix the locale apparently makes the version
Debian/Ubuntu has crash on perl_destruct. I'm not sure why it makes it
crash, but since it doesn't crash on newer Perl versions, I'm assuming
that it's another bug with the locale handling in that Perl version.
To avoid the crash, make sure to only set the locale if we detect that
it has been broken by Perl. We do this by checking if the value returned
by wcwidth (160) (the first non-ascii printable character) has changed.
If this value is not the same after the call to perl_construct, the
locale has been broken.
I moved the call to Perl_setlocale to right after perl_construct, as the
call to perl_construct is what breaks the locale.
Apparently the issue with the locale being reset with Perl 5.38 can
cause a crash when unloading the scripts on some systems (at least
Ubuntu 24.04). There was a workaround added in commit f4b9cad72, but it
doesn't work to avoid the crash. However if we set LC_ALL instead of
LC_CTYPE the crash doesn't occur.
Fixes#2187
If a request repeats the same header name multiple times, merge the
header values into a comma separated string. Previously, only the last
header specified would be used.
For header fields that are defined as a comma-separated list, a client
may choose to send it as multiple headers instead of one header with
comma-separated values. The specification says that these are
equivalent, so we can therefore join the headers into a comma-separated
string.
This is specified at https://datatracker.ietf.org/doc/html/rfc7230#section-3.2.2
which says:
A sender MUST NOT generate multiple header fields with the same field
name in a message unless either the entire field value for that
header field is defined as a comma-separated list [i.e., #(values)]
or the header field is a well-known exception (as noted below).
A recipient MAY combine multiple header fields with the same field
name into one "field-name: field-value" pair, without changing the
semantics of the message, by appending each subsequent field value to
the combined field value in order, separated by a comma. The order
in which header fields with the same field name are received is
therefore significant to the interpretation of the combined field
value; a proxy MUST NOT change the order of these field values when
forwarding a message.
The API for connecting to WebSockets in browsers unfortunately doesn't
support setting any Authorization header. This means that before this
commit it was impossible to connect to the API relay from a web browser.
The only thing that can be set apart from the URL is the
Sec-WebSocket-Protocol header. Therefore this allows you to send the
auth token in this header.
This is a weird way to send auth, but it seems to be the best one that
makes it possible for browsers to connect. Kubernetes also does it this
way: https://github.com/kubernetes/kubernetes/pull/47740
Here is a post describing the different ways to make it possible for a
browser to authenticate against a websocket connection, and it also
recommends doing it this way:
https://stackoverflow.com/questions/4361173/http-headers-in-websockets-client-api/77060459#77060459
Note that when this header is used to pass auth, the client also needs
to specify the `api.weechat` sub protocol. This is because the client
and server have to agree on a sub protocol when this header is
specified, and in order to not send the fake protocol used for auth back
to the client, we require specifying the protocol `api.weechat`, which
the server then returns to the client. This is only necessary when the
Sec-WebSocket-Protocol header is used. If the Authorization header is
used for auth as before, nothing changes.
Detail of changes:
- the save of upgrade files in plugins is now done as soon as the "upgrade"
signal is received, and not when the plugin is unloaded (it was too late to
detect any problem and prevent the upgrade to happen)
- if the write of an upgrade file fails, the signal callback in plugin now
returns WEECHAT_RC_ERROR and WeeChat checks this code to stop the upgrade as
soon as this return code is received
- a new flag is added in plugin structure: unload_with_upgrade, it is set to 1
before unloading all plugins when upgrade will happen (all *.upgrade files
are then already successfully written).
For now the only supported flag is:
- "stop_on_error": stop execution of callbacks immediately after an
error (ie return code of callback is WEECHAT_RC_ERROR) and return this code
(by default execute all callbacks and return the last return code, or return
WEECHAT_RC_EAT immediately if a callback returns this)
Example:
hook_signal_send("[flags:stop_on_error]my_signal", WEECHAT_HOOK_SIGNAL_STRING, "test");
Nils