Fantix King

icon indicating a website link http://about.me/fantix icon indicating an email [email protected]

icon company @edgedb icon location Toronto, ON icon location I code in Python and more. @decentfox: Outsourcing, Consulting, Startup

Results 216 comments of Fantix King

uvloop fails to import on SPARC64: OverflowError: Python int too large to convert to C long

> after all why do we need int64_t cast? I think this was because Python < 3.7 still return `long` instead of `unsigned long`. Now that we don't support Python...

TimerHandle.when() segfaults if called after callback

Thanks for the report and the PR! This is now fixed in c39afff.

enable the cython binding=True directive

Oh let me try that. --- OK, I'd probably do Cython 3 in another uvloop release, it'll take some time to adapt to Cython 3, also Cython 3 would be...

`pip install uvloop` error on LoongArch

Thanks for the report and sorry for the late reply! I'm happy to help supporting LoongArch. The `config.{sub, guess}` files included in the 0.16.0 source tarball is generated by an...

Issue with graceful shutdown

None of the two errors in the traceback indicates a bug in uvloop, it's likely an issue in the `AES` code, a reproducible code snippet would help. Closing for now,...

Get uv_loop_t pointer

Fixed in #310

set_exception_handler is not handling exception as expected.

Thanks for the report! Unfortunately with a simple echo server/client, I cannot reproduce your issue. Could you please provide a self-contained script to reproduce the issue please?

"Assertion `loop->watchers[w->fd] == w' failed." with multiprocessing and OS pipes

This seems to be a pretty serious issue - when the buffer is full writing to a pipe, this is 100% reproducible: ```python import asyncio from asyncio.subprocess import PIPE import...

"Assertion `loop->watchers[w->fd] == w' failed." with multiprocessing and OS pipes

@1st1 sry for the late reply! Let me try the latest libuv 1.39.0

"Assertion `loop->watchers[w->fd] == w' failed." with multiprocessing and OS pipes

#342 should've already fixed the crashing (using libuv internal flags as a workaround), while there isn't a proper fix from the upstream yet. However, I think this issue revealed another...