<d1b2>
<azonenberg> Yeah i'm really happy with how they're turning out
<d1b2>
<azonenberg> But I wasn't able to find anyone willing to donate time to draw these so I'm actually paying out of pocket to commission them
<d1b2>
<azonenberg> It hasn't been that expensive so far but if anyone wants to throw a few bucks in the hat to support the effort i wouldn't say no
Bird|otherbox has joined #scopehal
<d1b2>
<quantumdude836> Hello; I'm working on building for Windows and I ran into the apparently known issue of glslang not compiling; there was an issue in glslang (https://github.com/KhronosGroup/glslang/issues/3139) fixed a couple months ago, and the issue itself mentions a link to "Porting to GCC 13". What versions of gcc are being used for environments that build fine? My newly-installed MSYS2 env has gcc 13.2.0.
<d1b2>
<azonenberg> @bvernoux ^
<d1b2>
<hansemro> Was able to compile glslang (branch sdk-1.3.261.1) in MINGW64-MSYS2 environment with GCC 13.2.0
<d1b2>
<hansemro> Could you share more details on how you are building scopehal-apps on Windows?
Degi has quit [Ping timeout: 255 seconds]
Degi has joined #scopehal
juri_ has quit [Ping timeout: 260 seconds]
juri_ has joined #scopehal
<d1b2>
<quantumdude836> I just followed the "Getting Started" instructions in the online manual; for compiling glslang, I just added #include <cstdint> to glslang/Include/Common.h and it seemed to build fine
<d1b2>
<azonenberg> @quantumdude836 @hansemro the instructions in the windows section of the manual still point to the .224 vulkan SDK
<d1b2>
<azonenberg> which is quite old
<d1b2>
<azonenberg> Latest is .268
<d1b2>
<azonenberg> Can you try with a more recent release and let us know if that works OK without any changes? (and send a PR to scopehal-docs if that's the case)?
<d1b2>
<azonenberg> @tetrikitty this might sounds like the same problem you ran into
<d1b2>
<azonenberg> seems like it may have been fixed upstream and we never updated the build instructions to point to the new version
<d1b2>
<azonenberg> the github CI build is unaffected by this problem and it's using 1.3.250.1 so that should be a known-working version
<d1b2>
<azonenberg> (I can update the docs myself but dont want to change anything until i get a test report from someone who is actually able to build on Windows)
<d1b2>
<hansemro> 1.3.224 came before patches to support GCC 13, so I think it is worth updating docs to reflect that. I will try to build .224 and report back.
<d1b2>
<azonenberg> Yeah. So basically we've been telling people for months to build on an obsolete SDK and nobody noticed. oops lol
<d1b2>
<azonenberg> I expect 224 to give the same error, what's more important is that i get a test report of someone using a known-working version
<d1b2>
<azonenberg> so we can update the docs to point to a version that we know is stable
<d1b2>
<hansemro> Build does indeed fail with .224.
<d1b2>
<hansemro> Builds are slow atm since my laptop is the only machine with windows...
<d1b2>
<azonenberg> Welp. This is the kind of thing i wanted to fix before v0.1 official release lol
<d1b2>
<azonenberg> Find and fix new-user pain points
<d1b2>
<azonenberg> Directions telling you to install stuff that won't compile certainly counts :p
<d1b2>
<hansemro> Are there plans to move away from msys2 altogether? My memory of last meeting is a bit hazy.
<d1b2>
<azonenberg> Yes, we want to move to a vc++ based build flow. Unsure if that will happen before v0.1 or not
<d1b2>
<azonenberg> There's a bunch of dependencies we still have that are nicely packaged in msys2 (like Cairo)
<d1b2>
<azonenberg> that i want to retire
<d1b2>
<azonenberg> i also want to fully transition away from FFTS, which we still use in a small handful of places (i think some unit tests and the demo scope)
<d1b2>
<azonenberg> Long term plan is to use vkFFT for all fft functionality in the library and application, and FFTW as a golden reference for unit tests only
<d1b2>
<azonenberg> We talked about that last dev call but i havent had time to implement yet
<d1b2>
<azonenberg> On that note, do you think it's too late to schedule a dev call in December?
<d1b2>
<azonenberg> I'd like to have one soonish, wondering if it makes sense to try to squeeze it in the next 2ish weeks in anticipation that people will be taking time off work for the holidays and might have more time to code on stuff?
veegee has joined #scopehal
<d1b2>
<azonenberg> Also @hansemro any updates on your forays into better documentation platforms?
<d1b2>
<azonenberg> or are we going to continue with the current flow of latex as upstream source then synthesizing pdf + html docs from that?
<d1b2>
<hansemro> Okay, so I don't think it is too late, but yes, within the next 2 weeks is probably best.
<d1b2>
<azonenberg> How about Monday the 11th? That's currently wide open for me
<d1b2>
<azonenberg> at say 0900 Pacific / 1200 Eastern / 1800 CET
<d1b2>
<azonenberg> @david.rysk @johnsel does that work for you?
<d1b2>
<hansemro> Sorry, no time to explore doc platforms yet. Focusing more on missing content.
<d1b2>
<azonenberg> No worries. So you have been writing doc content?
_whitenotifier-b has quit [Ping timeout: 256 seconds]
<d1b2>
<hansemro> Drafted some for filters around Oct-Nov, but was not satisfied with I wrote, so yeah...
<d1b2>
<azonenberg> Anything is better than nothing at this point
<d1b2>
<azonenberg> unless it's wrong or completely unreadable
<d1b2>
<azonenberg> @hansemro for the UART filter i think the only thing i'd change is mention that the protocol output groups bytes into bursts, and that the cutoff for a new burst is hard coded to three byte times
<d1b2>
<azonenberg> i.e. if more than 30 baud times have elapsed since the last byte, a start bit starts a new packet
<_whitenotifier-e>
[scopehal-docs] azonenberg 2448fd5 - Merge pull request #74 from hansemro/cdruart filter:cdruart: update overview and add input/parameter/output description
<d1b2>
<azonenberg> cdruart looked fine as-is. we can polish later
<d1b2>
<azonenberg> it's better than nothing
<d1b2>
<azonenberg> (we will probably eventually want to make the inter-packet gap in the uart protocol view configurable but right now let's focus on documenting it as it is)
<d1b2>
<hansemro> Builds with Vulkan SDK 1.3.268.0 on Windows seem fine. Will post PR soon.
<d1b2>
<azonenberg> Excellent thanks
<d1b2>
<azonenberg> Can you also send a PR to the main scopehal-apps repo updating the github CI to use the same SDK rev?
<d1b2>
<azonenberg> if we're telling people to use that SDK we should have the CI verifying it as well
<d1b2>
<azonenberg> right now sdk is on 250 and docs are 224
<d1b2>
<hansemro> Should we bump for all platforms?
<d1b2>
<hansemro> Should be working fine for Linux
<d1b2>
<hansemro> not sure about macos
<d1b2>
<hansemro> but probably fine
<d1b2>
<azonenberg> I'm doing dev on 250 on Linux so that's a known stable version
<d1b2>
<hansemro> ok
<d1b2>
<azonenberg> We can bump once i upgrade my dev box (or someone else does)
<d1b2>
<azonenberg> i know there have been a handful of regressions in the SDK where they changed some api signature in a non-backward-compatible way
<d1b2>
<azonenberg> (especially in the c++ wrappers)
<d1b2>
<azonenberg> so i dont want to automatically assume newer sdk revs will work with code written against an older rev
<d1b2>
<azonenberg> the binaries will work on newer drivers but the wrappers may not compile the same
<_whitenotifier-e>
[scopehal-docs] hansemro 6d24b7a - ng-gettingstarted: bump Vulkan SDK to 1.3.268 for Windows This addresses a glslang build issue on 1.3.224 with GCC 13 (not specific to MINGW) due to missing cstdint include. Bump to a more recent (and tested) SDK in doc to resolve glslang build issue. Reference: https://github.com/KhronosGroup/glslang/issues/3139
<_whitenotifier-e>
[scopehal-docs] azonenberg a6c7b4d - Merge pull request #75 from hansemro/vk-sdk-1.3.268-windows ng-gettingstarted: bump Vulkan SDK to 1.3.268 for Windows
nelgau has quit [Read error: Connection reset by peer]
nelgau_ has joined #scopehal
nelgau_ has quit [Read error: Connection reset by peer]
nelgau has joined #scopehal
nelgau has quit [Ping timeout: 240 seconds]
nelgau has joined #scopehal
<d1b2>
<bvernoux> Documentation is wrong for windows it is validated with Vulkan 1.3.250.1 I have never tried that 1.3.268.0 anyway
<d1b2>
<quantumdude836> Just did a build this morning with 1.3.268.0 (uninstalled old SDK and installed new one; did a git pull + checkout for glslang), no issues building
<d1b2>
<quantumdude836> Sorry, I had only built glslang; trying to rebuild scopehal-apps seems to run into an issue with cmake having the old vulkan paths cached (I've verified the relevant env vars are updated). Looks like removing build/CMakeCache.txt got around that issue