azonenberg changed the topic of #scopehal to: ngscopeclient, libscopehal, and libscopeprotocols development and testing | https://github.com/ngscopeclient/scopehal-apps | Logs: https://libera.irclog.whitequark.org/scopehal
sgstair_ has joined #scopehal
sgstair has quit [Ping timeout: 268 seconds]
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 256 seconds]
Degi_ is now known as Degi
<_whitenotifier-9> [scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±12] https://github.com/ngscopeclient/scopehal-apps/compare/be845c32f848...dd56443033e0
<_whitenotifier-9> [scopehal-apps] azonenberg c0b68e6 - Initial refactoring to use unified add methods for scope, SDR, spectrometer, VNA
<_whitenotifier-9> [scopehal-apps] azonenberg dd56443 - Fixed bug where scopes would spawn dialogs for other types of instrument supported by the driver even if not supported in this specific unit
bvernoux has joined #scopehal
<_whitenotifier-9> [scopehal] azonenberg pushed 2 commits to master [+2/-0/±15] https://github.com/ngscopeclient/scopehal/compare/fe1e6be9cf75...11ccee9ac1e0
<_whitenotifier-9> [scopehal] azonenberg 194047b - Refactoring: moved enable_shared_from_this to base Instrument class
<_whitenotifier-9> [scopehal] azonenberg 11ccee9 - AntikernelLabsTriggerCrossbar: initial implementation of CDR LA
<_whitenotifier-9> [scopehal-apps] azonenberg pushed 3 commits to master [+0/-0/±9] https://github.com/ngscopeclient/scopehal-apps/compare/dd56443033e0...62076c00ae86
<_whitenotifier-9> [scopehal-apps] azonenberg c6f45d8 - Refactored to use shared_from_this in base class
<_whitenotifier-9> [scopehal-apps] azonenberg 67c4a86 - Improvements to waveform area allocation: infrequently used streams on instruments are hidden by default, digital streams try to pack into a single shared group if possible
<_whitenotifier-9> [scopehal-apps] azonenberg 62076c0 - Fixed crash caused by assuming that the first channel in an oscilloscope was always a scope channel
<_whitenotifier-9> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://github.com/ngscopeclient/scopehal/compare/11ccee9ac1e0...dea51634b4b1
<_whitenotifier-9> [scopehal] azonenberg dea5163 - Fixed bug causing trigger to not re-arm correctly
bvernoux has quit [Quit: Leaving]
<_whitenotifier-9> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±2] https://github.com/ngscopeclient/scopehal/compare/dea51634b4b1...c9aa1956f4a7
<_whitenotifier-9> [scopehal] azonenberg c9aa195 - ThunderScope: Initial support for doing sample conversion on the GPU. Clip detection is still CPU based.
<_whitenotifier-9> [scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±2] https://github.com/ngscopeclient/scopehal-apps/compare/62076c00ae86...6c93f51dd6b6
<_whitenotifier-9> [scopehal-apps] azonenberg 1f37cbc - Updated submodules
<_whitenotifier-9> [scopehal-apps] azonenberg 6c93f51 - Updated submodules
<azonenberg> @johnsel which, the debug object naming?
<dingwat> azonenberg: "QueueManager creating family=0 index-13 name=WaveformThread.queue" was the last console message before Segmentation fault :(
<azonenberg> no debug object names don't have to be unique
<azonenberg> dingwat: can you run under a debugger and get me a stack trace?
<d1b2> <johnsel> poolname & bufname I meant
<d1b2> <johnsel> if they're just for debug I missed that
<dingwat> azonenberg: I can try. I'm running on UCRT64 on Windows btw
<azonenberg> yeah those are just for debug so the buffers show up with good names in nsignt or something
<azonenberg> nsight*
<d1b2> <johnsel> alright no worries then, same for queue name?
<azonenberg> Yeah any of those names are purely for debug
<azonenberg> side note, we found and reported a mesa bug related to that :p
<d1b2> <johnsel> Good to know
<azonenberg> naming one type of object, i think a VKSurfaceKHR, would crash on mesa
<azonenberg> so we just didn't name it if we detected you were using mesa
<azonenberg> but there is now an upstream fix iirc, i just dont remember in which mesa version
<d1b2> <johnsel> nice
<d1b2> <johnsel> btw, I saw something that I'm now jealous of for in ngscopeclient
<azonenberg> oh?
<d1b2> <johnsel> signed distance field rendering for the lines
<azonenberg> signed distance field?
<d1b2> <johnsel> it's in alpha in cyberether
<azonenberg> show me a screenshot or something
<azonenberg> i suspect it will be too slow for the volume of data we're trying to push, whatever it is
<dingwat> azonenberg: does this help? https://paste.mozilla.org/Chh2mz71/raw
<dingwat> i'm a noob with gdb
<azonenberg> dingwat: run "print font"
<azonenberg> is it null?
<dingwat> yep
<azonenberg> This is probably the result of your preferences file getting borked somehow to point to font files it can't find
<azonenberg> This is a known bug we havent found a root cause for, some time soonish i need to add fallback to known safe/default fonts if the pref-specified ones don't load
<azonenberg> You should be able to delete the prefs file and be good to go
<azonenberg> i think it should be under %appdata%/ngscopeclient or something like that
<azonenberg> preferences.yml
<azonenberg> (its ~/.config/ngscopeclient/ on linux which is my main dev platform)
<dingwat> yep, that did it, thanks