-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Q] How to use the linecache #29
Comments
It appears that this only happens with documents which are larger than my view (so need scrolling) - or maybe the load on the linecache just increases at that point? |
I'm out for today, but do you mind cherry-picking 11b00d0 and sharing the logs? Otherwise I'll give it a try tomorrow. |
Here's the log: https://gist.github.com/1c117455b09c33e3bd8ded8ce83733b9 Everything starts going wrong at about 38:26/27. I'll look into it tomorrow too, gonna sleep now. Thanks for your help! |
So, here's a log of just the linecache, which is way easier to read: https://gist.github.com/cdcc742aad2b6d9b6b42fb361b39aea3 What looks really fishy to me:
It jumps from line_number 38 to 68, it has line_number 66 twice |
Maybe this is due to odd timing though? Right now I funnel all |
Ok so the last "good" cache is:
The operations that messes it up:
First messed up cache:
|
@Cogitri do you have the full logs corresponding the the "cleaned up" logs you shared? It seems that the first gist is from a different dump. |
Ah, I can make full logs in a bit, those are from different runs indeed. |
That's fine, don't worry. The first dump will be enough in case I need to try to debug timing issues. |
Alright, thank you very much for looking into this! |
Heh, seems like GitHub tried to be too smart on this one? |
Huh, I just tested this again with |
Alright, I think I've figured it out. I did a bit of debugging with gxi v0.8.1, the last release before I've switched to xrl. First I serialized a Then I switched it over to just use Using a Sorry that the commits aren't super tidy, I guess I should sleep now :) |
See https://github.com/Cogitri/gxi/tree/gxi-linecache for a version of gxi that uses xrl for everything but the cache for debugging purposes :) |
I'm a little confused: do you think your fix to gxi's line cache should be transposed to xrl's ? |
Ah, no, I still think we should go with xrl's LineCache due to xrl's version being faster, but while looking for what caused this I thought it'd be easiest to just try and replicate this issue on something known good in this regard, maybe my write-up about it helps :) Sorry that I wasn't clear on this :) |
Hello,
It appears that I misuse the linecache (or I somehow discovered a weird bug, which may very well be in gxi though?). I'm not 100% certain how to trigger the behaviour I'm going to describe, but it usually happens after working on a document which is rather big for a while. At some point the linecache just bugs out, not giving me the right lines, which manifests s such stuff:
The
i
is the line number (during drawing), theline.text
is the text of the line. The duplicates shouldn't be there. Maybe I'm getting the lines during an update of the linecache? My drawing function is a bit primitive and just looks like this:This happens both with gxi using all of xrl and with xrl only using xrl's linecache (Cogitri/Tau@911c4e3 the commit is a bit broken due to rebasing, but after a tiny bit of fixing I could observe the same behaviour).
The text was updated successfully, but these errors were encountered: