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]
