<azonenberg>
I don't think there was supposed to be an icon at all
<azonenberg>
The demo scope does a lot of slow CPU side random number geenration and stuff to create the sample waveforms, it's not at all optimized
<azonenberg>
25ish FPS does not sound unreasonable at all
<azonenberg>
also glscopeclient is slow compared to ngscopeclient
<azonenberg>
in general, we're going to be deprecating glscopeclient in favor of ngscopeclient in the indefinite near-ish future
<azonenberg>
as soon as ngscopeclient catches up in terms of missing features; most notably missing are multi-scope sync and session state load/save
<azonenberg>
But there's essentially no new development happening on glscopeclient, just fixing breakage caused by refactoring
<azonenberg>
in general the recommendation is to use ngscopeclient for new work as long as the missing features are not a problem for you
<azonenberg>
and to use glscopeclient if you need to a) save waveform data and filter graph state to a file for analysis later on, b) synchronize multiple scopes, or c) use spectrogram or waterfall display filters, as those shaders aren't ported to ngscopeclient yet
<azonenberg>
or d) export waveform data or protocol decode output to a csv or other file for interop with other tooling or something
<azonenberg>
those are i think the four major missing features right now
<d1b2>
<edgetriggered> % ./ngscopeclient free(): invalid pointer zsh: IOT instruction (core dumped) ./ngscopeclient % ./ngscopeclient ngscopeclient: /usr/include/vulkan/vulkan.hpp:1301: size_t vk::DispatchLoaderBase::getVkHeaderVersion() const: Assertion `m_valid' failed. zsh: IOT instruction (core dumped) ./ngscopeclient Thanks for the detailed rundown. I was able to run ngscopeclient earlier but now the same binary is failing. I'll try building with ASan
<d1b2>
and try to hunt down what's going wrong when I have a moment. It looks like the set_logo_default() call used in OscilloscopeWindow.cpp has the following explanation: "The logo is set to the default window icon set with Gtk::Window::set_default_icon() or Gtk::Window::set_default_icon_list()." Maybe that wasn't set and a broken icon image shows up instead? Very minor detail.
<azonenberg>
yeah probably. We're transitioning away from GTK for ngscopeclient, which is pure vulkan with imgui
<azonenberg>
GTK has lots of annoying dependency issues on Windows and is also much slower framerates due to how it manages 3D contexts
<azonenberg>
wrt ngscopeclient crashing, interesting that sounds like more driver or possibly SD ksetup issues
<azonenberg>
SDK setup*
<azonenberg>
i.e. compiling against headers from one version and linking against libs from another, or some headers inconsistent with others
<azonenberg>
Anyway, so still more refactoring needed in a few spots but I think i'm going to start work on a driver for my siglent load shortly
<azonenberg>
one more device class to start adding support for
<d1b2>
<edgetriggered> It is a whole lot faster! If I try to run it several times it does eventually start.
<azonenberg>
Yeah its also just a much nicer UI
<azonenberg>
e.g. supports multiple waveforms in a single plot
<azonenberg>
every dialog is non-modal and dockable
<azonenberg>
glscopeclient has a nasty habit of spawning the "new filter" settings dialog under something else so you cant see it and the UI is blocked for no obvious reason until you drag the other window away
<d1b2>
<hanetzer> oh hey, I saw you on some website that conglomerates (what's the word here?) nerd news stories. Someone was complaining that something you did was in c++
<azonenberg>
lol. i mean, all of libscopehal and gl/ngscopeclient is C++
<azonenberg>
there's not really a better language for doing this sort of work IMO
<azonenberg>
performance critical, lots of marshaling of raw structs across CPU-GPU boundaries
<azonenberg>
like, it's *possible* to do in something like rust but you'd be spending more time fighting the language and less actually getting work done
<azonenberg>
(I continue to hold out hope that one day a language as expressive as C++, but with improved safety guarantees that do not come at a significant performance cost, will one day be created. Rust is not that language)
<d1b2>
<hanetzer> I misread as 'marshmallow structs' and I was like tf is that?
<azonenberg>
lol
Degi_ has joined #scopehal
<d1b2>
<hanetzer> also I think I may know you from somewhere else on irc but I'm bad at names
Degi has quit [Ping timeout: 268 seconds]
Degi_ is now known as Degi
<azonenberg>
i've lived in many channels including libera, but always as this name except "fpgageek" on RPISEC
<d1b2>
<hanetzer> yeh its this name that's familiar.
<azonenberg>
twitter?
<azonenberg>
(moved to mastodon but i've used this name on both)
<d1b2>
<hanetzer> nah, its irc. I don't remember twitter people unless I know them elsewhere lmao
bvernoux has joined #scopehal
bvernoux has quit [Quit: Leaving]
bvernoux has joined #scopehal
<mxshift>
azonenberg: having been using Rust daily as part of OS development, it's perfectly capable of everything scopehal/ngscopeclient needs. Fighting with the compiler is the same learning curve involved with learning a new language.
<d1b2>
<edgetriggered> Can confirm, my experience with C++ has entirely been fighting the language and less actually getting work done. :o)
<d1b2>
<edgetriggered> Here's ASan's report: % ./ngscopeclient AddressSanitizer:DEADLYSIGNAL ================================================================= ==14777==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x555683f78849 bp 0x7ffc68532cf0 sp 0x7ffc68532ce0 T0) ==14777==The signal is caused by a READ memory access. ==14777==Hint: address points to the zero page. #0 0x555683f78849 in YAML::Node::Node(YAML::Node const&)
<d1b2>
/usr/include/yaml-cpp/node/impl.h:45 #1 0x555684057618 in PreferenceManager::LoadPreferences() /home/chris/src/antikernel/scopehal-apps.git/src/ngscopeclient/PreferenceManager.cpp:163 #2 0x5556840bd123 in PreferenceManager::PreferenceManager() /home/chris/src/antikernel/scopehal-apps.git/src/ngscopeclient/PreferenceManager.h:52 #3 0x5556840b0e1e in Session::Session(MainWindow*)
<d1b2>
/home/chris/src/antikernel/scopehal-apps.git/src/ngscopeclient/Session.cpp:70 #4 0x555683f5ab3e in MainWindow::MainWindow(std::shared_ptr<QueueHandle>) /home/chris/src/antikernel/scopehal-apps.git/src/ngscopeclient/MainWindow.cpp:86 #5 0x5556841be847 in std::__detail::_MakeUniq<MainWindow>::__single_object std::make_unique<MainWindow, std::shared_ptr<QueueHandle>&>(std::shared_ptr<QueueHandle>&) /usr/include/c++/12.2.1/bits/unique_ptr.h:1065
<d1b2>
#6 0x5556841bc66f in main /home/chris/src/antikernel/scopehal-apps.git/src/ngscopeclient/main.cpp:112 #7 0x7f1f5195478f (/usr/lib/libc.so.6+0x2378f) #8 0x7f1f51954849 in __libc_start_main (/usr/lib/libc.so.6+0x23849) #9 0x555683157884 in _start (/home/chris/src/antikernel/scopehal-apps.git/build/src/ngscopeclient/ngscopeclient+0x3b7884) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV
<d1b2>
/usr/include/yaml-cpp/node/impl.h:45 in YAML::Node::Node(YAML::Node const&) ==14777==ABORTING
<d1b2>
<edgetriggered> And after deleting ~/.config/ngscopeclient/ (attached)
<azonenberg>
mxshift: i was talking more like the lack of multiple inheritance support and such
<azonenberg>
scopehal's object model makes very heavy use of virtual inheritance, classes that derive from multiple bases which both have nontrivial member functinos, etc
<azonenberg>
rust would require a completely different object model
<azonenberg>
Carbon is closer but still not what i want
<azonenberg>
mxshift: basically, i'm sure one could write a scopehal-equivalent project in rust
<azonenberg>
but i dont see a transition being remotely viable
florolf_ has joined #scopehal
mikolajw has quit [Ping timeout: 248 seconds]
florolf has quit [Ping timeout: 248 seconds]
mikolajw has joined #scopehal
<mxshift>
it's not particularly different. With Rust, a struct would implement multiple traits which is extremely common.
<azonenberg>
yes but traits are like interfaces in java right?
<azonenberg>
they define a set of methods and maybe variables
<azonenberg>
but they can't contain code?
<azonenberg>
meaning in the derived class you have to implement every function in each of those interfaces
<azonenberg>
in scopehal it's common to have default implementations of methods that suffice for a significant majority of drivers, then a few override them
<azonenberg>
Lack of proper multiple inheritance support is one of the biggest things I've seen in potential C++-alternative languages
<azonenberg>
it's one of the few complaints I had with Carbon as well
<d1b2>
<david.rysk> it looks like you can have default implementation in traits
<azonenberg>
Interesting, worth looking into. But switching languages is still not happening any time soon considering we don't even have enough devs to support our basic functionality
<d1b2>
<david.rysk> Rust... seems to eschew the idea of classes and traditional inheritance entirely 😛
<d1b2>
<david.rysk> I need to get back to this
<azonenberg>
might be a nice goal for the 2030s :P
<azonenberg>
If i ever leave C++ it will probably be for Carbon
<azonenberg>
which seems to be the most viable memory safe C++ replacement
<azonenberg>
but it's not as mature as rust is yet
<d1b2>
<david.rysk> it doesn't seem like it will ever have something like the borrow checker
<azonenberg>
some folks would consider that a feature :p