FYI: I opened an issue: https://github.com/inducer/pudb/issues/375
On Wed, Jan 22, 2020 at 1:59 PM Aaron Meurer <[email protected]> wrote: > It would also help to open an issue about this in the PuDB issue > tracker so we don't forget about it. > > Aaron Meurer > > On Wed, Jan 22, 2020 at 9:52 AM David Carson <[email protected]> wrote: > > > > I cannot really give you anything to use to reproduce it. I'll dig > around in linecache some more and see if I can see anything useful there. > > > > The only lead that looked like it might be useful, mixed-case filenames, > did not seem to be a contributing factor based on my copy experiment > (copying to lowercase filename). But you might want to try that anyway, > together with the './<script>' method of command-line invocation. > > > > On Tue, Jan 21, 2020 at 5:42 PM Aaron Meurer <[email protected]> wrote: > >> > >> On Tue, Jan 21, 2020 at 3:06 PM David Carson <[email protected]> > wrote: > >> > > >> > > >> > > >> > On Tue, Jan 21, 2020 at 4:14 PM Aaron Meurer <[email protected]> > wrote: > >> >> > >> >> On Tue, Jan 21, 2020 at 1:51 PM David Carson <[email protected]> > wrote: > >> >> > > >> >> > > >> >> > On Tue, Jan 21, 2020 at 12:33 PM Aaron Meurer <[email protected]> > wrote: > >> >> >> > >> >> >> On Tue, Jan 21, 2020 at 6:24 AM David Carson <[email protected]> > wrote: > >> >> >> > > >> >> >> > >> >> >> At a technical level, PuDB reads the source from the linecache > module. > >> >> >> Python's import mechanism should put the source into the linecache > >> >> >> module whenever a file is first executed, so PuDB can't find the > >> >> >> source, it means that somehow that part failed. Normally this only > >> >> >> happens for automatically generated code (anything ran through > exec() > >> >> >> or compile() won't be put in the linecache unless you do so > manually), > >> >> >> or a C extension. To see what is going on, you would need to see > if > >> >> >> your file is in linecache.cache. > >> >> >> > >> >> > > >> >> > Hmm, interesting. The filename ("./foo.py") is a key in > linecache.cache. The value of that key (i.e., the file text) appears to be > correct. That gave me the idea of invoking from the command line using > `pwd`/foo.py instead of ./foo.py. Bingo! Now it works. > >> >> > > >> >> > It is still unclear what the difference is. I'm invoking from the > current directory, so using the dot notation should be the same thing. > >> >> > >> >> I guess somehow it gets put in there as "./foo.py" but the filename > >> >> that it gets compiled with is "/full/path/to/foo.py". Pudb will use > >> >> the filename that its compiled with. The linecache dictionary only > >> >> matches if the keys are exactly the same. I don't really know how > this > >> >> happens, and I can't reproduce it. It seems to me that whatever > >> >> compiles the code should use the same filename as whatever puts the > >> >> lines in the linecache. There's probably a bug here somewhere, but I > >> >> can't really say where without being able to reproduce it. > >> > > >> > > >> > I'm willing to help debug this if you give me some instructions on > what data you need. The tool has been my friend, so I ought to give back. > (If you want to take it off the mailing list, that's OK too. The e-mail > address I'm using to post is the right one to use.) > >> > >> The most helpful thing would be something that I can use to reproduce > >> the issue. What I would want to figure out is when the file's source > >> is put in the linecache, and why that filename differs from the one > >> present in the frame when it executes. > >> > >> Aaron Meurer >
_______________________________________________ Pudb mailing list -- [email protected] To unsubscribe send an email to [email protected]
