<_whitenotifier-f>
[scopehal-apps] kench forked the repository - https://git.io/JTBRg
<_whitenotifier-f>
[scopehal] azonenberg opened issue #314: Eye pattern: allow clock to be specified as center or edge aligned - https://git.io/JT2Ua
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #314: Eye pattern: allow clock to be specified as center or edge aligned - https://git.io/JT2Ua
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JT2LZ
<_whitenotifier-f>
[scopehal] azonenberg 7f3563b - EyePattern: Now accept rising, falling, or double rate edges - but might not work right with non-sparse clocks. Fixes #220.
<_whitenotifier-f>
[scopehal] azonenberg closed issue #220: Eye pattern: allow clock to be specified as rising, falling, or both edges - https://git.io/JJ673
<azonenberg>
Meanwhile, i'm close to having eye patterns working on low speed serial data
<azonenberg>
i.e. stuff like spi and i2c rather than just high speed SERDES
<azonenberg>
Which can actually be useful given the atrocious wiring harnesses those protocols are sometimes run over :p
<Kenley>
Just as a heads up, you're still going to need libatkmm-1.6.1-dll libcairo-1.0-1.dll libgdkmm-3.0-1.dll libgiomm-2.4-1.dll to run the Windows binaries.
<Kenley>
I don't have them on my desktop.
<azonenberg>
yeah those are standard GTK binaries. We're a long ways from being ready to have official usable binary releases still i think
<azonenberg>
in terms of stability
<azonenberg>
so if the CI binaries aren't usable without some prep, that's fine
<Kenley>
I want to add a note about this. Do we use GitHub wikis?
Pretzel4Life has joined #scopehal
<azonenberg>
Kenley: Not yet, but somebody's gotta be the first
<azonenberg>
Right now the pdf manual is the only official documentation and we don't have official releases
<azonenberg>
in fact, CI builds of the pdf manual would be great to be able to link to from somewhere as an unofficial "latest manual"
Pretzel4Ever has quit [Ping timeout: 246 seconds]
<azonenberg>
the one on antikernel.net/temp is just my working draft
<azonenberg>
and not always the most up to date
<Kenley>
I only see a .tex file and no PDF.
<azonenberg>
Kenley: there's another cmake flag to build the docs
<Kenley>
I can upload the .tex as an artifact.
<azonenberg>
it's off by default since a lot of people don't have full texlive installed
<azonenberg>
-DBUILD_DOCS=ON
<Kenley>
Where does the PDF end up?
<azonenberg>
$build/doc/
<azonenberg>
glscopeclient-manual.pdf
electronic_eel has quit [Ping timeout: 260 seconds]
<azonenberg>
Kenley: mingw might not ship with asan by default
<azonenberg>
can you look up if it's a separate pacakge you need to set up?
<azonenberg>
hmm
<azonenberg>
some quick googling suggests that gcc does not provide asan on Windows, but clang might
<azonenberg>
for now, leave debug off on windows i guess
<azonenberg>
I expect the general maturity of the windows build to lag linux as it gets much less attention paid to it
<azonenberg>
as we get more windows users/devs we can improve
<azonenberg>
For the time being with our limited resources i want to avoid burning too much effort on windows stuff at the expense of linux
<_whitenotifier-f>
[scopehal-apps] kench opened pull request #246: Add support for uploading artifacts and enable Linux debug builds - https://git.io/JT2nW
<azonenberg>
Kenley: you're missing uploading of the styles/shaders etc on the linux builds
<azonenberg>
also you upload scopeprotocols twice on windows
<Kenley>
Whoops!
<_whitenotifier-f>
[scopehal-apps] kench synchronize pull request #246: Add support for uploading artifacts and enable Linux debug builds - https://git.io/JT2nW
<_whitenotifier-f>
[scopehal-apps] azonenberg 6bd55ca - Added --nospectrum argument to hide spectrum channels during initial startup
<_whitenotifier-f>
[scopehal-apps] ... and 3 more commits.
<_whitenotifier-f>
[scopehal-apps] azonenberg closed issue #237: cppcheck false positives due to LogFatal not being parsed as noreturn - https://git.io/JTn6O
<_whitenotifier-f>
[scopehal-apps] azonenberg closed issue #243: CI builds should set -DCMAKE_BUILD_TYPE=DEBUG - https://git.io/JTgXC
<_whitenotifier-f>
[scopehal-apps] azonenberg closed pull request #246: Add support for uploading artifacts and enable Linux debug builds - https://git.io/JT2nW
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 10 commits to master [+0/-0/±10] https://git.io/JT28Z
<_whitenotifier-f>
[scopehal-apps] ... and 7 more commits.
<azonenberg>
Kenley: Merged
<azonenberg>
Kenley: So what's your next move? I think we've gone about as far as we can on the CI side without significant fixes to the windows build in general. Which, while necessary, may not be the highest priority
<azonenberg>
Or did you have more stuff still planned?
<azonenberg>
Enabling static analysis in CI should be done eventually but Bird|otherbox has some debugging to do before that will be ready
<Kenley>
Ideas I had include initial *Getting Started* documentation for folks wanting to get their feet wet in wiki.
<azonenberg>
Setting up a unit test framework and figuring out how to integrate my current proof-of-concept test case into it is a relatively high priority todo if you want to keep playing build monkey
<azonenberg>
re documentation i think focus should be on the manual
hlzr has quit [Quit: Connection closed for inactivity]
<azonenberg>
If you want to work on that, by all means
<Kenley>
I'm OK with build monkey, but I don't feel that I have enough background knowledge of C++/C test frameworks to make a data-driven decision on a unit testing framework.
<azonenberg>
Once we have text written it will be fairly easy to copy paste that onto the wiki or a web page or something if we decide that is more accessible to new users
<azonenberg>
Creation of the content is the higher priority than the formatting at this stag eIMO
<Kenley>
I want to write the getting started content.
<azonenberg>
Do you think the content in the pdf manual is insufficient? or what
<azonenberg>
i thought it was pretty good, and the big thing we were lacking was half the features of the software were undocumented
<Kenley>
But I probably want to get .deb packaging working as a forcing function to get the code running on my Linux box, not the Pi.
<azonenberg>
#140, 141, and 142 are related to that
<azonenberg>
(on scopehal-apps)
<azonenberg>
CPack is probably the lowest effort way to get deb packages
<azonenberg>
basically, once "make install" works, using CPack to generate .deb's is 5 minutes of work
<azonenberg>
But we need to actually write the relevant stuff to install all of the build artifacts
<Kenley>
I feel like a tutorial with screenshots will help. Use glscopeclient to do X.
<azonenberg>
If you wanna do that, I can assign #142 to you?
<Kenley>
Sure.
<azonenberg>
right now it's assigned to bird but i dont think he's actively working on it
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<azonenberg>
Also, tutorials actually sound like really good subject matter for the wiki
<azonenberg>
Leaving the manual for "what does X do?" type stuff
<azonenberg>
honestly i expect the bulk of meat in the manual to be explaining all of the filters and protocol decodes
<azonenberg>
as well as the basics of how various UI elements work
<azonenberg>
There are a couple of demos on my youtube channel (many of several-years-old versions of the software so things have changed in appearance) but they are focused more on showing off cool features
<azonenberg>
So in that case i guess your plan is going to be doing #141/142 first, followed by writing some tutorials?
<Kenley>
Yep.
<azonenberg>
Great :)
<Kenley>
I don't believe cpack is the idiomatic way of Debian packaging, but I can do some more research.
<azonenberg>
It is not. in fact, debian will not accept packages submitted for upstream that were built with any third party packaging tool whatsoever, as a matter of policy
<azonenberg>
I suggested cpack because it will generate deb, rpm, and i think nullsoft? installers for windows with very little work
<azonenberg>
it's a lot better than nothing
<azonenberg>
we can then create distro specific packaging as time and demand dictates
<Kenley>
I remember this from my Concerto days.
<azonenberg>
On my end, my immediate focus at this point is going to be finishing a few more features like different trigger types on Tek MSO5/6 driver
<Kenley>
We distributed .debs that did not fit.
<azonenberg>
because i'm borrowing it over VPN from a generous donor and he can ask for it back at any time
<azonenberg>
so i want to make good use of it
<Kenley>
Makes sense.
<azonenberg>
once i'm done with that, i think unit testing will be the next focus
<azonenberg>
I'm very glad you and bird are doing what you're doing because build monkey and doc stuff is about my least favorite part of software engineering lol
<azonenberg>
it needs to be done but i hate doing it so i keep putting it off to work on fun stuff like 10GbE protocol decoding etc :p
<Kenley>
Builds and software quality are my strong points.
<azonenberg>
Awesome
<azonenberg>
One thing i would absolutely love for someone to do is write unit tests for as many filters as possible (filters being a sizeable fraction of the codebase and far easier to automatically test than hardware drivers or GUI code)
<azonenberg>
is that something you'd be interested in doing once we have the test framework set up?
<azonenberg>
they're mostly going to be fuzzer style, basically generate a random chunk of data that is mostly/entirely valid for that protocol, run the decoder, and make sure it doesn't segfault or generate incorrect output
<azonenberg>
For lower level stuff like SPI and "rise time" this will be fairly easy, although for more complex stuff like Ethernet a test case will basically involve either implementing the entire protocol or simply replaying a canned waveform, neither of which is ideal
<Kenley>
I can help with that.
<azonenberg>
Excellent. IMO tests for each filter should be written in tandem with the documentation for it in the manual
<azonenberg>
describe what the inputs and outputs are, how to configure it, then write a test case to ensure it really does that
<azonenberg>
For starters the focus should be on the low hanging fruit, doing the easy protocols like UART and SPI and basic measurements like rise time, frequency, etc. There's a lot of them and the test cases are low effort to build
<azonenberg>
It will help shake out problems in the general testing strategy and improve % coverage of both unit tests and documentation
<azonenberg>
then worry about the more complex things like ethernet, usb, etc decoding later on
<azonenberg>
also low level PHY type stuff is generally a dependency for higher level protocols, e.g. both 1000base-X, PCIe, and SATA all depend on 8b10b working correctly
<azonenberg>
So the probability of a user hitting a bug in a protocol goes up as you move down the stack because more stuff depends on it
<azonenberg>
anyway, that's blocked on me committing to a test framework. I'm tempted to go with CTest as i like the kitware stack and we're already using CMake but I haven't done the research yet
<azonenberg>
Just making sure we're in agreement on the roadmap
<Kenley>
Did you take OSSP at RPI?
<azonenberg>
No
<azonenberg>
But i did a lot of work with VTK and ITK on a URP in Prof. Roysam's lab in ECSE
<Kenley>
I got my first exposure of CMake from that class.
<azonenberg>
And i've been using CMake for my projects since like sophomore year when i migrated away from visual studio and installed ubuntu
<azonenberg>
incidentally that was also my first exposure to filter graphs as a concept
<_whitenotifier-f>
[scopehal] azonenberg ab61546 - Dropout trigger support for Tek MSO5/6
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #259: Eye pattern: allow phase offset in ps from reference clock to eye midpoint to be specified - https://git.io/JUuFK
<_whitenotifier-f>
[scopehal] azonenberg commented on issue #259: Eye pattern: allow phase offset in ps from reference clock to eye midpoint to be specified - https://git.io/JT21t
<_whitenotifier-f>
[scopehal] azonenberg closed issue #259: Eye pattern: allow phase offset in ps from reference clock to eye midpoint to be specified - https://git.io/JUuFK
<_whitenotifier-f>
[scopehal] azonenberg closed issue #279: Add optional mode to SCPITransport reads to terminate a read with either a semicolon, new line, or both - https://git.io/JUKxi
<_whitenotifier-f>
[scopehal] azonenberg commented on issue #279: Add optional mode to SCPITransport reads to terminate a read with either a semicolon, new line, or both - https://git.io/JT21W
<_whitenotifier-f>
[scopehal] azonenberg opened issue #316: Support for Tek MSO5/6 width-qualified runt trigger - https://git.io/JT2Me
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #316: Support for Tek MSO5/6 width-qualified runt trigger - https://git.io/JT2Me
<_whitenotifier-f>
[scopehal] azonenberg edited issue #316: Support for Tek MSO5/6 width-qualified runt trigger - https://git.io/JT2Me
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #247: CI runs should log success/failure status to IRC - https://git.io/JT2yv
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #247: CI runs should log success/failure status to IRC - https://git.io/JT2yv
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #248: Develop regression test suite for each scope family/driver - https://git.io/JT2yZ
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #248: Develop regression test suite for each scope family/driver - https://git.io/JT2yZ
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±6] https://git.io/JT2Q8
<_whitenotifier-f>
[scopehal] azonenberg closed issue #316: Support for Tek MSO5/6 width-qualified runt trigger - https://git.io/JT2Me
promach3 has quit [Quit: killed]
_whitelogger has joined #scopehal
promach3 has joined #scopehal
jevinskie[m] has joined #scopehal
bluecmd[m] has joined #scopehal
<Bird|otherbox>
azonenberg: btw, Catch2 supports integrating with CTest
<azonenberg>
oh cool
<azonenberg>
I'll look into that
<azonenberg>
Bird|otherbox: so what might make sense, then
<azonenberg>
is to use CTest directly for testing filters, as those are more complex setups that require more infrastructure than just calling a function or something
<azonenberg>
and use catch2 for lower level tests like FindZeroCrossings()
<azonenberg>
does that sound reasonable?
<azonenberg>
then have a single ctest invocation in the CI build to run all of the test cases
<_whitenotifier-f>
[scopehal-apps] azonenberg commented on issue #241: Unit testing - https://git.io/JTat4