-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
367 compiled sucessfully in w10 py311 but createprocess fails call to dispread to measure #374
367 compiled sucessfully in w10 py311 but createprocess fails call to dispread to measure #374
Conversation
22d0e1b
to
89bf969
Compare
Ok, it fails to attach a TTY right to the subprocess and hangs, and I actually get a nice isatty NoneType AttributeError on Windows if launched via pythonw. So, wexpect/tty issues it appears. Will see what I can do about them. |
Ok, so it appears that frozen version does something extra in its script to make wexpect work: From wexpect.py - that's probably the secret sauce, it runs a subscript that does something to grab the console... and utterly fails. The executable is launched but sits there. I need more logs from wexpect to see what's up. |
And that's that. Not sure how you want to set it to utf-8 with this API by string. It should be number 65001. |
There's more, I have a patch cooking, though while it's working, I'm not sure it's fully correct and I need to clean it up. Specifically new Python as launched by wexpect gets no standard handles (stdin/out/err), while the Argyll subprocess created from that is told to inherit the handles - because new Python sets this process flag for itself, presumably so that it can thread and subprocess as expected. Plus there's yet another Unicode bug in WAIT_TEMPLATE which I fixed. |
See #383 for the additional fixes. This is on top of this branch. |
Hi, not sure if this is the place to post this or this should be a new issue. I tried going through the windows manual install process in the readme to build and run this branch. Encountering the below error where the argyll executable could not be started. I'm including the terminal output below if it's helpful. I'm on Windows 11 and Python 3.11.3. Thanks for the effort at modernizing DisplayCAL! Cheers
|
@nelsonlim You should try my branch, yes it includes this one. That is supposed to work, drop me a line if it does not. |
@nelsonlim please report this in another ticket, I'm ready to merge this one. |
…t contain any empty spaces.
…ame.profile_finish()`.
…handlers` attribute in `DisplayCAL.multiprocess.WorkerFunc.__call__()`.
…profile_loader.setup_profile_loader_task()`.
…ileFrame.LoadProfile()`.
…o._Sound.play()` on application exit.
…version number to allow the embedded manifest to follow Microsoft rules and the frozen executable to run.
…layCAL.wxScriptingClient` for `bytes` vs `str` problems.
…tialize the `print_` arg with `None` and set its default value inside the method, instead of writing a complex expression on the argument itself.
…e returned by the `kernel32` library instead of manually setting it to `utf-8` as `cp1252` seems to be working fine, after #383 has been merged. And, simplified a couple of `if` statements that are checking the `stdout.isatty()` value, and updated code formatting.
…commands through `py2exe` frozen `python` interpretter.
… that the installer uses "Program Files" instead of "Program Files (x86)" by default.
…file path between quotes to prevent space characters in the file path to cause any errors.
…conf()` for a `str` vs `bytes` error raised when the VCGT doesn't have exactly 256 entries.
…gs under Windows and not under Linux/MacOS.
Windows Installer
…rce distributions in `DisplayCAL.setup`.
… the `Makefile`. - [#367] Fix `build` target in the `Makefile` to first activate the virtual environment and then install the requirements.
DisplayCAL now runs properly on Windows with Python 3.9, 3.10 and 3.11.