You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The line responsible for this difference is AFAICS in tests\misc\sys_settrace_features.py: "misc" + "".join(frame.f_code.co_filename.split("tests/misc")[-1:]),
Where is the cause of these diffs? And how is the .exp file generated?
The .exp for this test is generated by running the file with CPython so the line which has frame.f_code.co_filename.split is the culprit indeed. This should do the trick (replace the slashes so the split() works again correctly):
Both commandlines shown are the same so not really sure what you mean. The diff still has the exact same problem, which is strange because e.g. r'miscF:\MingW32\src\Languages\MicroPython\tests\misc\sys_settrace_subdir\trace_generic.py'.replace('\\', '/').split("tests/misc")[-1:] is ['/sys_settrace_subdir/trace_generic.py'] so it looks as if the patch has no effect; was it applied to the wrong file?
I'm testing it here and the patch makes the path problem go away, and tests pass, so I'm not sure what the problem is on your machine. See #6690 which works for me.
And I noted on AppVeyor all these relevant tests are marked skip (why?):
Because settrace isn't enabled by default and the CI builds d not change that - you also had to change code or pass different flags to make to have it enabled, right?
So obviously something is different for you, but I don't know what and can't really help you. You could start by adding a print(frame.f_code.co_filename) into sys_settrace_features.py and then work from there to figure out why the path you get there doesn't get the expected treatment. Note you seem to be using py -3, not sure if it matters but run-tests defaults to using python3.exe unless you explcicitly set the the MICROPY_CPYTHON3 environment variable.
Sorry now I'm confused: I always assumed you were running a build where you explicitly enabled MICROPY_PY_SYS_SETTRACE, which for the windows ports means e.g. putting this in ports/windows/mpconfigport.h:
So when run with micropython without settrace functionality, this prints SKIP and run-tests picks that up to skip the test.
However from your explanation I now get the impression you didn't enable it explicitly, yet are gettings test failures. No idea how that is even possible.
To figure out what is wrong you'll have to supply enough information so we can get an idea of what you are doing exactly:
what version fo the code you are using (master branch? which commit?)
compiler version (I see you have a directory MingW32, note that only ming-w64 is supported)?
how you build micropython (from which shell, which commands etc)
if you run micropython and type import sys.settrace on the command line, what happens?
Well, the previous comment asked whether MICROPY_PY_SYS_SETTRACE has anything to do with this; to be on the safe side I did not interpret that as 'off course' :)
Anyway: without further info from your side it's going to be hard to fix anything, unless you can figure it out yourself.
Basically, yes, but perhaps not exactly, and that might matter here. Though if I run those commands (only difference for me being I invoke ..\ports\windows\micropython.exe) I get 2 files which are exactly the same.
@gvanem any news here? In the meantime I confirmed the fixes in aforementioned PR on multiple systems. Did you already figure out why simple replacing the slashes doesn't work on your setup?
Seems the replace()ass-u-mes wrongly. And adding a print (" co_filename: %s" % frame.f_code.co_filename), I see many: f:\ProgramFiler\Python36\lib\encodings\cp1252.py
Seeing the differences you have, is it possible you just pulled master? That won't cut it, my PR isn't merged there yet. The code from the PR can be fetched like
Have you considered your failure to understanding is the problem here, not the tool? I politely ignored all your other snarky comments in this thread, but this kind of language is not appreciated here. We want to maintain a nice and friendly environment. And there's plenty of room for criticism and reporting problems, I mean after all it's an issue tracker, but there's no reason to do that in such a disrespectful manner.
Activity
stinos commentedon Dec 10, 2020
The .exp for this test is generated by running the file with CPython so the line which has
frame.f_code.co_filename.splitis the culprit indeed. This should do the trick (replace the slashes so the split() works again correctly):gvanem commentedon Dec 10, 2020
I patched
tests/misc/sys_settrace_features.pyand did:Still fails:
Wrong syntax or wrong patch?
stinos commentedon Dec 10, 2020
Can you show the diff (i.e. run-tests --print-failures)?
gvanem commentedon Dec 10, 2020
With a
py -3 run-tests --print-failures misc\sys_settrace_features.py, there is no files inresults. So one would assume there are no errors?But a
py -3 run-tests misc\sys_settrace_features.py, gives this huge diff misc_sys_settrace_features.diff.txtHow is this obfuscated script supposed d to work?
stinos commentedon Dec 10, 2020
Both commandlines shown are the same so not really sure what you mean. The diff still has the exact same problem, which is strange because e.g.
r'miscF:\MingW32\src\Languages\MicroPython\tests\misc\sys_settrace_subdir\trace_generic.py'.replace('\\', '/').split("tests/misc")[-1:]is['/sys_settrace_subdir/trace_generic.py']so it looks as if the patch has no effect; was it applied to the wrong file?Which one?
gvanem commentedon Dec 10, 2020
I meant
py -3 run-tests misc\sys_settrace_features.py, give huge diffs.stinos commentedon Dec 10, 2020
I'm testing it here and the patch makes the path problem go away, and tests pass, so I'm not sure what the problem is on your machine. See #6690 which works for me.
gvanem commentedon Dec 11, 2020
I've applied you diff and reran
cd tests & py -3 ./run-tests. The same diffs on:tests/results/misc_sys_settrace_features.py.expandtests/results/misc_sys_settrace_features.py.outas before.
And I noted on AppVeyor all these relevant tests are marked
skip(why?):E.g. this one.
So how can you prove your diff works?
stinos commentedon Dec 11, 2020
Because settrace isn't enabled by default and the CI builds d not change that - you also had to change code or pass different flags to
maketo have it enabled, right?Here's a build for which I enabled it and where you can see all 3 tests pass both for the msvc and mingw ports: https://ci.appveyor.com/project/stinos/micropython/build/job/4jaq3kg21j8yrsba?fullLog=true (I don't know how long this stays available though)
So obviously something is different for you, but I don't know what and can't really help you. You could start by adding a
print(frame.f_code.co_filename)into sys_settrace_features.py and then work from there to figure out why the path you get there doesn't get the expected treatment. Note you seem to be usingpy -3, not sure if it matters but run-tests defaults to usingpython3.exeunless you explcicitly set the theMICROPY_CPYTHON3environment variable.gvanem commentedon Dec 11, 2020
Does
MICROPY_PY_SYS_SETTRACE0or1has anything to do with this? I fail to see where / howprelude->qstr_source_filegetsset.
stinos commentedon Dec 11, 2020
Sorry now I'm confused: I always assumed you were running a build where you explicitly enabled MICROPY_PY_SYS_SETTRACE, which for the windows ports means e.g. putting this in ports/windows/mpconfigport.h:
If that is not enabled, all related tests should be skipped automatically because the test files start with
So when run with micropython without settrace functionality, this prints SKIP and run-tests picks that up to skip the test.
However from your explanation I now get the impression you didn't enable it explicitly, yet are gettings test failures. No idea how that is even possible.
To figure out what is wrong you'll have to supply enough information so we can get an idea of what you are doing exactly:
import sys.settraceon the command line, what happens?gvanem commentedon Dec 11, 2020
Off course I have
MICROPY_PY_SYS_SETTRACE=1.stinos commentedon Dec 11, 2020
Well, the previous comment asked whether MICROPY_PY_SYS_SETTRACE has anything to do with this; to be on the safe side I did not interpret that as 'off course' :)
Anyway: without further info from your side it's going to be hard to fix anything, unless you can figure it out yourself.
gvanem commentedon Dec 11, 2020
Trying to simplify this nerdy tool:
cd tests & python3 misc\sys_settrace_features.py > temp.1compared tocd tests & ..\MicroPython.exe misc\sys_settrace_features.py > temp.2Isn't that how
run-testsbasically does it? With your patch,temp.1andtemp.2are different.stinos commentedon Dec 11, 2020
Basically, yes, but perhaps not exactly, and that might matter here. Though if I run those commands (only difference for me being I invoke ..\ports\windows\micropython.exe) I get 2 files which are exactly the same.
stinos commentedon Dec 17, 2020
@gvanem any news here? In the meantime I confirmed the fixes in aforementioned PR on multiple systems. Did you already figure out why simple replacing the slashes doesn't work on your setup?
dpgeorge commentedon Dec 17, 2020
I made a minor change to this settrace test in e0bb7a5 to make it work with more recent Python 3 versions. Not sure if that changes anything here.
stinos commentedon Dec 17, 2020
I had that one in my PR already, and the diff shown earlier only shows path differences, no zipimport calls, so shouldn't matter here I think.
gvanem commentedon Dec 17, 2020
@stinos I did a
git pull10 min ago and rebuilt everything (for Win32 with lwIP sockets) and re-ran this simple case:temp.1contains strings like:Seems the
replace()ass-u-mes wrongly. And adding aprint (" co_filename: %s" % frame.f_code.co_filename), I see many:f:\ProgramFiler\Python36\lib\encodings\cp1252.pyBut I'm utterly confused about what happens here.
stinos commentedon Dec 17, 2020
Seeing the differences you have, is it possible you just pulled master? That won't cut it, my PR isn't merged there yet. The code from the PR can be fetched like
where 'upstream' is the name of the MicroPython remote you use.
As mentioned earlier: the equivalent of this code is in the PR
so the most logical explanation would be that this code is not what you are using? How else could you still get the complete filename printed?
Which should also be solved by the PR since it explicitly skips any stack frame with "encodings" in it's name.
dpgeorge commentedon Dec 17, 2020
Ah, indeed, sorry, I missed it!
gvanem commentedon Dec 28, 2020
I'm closing this as this test-command (in my Makefile) works:
But adding option
--print-failuresas advised gives either no output or indicates a crash:Note it runs
extmod/uselect*.pywhen not told to. I fail to understand this junk tool.stinos commentedon Dec 28, 2020
Have you considered your failure to understanding is the problem here, not the tool? I politely ignored all your other snarky comments in this thread, but this kind of language is not appreciated here. We want to maintain a nice and friendly environment. And there's plenty of room for criticism and reporting problems, I mean after all it's an issue tracker, but there's no reason to do that in such a disrespectful manner.
Retry send if only some bytes sent