<_whitenotifier-4>
[scopehal-apps] Frederic Borry 4e9ad6e - Fist step to awg representation in StreamBrowserDialog: - Added FucntionGeneratorState to cache generator configuration - Added awg state update logic in instrument thread - Updated FunctionGeneratorDialog to track changes in awg state - First step to awg rendering
<_whitenotifier-4>
[scopehal-apps] ... and 28 more commits.
<d1b2>
<azonenberg> @fredzo_72653 will look in a bit. Can you PR the specan fixes? i have more i want to do in the stream browser but nothing un-merged as of now
<d1b2>
<azonenberg> so it's a good time to get everything synced
<d1b2>
<azonenberg> if we're both going to be working on that stuff it makes sense to merge as often as possible to minimize conflicts
<d1b2>
<fredzo_72653> Yep, working on it, I will need to cache center frequency and span values on Tek driver too if it's OK for you ?
<d1b2>
<azonenberg> yeah go for it
<d1b2>
<azonenberg> We need to redo a bunch of the tek stuff anyawy to enable things like i/q streaming from their ddc
<d1b2>
<azonenberg> but its not a priority and i dont have a tek scope to test on right now
<d1b2>
<josHua> wow that UI looks great
<d1b2>
<azonenberg> Yeah i'm really excited to get this stuff all done and merged for v0.1
<d1b2>
<azonenberg> i want to deprecate a lot of the existing popup properties dialogs for things like power supplies
<d1b2>
<azonenberg> i had wanted to redo them anyway and this is so much better
<d1b2>
<azonenberg> @fredzo_72653 one other thing that would be good to do soon, make filter nodes show up in the right color
<d1b2>
<azonenberg> i want to do a more extensive revamp of how we do filters later
<d1b2>
<azonenberg> but that's a good starting point
<d1b2>
<josHua> one properties thing to think about for UI is that atomic commit is probably important
<d1b2>
<azonenberg> So far we fundamentally have two kinds of properties
<d1b2>
<azonenberg> We have things that we consider "safe" like AWG frequency
<d1b2>
<azonenberg> which update as you hit enter while typing or shift focus to another widget
<d1b2>
<josHua> nod
<d1b2>
<azonenberg> and things we consider "risky" like PSU output voltage
<d1b2>
<azonenberg> which have an explicit apply button
<d1b2>
<josHua> right.
<d1b2>
<azonenberg> to prevent a fat-fingering from blowing your dut
<d1b2>
<azonenberg> the same delination, informally, is used at session load time
<d1b2>
<azonenberg> it's not strict 1:1
<d1b2>
<azonenberg> but when loading a session if i notice you have an input currently in 1M ohm with 10V/div and the session file wants to change it to 50 ohm with 200 mV/div
<d1b2>
<azonenberg> it's gonna pop up a warning dialog to make sure you really wanted to do that
<d1b2>
<azonenberg> and highlight what was changed
<d1b2>
<azonenberg> and give you the option to say "no no no wait that was the wrong setup"
<d1b2>
<azonenberg> There's a fine line between warning fatigue and making it too easy to fry people's expensive hardware
<d1b2>
<azonenberg> But this is something i want to be very deliberate and cautious about because bad code on our part or monentary carelessness on a user's part can cause thousands of dollars of damage in an instant
<d1b2>
<azonenberg> this is of course the nature of test equipmetn
<d1b2>
<azonenberg> but i want to avoid excessive footguns ๐
<d1b2>
<genialeprutser> Hello, new wanting-to-be developer here. I'n planning to test out the windows build steps found here: https://www.ngscopeclient.org/manual/GettingStarted.html Is it OK to post my findings here, or is there a better place for that?
<d1b2>
<genialeprutser> *I'm
<d1b2>
<azonenberg> Here is fine. Please do report any issues with Windows builds and tag @fredzo_72653 and @david.rysk if you have problems. As of now, the build should work fine if you are running out of the build directory however the system-wide install (creating an MSI package) still needs some work
<d1b2>
<azonenberg> Fixing that is one of our major TODO's before the v0.1 release later this year
<d1b2>
<fredzo_72653> Welcome @genialeprutser ! Yes the doc for Windows build should be up to date, but let me know if you run into troubles.
<d1b2>
<genialeprutser> Thank you @fredzo_72653 , I'll let you know.
<d1b2>
<azonenberg> On that note, the dev docs and pdf/html manuals on the website are a few months behind the github copies. i should sync those again soonish
<d1b2>
<azonenberg> yes, the docs on github are always the most up to date
<d1b2>
<azonenberg> we render and push to the website every so often
<d1b2>
<genialeprutser> Alright. I don't have a way to render tex on my system, so I have to do that manually for now.
<d1b2>
<azonenberg> Once we have an official release i'll probably rearrange some of the website so we have docs for the most recent release in one subdirectory and bleeding edge elsewhere
<d1b2>
<azonenberg> The web docs should be good enough to get you started. i dont think there's been major changes
<d1b2>
<azonenberg> i've been letting docs stagnate for a bit because code has been changing so fast i didnt want to update docs much until feature freeze
<d1b2>
<genialeprutser> alright, general users will read the html docs, so it makes sense to test that now.
<d1b2>
<azonenberg> yeah
<d1b2>
<azonenberg> if they're lagging materially behind the latest on git i want to know about that
<d1b2>
<azonenberg> but for now the plan is not to touch the web html renders until i've had time to do a more major update post feature freeze (scheduled for dec 1st)
<d1b2>
<azonenberg> all of december is going to be a documentation, bug fixing, and portability testing rampage
<d1b2>
<genialeprutser> @Fredzo @david.rysk At step 3. Install general dependencies I tried to copy and paste these lines: pacman -S mingw-w64-ucrt-x86_64-vulkan-headers mingw-w64-ucrt-x86_64-vulkan-loader mingw-w64-ucrt-x86_64-shaderc \ mingw-w64-ucrt-x86_64-glslang mingw-w64-ucrt-x86_64-spirv-tools This fails with this error message: cedric@DESKTOP-LRFL83R UCRT64 ~ $ pacman -S mingw-w64-ucrt-x86_64-vulkan-headers mingw-w64-ucrt-x86_64-vulkan-loader
<d1b2>
mingw-w64-ucrt-x86_64-shaderc \ mingw-w64-ucrt-x86_64-glslang mingw-w64-ucrt-x86_64-spirv-tools error: target not found: -bash: mingw-w64-ucrt-x86_64-glslang: command not found cedric@DESKTOP-LRFL83R UCRT64 ~
<d1b2>
<genialeprutser> @Fredzo @david.rysk It does succeed when I copy and paste the two lines separately, without the \ cedric@DESKTOP-LRFL83R UCRT64 ~ $ pacman -S mingw-w64-ucrt-x86_64-vulkan-headers mingw-w64-ucrt-x86_64-vulkan-loader mingw-w64-ucrt-x86_64-shaderc mingw-w64-ucrt-x86_64-glslang mingw-w64-ucrt-x86_64-spirv-tools resolving dependencies... looking for conflicting packages... Packages (5) mingw-w64-ucrt-x86_64-glslang-14.3.0-1
<d1b2>
<genialeprutser> Looks the same problem (the \ character), but that bug refers to a different command
<d1b2>
<azonenberg> so i dont think its the \ per se. the \ is intended to combine two lines into one command
<d1b2>
<azonenberg> and the rendered docs add an extra linebreak after it
<d1b2>
<azonenberg> which breaks the combining
<d1b2>
<azonenberg> that bug is likely present in all multi-line example commands in the documentation
<d1b2>
<genialeprutser> Probably. Add that notion to that bug report?
<d1b2>
<azonenberg> beyond just the one mentioned in the issue. if you comment on the github ticket and mention the windows build instructions are affected we'll make sure we fix it
<d1b2>
<david.rysk> Copy-paste from LaTeX generated text is a mess
<d1b2>
<david.rysk> Wasnโt the documentation getting ported to something else?
<d1b2>
<azonenberg> There was a dream of doing that at some point in the indefinite future
<d1b2>
<azonenberg> i think @hansemro was interested
<d1b2>
<azonenberg> to my knowledge, nobody is actively working on it
<d1b2>
<azonenberg> i want to get something usable for v0.1 and make a more extensive port be a v0.2 issue
<d1b2>
<genialeprutser> As an aside, I'm pleased by how active and friendly you are on github, you gave me a very fast, friendly and helpful message why the low-end logic analysers are not supported yet: https://github.com/ngscopeclient/scopehal-apps/issues/796
<d1b2>
<azonenberg> @david.rysk in general given that we only have <2 months until release, i want to pick and choose our battles carefully to make sure we can ship something, and have it be usable, on time
<d1b2>
<azonenberg> and avoid letting perfect be the enemy of the good
<d1b2>
<azonenberg> So i'm focusing remaining efforts on things that will break the new user experience - can't compile, can't install, crashes, can't figure out how to use it
<d1b2>
<azonenberg> as well as major usability improvements like we've been doing to the stream browser, at least to the extent we can get it done before freeze end of month
<d1b2>
<david.rysk> I tried to fix the copy paste generation in the LaTeX but I can look at it again
<d1b2>
<david.rysk> (If itโs obviously not fixed yet)
<d1b2>
<azonenberg> It's possible it's already fixed in the tex and the website docs are simply that far out of date
<d1b2>
<azonenberg> if so, let me know and i'll do a new compile of the docs and push to the website
<d1b2>
<hansemro> https://github.com/ngscopeclient/scopehal-docs/pull/70 should insert a backslash when text overflows, so manual insertion of backslashes are not necessary. I will check again if something is wrong here
<d1b2>
<azonenberg> @hansemro OK. If the generated PDF/HTML on the website are just out of date compared to the tex then that's at least a quick fix to push a new version to the website
<d1b2>
<genialeprutser> @Fredzo @david.rysk the top of the instructions say this: On Windows, we make use of the MSYS2 development environment, which gives us access to the MingGW-w64 toolchain. Further down it says: All following steps are to be done in a UCRT64 shell. In the start menu I see the following flavors of msys2: UCRT64, MINGW64, CLANG64, MiNGW32 and CLANGARM64, so why not use UCRT64?
<d1b2>
<hansemro> Can confirm that html has additional whitespace character after backslash (which is not present in pdf)...
<d1b2>
<genialeprutser> @Fredzo @david.rysk cmake .. fails: CMake Error at CMakeLists.txt:109 (find_package): By not providing "Findyaml-cpp.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "yaml-cpp", but CMake did not find one.
<d1b2>
<genialeprutser> (I can't post the entire message, as that's more than 2000 chars.)
<d1b2>
<genialeprutser> I found the answer, https://www.msys2.org/docs/environments/ "MSVCRT (Microsoft Visual C++ Runtime) is available by default on all Microsoft Windows versions, but due to backwards compatibility issues is stuck in the past, not C99 compatible and is missing some features." and "UCRT (Universal C Runtime) is a newer version which is also used by Microsoft Visual Studio by default. It should work and behave as if the code was compiled with
<d1b2>
MSVC."
sgstair has quit [Remote host closed the connection]
sgstair has joined #scopehal
<d1b2>
<fredzo_72653> Yes please! I meant we're in 2024 aren't we ? ๐
<d1b2>
<fredzo_72653> Yes you need to use ucrt64
<d1b2>
<fredzo_72653> Can you try ?: pacman -S mingw-w64-ucrt-x86_64-yaml-cpp
<d1b2>
<genialeprutser> I get a different error now: cedric@DESKTOP-LRFL83R UCRT64 ~/scopehal-apps/build $ cmake .. CMake Warning (dev) at CMakeLists.txt:3 (enable_language): project() should be called prior to this enable_language() call. This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) at C:/msys64/ucrt64/share/cmake/Modules/Platform/Windows-GNU.cmake:193 (enable_language): project() should be called prior to
<d1b2>
this enable_language() call. Call Stack (most recent call first): C:/msys64/ucrt64/share/cmake/Modules/Platform/Windows-GNU-CXX.cmake:2 (__windows_compiler_gnu) C:/msys64/ucrt64/share/cmake/Modules/CMakeCXXInformation.cmake:48 (include) CMakeLists.txt:3 (enable_language) This warning is for project developers. Use -Wno-dev to suppress it. CMake Error at CMakeLists.txt:132 (message): Unable to find any version of sigc++; this is required to
<d1b2>
<azonenberg> sounds like missing dependencies in both cases?
<d1b2>
<genialeprutser> I've removed & recreated the build directory, it gives about the same error:
<d1b2>
<genialeprutser> cedric@DESKTOP-LRFL83R UCRT64 ~/scopehal-apps/build $ cmake .. -- Building for: Ninja CMake Warning (dev) at CMakeLists.txt:3 (enable_language): project() should be called prior to this enable_language() call. This warning is for project developers. Use -Wno-dev to suppress it. -- The CXX compiler identification is GNU 14.1.0 CMake Warning (dev) at C:/msys64/ucrt64/share/cmake/Modules/Platform/Windows-GNU.cmake:193
<d1b2>
(enable_language): project() should be called prior to this enable_language() call. Call Stack (most recent call first): C:/msys64/ucrt64/share/cmake/Modules/Platform/Windows-GNU-CXX.cmake:2 (__windows_compiler_gnu) C:/msys64/ucrt64/share/cmake/Modules/CMakeCXXInformation.cmake:48 (include) CMakeLists.txt:3 (enable_language) This warning is for project developers. Use -Wno-dev to suppress it. -- Detecting CXX compiler ABI info -- Detecting CXX
<d1b2>
compiler ABI info - done -- Check for working CXX compiler: C:/msys64/ucrt64/bin/c++.exe - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- The C compiler identification is GNU 14.1.0 -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: C:/msys64/ucrt64/bin/cc.exe - skipped -- Detecting C compile features -- Detecting C compile features - done -- Found Git:
<d1b2>
C:/msys64/usr/bin/git.exe (found version "2.45.2") -- Found PkgConfig: C:/msys64/ucrt64/bin/pkg-config.exe (found version "2.2.0") CMake Error at CMakeLists.txt:132 (message): Unable to find any version of sigc++; this is required to build ngscopeclient. -- Configuring incomplete, errors occurred!
<d1b2>
<fredzo_72653> @azonenberg this one is for cashing frequency parameters on Tek driver: https://github.com/ngscopeclient/scopehal/pull/933 not tested as I unfortunately don't own a Tek scope.. ๐
<d1b2>
<fredzo_72653> @genialeprutser my guess is that you failed to install some dependencies due to the \ not splitting lines correctly Make sure you run all pacman commands on separated lines each time the doc as a \ in it
<d1b2>
<genialeprutser> There's one occurrence of a \ char in the build instructions. Here are the commands I've entered in msys2 (obtained by pressing up repeatedly and copy and pasting every singe one:) $ pacman -S mingw-w64-ucrt-x86_64-ffts $ cd ~ $ git clone --recursive https://github.com/ngscopeclient/scopehal-apps $ cd scopehal-apps $ mkdir build $ cd build $ cmake .. $ pacman -S mingw-w64-ucrt-x86_64-yaml-cpp $ cmake .. $ cd .. $ rm -rf build/ $ mkdir
<d1b2>
build $ cd build/ $ cmake ..
<d1b2>
<genialeprutser> So I'm convinced I've entered the commands from the build instructions correctly.
<d1b2>
$ cmake .. $ cd .. $ rm -rf build/ $ mkdir build $ cd build/ $ cmake ..
<d1b2>
<fredzo_72653> OK so your last error message was complaining about missing sigc++, cay ou run: pacman -S mingw-w64-ucrt-x86_64-libsigc++ and give us the result prompt ?
<d1b2>
[##############################################################] 100% cedric@DESKTOP-LRFL83R UCRT64 ~/scopehal-apps/build $ cmake .. CMake Warning (dev) at CMakeLists.txt:3 (enable_language): project() should be called prior to this enable_language() call. This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) at C:/msys64/ucrt64/share/cmake/Modules/Platform/Windows-GNU.cmake:193
<d1b2>
(enable_language): project() should be called prior to this enable_language() call. Call Stack (most recent call first): C:/msys64/ucrt64/share/cmake/Modules/Platform/Windows-GNU-CXX.cmake:2 (__windows_compiler_gnu) C:/msys64/ucrt64/share/cmake/Modules/CMakeCXXInformation.cmake:48 (include) CMakeLists.txt:3 (enable_language) This warning is for project developers. Use -Wno-dev to suppress it. CMake Error at CMakeLists.txt:141 (message):
<d1b2>
Unable to find any version of cairomm; this is required to build ngscopeclient. -- Configuring incomplete, errors occurred! cedric@DESKTOP-LRFL83R UCRT64 ~/scopehal-apps/build
<d1b2>
<fredzo_72653> OK so as you can see libsigc++ was not installed otherwise you would have had somthing like: warning: mingw-w64-ucrt-x86_64-libsigc++-2.12.1-1 is up to date -- reinstalling
<d1b2>
<fredzo_72653> No you have to go on with cairomm and all other missing dependencies
ALTracer has joined #scopehal
<d1b2>
<genialeprutser> Interesting. I'll re-test later, it's getting late here.
<d1b2>
<fredzo_72653> Where are you from ? Europe ?
<d1b2>
<fredzo_72653> @azonenberg I have something for Filter node color rendering in StreamBrowserDialog, do you want me to push over the specan fixes PR or I wait for you to merge it and create a new PR ?