<_whitenotifier-4>
[scopehal-apps] azonenberg 26c9fd3 - Updated to latest scopehal. Updated unit tests with noisy sine to handle new API. Loosened absolute accuracy tolerances for noisy sine, but tightened tolerance for CPU-GPU match
<_whitenotifier-4>
[scopehal-apps] azonenberg 86ad088 - Updated to latest scopehal with GPU accelerated TestWaveformSource
<azonenberg>
So I just implemented a GPU accelerated version of the waveform generation for the demo scope
<azonenberg>
it now runs at ~40 WFM/s at 1M point memory depth
<d1b2>
<azonenberg> is this still relevant? did it get fixed?
<tnt>
Anyone seen ` ERROR: Failed to open texture file "" ` ? Just did a fresh update of repo and all submodule, rebuild from scratch and install and ... that's what I get :/
<tnt>
Looking at strace, it tries to load stuff from /opt/scopehal/bin/share/ngscopeclient/icons/shapes/harris.png instead of /opt/scopehal/share/ngscopeclient/icons/shapes/harris.png
<tnt>
Had to hack InitializeSearchPaths ...
<d1b2>
<david.rysk> Yeah that’s a known issue…
<d1b2>
<david.rysk> Oh, maybe not that one. bin/share isn’t right
<tnt>
There is some code to remove the `bin` part but only for _WIN32 for some reason ...
RedMoss has joined #scopehal
<azonenberg>
tnt: yeah bin/share is wrong, send a PR or something?
<azonenberg>
also what platform are you even using to install to /opt/scopehal by default? or is that a custom path?
<tnt>
azonenberg: It's a custom path. I never install stuff to default path ... I keep all software installed manually in custom prefixes.
<azonenberg>
either way though, as long as you have a relatively standard structure under the prefix it should recognize it no matter what the prefix is
<azonenberg>
and if not, thats a bug
<azonenberg>
I think what you're running into is the expectation of installing to /usr/bin/ngscopeclient vs /usr/share/ngscopeclient maybe?
<azonenberg>
i.e. it wants prefix/type-of-dir/ngscopeclient
<tnt>
yeah, I just set `CMAKE_INSTALL_PREFIX` and it installed in the normal structure $prefix/bin/ngscopeclient and $prefix/share/ngscopeclient which is what I expect.
<azonenberg>
That should work
<azonenberg>
$prefix/ngscopeclient/bin and $prefix/ngscopeclient/share will not
<azonenberg>
there goes that idea
<azonenberg>
anyway if you can root cause and send a PR. go for it
<tnt>
yeah, trying to write one ... Annoyingly dirname(binRootDir.c_str()); doesn't work because dirname doesn't take a `const char*` but a `char *`
<d1b2>
<david.rysk> @azonenberg this has to do with that paths issue
<d1b2>
<david.rysk> (Which I think we have an issue for)
<azonenberg>
send me a ticket if it's a known issue?
<d1b2>
<david.rysk> Search paths handling really just needs to be overhauled
<azonenberg>
i mean yes
<d1b2>
<david.rysk> There is a ticket
<azonenberg>
ok
<azonenberg>
every time i think we're close to cutting v0.1 we find more crashes or something lol
<azonenberg>
tnt: that is a long term planned cleanup/refactoring, if you wanna do this as part of that great
<azonenberg>
but i think we had other tickets for specific problems?
<tnt>
I did a quick search when I git the issue but didn't really find anything ...
<azonenberg>
we may have closed the others as "we think they're fixed"
<d1b2>
<david.rysk> it was related to this one but I thought I fleshed it out more
<d1b2>
<david.rysk> The idea there being to consolidate how search paths are handled across platforms and to use std::filesystem to make the code cleaner
<_whitenotifier-4>
[scopehal] azonenberg 41a76f6 - Merge pull request #976 from smunaut/share-path-fix Fix InitializeSearchPaths to use the right '/share' location
<_whitenotifier-4>
[scopehal-apps] azonenberg 75b3707 - Updated to latest scopehal
<d1b2>
<david.rysk> why not change the type of g_searchPaths
<tnt>
It'd be nice if the action was on scopehal and run on every pull requests ... so you know beforehand. I can test it work on my machines, but I can't test on all the things locally.
<tnt>
david: I was trying to change as little as possible to exactly avoid breaking stuff ... and still failed at that :/
<d1b2>
<david.rysk> This was part of the reason for a refactor here, paths aren’t consistently path vs string and path can represent things that string can’t
<d1b2>
<david.rysk> I kinda wish it was a monorepo lol
<azonenberg>
Yeah the intent was to allow separate packaging long term
<azonenberg>
so you can install e.g. scopehal-dev and not scopehal-apps
<azonenberg>
and at this point with all the issues on two repos
<azonenberg>
merging would become a nightmare
<tnt>
But you could still have an action on scopehal that tries to build scopehal-apps ...
<azonenberg>
Yes, there's probably a way to do that
<azonenberg>
i think we might have a long term todo for it
<azonenberg>
but again, limited dev resources
<d1b2>
<david.rysk> Merging the code wouldn’t be too bad with git subrepo
<d1b2>
<david.rysk> Merging the other stuff… yeah
<azonenberg>
too busy putting out the fires we know about :p
<azonenberg>
its more than just that
<azonenberg>
for example, if you merge without commit history
<azonenberg>
you lose all that valuable data
<azonenberg>
if you merge with commit history github will take all the "fixes #123" messages
<d1b2>
<david.rysk> Subrepo is meant to extract or merge commit history
<azonenberg>
and close the matching tickets on scopehal-apps
<azonenberg>
this happened to us when we squashed -apps and scopehal-cmake
<d1b2>
<david.rysk> Yeah you’d have to do some rebasing for that, bleh
<azonenberg>
(yes we had 3 repos originally, with the build system separate, because at the time i was dual stacking on an in house build system)
<azonenberg>
and cmake was the "public fork" of it
<azonenberg>
but that was early enough in the project's history that there were a lot less incorrectly closed tickets to undo
<azonenberg>
The conclusion i came to last time we looked at it was that it would be a huge amount of work and probably not worth it
<azonenberg>
aaand that did not fix it... hmm
<tnt>
(xxx).string()
<azonenberg>
i'll try that
<azonenberg>
the question is why it didn't just call operator std::string()
<_whitenotifier-4>
[scopehal-apps] azonenberg d059b8e - Updated to latest scopehal
<tnt>
Pfff ... implicit conversion on windows is only to std::wstring
<azonenberg>
ok i think its fixed now with the explicit conversion and where we're now seeing CI problems is with the GPU accelerated AC RMS measurement returning an off-by-one result on ubuntu 22.04 CI
<azonenberg>
that i cannot reproduce on my debian
<azonenberg>
but that is a known-ish bug from a few days ago that is unrelated to your PR
<d1b2>
<david.rysk> Yeah this is why paths should stay paths 😛 … but that’s a bigger refactor
<azonenberg>
yeah i have a lot of large refactors planned for way down the pipie
<azonenberg>
the single biggest is probably switching filters to be shared_ptr's
<azonenberg>
that is going to be priority #1 after we cut v0.1
<azonenberg>
since that will enable a lot of other stuff
<azonenberg>
there may be some ancillary things happening before then also
<azonenberg>
like making IDTable type safe
<azonenberg>
or at least slightly less cursed
<d1b2>
<azonenberg> all of these are sweeping enough changes i dont want to make them before v0.1
<azonenberg>
But they need to happen for reliability and maintainability down the road
<_whitenotifier-4>
[scopehal] azonenberg 1868aa5 - FilterGraphExecutor: add exponential moving average to reduce noise in performance numbers. Keep old data around after partial graph updates so that we don't get flickering when we have multiple async data sources.
<_whitenotifier-4>
[scopehal-apps] azonenberg b0bf659 - Updated FilterGraphExecutor with exponential moving average and keeping stale data around after delta updates. Fixes #815.