irssi-import / irssi-python Goto Github PK

Loading the python module through the startup file results in:

/usr/local/lib/x86_64-linux-gnu/irssi/modules/libpython.so: undefined symbol: dcc_conns

A simple run of nm on the irssi shared objects shows that that symbol is defined in libirc_dcc.so.

$ nm libirc_dcc.so | grep dcc_conns
00000000000145e8 B dcc_conns

The startup file is being acted upon in textui_finish_init in main in src/fe-text/irssi.c(autorun_startup <- fe_common_core_finish_init <- textui_finish_init to be more accurate).
I did a quick run with gdb. the module(s) in the startup file are being loaded before the modules are being loaded by default which in case of the python module causes a failure to actually load the module.

#0  module_load (path=0x5555556a1628 "dcc", prefixes=0x5555556c30e0) at ../src/core/modules-load.c:326
#1  0x00005555555d19fe in cmd_load (data=0x5555556a0fc0 "-silent dcc") at ../src/fe-common/core/fe-modules.c:194
#2  0x00005555555b1b2c in signal_emit_real (rec=0x555555663e90, params=0x1, va=0x7fffffffe4b0, first_hook=0x555555663ec0) at ../src/core/signals.c:242
#3  0x00005555555b1dbe in signal_emit (signal=0x5555555f7c97 "command load", params=0x1) at ../src/core/signals.c:286
#4  0x000055555557f99d in sig_autoload_modules () at ../src/fe-text/irssi.c:95
#5  0x00005555555b1b2c in signal_emit_real (rec=0x555555662250, params=0x0, va=0x7fffffffe680, first_hook=0x5555556793b0) at ../src/core/signals.c:242
#6  0x00005555555b1dbe in signal_emit (signal=0x555555601dfb "module autoload", params=0x0) at ../src/core/signals.c:286
#7  0x00005555555c696a in fe_common_core_finish_init () at ../src/fe-common/core/fe-common-core.c:533
#8  0x000055555557fc83 in textui_finish_init () at ../src/fe-text/irssi.c:202
#9  0x0000555555580041 in main (argc=0x1, argv=0x7fffffffe8d8) at ../src/fe-text/irssi.c:328

Breakpoint 1, module_load (path=0x5555556a1628 "dcc", prefixes=0x5555556c30e0) at ../src/core/modules-load.c:326
326     {
(cmd)GDB >>> print(path)
$4 = 0x5555556a1628 "dcc"

The order should be flipped for autorun_startup() and signal_emit("module autoload",0):
https://github.com/irssi/irssi/blob/master/src/fe-common/core/fe-common-core.c#L532

Currently the load path for the python scripts is hardcoded to either be $(data_dir)/irssi/scripts or $IRSSI_HOME/scripts.
The module will refuse to load scripts from other paths.
The message returned in this case is a "script not found" which is not helpful and confusing(if you expect the same behaviour as the perl module).
Either the error message should reflect this or like the perl module, we should allow the python scripts to be loaded from other paths as well.

Hi; any plans to get this working with 3.7+?

Is there an equivalent for the perl modules's Irssi::parse_special in the python module?
I'm trying to get the contents of the input buffer but I'm not sure how to do that.

Calliing irssi.settings_add_str with string args will result in error.
For example:
running this snippet

irssi.settings_add_str("misc", "transformer_model", "gpt-3.5-turbo")

will result in this:

TypeError: a bytes-like object is required, not 'str'

doing something like below will "bypass" the problem:

irssi.settings_add_str(bytes("misc", encoding="utf-8"), bytes("transformer_model", encoding="utf-8"), bytes("gpt-3.5-turbo", encoding="utf-8"))

(not saying this is acceptable, just providing context)

For this specific case, looking at the source code the answer is obvious:
https://github.com/irssi-import/irssi-python/blob/py3/src/objects/pyscript-object.c#L414

PyArg_ParseTupleAndKeywords is being called with a yyy format string which according to here means it expects a byte-like object and not string.
I'm assuming there was a change in python's C API a while back which causes this issue now.

Currently there 147 instances of PyArg_ParseTupleAndKeywords being called in irrsi-python. most of them have y in their format. i will have to look at each and every one of them on a case by case basis and see whether a change is required for newer python versions.

This problem should be present in a lot more places is what I'm saying essentially.

As for the fix, I should first read this thoroughly and then find out when the "supposed change" happened in python's C API to decide whether we want to be backwards compatible with that specific python version or not. But that's a technicality of adding in pragmas. The proposed change will be to use another format string so that the functions actually accept string, decided on a case by case basis.
(the issue is present in python 3.10, the docs im linking to here are for 3.11, havent looked at any other python version yet)