<d1b2>
<david.rysk> Thanks, I guess I'll build it here
<d1b2>
<david.rysk> i may comment out the cairomm dependency to save time
<d1b2>
<david.rysk> ohh, you did it as bugs on their tracker, not PRs on their github? ok
<d1b2>
<darius0949> yeah
<d1b2>
<darius0949> I don't have a macports checkout handy
<d1b2>
<darius0949> I ran cmake as cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr/local -DCMAKE_PREFIX_PATH=/opt/local and ran the resulting binary with env OMP_WAIT_POLICY=PASSIVE DYLD_LIBRARY_PATH=/opt/local/lib ./src/ngscopeclient/ngscopeclient FWIW
<d1b2>
<david.rysk> I'm not sure I understand your patch to the shaderc CMakeLists
<d1b2>
<darius0949> without it the build process wants its own version of spirv-tools and glslang
<d1b2>
<david.rysk> Ah yeah I see
<d1b2>
<david.rysk> the Homebrew formula uses its own versions but disables installation of them
<d1b2>
<david.rysk> (I wish Homebrew on Intel didn't use /usr/local; they fixed that on ARM)
<d1b2>
<darius0949> hmm OK
<d1b2>
<david.rysk> I have macports set up with a custom prefix here for Rosetta
<d1b2>
<david.rysk> of course that means compiling everything from source
<d1b2>
<darius0949> what do you need to run under rosetta that can't be built for native arm?
<d1b2>
<david.rysk> ffts
<d1b2>
<darius0949> ahh
<d1b2>
<darius0949> just write an ARM code generator for it 😤
<d1b2>
<david.rysk> the plan is to phase it out
<d1b2>
<darius0949> OK
<d1b2>
<david.rysk> replace it with vkFFT in the lib and fftw in the tests
<d1b2>
<david.rysk> but I've had other priorities
<d1b2>
<darius0949> fair enough
<d1b2>
<darius0949> it is unfortunate FFTS is abandonware
<d1b2>
<david.rysk> we're already using vkFFT pretty heavily
<d1b2>
<david.rysk> there's just one function in the core that hasn't been rewritten
<d1b2>
<darius0949> ahh makes sense then
<d1b2>
<david.rysk> and then for the tests, the GPL dependency of fftw isn't a problem
<d1b2>
<darius0949> no GPU available for me 🙂
<d1b2>
<david.rysk> and we want a big, well-tested lib there
<d1b2>
<david.rysk> oh?
<d1b2>
<david.rysk> you're going to need Vulkan support (or Metal support) to be able to use ngscopeclient
<d1b2>
<david.rysk> it doesn't have to be a big fast GPU
<d1b2>
<darius0949> oh yeah I know, I am running it on a mac. Where I used PocketFFT was for a radar PC with no GPU
<d1b2>
<david.rysk> aaah ok
<d1b2>
<david.rysk> yeah fair enough
<d1b2>
<david.rysk> anyway if you want to take a look at the code feel free, otherwise I'm sure one of us will get around to it sooner or later
<d1b2>
<darius0949> oh I am on an intel mac so no problem for me 😉
<d1b2>
<david.rysk> doesn't it crash though?
<d1b2>
<darius0949> yes 😦
<d1b2>
<david.rysk> I was going to look into that
<d1b2>
<darius0949> ahh gotcha
<d1b2>
<david.rysk> but getting rid of it would be better
<d1b2>
<darius0949> yeah I will see if I can work it out
<d1b2>
<darius0949> maybe I can just hack pocketfft in there since I already know how that works..
<d1b2>
<darius0949> vkFFT looks like deep magic
<d1b2>
<azonenberg> Commenting out the calls to DegradeSerialData() in TestWaveformSource should fix any FFTS issues you have
<d1b2>
<azonenberg> it just means the demo waveforms will be a bit less realistic
<d1b2>
<azonenberg> I have plans to switch to a more realistic waveform generator in the future anyway, just too busy to do that right now
<d1b2>
<azonenberg> The only other remaining use of FFTS is in unit tests
<d1b2>
<azonenberg> as a golden reference implementation to compare vkFFT and our wrapper code around it to
<d1b2>
<darius0949> oh right
<d1b2>
<david.rysk> can we just use VulkanFFTPlan in DegradeSerialData()?
<d1b2>
<darius0949> that is pretty straightforward then
<d1b2>
<david.rysk> yeah that was the place where @azonenberg wanted to use fftw (the tests)
<d1b2>
<azonenberg> We could but i've been holding off since i want to completely rewrite it to use a realistic s-parameter channel
<d1b2>
<azonenberg> and give less strange looking waveforms that actually seem like they could have been measured in real hardware
<d1b2>
<darius0949> ooh demo works
<d1b2>
<darius0949> very pretty 🙂
<d1b2>
<azonenberg> i didnt see the point in patching legacy code that i was going to rip out soon anyway
<d1b2>
<azonenberg> (especially since it only blocks the demo scope and not any real instrument)
<d1b2>
<darius0949> now I just need a scope to connect to it 😖
<d1b2>
<david.rysk> demo scope is the first thing someone testing out the software will try
<d1b2>
<azonenberg> Yeah I know, it needs to be fixed
<d1b2>
<azonenberg> i just dont want to halfass it when it's gonna be rewritten in the next few months
<d1b2>
<azonenberg> and i have a bunch of other big refactorings and cleanups and docs work to do, plus other filters i need for work or ongoing R&D stuff
<d1b2>
<azonenberg> anyway, replacing ffts in the unit tests with fftw is straightforward for anyone to do
<d1b2>
<darius0949> for now you could just #ifdef __APPLE__
<d1b2>
<darius0949> assuming it doesn't blow up on Linux/Windows
<d1b2>
<azonenberg> i i thought we had ifdef apple_silicon or similar
<d1b2>
<azonenberg> or arm64
<d1b2>
<darius0949> yeah there is
<d1b2>
<darius0949> but it blows up for me on amd64 apple
<d1b2>
<azonenberg> (because afaik ffts works fine on x86 macs)
<d1b2>
<azonenberg> interesting
<d1b2>
<darius0949> maybe that is my ffts is toast
<d1b2>
<azonenberg> ok apparently it doesnt :p
<d1b2>
<azonenberg> anyway, yeah, x86 mac is a small enough target userbase that it didnt really register as a priority. it'll happen, you have a workaround in the meantime
<d1b2>
<darius0949> yeah no worries
<d1b2>
<darius0949> I got my shiny bling demo so it's all good 🙂
<d1b2>
<azonenberg> oh right i was halfway through writing this decodew when i remembered
<d1b2>
<azonenberg> i still have a segfault in the graph editor i need to investigate
<d1b2>
<azonenberg> looks like a use-after-free where we delete a no-longer-referenced node midway through the frame but try to do physics processing on the same node later in the frame
<d1b2>
<azonenberg> (yet another thing that moving to shared_ptr's will fix)
d1b2 has quit [Read error: Connection reset by peer]
d1b21 has joined #scopehal
d1b21 is now known as d1b2
bvernoux has joined #scopehal
moreentropy has joined #scopehal
bvernoux has quit [Quit: Leaving]
Stephie has joined #scopehal
<d1b2>
<david.rysk> @darius0949 > Unless there is a good reason to prohibit it, we prefer to have permission up-front to make minor modifications to the port without consulting the maintainer. This permission can be indicated by adding openmaintainer to the maintainers line. This applies to the two existing ports you maintain as well. Probably a good idea
<d1b2>
<darius0949> yeah I updated my patch with that
<d1b2>
<david.rysk> oh I probably clicked on the old patch then
<d1b2>
<darius0949> it's possible I fucked it up 🙂