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:
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:
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>:
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
-- Amaury Forgeot d'Arc
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:
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:
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>:
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
-- Amaury Forgeot d'Arc
participants (4)
-
Amaury Forgeot d'Arc -
Armin Rigo -
Matti Picus -
Yaacov Finkelman