Open adeak opened 1 year ago
Hi @adeak
I may be facing the same issue in https://github.com/PyFPDF/fpdf2/pull/714, and I'd love to try your patch.
Considering that the patch applies to kaleido/cc/utils.h
, will it be taken into account if install Kaleido
from your git branch?
pip install git+https://github.com/adeak/Kaleido.git@flush_after_json_printing
Or do I have to compile my own version of the kaleido
binary executable?
That won't work @Lucas-C, because the package has no setup.py, and because it's probably not how it works in general.
Reading the README (especially the "disadvantages" section) sounded like compilation is a huge amount of effort. This is why I didn't try to do that... Even if this PR works I'd have to build kaleido twice: first to check that a local rebuild on its own doesn't make the issue go away, and then rebuild for the PR branch. And it's very likely that
Considering that the library seems unmaintained in general, this is not a super encouraging situation for going on potential wild goose chases, alas. When I opened this PR I was hoping that someone with the project already has tooling and CPU hours to build this so we can test.
Thank you for the detailed answer @adeak!
I tried to compile it on my machine yesterday, following the steps in the .circleci/config.yml, win_scripts/fetch_chromium.ps1 & win_scripts/build_kaleido.ps1 files, but it took ages to download & setup all the required repos & tools, so I gave up in the end.
I probably won't dive into this any further.
Whoever reads this: have a nice day!
I pulled the latest version and the fork into a local repo and went through all of the compilation steps, and installed the generated wheel file on my WSL2 setup, which is having the same issue, and unfortunately I had no luck with it. It was still hanging on image generation forever, and the error stream when interrupted was the same.
The next step I'd like to try would be pulling a newer version of Chromium, since this current Kaleido build uses one that is significantly older, but it requires re-tooling the majority of the build process, and won't be a fast process to find all of the changes that have to be made.
Thanks for your interest in Kaleido. We are currently working on an overhaul that might address your issue - we hope to have news in a few weeks and will post an update then. Thanks - @gvwilson
Sounds great, thanks for the update @gvwilson.
This is a potentially "wishful thinking" attempt to fix (a subset of?) the "writing image stalls" problem with a dozen or so open issues. Unfortunately I haven't been able to test whether it fixes the issue, because I do not have the tooling at hand to build the library (assuming this indeed involves the 50 GB chromium compile). If there's a low-profile way to compile this patch I'd love to test it locally on my "known bad" setup.
My situation:
fig.write_image()
will hang on my machine, and it will always succeed on coworker's machine. (So it's not the "sometimes hangs on the same system" case some people see.)self._proc.stdout.readline()
line in_ensure_kaleido()
, see e.g. traceback in https://github.com/plotly/Kaleido/issues/36#issuecomment-756614157Buffering?
The only thing I can suspect here is buffering. If for some reason the process is not line buffered (and kaleido runs the subprocess with a binary stdout stream, so I'm not even sure line buffering is a thing there), the
readline()
call might be stuck, waiting for the stdout stream to flush, which for some reason might not happen on some systems.Why it might not be buffering:
universal_newlines=True
doesn't make the problem go away. Manually callingself._proc.stdout.flush()
doesn't make the problem go away. Accessingself._proc.stdout.raw
which might be less buffered doesn't make the problem go away. Callingself._proc.stdout.read(70)
or even.read(50)
(since we expect 70 characters for the JSON) halts all the same.subprocess.Popen
setup) doesn't stall.bufsize=50
(say) which is shorter than the 70 bytes of the expected JSON doesn't make the problem go away (it still stalls).Why it might be buffering:
readline()
call freezes in the subprocess call (JSON is stuck in the buffer).std::endl
which would flush.Unfortunately I couldn't find any exact information on what kind of buffering options are available on a given OS, and what defaults are. The only thing I could figure out is that both in my native Windows and in my WSL the
io.DEFAULT_BUFFER_SIZE
is 8192, so if the output is not line buffered then it would take a lot of output to get it flushed (assuming I even understand the mechanics here correctly).