Hi, I was wondering what the plan is for fixing: https://bitbucket.org/pypy/pypy/issue/1651/ It is just a hassle with each upgrade of pypy. I'd be happy to fix, but I don't know where to start. Best, Jacob
On 04/02/15 20:30, Yaacov Finkelman wrote:
> Hi,
>
> I was wondering what the plan is for fixing:
> https://bitbucket.org/pypy/pypy/issue/1651/
>
> It is just a hassle with each upgrade of pypy.
>
> I'd be happy to fix, but I don't know where to start.
>
> Best,
>
> Jacob
> _______________________________________________
> pypy-dev mailing list
> pypy-dev@python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
We would love to get more windows people on board.
The "where to start" could mean a number of things
1. Where to start with the pypy dev process - try reading
http://pypy.readthedocs.org/en/latest/getting-started-dev.html
2. Where to start with pypy and windows - try reading
http://pypy.readthedocs.org/en/latest/windows.html
3. Where to start fixing this issue once you understand those two - try
looking at how pythonw.exe is different from python.exe in cpython,
create a branch and try to think of how to write tests for that
difference, then implement code that passes the tests, then ask us to
merge the branch.
When you say "it is just a hassle" that leads me to believe you already
know how to fix it (Hint: |cl /subsystem:windows|)
Matti
Hi, On 4 February 2015 at 20:04, Matti Picus <matti.picus@gmail.com> wrote:
When you say "it is just a hassle" that leads me to believe you already know how to fix it (Hint: |cl /subsystem:windows|)
It's probably as easy as tweaking the generated Makefile, to call once "cl" and once "cl /subsystem:windows" to make "pypy.exe" and "pypyw.exe". A bientôt, Armin.
HI, I have "fix it" by copying Pypy.exe then using "EDITBIN.EXE /SUBSYSTEM:WINDOWS C:\pypy\pypyw.exe" from Microsoft Visual Studio to change the relevant byte. [http://stackoverflow.com/questions/574911] So yes, don't give me too much credit for knowing what I'm doing. In honor of learning on the job, let me barg ahead. tweaking a Makefile sounds like a good solution. What part of the code generates the Makefile? The difference between pythonw.exe and python.exe is that one is a "windows" application and the other is a "console" application. Testing this defence... We could run pypyw.exe and check whether a console appears. Slow and requires running on windows. We could check the binary file to see if the relevant byte is set to the correct setting. Requires thorough understanding of the structure of exe that I don't at this time have. As such the test would require good testing. Uew a third party module to check the exe for the correct SUBSYSTEM. All the packages I can find are incredibly out of date, but maybe I missed one, or maybe they still work. Best, Jacob On Thu, Feb 5, 2015 at 10:24 AM, Armin Rigo <arigo@tunes.org> wrote:
Hi,
On 4 February 2015 at 20:04, Matti Picus <matti.picus@gmail.com> wrote:
When you say "it is just a hassle" that leads me to believe you already know how to fix it (Hint: |cl /subsystem:windows|)
It's probably as easy as tweaking the generated Makefile, to call once "cl" and once "cl /subsystem:windows" to make "pypy.exe" and "pypyw.exe".
A bientôt,
Armin.
2015-02-06 3:34 GMT+01:00 Yaacov Finkelman <yeomanyaacov@gmail.com>:
The difference between pythonw.exe and python.exe is that one is a "windows" application and the other is a "console" application.
This has other implications. For example, sys.stdout points to an invalid file descriptor, and I remember that old versions of pythonw.exe used to freeze after printing 8192 characters. -- Amaury Forgeot d'Arc
Hi, On 6 February 2015 at 11:15, Amaury Forgeot d'Arc <amauryfa@gmail.com> wrote:
This has other implications. For example, sys.stdout points to an invalid file descriptor, and I remember that old versions of pythonw.exe used to freeze after printing 8192 characters.
I'm not finding anything special done with stdout if we're pythonw.exe. Can you be more specific? Otherwise I suppose the way forward is to produce pypyw.exe (by editing rpython/translator/platform/windows.py, gen_makefile(), rule for $(DEFAULT_TARGET), to run $(CC_LINK) twice instead of once), and then to wait until people report issues with it. A bientôt, Armin.
2015-02-06 11:27 GMT+01:00 Armin Rigo <arigo@tunes.org>:
Hi,
On 6 February 2015 at 11:15, Amaury Forgeot d'Arc <amauryfa@gmail.com> wrote:
This has other implications. For example, sys.stdout points to an invalid file descriptor, and I remember that old versions of pythonw.exe used to freeze after printing 8192 characters.
I'm not finding anything special done with stdout if we're pythonw.exe. Can you be more specific?
CPython3 has this code to set sys.stdout to None in this case: https://hg.python.org/cpython/file/v3.3.4/Python/pythonrun.c#l1083 But that's probably only for python3, python2 chose to not change anything: http://bugs.python.org/issue706263
Otherwise I suppose the way forward is to produce pypyw.exe (by editing rpython/translator/platform/windows.py, gen_makefile(), rule for $(DEFAULT_TARGET), to run $(CC_LINK) twice instead of once), and then to wait until people report issues with it.
A bientôt,
Armin.
-- Amaury Forgeot d'Arc
On 22/05/15 10:10, Matti Picus wrote:
On 06/02/15 13:14, Amaury Forgeot d'Arc wrote: CPython3 has this code to set sys.stdout to None in this case: https://hg.python.org/cpython/file/v3.3.4/Python/pythonrun.c#l1083
But that's probably only for python3, python2 chose to not change anything: http://bugs.python.org/issue706263 I merged pypyw which simply creates another exe, in line with what Armin suggested. Amaury, it is not clear to me how stdout is set to None since AFAICT is_valid_fd(stdout) passes, at least in the rpython test I tried. To reproduce: run test_shared in translator/c/test_standalone.py, then run the resulting test-1w.exe as
test-1.exe a b 2>err.txt
It will print a rpython exception to err.txt indicating that it failed in the actual write, not in the is_valid_fd(stdout) test just before the write.
Matti
Ahh, is_valid_fd in cpython also checks dummy_fd = dup(fd), which we do not do (in rposix.py). Sorry for the noise. Matti
participants (4)
-
Amaury Forgeot d'Arc -
Armin Rigo -
Matti Picus -
Yaacov Finkelman