azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/azonenberg/scopehal-apps, https://github.com/azonenberg/scopehal, https://github.com/azonenberg/scopehal-docs | Logs: https://freenode.irclog.whitequark.org/scopehal
_whitelogger has joined #scopehal
_whitelogger has joined #scopehal
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #scopehal
_whitelogger has joined #scopehal
DanRoh has joined #scopehal
electronic_eel has quit [Ping timeout: 256 seconds]
electronic_eel_ has joined #scopehal
juli965 has joined #scopehal
<_whitenotifier-f> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JU3Vu
<_whitenotifier-f> [scopehal] azonenberg 78f3629 - SPIFlashDecoder: added "read ID code" parsing support
<azonenberg> Hmmmm
<azonenberg> So right now the glscopeclient protocol analyzer view is a simple list
<azonenberg> but it's internally implemented as a tree view control
<azonenberg> Because in GTK, a list view is just a tree view with a single level of hierarchy
<azonenberg> I'm wondering if it might not make sense to eventually implement multilevel support
<azonenberg> my immediate use case is in the protocol analyzer view, i see a lot of SPI flash transactions that are "poll status until some bit is set"
<azonenberg> and i feel like it would make sense in the view to collapse this into a single heading "status poll loop" or similar
<azonenberg> that you can expand if you really want to see each poll
<azonenberg> but would be hidden by default normally to avoid cluttering the analyzer view
<azonenberg> thoughts?
<noopwafel> as opposed to basically stacking another analyzer on top?
<noopwafel> I think UI-wise, without thinking, tree is nicer, but I don't know how fiddly it might get in practice
<azonenberg> Yeah
<azonenberg> i feel like with more complex protocols showing/hiding stuff might be helpful
<azonenberg> i dont have exact use cases other than this one
<azonenberg> also this giant flash capture i have is hitting floating point precision issues in rendering
<azonenberg> So i need to start thinking about fixing that...
<sorear> makes me think of the wireshark tree view
<_whitenotifier-f> [scopehal-apps] azonenberg opened issue #162: Floating point precision issues (?) in rendering of very deep waveforms - https://git.io/JU3rl
<_whitenotifier-f> [scopehal-apps] azonenberg labeled issue #162: Floating point precision issues (?) in rendering of very deep waveforms - https://git.io/JU3rl
<_whitenotifier-f> [scopehal-apps] azonenberg labeled issue #162: Floating point precision issues (?) in rendering of very deep waveforms - https://git.io/JU3rl
<azonenberg> Gotta love it being 1am, not tired at all, and needing to get up in ~3 hours
Nero_ has joined #scopehal
Nero_ is now known as NeroTHz
_whitelogger has joined #scopehal
promach3 has quit [Quit: killed]
promach3 has joined #scopehal
juli965 has quit [Quit: Nettalk6 - www.ntalk.de]
juli965 has joined #scopehal
DanRoh has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bvernoux has joined #scopehal
bvernoux has quit [Quit: Leaving]
DanRoh has joined #scopehal
bvernoux has joined #scopehal
bvernoux has quit [Quit: Leaving]
juli965 has quit [Quit: Nettalk6 - www.ntalk.de]
DanRoh has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
DanRoh has joined #scopehal
DanRoh has quit [Client Quit]
<miek> lol.. i guess that's a valid way to get some delay https://i.imgur.com/T2ejx1b.jpg
<monochroma> wow that's a messy delay loop