<azonenberg>
woo 96 files changed, lol. ok this will take me some time to review
<azonenberg>
ehntoo: longer term it would be nice if we could use raw RGB values or something as color codes to avoid all the string parsing. but so far that's not a huge performance bottleneck
<azonenberg>
it's something to think about for the future
<azonenberg>
during the transition period strings are common ground both libs can work with
<azonenberg>
did you notice any impact on build times from not pulling all of the GTK stuff into scopehal?
<azonenberg>
ehntoo: you include dirent.h and unistd.h in scopehal, those files are unix-only
<azonenberg>
in scopehal.h*
<azonenberg>
should not be included on win32 as we use winapi functions there (remember the long term plan is to move away from mingw and have a native win32 build)
<d1b2>
<david.rysk> note that mingw is winapi
<d1b2>
<david.rysk> so something done with mingw should be mostly portable to native win32 (outside of the build system)
<azonenberg>
that's a "after we deprecate glscopeclient" refactoring
<azonenberg>
just fix the includes and i can merge #710
<azonenberg>
now looking at #531
<d1b2>
<ehntoo> I didn't notice any build time impact
<azonenberg>
ok yeah 531 is good to merge after that include fix too
<d1b2>
<ehntoo> re: includes, that was my understanding, but there was some non-*nix-only usage of things included by unistd/dirent that required it. Let me comment them back out and see what it was
<azonenberg>
we should not be using any posix apis on win32. if so, that's introducing a gnu/mingw dependency we shouldn't have
<azonenberg>
which will be a future blocker on a visual studio native build
<d1b2>
<ehntoo> ok. I'll take another pass and make sure we can get rid of them
<d1b2>
<ehntoo> does anyone here know offhand if something else provides ftruncate on windows?
<d1b2>
<david.rysk> stack overflow says "Use SetFilePoiner or SetFilePoinerExto set the current position to the size you want, then call SetEndOfFile."
<d1b2>
<ehntoo> oh, that usage is actually #ifdef'd for windows already. never mind
<d1b2>
<ehntoo> just need to update the includes
<d1b2>
<david.rysk> ah
<d1b2>
<ehntoo> looks like there's a couple other usages of unistd.h, fcntl.h, and dirent.h throughout the codebase. I'll open an issue to clean them up, and just take care of the new usages I added for now.
<azonenberg>
We use them in a bunch of spots but they should all be ifdef'd
<_whitenotifier-7>
[scopehal-apps] azonenberg 0eb8a98 - WaveformGroup: cursor table names are now color coded
bvernoux has joined #scopehal
<bvernoux>
Nice I see there is lot of refactor on scopehal ...
<azonenberg>
bvernoux: yeah ehntoo is working towards removing the GTK dependencies
<azonenberg>
enabling a future visual studio based build of ngscopeclient without needing to pull in gtk
<d1b2>
<ehntoo> pretty sure only cairo should be required for everything that goes into ngscopeclient now. unsure if that's workable under visual studio
<azonenberg>
We also use sigc++ for notifications when filter parameters change
<azonenberg>
but afaik that is not a big deal to use under vc++
<azonenberg>
(removing it would also be a fair bit of work)
<azonenberg>
the Cairo should also not be too bad. in particular, we don't actually use it for rendering per se
<d1b2>
<david.rysk> Hm let me dig deeper
<azonenberg>
in scopeprotocols
<azonenberg>
We draw the eye mask polygons which could be trivially replaced with a function that returns a list of points to be drawn via a GUI-side APIO of your choice
<azonenberg>
but there is a second internal function also using cairo which converts the eye mask polygons into an on/off bitmap for pass/fail testing
<d1b2>
<david.rysk> Yeah looks like Cairo should be doable
<azonenberg>
So we will have to replace that second function with something else
<azonenberg>
@david.rysk: it's a huge library we'd be using for like two functions
<azonenberg>
it's silly to keep it around when we've gone this far
<azonenberg>
even if it *can* build under vc++
<d1b2>
<ehntoo> I started playing with some CMake cleanups last night. Is there a minimum version of CMake we want to support? It looks like Debian stable ships 3.18 right now.
<d1b2>
<david.rysk> are we still supporting cmake 2?
<d1b2>
<ehntoo> I sure hope not.
<d1b2>
<ehntoo> Especially since we're using c++17
<miek>
the current minimum supported version in the project is 3.16
<miek>
i think that's probably still a good choice for now, that's what ubuntu 20.04 is shipping
<d1b2>
<ehntoo> seems like a good target to me.
<azonenberg>
Yeah. As a general guideline we should be aiming for the lowest version of all dependencies available on ubuntu, fedora, and debian stable/LTS
<azonenberg>
anything newer should only be used if the cost of significant inconvenience to users (and inability to use distro packaging) is justifiable