Created on 2009-01-15 23:00 by lkcl, last changed 2010-08-03 18:31 by terry.reedy. This issue is now closed.
|x||lkcl, 2009-01-16 11:59||updated patch|
|msg79924 - (view)||Author: Luke Kenneth Casson Leighton (lkcl)||Date: 2009-01-15 23:00|
this is a _very_ strange case where the file contents cannot be read, under msys+wine, but under _just_ wine (cmd.exe) everything goes absolutely fine. by moving Py_Initialize() to _before_ the file load, it works!
|msg79933 - (view)||Author: Gabriel Genellina (gagenellina)||Date: 2009-01-16 06:16|
what is WEIRD_DEBUG? why do you remove a test from string_tests.py? why do you modify a command in setup.py? What do you mean "the file contents cannot be read under msys+wine"? What specific error you have? The right thing to do would be to analize that error and fix the causes. Randomly flipping blocks of code isn't a good practice.
|msg79951 - (view)||Author: Luke Kenneth Casson Leighton (lkcl)||Date: 2009-01-16 10:53|
hi gabriel, thanks for looking at this, and my apologies for not editing the patch to remove debug and other information: i'm in the middle of a comprehensive porting session. WEIRD_DEBUG was me endeavouring to find out what the hell is going on test_str.py segfaulted python under wine due to HAVE_SNPRINTF not being defined - but that's irrelevant to this issue likewise ignore the modification to setup.py regarding the advice to "seek out and understand the cause", i have to say that i much prefer to ... how can i put this best... @BEGIN CAVEAT THE FOLLOWING STATEMENTS ARE MADE WITH ABSOLUTELY NO INTENTION TO CAUSE OFFENSE DO NOT TAKE THIS PERSONALLY IN ANY WAY DO NOT TAKE IT AS A DELIBERATE INTENT TO OFFEND, CAUSE OFFENSE, CRITICISE OR OTHERWISE INDICATE MALICIOUS OR HOSTILE INTENT being absolutely honest: i genuinely do not care about "the cause". what i care about is "working". "does it work if this code is moved? yes." "does it work if the code is not moved? no". does it _matter_ if the "cause" is identified? no. will someone else, possibly in the future, accidentally encounter or deliberately and actively seek out the "cause"? possibly. so - many many apologies for saying this, but i have much better and more interesting and valuable things to be doing with my time than _finding out_ why moving specific bits of code "makes things works". yes it would be nice to know... but i don't care!! because, most importantly, me _knowing_ makes absolutely xxxx-all difference to the outcome of whether "it will work" or not. so, on balance, i'd rather spend my time finding out the additional code-moving and code-improving required to debug the additional bug where "python.exe -i" will give me a prompt but "python.exe" with no arguments will not (and hangs). @END CAVEAT gabriel, hi, debugging python.exe under msys under wine under linux is _really_ tricky. * gdb.exe under msys under wine under linux not only segfaults on exit but also refuses to fork() in order to spawn the process to be debugged! * strace obviously cannot be used _inside_ msys / wine * strace _outside_ - on the /usr/bin/wine process - often interferes with the processes it is tracking, causing them to run out of resources and also to fail to start up. * gdb cannot be attached from _outside_ of wine (/usr/bin/winegdb) to an internal process. fortunately, segfaults inside wine result in quite a good stacktrace report, including line numbers and filenames inside python, but in this case it's "hanging" - and there's something _really_ weird going on with the stdin, stdout and stderr. overall, then, the payoff in time invested in "understanding" what is going on by using non-standard and laborious debugging techniques is extremely small. small enough so that, i am very very sorry to say, i'm not going to put any further time into this _other_ than to _actually_ fix bugs, rather than "understand" bugs. it's a development technique that has saved me _vast_ amounts of time. i never worry about "why" - i just "get on with it".
|msg79952 - (view)||Author: Luke Kenneth Casson Leighton (lkcl)||Date: 2009-01-16 10:55|
here's a clue: $ ./python.exe -i Python 2.5.2 (r252:60911, Jan 16 2009, 10:34:33) [gcc] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> >>> exit() close failed: [Errno 0] Success $
|msg79953 - (view)||Author: Luke Kenneth Casson Leighton (lkcl)||Date: 2009-01-16 10:56|
here's another clue: $ ./python.exe stdin_is_interactive: 0
|msg79954 - (view)||Author: Luke Kenneth Casson Leighton (lkcl)||Date: 2009-01-16 11:59|
here's an updated version, without the cruft. this has a workaround for the problem of stdin being seen as not a tty (!) until _after_ Py_Initialize() is run.
|msg79998 - (view)||Author: Gabriel Genellina (gagenellina)||Date: 2009-01-17 03:25|
Ok, imagine for a moment that your patch is accepted and applied. Python runs in a wide variety of systems. Now imagine that, in a few of them, it stops running. What would you say to defend your changes? "I have no idea why, but it works for me!". I have no doubt your changes would be reverted in two nanoseconds, and your chances of getting a second patch accepted would drop near zero. I understand your project and hope you successfully complete your goals, but it seems it's not madure enough yet. At this stage, blogging about your progresses and writing some sort of recipe would be more adequate, until you get a system that builds cleanly and passes most (if not all) test cases. This applies to your other pending patches too. PS: I don't know the English term, but here in Argentina (Spanish) the way you "fix" bugs would be called "chapuza". No offense intended.
|2010-08-03 18:31:53||terry.reedy||set||status: open -> closed|
resolution: out of date
|2009-01-17 03:25:19||gagenellina||set||messages: + msg79998|
|2009-01-16 14:13:36||lkcl||set||files: - f|
messages: + msg79954
|2009-01-16 10:56:29||lkcl||set||messages: + msg79953|
|2009-01-16 10:55:42||lkcl||set||messages: + msg79952|
|2009-01-16 10:53:36||lkcl||set||messages: + msg79951|
messages: + msg79933