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
<_whitenotifier-4> [scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±2] https://github.com/ngscopeclient/scopehal-docs/compare/39ffb8ef2d90...c9d2156038b5
<_whitenotifier-4> [scopehal-docs] azonenberg c9d2156 - Fixed formatting of copy-pasteable code listings to be properly copy-pasteable on both PDF and HTML formats. Fixes #87.
<_whitenotifier-4> [scopehal-docs] azonenberg closed issue #87: Documentation: Ubuntu and Debian HTML pages have double line breaks so apt-get install x \ ... (next line) is treated as a new command, which fails - https://github.com/ngscopeclient/scopehal-docs/issues/87
<_whitenotifier-4> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://github.com/ngscopeclient/scopehal-apps/compare/b340258b76c3...caef0e077aa5
<_whitenotifier-4> [scopehal-apps] azonenberg caef0e0 - Updated to latest scopehal-docs
<azonenberg> aaand with that, we're down to a single digit number of tickets blocking the v0.1 release
<azonenberg> (plus cutting a final version of the docs talking about installing packages etc, and reformatting the website to have "latest" and v0.1 release docs, etc - but that will all come later)
<_whitenotifier-4> [scopehal-apps] azonenberg closed issue #748: Copy DLLs needed to run ngscopeclient.exe as part of the build process - https://github.com/ngscopeclient/scopehal-apps/issues/748
<_whitenotifier-4> [scopehal-apps] azonenberg commented on issue #748: Copy DLLs needed to run ngscopeclient.exe as part of the build process - https://github.com/ngscopeclient/scopehal-apps/issues/748#issuecomment-3060173594
Degi has quit [Ping timeout: 248 seconds]
Degi has joined #scopehal
<_whitenotifier-4> [scopehal-docs] lainy pushed 1 commit to master [+0/-0/±1] https://github.com/ngscopeclient/scopehal-docs/compare/c9d2156038b5...e3c3aefae149
<_whitenotifier-4> [scopehal-docs] lainy e3c3aef - Remove phantom glew dependency
<_whitenotifier-4> [scopehal-apps] lainy pushed 1 commit to master [+0/-0/±3] https://github.com/ngscopeclient/scopehal-apps/compare/caef0e077aa5...cade73b8708d
<_whitenotifier-4> [scopehal-apps] lainy cade73b - Remove phantom glew dependency
<_whitenotifier-4> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://github.com/ngscopeclient/scopehal/compare/9dd39728c0db...319b2ce04b0c
<_whitenotifier-4> [scopehal] azonenberg 319b2ce - ACRMS: Fixed bug where AC RMS measurement would sometimes truncate the last sample in the GPU implementation
<_whitenotifier-4> [scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±5] https://github.com/ngscopeclient/scopehal-apps/compare/cade73b8708d...f01b051154cf
<_whitenotifier-4> [scopehal-apps] azonenberg 3b5ae98 - Filter_ACRMS: make reference implementation properly avoid divide-by-zero, updated to latest scopehal with bug fixes for ACRMS
<_whitenotifier-4> [scopehal-apps] azonenberg f01b051 - Merge branch 'master' of github.com:ngscopeclient/scopehal-apps
<_whitenotifier-4> [scopehal-apps] lainy opened issue #860: linux-gpib shared library is incompatible - https://github.com/ngscopeclient/scopehal-apps/issues/860
<_whitenotifier-4> [scopehal-apps] lainy edited issue #860: linux-gpib shared library is incompatible - https://github.com/ngscopeclient/scopehal-apps/issues/860
<azonenberg> miek: so it looks like the GPIB driver we have now depends on linux-gpib which is GPLv2 only
<azonenberg> Thoughts on how to proceed? We can't ship a release that links to GPL code
<azonenberg> It's currently an optional build time component
<azonenberg> I suppose we can make it be off by default and then add a separate ENABLE_GPL cmake flag
<azonenberg> since the vast majority of users probably won't be using gpib hardware and those that are can always compile themselves
<azonenberg> but a long term solution is needed
<d1b2> <josHua> is there a reason you cannot ship a GPL-covered binary?
<d1b2> <josHua> (are there proprietary components that conflict?)
<d1b2> <azonenberg> Project policy, for the most part. We want to be compatible with third party proprietary plugins etc
<d1b2> <azonenberg> None currently exist but we want to allow it
<d1b2> <azonenberg> And that is not going to change
<d1b2> <azonenberg> The goal is to become an industry standard T&M API and that means being compatible with blobs
<d1b2> <josHua> hmm are plugins dynamically loaded? if so, you are good on GPL components (a user can certainly dynamically load a proprietary plugin into a GPL-covered app of their own)
<d1b2> <azonenberg> Plugins are dynamic, yes. But still, per project policy, we do not use GPL dependencies
<d1b2> <josHua> and if not, it does not matter, because you are not going to ship a binary that has both a proprietary blob and a GPL component yet
<d1b2> <azonenberg> Not sure how this slipped through the cracks
<d1b2> <josHua> it is a fair policy, though I guess my point is it may not need to be an emergency blocking 1.0
<d1b2> <azonenberg> We want to support use cases like a scope vendor shipping ngscopeclient plus a proprietary driver as an on device UI, etc
<d1b2> <josHua> right
<d1b2> <azonenberg> I would rather disable gpib support than ship a GPL release
<d1b2> <azonenberg> We can easily do that and ship v0.1 without gpib enabled
<d1b2> <azonenberg> then users can turn it on manually if they are ok with their local copy being GPL
<d1b2> <josHua> reasonable
<d1b2> <azonenberg> I suppose one possibility would be to refactor the gpib driver into a separate repo that builds as a plugin
<d1b2> <azonenberg> similar to how gstreamer splits up plugins by license compatibility etc
<d1b2> <josHua> which would also be good as an example of how to write a plugin in a separate repo
<d1b2> <azonenberg> I've thought about modularizing scopehal to have scope drivers move to a plugin library etc too and keep the core library simple
<d1b2> <azonenberg> So this is not implausible
<d1b2> <josHua> it would also be nice to reduce the link size when developing only on a scope driver
<d1b2> <azonenberg> Yeah I'm picturing an eventual structure where scopehal is just base classes and core math blocks a lot of other stuff uses like "get average value of waveform"
<d1b2> <azonenberg> then we have either one plugin for all drivers or even one per vendor or something
<d1b2> <azonenberg> and then perhaps filter graph blocks done similarly, idk
<d1b2> <azonenberg> anyway, i think that's the cleanest solution
<_whitenotifier-4> [scopehal-apps] lainy commented on issue #860: linux-gpib shared library is incompatible - https://github.com/ngscopeclient/scopehal-apps/issues/860#issuecomment-3060555893
<azonenberg> Made a scopehal-plugins-gpl repo skeleton and will work on migrating stuff over
<azonenberg> There's no proprietary linking exception, so basically if you are running a closed source fork of ngscopeclient or including blob plugins you can't also use that plugin technically
lain has quit [Ping timeout: 276 seconds]
<_whitenotifier-4> [scopehal-apps] Gherkin synchronize pull request #859: Added github workflows to build in fedora and debian using containers - https://github.com/ngscopeclient/scopehal-apps/pull/859
<_whitenotifier-4> [scopehal-apps] Gherkin synchronize pull request #859: Added github workflows to build in fedora and debian using containers - https://github.com/ngscopeclient/scopehal-apps/pull/859
<_whitenotifier-4> [scopehal-apps] Gherkin synchronize pull request #859: Added github workflows to build in fedora and debian using containers - https://github.com/ngscopeclient/scopehal-apps/pull/859
<_whitenotifier-4> [scopehal-apps] Gherkin synchronize pull request #859: Added github workflows to build in fedora and debian using containers - https://github.com/ngscopeclient/scopehal-apps/pull/859
<_whitenotifier-4> [scopehal-apps] Gherkin commented on issue #855: Set up Fedora and Debian container for GH actions runner - https://github.com/ngscopeclient/scopehal-apps/issues/855#issuecomment-3061922126
<_whitenotifier-4> [scopehal] lainy opened issue #982: linux-gpib shared library is incompatible - https://github.com/ngscopeclient/scopehal/issues/982
<_whitenotifier-4> [scopehal] azonenberg assigned issue #982: linux-gpib shared library is incompatible - https://github.com/ngscopeclient/scopehal/issues/982
<_whitenotifier-4> [scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±2] https://github.com/ngscopeclient/scopehal-docs/compare/e3c3aefae149...14f8855883ff
<_whitenotifier-4> [scopehal-docs] azonenberg 14f8855 - Removed references to linux-gpib from getting started section. Added note to scopehal-plugins-gpl under the transports section.
<_whitenotifier-4> [scopehal] azonenberg pushed 1 commit to master [+0/-2/±3] https://github.com/ngscopeclient/scopehal/compare/319b2ce04b0c...81f8bd8bf5d5
<_whitenotifier-4> [scopehal] azonenberg 81f8bd8 - Removed GPIB transport and refactored it out to a plugin. Fixes #982.
<_whitenotifier-4> [scopehal] azonenberg closed issue #982: linux-gpib shared library is incompatible - https://github.com/ngscopeclient/scopehal/issues/982
<_whitenotifier-4> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±3] https://github.com/ngscopeclient/scopehal-apps/compare/f01b051154cf...f7ef694ef6dd
<_whitenotifier-4> [scopehal-apps] azonenberg f7ef694 - Updated submodules with linux-gpib references removed