<bvernoux>
@azonenberg, Do you plan to update glscopeclient/imgui stuff are they pretty old and there is tons of new commit (332) in latest imgui
bvernoux has quit [Quit: Leaving]
bvernoux has joined #scopehal
<azonenberg>
bvernoux: yes i plan to update. i've been updating carefully with testing because we already had the filter graph editor break with an imgui update
<azonenberg>
so its not something i do without verification
<azonenberg>
and i've been working 60-hour weeks lately (well ok 40 in the offiec and 20 of commuting, but just as bad)
<azonenberg>
so havent had much time
<bvernoux>
yes no problem
<bvernoux>
I will update the dependencies for glscopeclient if you want and add ngscopeclient
<bvernoux>
the previous CMakeLists.txt is using ldd which is not good to find all dependencies
<bvernoux>
It is mandatory to do the full 4 ports calibration without spending >4h per LibreCAL
<bvernoux>
Using my HP8753D VNA
<bvernoux>
miek, why you are interested by 1 unit ?7
<bvernoux>
I was searching a way to compress the cal files in a transparent way too to fit 4 ports cal in default 2MB SPI Flash see https://github.com/jankae/LibreCAL/issues/14
<bvernoux>
I have some bigger SPI flash but I will need to swap the flash on the 4 boards I have (I have already tested that with success on 1 board)
<miek>
i'm very interested to know how well the design works, i'd probably produce my own though as i'd want to measure it myself up to a higher frequency and definitely put some bigger flash on there
<azonenberg>
bvernoux: my plan is to not spend any more time on mingw
<azonenberg>
i intend to deprecate glscopeclient and gtk in the very near future
<azonenberg>
all dev work needs to focus on making that happen (i.e. getting all missing features in ngscopeclient)
<bvernoux>
azonenberg, yes anyway the dependencies will be required also for ngscopeclient as today there is no any installer
<bvernoux>
azonenberg, I have provided my mingw shell script to do it anyway
<azonenberg>
yes because today ngscopeclient is built with mingw
<azonenberg>
long term plan is to build it as a native win32 app under visual studio
<bvernoux>
you want to say as native win64 app ?
<bvernoux>
win32 app is obsolete and very limited
<azonenberg>
sorry yeah
<azonenberg>
i meant native windows OS rather than any compatibility layers
<bvernoux>
mingw32 build is native too
<azonenberg>
yeah but it's got posix glue all over it
<bvernoux>
not so much in fact
<azonenberg>
anyway point is the mingw build process is a giant pain and i want to move away from it
<bvernoux>
you maybe confuse it with cygwin which is really crappy and bloated
<azonenberg>
msys2 is a huge pain point for new users
<azonenberg>
we constantly get complaints about people having problems getting things to install or run on windows because of it
<azonenberg>
i want a fully native solution, end of story
<bvernoux>
In fact for developer yes
<bvernoux>
but for user's with a good portable apps with dependencies we will have exactly the same as with VS build
<bvernoux>
VS build add even more dependencies in fact even in MT
<d1b2>
<david.rysk> can't cmake produce VS projects and makefiles for cygwin equally well?
<bvernoux>
Today we do not product cygwin project
<d1b2>
<david.rysk> for mingw*
<bvernoux>
but Mingw64 build and Linux (and MacOS WIP)
<azonenberg>
yes the goal is to have cmake produce a vs project
<bvernoux>
product=>produce
<azonenberg>
and just build a native OS application
<bvernoux>
I can show you the mingw64 build
<bvernoux>
all is native
<azonenberg>
we bundle most of our core dependencies like imgui already, the vulkan sdk has an installer
<bvernoux>
the different posix stuff compatible with Linux are also native in fact
<azonenberg>
one of the biggest benefits of moving to imgui was the potential to get rid of mingw64
<bvernoux>
for vulkan that will simplify things for VS yes
<bvernoux>
mainly the lib provided in Vulkan are produced with VS 2017 IIRC
<bvernoux>
I'm not sure they have switched to VS2019 or more in latest official version
<bvernoux>
Unfortunately their support and reaction towards issue is dead slow
<bvernoux>
I have an issue create few years ago withou any update
<d1b2>
<david.rysk> VS2015/2017/2019/2022 all use the same standard libs
<bvernoux>
towards their VulkanSDK for Windows which miss lot of header/c files which are present in the VulkanSDK for Linux which is OK
<d1b2>
<david.rysk> (and that's annoying because it means certain newer C++ lib features are broken and can't be fixed as MS doesn't want to break ABI)
<azonenberg>
@david.rysk: any idea if we use any of those?
<d1b2>
<david.rysk> I doubt it
<azonenberg>
and i thought that was the whole point of winsxs
<d1b2>
<david.rysk> and there are workarounds
<d1b2>
<david.rysk> lol
<azonenberg>
that you can have arbitrarily many libc's etc installed
<azonenberg>
and they dont conflict
<azonenberg>
bvernoux: iirc they explicitly said that the packaging is different for windows and that module wasnt included or something?
<bvernoux>
azonenberg, it works today by rebuilding some part of VulkanSDK because anyway they have missed some header/lib even for VS for spirv ...
<bvernoux>
to be checked with their latest official SDK
<bvernoux>
1.3.250.0
<bvernoux>
Which is official and available for all platform
<bvernoux>
Win/Linux/MacOS
<bvernoux>
Which include potentially some interesting fix towards Vulkan Configurator (vkconfig) has been updated to improve quality and stability. ...
<bvernoux>
As it is really buggy (at least on Windows) with old VulkanSDK 1.3.224.1 we are using
<bvernoux>
Are you ready to check VulkanSDK 1.3.250.0 can be used with ngscopeclient ?
<bvernoux>
if they have not broken some things vs VulkanSDK 1.3.224.1 at least to build & use ngscopeclient
<azonenberg>
I'll play with it in a bit
<azonenberg>
version 239 at least is known good, thats what i am using for dev
<azonenberg>
but there are some in between versions that break