<ALTracer>
azonenberg: I could not build git HEAD of scopehal-apps on Mint 21.3 (Ubuntu 22.04 LTS) with CMake/ninja and all recursive submodules. A strange link error.
<ALTracer>
/usr/bin/ld: lib/scopehal/libscopehal.so: undefined reference to `SCPITMCTransport::GetTransportName[abi:cxx11]()'
<ALTracer>
collect2: error: ld returned 1 exit status
<ALTracer>
ninja: build stopped: cannot make progress due to previous errors.
ALTracer has quit [Read error: Connection reset by peer]
ALTracer has joined #scopehal
<azonenberg>
hmmmm weird
<d1b2>
<david.rysk> ALTracer: clean build?
<d1b2>
<altracer> Absolutely. I ninjacleaned builddir and redone a MinSizeRel without PCH afterwards, it took 19m vs 17m, but resulted in the same link errors
<d1b2>
<david.rysk> and are you on the latest submodules?
<d1b2>
<altracer> yes, that's what I did eventually, with a sane depth
<ALTracer>
azonenberg: 4eaeef2e has tacked override qualifiers to most methods except that and constructor, why is that?
<azonenberg>
newer gcc warns about not having override qualifiers. on virtual methods (most driver methods are virtual). That's one of the few that isn't
<ALTracer>
I'm trying gcc-12 now (was gcc-11), each build takes ~20min on i5-4440 in tmpfs
<ALTracer>
when I looked at libscopehal.so with nm -C I saw the two demangled symbols undefined (and one weak)
<azonenberg>
that sounds really weird because those methods are in SCPITMCTransport.cpp and there's no ifdefs or anything around it
<azonenberg>
Are you seeing that file even being compiled?
<azonenberg>
It's only enabled on Linux since we don't have usbtmc on other OSes
<azonenberg>
i wonder if LINUX is not being defined in cmake for some reason?
<azonenberg>
(lib/scopehal/cmakelists.txt:204)
<azonenberg>
if so, that would likely cause a lot of breakage if you did get a binary
<azonenberg>
but why mint wouldnt be detected as linux is another question :p
<azonenberg>
that's the only explanation i can think of for that link issue though
<ALTracer>
how do I check for it? I am not on BSD or MacOS or Msys2 rn
<azonenberg>
just check the build log if SCPITMCTransport.cpp is being compiled, first
<ALTracer>
I think you don't want my /etc/os-release, it's PRETTY_NAME="Linux Mint 21.3", ID_LIKE="ubuntu debian", UBUNTU_CODENAME=jammy
<ALTracer>
Also I have a lesser bone to pick. 4 copies of 600 MiB PCH is a pain. -g forced in Release/MinSizeRel is a pain.
<azonenberg>
We eventually want release binaries to have external debug symbol files on linux
<azonenberg>
so the main app package is small but you can still download the separate symbol package to investigate a crash
<azonenberg>
i think there might be a ticket for that
<ALTracer>
-mtune=native is cheeky, I'll let it fly, but also I use -march=native equivalents on Gentoo globally, and you force people to build locally anyways, there are no packages which would use march=x86-64-v2
<azonenberg>
we may also add a "no debug release" target for people who just want smaller binaries and dont care about debugging
bvernoux has joined #scopehal
<azonenberg>
Optimizing for your local system makes sense, we explicitly do not -march=native because we want binaries to be able to run on older systems that e.g. lack avx512
<ALTracer>
This is a difference of ~200MiB and 6.6 GiB in tmpfs -- that might have been homedir harddrive
<azonenberg>
if you want to override that locally you can do that
<azonenberg>
but official builds need to not depend on more advanced ISA extensions for backward compat
<ALTracer>
My N6000 laptop never saw avx512, it's march=tremont
<azonenberg>
exactly my point
<azonenberg>
so we dont want binaries made on a xeon to not be able to run on your system
<ALTracer>
Yes, I draw the line between GH CI public binaries and dev builds
<ALTracer>
smells ARM toolchain 11
<azonenberg>
We do dynamic dispatch and call vectorized versions of specific functions at run time if the CPU supports them
<azonenberg>
Anyway, shrinking dev binaries is certainly something we can look into
<azonenberg>
and generally optimizing the build for speed and/or disk usage
<azonenberg>
So far i dont think any engineering has gone into that
<azonenberg>
I will say, with the v0.x series, having debug symbols in all binaries - even if it bloats them - is probably a good thing
<azonenberg>
since you are likely to be debugging crashes at a nontrivial frequency :p
<ALTracer>
I'm not even asking for ccache or -O1 atm, albeit I don't anticipate capturing raw PCIe or HDMI any time soon
<ALTracer>
-gz is my friend
<ALTracer>
do you leverage unwind on uncaught exception or ASan etc.?
<azonenberg>
We have a SANITIZE build option for asan, there has been talk of adding ubsan but i dont think that's happened yet. It's not on by default in standard builds
<azonenberg>
On my own machines I have three different build configurations - release, debug, debug with asan
<ALTracer>
that much I've seen
<azonenberg>
i use them all for different testing
<azonenberg>
i typically run release ~95% of the time, debug for investigating problems, debug asan for investigating segfaults specifically
<azonenberg>
(with -O0 it gets slooooow working with large waveforms so you really dont want to dogfood that daily)
<azonenberg>
(not sure about with your instruments but on my lecroy/pico gear 1M point memory is about a small as I go and often I'm working with significantly larger datasets)
<d1b2>
<david.rysk> ccache works if you turn off PCH
<ALTracer>
I'll remember to enable ccache later if I get to incr-build scopehal during any development ;)
<ALTracer>
yay it linked! no CPack? :(
<azonenberg>
Nope. There's been talk of doing that so that we can get distro native packages for CI builds, but official release packaging once we get to that point will be maintained separately (probably by distros)
<azonenberg>
in general packaging/installability is something we're starting to work on but it's not where it needs to be yet
<d1b2>
<david.rysk> ALTracer: I haven’t focused on install phase yet, but what are your recommendations re CPack?
<ALTracer>
just set minimal project and author name so it can generate something, I am not a dpkg-speaking maintainer. Dependencies can be dealt with later. I just didn't wanna pollute /usr/local with yet another suite.
<d1b2>
<david.rysk> Right know most of us run from source dir
<ALTracer>
so for me cpack -G DEB is a go-to way to make the package manager do its job
<azonenberg>
Yeah that was kinda my thought too. Make "something installable" ASAP then get something closer to release grade later
<ALTracer>
otherwise I did sudo make install; sudo ldconfig
<ALTracer>
might have been make install-strip
<azonenberg>
if it doesnt include all dependencies, whatever. its better than nothing
<ALTracer>
you kinda installed all the dev dependencies anyway. Dpkg utils had that nice tool of checking shlibdeps recursively
<azonenberg>
Well the thoguht is, we want github CI to eventually spit out nightly debs
<azonenberg>
that you can install over / instead of a distro package to get bleeding edge
<azonenberg>
those users may not be building from source
<azonenberg>
in fact, the target user installing a nightly *package* probably isnt a dev or they'd just build from source
<azonenberg>
so deps will eventually matter for them
<d1b2>
<david.rysk> There are still some bugs around finding file paths that I’m working on fixing
<d1b2>
<david.rysk> The filesystem handling code is some of the oldest and predates std::filesystem
<ALTracer>
Oh interesting. It kinda talks to hmo1002 over tcp/5025, but the scaling is funky and Imgui likes to lock up intermittently
<azonenberg>
We're working our way through hidpi issues
<azonenberg>
are you sure its imgui hanging and not something else? I havent had any crashes or hangs that were gui related
<azonenberg>
the gui hanging as a result of bugs elsewhere is a different story
<azonenberg>
And if the driver isn't well optimized to avoid blocking the GUI on API calls hangs and slow response can very much happen
<azonenberg>
Taking a quick glance at the R&S driver it looks like it's using the old (non-queued) command API which means every call that sends data to the instrument is going to block the gui thread
<ALTracer>
ch2 is mostly missing?
<ALTracer>
WHOA FRACTIONAL V-scale?!
<azonenberg>
(as opposed to the newer driver for the R&S RTO6 series which uses the new API)
<ALTracer>
No HiDPI, Cinnamon 1080p 100%
<ALTracer>
I can hook USB VCP or USB TMC of it instead
<azonenberg>
no the big issue is likely the command API. I can try doing a blind refactoring of it to use the new API at some point although it'll be hard for me to debug if i break anything doign it
<azonenberg>
i mean there may be other problems but that is at least an easy improvement to make
<azonenberg>
eventually we want to deprecate the old API but havent got around to refactoring all of the old drivers yet
<ALTracer>
mesa-intel warningv Haswell Vulkan support is incomplete
<azonenberg>
And yeah generally speaking the GUI should always run at full 60fps
<azonenberg>
and then waveforms will update at whatever rate they come in
<azonenberg>
as you pan and zoom the waveform view, it'll re-render the waveforms in a background thread, this may be slower than the gui refresh rate
<ALTracer>
well the main thread does not service UI events during rs acquisition
<azonenberg>
What's probably happening is some method it's calling during the render is blocking on a socket call. Which it shouldn
<azonenberg>
shouldn't
<azonenberg>
We go out of our way to avoid that in actively maintained drivers, the old-rs driver has somewhat bitrotted as i dont think anyone is actively using it
<azonenberg>
and nobody here has an older r&s scope to dev against so its just sat there :p
<azonenberg>
rendering wise once you get to the megapoint range you may notice slowdowns especially on older cards. On my RTX 2080 Ti for reference, the rendering shader runs at about 2.3 gigapoints of (visible on screen) sample data per second
<azonenberg>
so if you have a half-gigapoint waveform on screen fully zoomed out it's 4fps max
<azonenberg>
(of course, few if any scopes can give you waveforms that deep that fast, and if you zoom in a bit then it's comfortably fast)
<azonenberg>
But yeah i've gotta get back to $dayjob stuff but later today if i remember i'll try and convert the R&S driver to the queued command API which should at least be an improvement
<azonenberg>
the basic idea is, don't ever block the gui thread on a send command, instead push the command into a fifo and send it to the instrument when available
<azonenberg>
in a background thread
<ALTracer>
usbtmc: sigrok ID's, ngscopeclient gets three Bad IDN responses, gives up and eventually std::terminates
<ALTracer>
you have 9 threads?
<azonenberg>
We run a lot of threads, i think the filter graph by default has a pool of 8
<azonenberg>
then there's the gui thread, one for each scope
<azonenberg>
some stuff uses openmp which has its own thread pools
<azonenberg>
~90% of requests to the scope should come from the driver thread with a few from the gui thread
<azonenberg>
Can you run with --debug --trace SCPITMCTransport and see what if anything we're getting back when it complains about the bad IDN?
<ALTracer>
I can gdb backtrace, but your logs are more interesting
<ALTracer>
it gets emptiness to *IDN?
<ALTracer>
also dmesg starts complaining -110 for usbtmc
<azonenberg>
Sounds like probably not scopehal's fault then lol
<azonenberg>
does sigrok still work in that state?
<azonenberg>
or is the scope firmware derping out?
<ALTracer>
sigrok complains bulk libusb timeout until I usbreset the port
<azonenberg>
Sounds like firmware then
<azonenberg>
the scope stopped talking to us
<azonenberg>
(this is not uncommon for whatever reason, we see it with a lot of lower end scopes)
<ALTracer>
in VCP mode I see a /dev/ttyACM0 (compared to /dev/usbtmc0) and sigrok sees it. What scopehal backend is it, uart?
<azonenberg>
Yeah
<azonenberg>
its gonna be slow but worth trying
<ALTracer>
talks somewhat and hangs on CHAN1:OFFS?
<ALTracer>
Pulseview can't capture over either ACM or TMC
<ALTracer>
I'mma head out for today, thanks for all
<azonenberg>
(this is about the point where i'd power cycle the scope a few times lol)
<ALTracer>
(I did)
<azonenberg>
also probably dumb question but is it on latest firmware from R&S?
<ALTracer>
No idea, I checked in prior years, R&S did not have updates for it
<ALTracer>
It has a bunch of options and decoders unlocked, I would like to update it only if I had key backups or a hameg keygen
<azonenberg>
Well, if we can figure out a specific command sequence we're sending thats making it hang or act funny we can look into workarounds
<azonenberg>
i know on some siglent scopes we have software rate limiting that sends commands at a max of like 20 Hz to work around buggy firmware
<azonenberg>
performance suffers, of course, but it beats hangs or dropping requests
<ALTracer>
it'd helped if there was a SCPI dialect manual/UG or something for Hamegs
<ALTracer>
It was eye-opening to me that you try to fetch 2 scoperam buffers per second over any SCPI link and render them
<ALTracer>
Do you have UART Receive Timeouts somewhere above read/write HAL?
<azonenberg>
2 buffers per second is nothing lol
<azonenberg>
we get 60 Hz updates on picoscopes and lecroys at shallower memory depths. and the only reason that's not higher is that we dont yet support polling faster than the video refresh rate (it wants to draw each waveform)
<azonenberg>
I dont think we have any timeouts implemented in the uart layer right now. we do for sockets
<azonenberg>
Improving error handling when an instrment goes unresponsive is on our longer term wishlist. in particular, we want to be able to seamlessly transition from online to offline mode if a scope loses contact (whether due to hanging or just you unplugging a cable)
<azonenberg>
and be able to continue analyzing data and processing stuff then reconnect later on
<azonenberg>
that's a long ways off but its the dream
<ALTracer>
we the two active devs? or you're also a multisystem?
<azonenberg>
Lol no i'm just me, despite the impression you might get not *everyone* on mastodon is plural :p
<azonenberg>
and yeah theres only a handful of reasonably active devs, sometimes other people come in and do a bunch but i'm really the main constant and balrog / david.rysk has been doing a lot of build/infra stuff lately
<ALTracer>
Teledyne lecroy and pico technology produce devices way above out paygrade and technology level requirements
<ALTracer>
having a devops friend is good (I am/was one, a bit dusty)
<ALTracer>
above our*
<ALTracer>
Rigols might be too simple, on the other hand
<ALTracer>
lol nice to meet singular you! asked because I often need to estimate manpower availability on opensource stuff
<ALTracer>
I don't use mastodon, but I mainly hang on the Discord side of 1b^2 bridge, so @ me
ALTracer has quit [Read error: Connection reset by peer]