<Bird|otherbox>
azonenberg: on that IWYU thing -- do you want me to just remove the #includes that it finds as unused, or add in what it says to add as well? should I pastebin the output from IWYU here?
esden has quit [Read error: Connection reset by peer]
elms has quit [Read error: Connection reset by peer]
esden has joined #scopehal
elms has joined #scopehal
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #scopehal
Pretzel4Life has joined #scopehal
Pretzel4Ever has quit [Ping timeout: 240 seconds]
electronic_eel has quit [Ping timeout: 264 seconds]
electronic_eel has joined #scopehal
alexhw has quit [Ping timeout: 264 seconds]
alexhw has joined #scopehal
_whitelogger has joined #scopehal
azonenberg_work has quit [Ping timeout: 240 seconds]
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±4] https://git.io/JTS8y
<_whitenotifier-f>
[scopehal-apps] azonenberg 2e2ea44 - Timeline: correct handling of GDK_SCALE. See #255.
<_whitenotifier-f>
[scopehal-apps] azonenberg a739998 - WaveformArea: various fixes to display and input handling when high-DPI scaling is active. See #255.
<_whitenotifier-f>
[scopehal-apps] azonenberg commented on issue #255: With GDK_SCALE=2, trigger cannot be dragged - https://git.io/JTS8F
<azonenberg>
also yay, just got tracking from lecroy
<azonenberg>
lain, monochroma: the D400A-AT-PB2 is eta weds
<azonenberg>
That's the handheld 4 GHz active diff probe
<lain>
:D
<azonenberg>
the solder in one is still pending, they've put it aside so it wont sell to anyone else but i havent paid yet
<azonenberg>
that will probably be end of nov
<azonenberg>
i need to send them the WL-PBUS on a RMA and get them cal'd together first
<azonenberg>
and havent had a chance to print out the shipping label etc yet
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JTSEo
<_whitenotifier-f>
[scopehal-apps] azonenberg closed issue #159: Make cursor colors configurable in preferences - https://git.io/JJF4b
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #262: Make FFT peak label colors configurable in preferences - https://git.io/JTSgN
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #262: Make FFT peak label colors configurable in preferences - https://git.io/JTSgN
asy_ is now known as asy
asy is now known as asy_
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±4] https://git.io/JTSwE
<_whitenotifier-f>
[scopehal-apps] azonenberg 5850b12 - Removed test color preference, it's not needed now that we have real color settings to play with
<_whitenotifier-f>
[scopehal-apps] azonenberg closed issue #43: Add preference for changing protocol decoder field colors (Filter::m_standardColors) - https://git.io/JeHyu
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #263: Add preference for PacketDecoder field colors (m_backgroundColors) - https://git.io/JTSww
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #263: Add preference for PacketDecoder field colors (m_backgroundColors) - https://git.io/JTSww
<_whitenotifier-f>
[scopehal] azonenberg commented on issue #151: Add support for configuring channel bit depth on LeCroy HDO9000 series - https://git.io/JTS67
alexhw has quit [Remote host closed the connection]
alexhw has joined #scopehal
Katharina has joined #scopehal
<Katharina>
o/
<azonenberg>
o/ Katharina
<azonenberg>
Wie geht's?
<Katharina>
oh niiice, unexpected :P
<Katharina>
im well, hope youre too
<azonenberg>
I'm just swearing at these two can bus dongles from $work
<Katharina>
oh haha
<azonenberg>
i'm supposed to be fuzzing this [redacted] which has a can bus interface
<azonenberg>
We have three dongles at the lab. My boss couldnt find the one i asked for and sent me the other two
<azonenberg>
One of them is abandonware, the company that made it no longer exists
<azonenberg>
i cant find software to use it
<azonenberg>
the other is a super fancy Vector that you can't downlod the software for. I only have a service pack installer
<Katharina>
oufff
<Katharina>
that sucks
<azonenberg>
the actual software itself appears to come on a CD-ROM that nobody knows the whereabouts of
<azonenberg>
And my company laptop doesnt have a CD-ROM drive so even if they found it i'm still screwed :p
<azonenberg>
The good news is i tracked down the engineer who had the PCAN that i wanted - which actually has a driver in the mainline linux kernel
<Katharina>
haha
<azonenberg>
so it's being overnighted to me and i'll have it tomorrow :p
<Katharina>
im looking forward to spending some time implementing a decoder for my cockpit in glscope client
<azonenberg>
Well I'll probably be tweaking the current bits of decodes as soon as i get that thing
<azonenberg>
So if you are interested
<azonenberg>
one feature lecroy has with a lot of their decodes, that i would love to add to glscopeclient, is a "software dac"
<Katharina>
what does it do?
<azonenberg>
basically, you can take output of a protocol decode that describes an analog quantity
<azonenberg>
and graph it
<Katharina>
oh thats neat
<azonenberg>
so you can look at steering wheel position or something as an analog waveform
<azonenberg>
by parsing the can bus messages
<azonenberg>
the tricky bit would be figuring out how to make it generic enough that it can work with many different types of protocol data. We might have to tweak the object model for some existing decodes and/or write a dac filter for each bus that we support (can, i2c, etc)
<Katharina>
that would be pretty nice, i do have tons of analogue knobs in the cockpit, for things like instrument illumination brightness, position lights, helmet mounted display brightness etc
<azonenberg>
so you can say "plot bytes 3-4 of message with can id 12345"
<azonenberg>
and maybe supply some scaling factors, specify the output unit, etc
<azonenberg>
but there's an open ticket for that and i feel like your system might not be a bad testbed
<Katharina>
:)
<azonenberg>
anyway, just a thought and certainly not the top priority
<azonenberg>
but if you think it will be helpful when the time comes it's something that i want to happen eventually
<Katharina>
Sure, id love to
<azonenberg>
The other thing that kinda ties into this is that i want the ability to do global 'trend' plots
<azonenberg>
that take data from individual waveforms or statistics/measurements
<azonenberg>
and plot over many triggers as a running history
<azonenberg>
right now all of my plots are attached to a single trigger event
<azonenberg>
Thinking about the object model for this might be a little tricky as right now waveforms are mostly assumed to be immutable, you can create new ones but once you set the current waveform it's not expected to change
<azonenberg>
But that might also tie into memory waveforms and some other stuff i want to add eventually
<Katharina>
:)
<Katharina>
BTW, im most likely going to do little bit of a breaking change today
<azonenberg>
oh?
<Katharina>
i think the way preferences are constructed right now is inadequate, and its going to get worse with enums. Essentially, we abuse the compilers overload resolution to decide which type of preference it is
<Katharina>
idk if you noticed, but this already required a const char* overload
<azonenberg>
Yeah
<Katharina>
for ergonomic enums, i want to offer a template overload, but then i have to use SFINAE and an enum detecting trait
<azonenberg>
well, at this time i've pushed all of the changes i've done for prefs
<azonenberg>
and i'm doing $dayjob stuff for the next few hours
<azonenberg>
So if you want to do some refactoring it's a great time
<Katharina>
yep id just adjust everything you made :)
<Katharina>
it wont be a big change, just explicitely naming the type
<azonenberg>
makes sense
<Katharina>
its more rigid that way
<azonenberg>
also while you're at it, pull the init function into a separate file like we discussed
<azonenberg>
since it's gonna get big fast
<Katharina>
will do, its a good time for it
<azonenberg>
also have a look at how i synced the color prefs
<azonenberg>
see if you think htat was a good way to do it or what
<azonenberg>
i didnt want to be doing a zillion string lookups in the protocol decodes
<azonenberg>
so i kept the array i had before
<Katharina>
i think its okay
<Katharina>
and the preferences API seems to be good enough for actual usage
<azonenberg>
Yeah
<azonenberg>
The next step will be, after you do whatever refactoring your consider appropriate
<azonenberg>
i want to add font preferences for various parts of the display
<azonenberg>
i have a bunch of font member vars in WaveformArea etc
<azonenberg>
i just need to tie them to prefs
<azonenberg>
and then the icon size on the toolbar is blocked on enum prefs
<Katharina>
im implementing enum prefs as we are speaking
<azonenberg>
Awesome
<Katharina>
i decided to use your way, with forward and backward mappings
<azonenberg>
You may want to use the Bijection class in scopehal
<azonenberg>
which makes this nice and convenient
<Katharina>
oh nice
<azonenberg>
As you can tell this is a problem i've had in the past :p
<Katharina>
this might be an odd question
<Katharina>
but how can i actually update the submodules in my branch?
<Katharina>
i never had that problem before, but it doesnt compile anymore because of a missing change in libscopehal
<Katharina>
nvm i got it, thats what i get for using SVN at work >_>
electronic_eel has quit [Ping timeout: 268 seconds]
electronic_eel has joined #scopehal
<_whitenotifier-f>
[scopehal-apps] Cushychicken opened issue #264: No .cmake file for Catch2 - https://git.io/JT9Yc
<_whitenotifier-f>
[scopehal-apps] nshcat commented on issue #264: No .cmake file for Catch2 - https://git.io/JT9Y0
<_whitenotifier-f>
[scopehal-apps] nshcat assigned issue #264: No .cmake file for Catch2 - https://git.io/JT9Yc
<_whitenotifier-f>
[scopehal-apps] nshcat labeled issue #264: No .cmake file for Catch2 - https://git.io/JT9Yc
<_whitenotifier-f>
[scopehal-apps] nshcat edited a comment on issue #264: No .cmake file for Catch2 - https://git.io/JT9Y0
<_whitenotifier-f>
[scopehal-apps] nshcat edited a comment on issue #264: No .cmake file for Catch2 - https://git.io/JT9Y0
<_whitenotifier-f>
[scopehal-apps] azonenberg commented on issue #264: No .cmake file for Catch2 - https://git.io/JT9OG
<azonenberg>
Katharina: My recommendation is to do "git config submodule.recurse true" in the scopehal checkout
<azonenberg>
if you pull from the scopehal checkout it will then automatically update changes from submodules
<_whitenotifier-f>
[scopehal-apps] Cushychicken commented on issue #264: No .cmake file for Catch2 - https://git.io/JT9Oa
<_whitenotifier-f>
[scopehal-apps] azonenberg commented on issue #264: No .cmake file for Catch2 - https://git.io/JT9OP
<Katharina>
azonenberg thx
<_whitenotifier-f>
[scopehal-apps] Cushychicken commented on issue #264: No .cmake file for Catch2 - https://git.io/JT9OF
<_whitenotifier-f>
[scopehal-apps] azonenberg commented on issue #264: No .cmake file for Catch2 - https://git.io/JT93k
<_whitenotifier-f>
[scopehal-apps] Cushychicken commented on issue #264: No .cmake file for Catch2 - https://git.io/JT932
<_whitenotifier-f>
[scopehal-apps] Cushychicken forked the repository - https://git.io/JT93V