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
Using TextLog with max_lines defined doesn't seem to work as intended, with the widget refreshing every power-of-10 line writes (sounds very weird, keep reading).
Code below writes to the text log every time a key is pressed ("Key press #{counter}") and advance a counter. With max_lines=3, three lines are printed out, sequentially and as expected:
from textual.app import App
from textual.widgets import TextLog
class TextLogLines(App):
count = 0
def compose(self):
yield TextLog(max_lines=3)
async def on_key(self):
self.count += 1
log_widget = self.query_one(TextLog)
log_widget.write(f"Key press #{self.count}")
print(log_widget.lines) # Sanity check via `textual console`
print(dict(log_widget._line_cache)) # What's in the cache?
app = TextLogLines()
if __name__ == "__main__":
app.run()
A fourth press should refresh the TextLog and show lines #1,#2,#3. However, it doesn't. The print statement (as viewed at the output of textual console) shows the proper array of lines (list is 3-members long as one would expect from the source code.
Up to now this might be a "reasonably-misbehaving" bug - but if the key is pressed multiple times, the widget refreshes at the 10th press. This happens again at 100 (namely, no refresh when counter=11 to 99, but with the 100th press, the widget refreshed). 10, 100, best guess of next refresh is 1000 and indeed, widget refreshes again at 1000. Same at 10k line writes.
This odd behavior was observed with varying screen sizes, and max_line values (if max_lines > 10, e.g. 30 widget fills to 30 lines just fine, but next refresh is at 100 line writes).
Might this be somehow related to the LRUCache? Looking at the console output, the LRU cache fills to the third line, only updates on the 11th log write, but shows lines 1,2,3, 8,9,10 cached. Here's the output (well after the 11th write, for both the self.lines object and the LRU cache):
Without knowing much about LRU cache behavior, it seems odd to have these two groups of Segments cached, w/o anything in between, and it's unclear how any of this might lead to power-of-10 refreshes.
The text was updated successfully, but these errors were encountered:
mindset-team
changed the title
TextLog w/ max_lines only refreshes on powers of 10?
TextLog w/ max_lines only refreshes on powers-of-10 line writes?
Oct 30, 2022
Using TextLog with max_lines defined doesn't seem to work as intended, with the widget refreshing every power-of-10 line writes (sounds very weird, keep reading).
Code below writes to the text log every time a key is pressed ("Key press #{counter}") and advance a counter. With max_lines=3, three lines are printed out, sequentially and as expected:
A fourth press should refresh the TextLog and show lines #1,#2,#3. However, it doesn't. The print statement (as viewed at the output of
textual console
) shows the proper array of lines (list is 3-members long as one would expect from the source code.Up to now this might be a "reasonably-misbehaving" bug - but if the key is pressed multiple times, the widget refreshes at the 10th press. This happens again at 100 (namely, no refresh when counter=11 to 99, but with the 100th press, the widget refreshed). 10, 100, best guess of next refresh is 1000 and indeed, widget refreshes again at 1000. Same at 10k line writes.
This odd behavior was observed with varying screen sizes, and max_line values (if max_lines > 10, e.g. 30 widget fills to 30 lines just fine, but next refresh is at 100 line writes).
Might this be somehow related to the LRUCache? Looking at the console output, the LRU cache fills to the third line, only updates on the 11th log write, but shows lines 1,2,3, 8,9,10 cached. Here's the output (well after the 11th write, for both the self.lines object and the LRU cache):
Without knowing much about LRU cache behavior, it seems odd to have these two groups of Segments cached, w/o anything in between, and it's unclear how any of this might lead to power-of-10 refreshes.
The text was updated successfully, but these errors were encountered: