<azonenberg>
So I'm looking at overhauling some of the startup stuff
<azonenberg>
What do you think of having glscopeclient start with an (empty) full application window, rather than the startup dialog, if run with no arguments?
<azonenberg>
Then have a file|connect or similar dialog to connect to an instrument
<azonenberg>
With a list of recently used instruments you can connect to
<xzcvczx>
that sounds like a much more reasonable workflow
<xzcvczx>
seeing as you can load waveforms and stuff
<azonenberg>
Yeah. the original plan had been to add file opening to the startup dialog but i think that makes less sense
<azonenberg>
especially since we need to keep that dialog around for connecting once you have a session active
<azonenberg>
so file|connect to instrument
<azonenberg>
file | recent instruments | submenu with list
<xzcvczx>
azonenberg: if you want to add waveforms from multiple files then file opening in startup dialog also makes little sense
<xzcvczx>
but yeah both of those sound good
<azonenberg>
Multiple files is still a WIP. there's no gui driven way to do that
<azonenberg>
we can import multiple CSVs with the same channel configuration on the command line
<azonenberg>
The trick being that if i enable multiselect in the file browser dialog it enables it for *all* file formats
<azonenberg>
and not all of the parsers currently support that
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 264 seconds]
Degi_ is now known as Degi
_whitenotifier-a has joined #scopehal
<_whitenotifier-a>
[scopehal] azonenberg labeled issue #491: Channel emulation: allow any S-parameter to be selected, rather than only S11 - https://git.io/JGgE5
<_whitenotifier-a>
[scopehal] azonenberg opened issue #491: Channel emulation: allow any S-parameter to be selected, rather than only S11 - https://git.io/JGgE5
<_whitenotifier-a>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±6] https://git.io/JGgu3
<_whitenotifier-a>
[scopehal-apps] azonenberg 10c2c40 - Connection dialog is no longer auto launched when glscopeclient starts with no arguments, but can be accessed from File | Connect menu. Fixes #119.
<_whitenotifier-a>
[scopehal-apps] azonenberg closed issue #119: Allow "connect to scope" dialog to be re-launched once a session is active - https://git.io/JfA1s
<_whitenotifier-a>
[scopehal-apps] azonenberg commented on issue #118: When starting glscopeclient with no arguments, allow a file to be opened for offline analysis instead of connecting directly to an instrument - https://git.io/JGguZ
<_whitenotifier-a>
[scopehal-apps] azonenberg closed issue #118: When starting glscopeclient with no arguments, allow a file to be opened for offline analysis instead of connecting directly to an instrument - https://git.io/JfA1Y
_whitelogger has joined #scopehal
<_whitenotifier-a>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±4] https://git.io/JG2LW
<_whitenotifier-a>
[scopehal-apps] azonenberg closed issue #226: Add preferences, menu item, etc for "recent instruments" list - https://git.io/JTktj
<azonenberg>
Well that's a nice step up in usability
<azonenberg>
The Windows build is still broken thanks to the recent BSD fixes though
<azonenberg>
Hmmm
<azonenberg>
Thoughts on having a "disconnect" menu item?
<azonenberg>
basically, break the connection with the scope and switch to offline mode
<azonenberg>
possibly with a reconnect button to go back
<azonenberg>
so you can open a file for offline analysis then reconnect to it
<azonenberg>
Doing that right is going to require fixing the MockOscilloscope driver to store the original driver used for connection, though
<azonenberg>
because right now you can save a file while online, then reopen that file offline
<azonenberg>
but if you save the file while offline the driver becomes "mock" and you can no longer reconnect to the original scope
<azonenberg>
as you've lost the connection information
<_whitenotifier-a>
[scopehal] azonenberg opened issue #492: MockOscilloscope: store original connection information (if applicable) so we can reconnect in the future - https://git.io/JG2B8
<_whitenotifier-a>
[scopehal] azonenberg labeled issue #492: MockOscilloscope: store original connection information (if applicable) so we can reconnect in the future - https://git.io/JG2B8
<_whitenotifier-a>
[scopehal] rroohhh forked the repository - https://git.io/JGaCD
<_whitenotifier-a>
[scopehal] rroohhh opened pull request #493: Add additional search paths used on Guix - https://git.io/JGa4X
<vup>
azonenberg: Which c++ standard version is scopehal / scopehal-apps supposed to be compatible with?
bvernoux has joined #scopehal
<xzcvczx>
i have seen 11
<xzcvczx>
so it must be at least 11
<xzcvczx>
although i guess that wasn't in scopehal/scopehal-apps but an extra
<xzcvczx>
vup: there we go, scopehal-apps set(CMAKE_CXX_FLAGS "-g ${WARNINGS} --std=c++11 -mtune=native -ffast-math")
<xzcvczx>
azonenberg: worth converting to using CMAKE_CXX_STANDARD for this?
<vup>
Yeah I found that, but does that mean, all code should be 11 compatible, or just that up until now only 11 was needed and 14 or 17 would be acceptable aswell?
<xzcvczx>
any particular part of 14/17 you keen for?
<vup>
17 has structured bindings which are nice
<xzcvczx>
ah fair enough
<vup>
I mean 14 + 17 have a bunch of goodies, auto in lambda arguments, variable templates, auto as function return type, auto for non template arguments, `if constexpr`, class template argument, etc
<xzcvczx>
the only downside i could see to that tbh is stretch not supporting 17
<xzcvczx>
but stretch is about to even lose oldstable status
<_whitenotifier-a>
[scopehal-apps] rroohhh forked the repository - https://git.io/JGaCD
<vup>
I mean stretch has LTS support till 30.06.2022, thats a year out
<_whitenotifier-a>
[scopehal-apps] rroohhh opened pull request #371: Fix null pointer dereference in graph editor - https://git.io/JGaFQ
bvernoux has quit [Quit: Leaving]
<azonenberg>
vup: as of now we target c++ 11 because of lack of any reason to use 14/17
<azonenberg>
I think redhat based distros probably have the oldest gcc of all potential targets
<azonenberg>
Or debian oldstable
<azonenberg>
As a general rule, once all LTS distros still supported have a given feature I'm willing to use it
<_whitenotifier-a>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/JGV2t
<_whitenotifier-a>
[scopehal] rroohhh 2545c96 - Add additional search paths used on Guix Signed-off-by: Robin Ole Heinemann <robin.ole.heinemann@gmail.com>
<_whitenotifier-a>
[scopehal] azonenberg 4039259 - Merge pull request #493 from rroohhh/master Add additional search paths used on Guix
<_whitenotifier-a>
[scopehal] azonenberg closed pull request #493: Add additional search paths used on Guix - https://git.io/JGa4X
<_whitenotifier-a>
[scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/JGV2z
<_whitenotifier-a>
[scopehal-apps] azonenberg f48679e - Updated to latest scopehal
<_whitenotifier-a>
[scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/JGV2w
<_whitenotifier-a>
[scopehal-apps] rroohhh 7b59c98 - Fix null pointer dereference in graph editor When right clicking while dragging onto nothing, the selected node gets set to NULL, but the node rendering assumes the selected node to be valid during a drag. The drag is now just canceled on a right click. Signed-off-by: Robin Ole Heinemann <robin.ole.heinemann@gmail.com>
<_whitenotifier-a>
[scopehal-apps] azonenberg ecfc6a2 - Merge pull request #371 from rroohhh/right_click_drag Fix null pointer dereference in graph editor
<_whitenotifier-a>
[scopehal-apps] azonenberg opened issue #372: When connectivity to an instrument is lost, switch to offline mode - https://git.io/JGVwq
<_whitenotifier-a>
[scopehal-apps] azonenberg labeled issue #372: When connectivity to an instrument is lost, switch to offline mode - https://git.io/JGVwq
<vup>
azonenberg: ok, reasonable
<azonenberg>
So if stretch has 14, and older redhat based distros do too, i'm fine with switching to 14 if there's a good reason
<azonenberg>
Let's hold off on 17 until stretch goes out of support
<vup>
I am assuming you don't could rhel extended support? :)
<azonenberg>
xzcvczx: if there is a proper cmake way of specifying the standard I'm ok with switching to it. Same goes for any other compiler flags
<azonenberg>
vup: that might be a little too old lol
<vup>
s/could/count/
<azonenberg>
but current rhel should be included in the list of targets
<azonenberg>
I'd say anything supported by current rhel, fedora, debian LTS, and mingw/msys2 is fair game
<azonenberg>
arch and ubuntu are recent enough that anything those guys have, they have too
<vup>
so you don't care about rhel 7, even though it will get regular updates till 01.07.2024?
<azonenberg>
I think that's safe enough to skip. Most stuff that's THAT old is probably server platforms not desktops
<vup>
fair
<azonenberg>
The other thing is, with stuff like opengl or c++ versions
<azonenberg>
while we make a decision based on what's available now, we are not going to continue having our requirements keep pace
<azonenberg>
i.e. we're not likely to be requiring opengl 5.0 and c++ 23 in a few years
<vup>
so then debian stretch is what is currently the lowest denominator, which has gcc 6.3 giving up to c++14 support
<azonenberg>
The other thing re C++ versions specifically
<azonenberg>
is that these are *dev* platforms
<azonenberg>
i.e. we could plausibly compile on a recent system and have the binary run on something older
<azonenberg>
or install newer gcc on stretch
<azonenberg>
etc
<azonenberg>
So i think 14 is a reasonable minimum version at the moment
<azonenberg>
with 17 becoming available next year
<vup>
seems good. I am not trying to push for 17 or anything, was just wondering what the policy is, for me to keep in mind for potential future contributions
<azonenberg>
Yeah
<azonenberg>
In any case xzcvczx if you want to switch to the cmake way of referencing the c++ version that's fine
<_whitenotifier-a>
[scopehal-apps] azonenberg labeled issue #373: Allow importing a CSV or WAV file into an existing session if applicable - https://git.io/JGVXl
<_whitenotifier-a>
[scopehal-apps] azonenberg opened issue #373: Allow importing a CSV or WAV file into an existing session if applicable - https://git.io/JGVXl
<_whitenotifier-a>
[scopehal-apps] azonenberg labeled issue #373: Allow importing a CSV or WAV file into an existing session if applicable - https://git.io/JGVXl
<_whitenotifier-a>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/JGVHE
<_whitenotifier-a>
[scopehal] azonenberg 3420fb7 - Initial support for importing complex int16 I/Q data. See #487.
<_whitenotifier-a>
[scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±5] https://git.io/JGVHg
<_whitenotifier-a>
[scopehal-apps] azonenberg 271904b - Added initial complex I/Q import support. Only handles 16-bit signed format so far. Fixed some but not all bugs related to multi stream channels.