azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | | Logs:
<azonenberg> kc8apf: yes, there's not a website yet. gotta make one
<xzcvczx> darius: dumb question but you are using clang++ as your compiler or including the c++ libs? that used to bite me
<xzcvczx> on macos
<d1b2> <Darius> I am using GCC 10 from Macports
<d1b2> <Darius> mainly because it has OpenMP support
<d1b2> <Darius> I have tried clang and it had the same issue
<d1b2> <Darius> but it demangled the symbols for me 😉
<xzcvczx> maybe try explicitly linking the c++ libs?
<d1b2> <Darius> it is only a Glib link error though
<d1b2> <Darius> I wonder if needs cast or something
<d1b2> <Darius> eg Glib::ustring::ustring(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)" should match up with I think
<d1b2> <Darius> but I dunno if std::__cxx11::basic_string is compatible with std::string..
<xzcvczx> i wonder what default standard is being used
<d1b2> <Darius> based on the std::__cx11::basic_string I guess C++11 🙂
<xzcvczx> nah i mean for hte compiler
<d1b2> <Darius> the other annoying thing is.. I can't find where the code uses ustrin
<d1b2> <Darius> I can see where SetStringWidth is but it doesn't directly call ustring
<xzcvczx> maybe try adding
<xzcvczx> set(CMAKE_CXX_STANDARD 11)
<xzcvczx> to the root cmake file?
<xzcvczx> if its not already there
<d1b2> <Darius> no change alas
pepijndevos has quit [Ping timeout: 246 seconds]
pepijndevos has joined #scopehal
<xzcvczx> darius: you are on x86 eh?
<xzcvczx> well x86-64 for the purists
<d1b2> <Darius> Yes
<d1b2> <Darius> amd64 for total purists 😅
<xzcvczx> i *think* intels abomination was called ia64 or something so not sure if x86-64 is technically incorrect
<d1b2> <Darius> ia64 is different
<d1b2> <Darius> that is itanic^WItanium
<d1b2> <Darius> amd64 was used in FreeBSD when it added support for the 64 bit extensions (one of the first OSen to do so)
<d1b2> <Darius> I think Intel prefer x86_64 since it doesn't have their competitors name in it 8-)
<xzcvczx> hence "abomination"
<xzcvczx> maybe it should be called titanic
<d1b2> <Darius> I do like "Itanic" I think The Register coined it
<ericonr> it's a bit sad that amd's stroke of genius was "let's continue supporting legacy garbage"
<d1b2> <Darius> hah they are finally discontinuing it.. July this year
<xzcvczx> discontinuing what?
<d1b2> <Darius> razor thin margins mean noone has the money to rewrite all their working and debugged code so..
<d1b2> <Darius> Itanium
<xzcvczx> i thought it was ditched like a year or 2 ago
<xzcvczx> oh nvm it was just the announcment i got confused
<d1b2> <Darius> also, Itanium asked some pretty heroic things of compilers so performance was.. not great
<xzcvczx> yeah that and dropping compatibility is always going to bite you
<xzcvczx> esspecially when xp's x64 support was beyond rubbish
<sorear> imo IA-32e is by far the worst name
<xzcvczx> can't say i know that one
<sorear> that’s what the intel software developer’s manual calls 64 bit mode
<xzcvczx> you must really hate yourself to read that
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 240 seconds]
Degi_ is now known as Degi
ericonr has quit [Ping timeout: 252 seconds]
ericonr has joined #scopehal
<azonenberg> darius: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > is std::string in glibc
<azonenberg> so that sounds fine
<d1b2> <Darius> hmmmm
<d1b2> <Darius> don't like those UNDs...
<d1b2> <Darius> oh wait I need to look in glib
<d1b2> <Darius> 00000000000239ca g F TEXT,text Glib::ustring::ustring(std::1::basic_string<char, std::1::char_traits<char>, std::__1::allocator<char> > const&)
<d1b2> <Darius> glibmm built against the wrong C++ standard?
<azonenberg> Hmmmm sounds more like compiler mismatch or something?
<azonenberg> because i've built with c++03 to c++17 at least against the same libraries and been fine
<azonenberg> using g++ on linux
<d1b2> <zyp> libc++ vs libstdc++ mismatch perhaps?
<d1b2> <Darius> I'll rebuild glibmm and see
Tost has joined #scopehal
<d1b2> <Darius> hmm glibmm is built with: /usr/bin/clang++ -std=c++11 -Wall -pipe -Os -stdlib=libc++ ...
<d1b2> <Darius> guess I'm using clang then
<d1b2> <Darius> luckily I now have clang 11 with MP support
<xzcvczx> azonenberg: i assume you saw update from trevor?
<azonenberg> Yep
<azonenberg> So should have plenty of time for us to finish the refactoring before you get the hardware
<azonenberg> xzcvczx: so in the meantime i guess you'll be working on the BSD stuff?
<azonenberg> How far are you from having stuff to merge?
<azonenberg> xzcvczx: also in the meantime i do have another driver dev project you can work on if you're interested?
<azonenberg> there's hundreds of similar fx2 based saleae clone LAs out there
<xzcvczx> azonenberg: i have 2 selae clones
<azonenberg> excellent
<azonenberg> Well, if you wanna try to write a driver we'd definitely appreciate that
<azonenberg> We should be able to use as firmware for it
<azonenberg> It's a GPL'd blob from sigrok but i think it's OK to ship a GPL blob as this doesn't contaminate our core codebase with GPL content
<azonenberg> we'd just need to write our own host-side driver that speaks a compatible protocol via libusb
<azonenberg> We can just grab the binaries from
<xzcvczx> yeah building it is a freaking nightmware
<azonenberg> Hence why i suggested just shipping the blobs
<azonenberg> As long as they're in a separate subdirectory and clearly identified as GPL I don't see an issue
<xzcvczx> were you still thinking of bridging it to tcp?
<azonenberg> Hmmm
<xzcvczx> well do you think bridging it to tcp is the best choice
<azonenberg> That's a good question
<xzcvczx> as we were talking about the hantek last time i think this came up
<azonenberg> Native libusb would work fine but in my lab i often am sitting across the building from the machine that the scope/LA is hooked to
<azonenberg> It probably wouldn't be a bad idea to write a bridge
<azonenberg> Idea: maybe we could refactor the dual socket protocol from the pico driver to a new base class
<azonenberg> then have pico and the fx2la dsrivers derive from that class and include model specific extensions?
<azonenberg> How about you start by writing a libusb based fx2la driver that is a native scopehal device
<azonenberg> I think long term what i'm going to want to do is write a socket server that bridges a libscopehal Oscilloscope object to a common socket protocol
<azonenberg> this would allow you to provide tcp remoting to any instrument connected via libscopehal even if it lacks an ethernet port
<azonenberg> We might even fold the pico code into that one day?
<xzcvczx> do we wnat to cleanroom the fx2la protocol?
<azonenberg> I think it should be OK to read the fx2la source, just don't copy anything from the sigrok host side
<azonenberg> i.e. dont look at libsigrok code for it
<xzcvczx> fx2lafw you mean (just fyi for hte firmware)
<azonenberg> Correct
<xzcvczx> lol i think you have pretty much the exact model of clone as one of the ones i have
<xzcvczx> except i didn't get the completely crappy test hooks that you did
<azonenberg> Well i didn't get it intending to *use* it :p
<azonenberg> I got it as a test subject for driver development and no more
<xzcvczx> is yours mini-b or micro-b?
<azonenberg> Dont know, i dont even think i ever plugged it in
<azonenberg> it's been sitting on a shelf waiting for me to find time to work on it
<xzcvczx> fair enough
<xzcvczx> oh nvm picture shows its mini
<xzcvczx> i was looking at the LA rather than the cable but the cable is clearly mini
<azonenberg> ah ok
<azonenberg> Ok so... summarizing the pending blockers for v0.1 right now
<azonenberg> Six tickets (14% of total across scopehal and scopehal-apps) are related to the scopesession file format
<azonenberg> Three (7%) are build system/packaging
<azonenberg> Eleven (25%) are driver related, of which two are LeCroy and three are Pico
<azonenberg> Four (9%) re protocol decode related
<azonenberg> Seven (16%) are UI related
<azonenberg> Another four (9%) file import/export related
<azonenberg> and then the other nine (20%) are miscellaneous
<xzcvczx> i think for hte fx2lafw i might just go straight for doing mso for it
<azonenberg> you have a scope with mso hardware that uses fx2la?
<xzcvczx> the hantek i have does the oscope side
<xzcvczx> and the la side, just can't do it at the same time
<azonenberg> wait you can use either scope and la via usb, but not both?
<azonenberg> scope or*
<xzcvczx> yes
<xzcvczx> hardware switch
<azonenberg> if thats not an awful design i don't know what is, lol
<xzcvczx> well if you only need one or the other
<xzcvczx> so i guess its not mso, but i was more meaning that i can do both the oscope side of fx2la and the la side
<azonenberg> oh the hantek uses fx2lafw for the scope interface too?
<xzcvczx> yes
<azonenberg> Perfect. Go for it then
<azonenberg> Which Hantek is it?
<xzcvczx> 6022bl in my case
<xzcvczx> the 6022be is the oscope only one
<azonenberg> How similar is that to the MSO5074?
<xzcvczx> not at all iirc
<azonenberg> ah ok we had a ticket for that. I'll leave that open and not marked for v0.1 then
<xzcvczx> i dont think the mso5074 is even bsaed on fx2
<azonenberg> ah, i see
<d1b2> <Darius> hmm cmake found yaml-cpp but it isn't telling the makefile where it found it
<xzcvczx> azonenberg: any recommendation of a good mso implementation to look at?
<azonenberg> xzcvczx: LeCroy is the most complete one that I know of
<xzcvczx> ok thank you
<azonenberg> or Tek MSO6
<azonenberg> The LeCroy driver code is a bit ugly because of the vbscript and the fact that their logic analyzer waveforms are literally xml
<azonenberg> I wish i was kidding\
<d1b2> <Darius> @azonenberg BTW I built glscopeclient on OSX
<xzcvczx> >_< vbscript? ummmm are you sure its not a virus?
<xzcvczx> lol
<xzcvczx> do null for path
<xzcvczx> on demo
<d1b2> <Darius> ah path has to be non null
<xzcvczx> yeah that bit me too
<d1b2> <Darius> then I get the "Your graphics card or driver does not appear to support OpenGL 4.2"
<d1b2> <Darius> not too surprising I suppose
<azonenberg> No
<azonenberg> xzcvczx: LeCroy's internal driver model is all Windows COM
<azonenberg> They have bridges from some of the more frequently used commands to SCPI
<azonenberg> but to access anything at all obscure, you usually end up using the VBS SCPI command that literally executes a line of vbscript
<azonenberg> to poke the COM object
<azonenberg> It's actually a halfway decent object oriented API, just a really clunky way of accessing it remotely
<xzcvczx> fair enough
<azonenberg> darius: Nice, that's a good start at least
<azonenberg> It would not surprise me if libscopehal headless works on osx at that point
<azonenberg> Getting the GUI working is a different story of course
<azonenberg> But it's starting to look like compute shaders might be the only blocker
_whitenotifier-1 has joined #scopehal
<_whitenotifier-1> [scopehal-apps] azonenberg opened issue #344: Look into alternate (OpenCL based?) renderers so we can support OSX -
<_whitenotifier-1> [scopehal-apps] azonenberg labeled issue #344: Look into alternate (OpenCL based?) renderers so we can support OSX -
<_whitenotifier-1> [scopehal-apps] azonenberg edited issue #344: Look into alternate (OpenCL based?) compute shader equivalents so we can support OSX -
<xzcvczx> darius: did you end up building it with opencl support?
<xzcvczx> darius: and was it gcc or clang in the end?
<xzcvczx> darius: and was it the libc++ vs stdlibc++ think that i saw earlier?
<d1b2> <Darius> no OpenCL support - OSX doesn't have C++ bindings 🥺
<d1b2> <Darius> I used clang because glibmm was built with it otherwise there were missing symbols
<azonenberg> So we need to figure out how we can do accelerated waveform rendering on osx then
<azonenberg> if both compute shaders and c++ opencl are out
<xzcvczx> metal of course :)
<azonenberg> Are the khronos C++ bindings for opencl something that actually needs OS support?
<azonenberg> can we just install them seaprately?
<azonenberg> i seem to recall they're just a wrapper around the C API
<d1b2> <Darius> If I hack out the OGL 4.2 check it then complains about GL_ARB_arrays_of_arrays, GL_ARB_compute_shader, GL_ARB_shader_storage_buffer_object, GL_ARB_vertex_array_object, GL_EXT_blend_equation_separate, and GL_EXT_framebuffer_object
<azonenberg> darius: array of arrays and shader storage buffer object are only used in the compute shaders i think, so if we avoid compute shaders they're not needed
Famine_ has joined #scopehal
<azonenberg> no VAO or FBO is a little surprising, what GL version is it reporting?
<azonenberg> the separate blend equation i might be able to work around
<d1b2> <zyp> it should support 4.1
<d1b2> <Darius> dunno about the version sorry
<d1b2> <Darius> how do I tell?
* xzcvczx is sorta glad to not be at fault for making azonenberg rejigger the opengl to work this time
<d1b2> <zyp> I'd also appreciate macos support
<azonenberg> zyp: my understanding was that apple silicon did 4.1 and most other osx was stuck on 3.3
<d1b2> <zyp> hmm, I'm not sure
<azonenberg> i think the M1 is the only thing with 4.1, is that what you have?
<d1b2> <Darius> are the diffs I have BTW
Famine- has quit [Ping timeout: 260 seconds]
<d1b2> <zyp> hmm, is glxinfo supposed to show highest supported? if so this is not very promising: OpenGL version string: 2.1 NVIDIA-12.0.23 355.
<azonenberg> zyp: wow that is older than i thought
<azonenberg> I think apple silicon support is the first reasonable OSX target for us. Older might be possible but should not be the priority
<d1b2> <zyp> they killed off nvidia support some years back though
<azonenberg> I think the path should be linux ARM -> apple silicon -> possibly other osx
<d1b2> <zyp> I'm running a nine year old hackintosh
<azonenberg> yeah good luck on that lol
<xzcvczx> darius: haha so many of your changes are pretty much exactly the changes i made to the letter :)
<d1b2> <zyp> been working well so far 🙂
<d1b2> <Darius> hah OK
<azonenberg> darius, xzcvczx: ok so, as far as BSD goes, some of those changes look like they might break other stuff
<xzcvczx> but yeah my bad i hadn't gotten around to throwing them at azonenberg
<d1b2> <Darius> I have a Radeon Pro 560X
<xzcvczx> azonenberg: like which?
<azonenberg> e.g. omp.h is required for various openmp apis on linux
<xzcvczx> oh i didn't need to ditch omp.h on bsd
<d1b2> <Darius> I removed omp where it was not needed
<azonenberg> Oh you only removed if it wasnt used
<azonenberg> ok thats fine then
<azonenberg> xzcvczx: anyway if you can come up with a set of patches to get it to build and run on bsd without breaking linux or windows, by all means send 'em my way
<azonenberg> let me actually file a ticket for that so i have something
<d1b2> <Darius> the -mavx is needed for Clang, not BSD per se
<xzcvczx> azonenberg: well are you going to merge that diff from darius?
<xzcvczx> as thats most of them
<azonenberg> Not as is
<xzcvczx> fair enough
<azonenberg> I also want a github PR rather than a raw diff if possible
<azonenberg> sine i can link it to tickets etc
<_whitenotifier-1> [scopehal] azonenberg opened issue #474: BSD build support -
<_whitenotifier-1> [scopehal] azonenberg labeled issue #474: BSD build support -
<xzcvczx> darius: yo uhappy to do a pr or do you want me to do it?
<_whitenotifier-1> [scopehal-apps] azonenberg opened issue #345: BSD build support -
<_whitenotifier-1> [scopehal-apps] azonenberg labeled issue #345: BSD build support -
<d1b2> <Darius> if you can do it that would be nice please
<xzcvczx> ok
<d1b2> <zyp> ah, I do indeed have full 4.1 support
<xzcvczx> darius: any changes that are macos specific i can name you in the commit but it will still be under my name
<azonenberg> So if you have full 4.1 then that's a lot more reasonable then as far as potential for getting more stuff supported
<d1b2> <Darius> is what glewinfo shows BTW
<azonenberg> I suspect, but am not certain, that the majority of the >4.1 stuff we use is compute shader specific
<d1b2> <Darius> OK that;s no problem with me
<azonenberg> and thus if we were to render via opencl, cuda, or similar we could then use GL 4.1 just fine to splat those textures on the screen
<xzcvczx> darius: oh you did need to add min/max in the end
<xzcvczx> i will probably need to ifdef them
<d1b2> <Darius> Yes, only in that file though
<azonenberg> Those should be in the c++ libraries?
<d1b2> <Darius> I think gcc has it built in but clang doesn’t
<azonenberg> maybe you just need to #include <algorithm>
<d1b2> <Darius> Ahh could be
<d1b2> <Darius> I can try later, heading home now
<xzcvczx> okay if darius responds can someone please ping me with it as highlight doesn't work from the bridge
<xzcvczx> if/when
ericonr has quit [Ping timeout: 260 seconds]
ericonr has joined #scopehal
<azonenberg> xzcvczx: OSX is a separate issue. Let's focus on getting it to build and run under BSD first
<azonenberg> that will get us most of the way to compiling on osx it seems, and actually running on osx is a whole other battle
<xzcvczx> fair enough
<xzcvczx> darius: just fyi GLOB_ONLYDIR is only a performance thing and doesn't gaurantee only dirs
<_whitenotifier-1> [scopehal] azonenberg commented on issue #386: SCPITMCTransport: reading a reply via multiple ReadRawData() calls fails -
<azonenberg> Hey, if anybody here has a bit of time for what should be a pretty quick fix
<azonenberg> All you need to do is add a bit of code in MockOscilloscope::LoadCSV() around line 379 that does a stat() on the file, or equivalent on windows, to get the file mod timestamp
<azonenberg> and then set timestamp to that
<azonenberg> fs can probably be zero unless the filesystem has sub-second timestamp resolution
<azonenberg> (doing the same in LoadWAV() wouldn't hurt either)
<xzcvczx> is a timestamp from mtime really a great idea?
<xzcvczx> if you copy a bunch of files at the same time they will all end up with the same timestamp potentially leading to confusion unless there is a warning
<xzcvczx> theoretically at least
<azonenberg> xzcvczx: It's better than january 1970
<azonenberg> Which is what it does right now if there's no timestamp in the file header comment
<azonenberg> (if one is present, it should be used in preferenec to the mod time)
<azonenberg> In the absence of anything else, mtime is the best information we have
<xzcvczx> ok
<_whitenotifier-1> [scopehal-apps] azonenberg commented on issue #141: Debian packaging -
<xzcvczx> azonenberg: btw is there any reason you are setting --std=c++11 in flags rather than using proper cmake stuff for it?
<azonenberg> xzcvczx: probably just lack of knowledge of the cmake way to do it
<xzcvczx> ok
<d1b2> <Darius> @xzcvczx: ahh OK, easy then!
<xzcvczx> azonenberg: do you care that you are using gnu extensions?
<xzcvczx> or rather do you care if scopehal/-apps uses gnu extensions?
<azonenberg> which extensions? i know we use a few attributes to enable avx code generation in certain functions
<azonenberg> but i thought that was our main gnu-ism
<xzcvczx> -Wgnu-zero-variadic-macro-arguments
<xzcvczx> #define LogTrace(...) LogDebugTrace(__PRETTY_FUNCTION__, ##__VA_ARGS__)
bvernoux has joined #scopehal
<_whitenotifier-1> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-1> [scopehal-apps] azonenberg 9d0ebd7 - Updated CI pipeline to create source tarball as an artifact
<azonenberg> Oh, yes - we had warnings otherwise when we passed no arguments to LogTrace
<azonenberg> we couldn't find a clean way to do that otherwise
<azonenberg> we wanted it to behave with printf semantics so you could have a format string and not require args
<bvernoux> azonenberg, I have checked that with MSYS2 MINGW64 too
<bvernoux> even with the good flags there is warning :(
<bvernoux> but all work fine in fact
<azonenberg> So i guess one potential workaround would be
<bvernoux> %zu work like expected for example
<azonenberg> nvm no that wouldnt work
<xzcvczx> i am just warning chasing on bsd now
<bvernoux> it seems the warning comes from the fact the definition of the function is not printf() but an other name ...
<bvernoux> Also there is tons of warnings for fix with MSYS2 MINGW64 which are minor ....
<xzcvczx> bvernoux: do you build with msvc as well or just msys2?
<bvernoux> no only MSYS2 mINGW64
<azonenberg> bvernoux: no the problem is related to the fact that it's a macro not a function
<bvernoux> msvc is not supported
<azonenberg> and apparently varadic macros require at least one argument
<azonenberg> per the c++ standard
<bvernoux> azonenberg, ha yes probably it is the root cause you have same type of warning on bsd or other too ?
<azonenberg> not with that gnu extension
<bvernoux> ok so it seems to impact only MSYS2 MINGW64
<xzcvczx> msys2 mingw64 is gcc though isn't it?
<bvernoux> xzcvczx, yes but special GCC ;)
<bvernoux> xzcvczx, it does not support POSIX stuff as it is more linked to Windows stuff
<bvernoux> xzcvczx, advantage is it do not generate bloated exe like cygwin which is POSIX compliant ...
<xzcvczx> yeha i am just a big caught on whether i am adding the right stuff to shut up warnings :)
<xzcvczx> well warnings about warnings :)
<bvernoux> xzcvczx, are you trying to rebuild glscopeclient with MSYS2 MINGW64 or with Linux(Ubuntu ...) ?
<xzcvczx> bsd :)
<xzcvczx> clang
<bvernoux> ha ok so linux stuff ;)
<bvernoux> glurps with clang ;)
<bvernoux> It will probably add tons of new warning with clang
<xzcvczx> hence the limiting some stuff go GNU onlu
<xzcvczx> only
<bvernoux> yes I imagine there is lot of things to change ...
<xzcvczx> and wasn't sure whether it would burp at mingw but based on my reading it shouldnt
<bvernoux> You cannot start using GCC on BSD it will be easier ?
<xzcvczx> well a majority of it has been setting includes to SYSTEM
<xzcvczx> bvernoux: i know it builds currently i just want it quieter
<bvernoux> ha ok great
<bvernoux> improving warning and adding clang is a nice things anyway
<bvernoux> on my side there is tons of GTKMM warnings
<bvernoux> with some redefinitions ...
<bvernoux> those warning have appeared since few months now
<xzcvczx> i will clean up most of those
<bvernoux> I think I'm not the only one to have them on MSYS2 MINGW64 ;)
<xzcvczx> the gtkmm warnings
<bvernoux> yes
<bvernoux> they are ugly everywhere ;)
<bvernoux> I was too lazy to start tackling them
<xzcvczx> yeah i am just rebuilding hopefully fixed them all now
<bvernoux> ha great
<xzcvczx> they just require SYSTEM on all hte include dirs for system libs
<azonenberg> Yeah the currently official build pipeline is gcc and has, i think, two warnings in total
<azonenberg> both of which are legitimate issues about incomplete code
<xzcvczx> clang is currently throwing a few odd ones
<xzcvczx> at this point i do not understand them so am just going for hte easy fish first
<bvernoux> for example do you have such
<bvernoux> textbuffer.h:59:17: warning: type attributes ignored after type is already defined [-Wattributes]
<bvernoux> 59 | class GTKMM_API TextIter;
<xzcvczx> if i did its gone now sorry
<xzcvczx> i am not seing any gtkmms currently
<xzcvczx> i am currently building on an i5 from the stone age though so its not quick
<bvernoux> I think it is specific to MSYS2 MINGW64 in that case :(
<bvernoux> I have tons of warnings like
<bvernoux> In file included from C:/msys64/mingw64/include/gtkmm-3.0/gtkmm.h:297,
<bvernoux> from C:/msys64/home/Ben/scopehal-apps/lib/graphwidget/Graph.h:39,
<bvernoux> from C:\msys64\home\Ben\scopehal-apps\lib\scopeprotocols\PeakHoldFilter.cpp:30:
<bvernoux> from C:/msys64/home/Ben/scopehal-apps/lib/scopehal/scopehal.h:54,
<bvernoux> C:/msys64/mingw64/include/gtkmm-3.0/gtkmm/textbuffer.h:58:17: warning: type attributes ignored after type is already defined [-Wattributes]
<bvernoux> 58 | class GTKMM_API TextMark;
<bvernoux> | ^~~~~~~~
<bvernoux> C:/msys64/mingw64/include/gtkmm-3.0/gtkmm/textbuffer.h:59:17: warning: type attributes ignored after type is already defined [-Wattributes]
<bvernoux> 59 | class GTKMM_API TextIter;
<xzcvczx> not that will be ignored
<bvernoux> | ^~~~~~~~
<xzcvczx> with it marked as system
<xzcvczx> system means it won't throw up any warnings for stuff inside gtkmm
<bvernoux> It seems I'm not the only ones
<bvernoux> it is clearly something with mingw64 ...
<xzcvczx> oh ok
<bvernoux> haha their solution => Confirmed. Quick and dirty solution would be to silence the warnings using -Wno-attributes.
<bvernoux> what a crap ...
<xzcvczx> meh just set -Wnone while you are at it :)
<bvernoux> hmm an other issue here
<bvernoux> it seems doing -DGTKMM_USE_GENDEF shall remove those warnings ;)
<xzcvczx> i think ~90% of my warnings are now the variadic ones as mentioned earlier
<bvernoux> interesting to check what change with msys2 with your warning fixes
<bvernoux> I have just tested
<bvernoux> -DGTKMM_USE_GENDEF but that does not change anything
<xzcvczx> is most of the warnings that aren't the variadic one
<bvernoux> I suspect the issue is #include <gtkmm.h> is declared in Graph.h & glscopeclient.h ...
* xzcvczx forces the dunst cap on azonenberg for returning a bool from main
<azonenberg> when did i do that? must be a mistake
<xzcvczx> usbcsv:92
<azonenberg> usbcsv is a test/demo tool codysseus did a lot of the work on iirc
<azonenberg> it was just a demo of headless libscopehal usage i wrote and he modified
<azonenberg> that might not even be my code
<xzcvczx> oh my bad
<azonenberg> But it's certainly not something critical to the project , it's been essentially unmaintained
<xzcvczx> well clang complains at it
<xzcvczx> do you care about any of those pastebinned warnings?
<azonenberg> Looking
<azonenberg> The cast alignment issues are all over the place and are just the nature of parsing raw binary data. For the time being glscopeclient just won't run on anything that mandates alignment
<azonenberg> But i think at least a few are false positives
<azonenberg> as far as the edge type stuff i think those are... there's not a good way to add new members to an enum in a derived class
<azonenberg> i'm not sure if we can find a way to make that better
<xzcvczx> fair enough
<azonenberg> I mean if somebody wants to try, go for it
<xzcvczx> why would we want to take that honour away from you
<noopwafel> time for my next PR, "squash compiler warnings by replacing all enums with #defines"
* xzcvczx changes all noopwafel's PRs to NOP
<azonenberg> Also he's not in the channel but @GyrosGeier is interested in working on getting debian packaging made
<xzcvczx> azonenberg:
<azonenberg> xzcvczx: sounds like a compiler issue... on 753 the attribute of avx2 is supposed to mean that use of avx in that function is allowed
<azonenberg> clang is probably ignoring that
<azonenberg> which is odd because suggests it's supported
<azonenberg> i wonder if immintrin.h is the problem and doesnt include those attributes
<xzcvczx> well i am not specifying -mavx currently
<azonenberg> You shouldn't
<azonenberg> the whole point of the attributes is that i want all of the code to be built without avx, to run on older CPUs
<xzcvczx> oh my bad i misunderstood what you said before
<azonenberg> and then specific functions marked for optimization are compiled with avx
<azonenberg> it should be used there and nowhere else
<xzcvczx> i thought you said avx2 versus avx not avx2 enables avx
<azonenberg> oh, no
<azonenberg> target -mavx2 implies -mavx as well
<xzcvczx> can you not rely on multiversioned?
<xzcvczx> aka same function names and it just runs the one that fits?
<xzcvczx> or is that not in gcc?
<azonenberg> I'm not aware of that in gcc, if it exists it would be nice to switch to that
<azonenberg> apparently it does
<xzcvczx> apparently its been in since 4.8
<xzcvczx> stop using gcc 4.5
<azonenberg> Lol i'm using 8.3
<azonenberg> I just didnt know it existed
<azonenberg> it looks to be x86 only so not supported for things like NEON vs non-NEON on ARM?
<azonenberg> But still good to know, I'll file a ticket for that
<xzcvczx> oh really? thats annoying
<azonenberg> well right now we only run on x86 sooo :p
<azonenberg> Does clang have that too?
<_whitenotifier-1> [scopehal] azonenberg opened issue #475: Switch to GCC function multiversioning for AVX forks of functions -
<_whitenotifier-1> [scopehal] azonenberg labeled issue #475: Switch to GCC function multiversioning for AVX forks of functions -
<_whitenotifier-1> [scopehal] xzcvczx opened pull request #476: fix indentation warnings -
<_whitenotifier-1> [scopehal] xzcvczx opened pull request #477: change system includes to SYSTEM to hide their warnings -
<xzcvczx> you are going to get a bunch of the change system includes as they need to go to each of the repos
<xzcvczx> azonenberg: ah yeah sorry clang does have it to, thats how i found out about it
<_whitenotifier-1> [scopehal-apps] xzcvczx forked the repository -
<_whitenotifier-1> [scopehal-apps] xzcvczx opened pull request #346: change system includes to SYSTEM to hide their warnings -
<_whitenotifier-1> [scopehal] azonenberg pushed 2 commits to master [+0/-0/±4]
<_whitenotifier-1> [scopehal] xzcvczx 3d7dfc5 - change system includes to SYSTEM to hide their warnings
<_whitenotifier-1> [scopehal] azonenberg eac3c7d - Merge pull request #477 from xzcvczx/system-includes change system includes to SYSTEM to hide their warnings
<_whitenotifier-1> [scopehal] azonenberg closed pull request #477: change system includes to SYSTEM to hide their warnings -
<_whitenotifier-1> [scopehal] azonenberg closed pull request #476: fix indentation warnings -
<_whitenotifier-1> [scopehal] azonenberg pushed 2 commits to master [+0/-0/±2]
<_whitenotifier-1> [scopehal] xzcvczx 75848b1 - fix indentation warnings
<_whitenotifier-1> [scopehal] azonenberg fb2950a - Merge pull request #476 from xzcvczx/indent-fix fix indentation warnings
<_whitenotifier-1> [scopehal] azonenberg pushed 2 commits to master [+0/-0/±4]
<_whitenotifier-1> [scopehal] azonenberg 1531944 - Updated graphwidget
<_whitenotifier-1> [scopehal] azonenberg 0df41ae - Merge branch 'master' of
<_whitenotifier-1> [scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±16]
<_whitenotifier-1> [scopehal-apps] xzcvczx fa93c2e - change system includes to SYSTEM to hide their warnings
<_whitenotifier-1> [scopehal-apps] azonenberg 9c3c5eb - Merge pull request #346 from xzcvczx/system-includes change system includes to SYSTEM to hide their warnings
<_whitenotifier-1> [scopehal-apps] azonenberg closed pull request #346: change system includes to SYSTEM to hide their warnings -
<xzcvczx> thank you
<_whitenotifier-1> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-1> [scopehal-apps] azonenberg 1770bf7 - Updated scopehal
<xzcvczx> azonenberg: for now should i just add -mavx on clang only?
GyrosGeier has joined #scopehal
<GyrosGeier> oh hai
<xzcvczx> were your ears burning?
<azonenberg> o/ GyrosGeier
<azonenberg> xzcvczx: i'd rather not, you can do it in your local build
<azonenberg> actually hmmm
<azonenberg> Your cpu is older than haswell right?
<azonenberg> ivy bridge or something like that?
<xzcvczx> yes
<xzcvczx> but dont forget the same happened for darius using clang
<xzcvczx> darius is a mac user so can't have hardware older than like 1yr
<azonenberg> So i guess the question is, if we add -mavx who are we cutting off?
<azonenberg> i.e. who could use it before that can't now?
<xzcvczx> discrete graphics users i guess
<azonenberg> avx1 has been around for a long time, i dont want to mandate avx2
<azonenberg> avx1 dates to sandy bridge
<azonenberg> the bigger issue is pentium and celeron branded SKUs of modern CPUs don't have avx
<azonenberg> so the question is how prevalent those are among potential glscopeclient users?
<azonenberg> i would really like to find a solution that doesn't involve turning avx on globally
<xzcvczx> well its not like they will be able to build or run a clang build anyway
<xzcvczx> it will only affect clang and i will tag it with a comment stating what issue its waiting on
<azonenberg> Ok fine, add it for clang only
<xzcvczx> ok building to test my changes now then i will be doing a bunch more pushes
<xzcvczx> was great to hear back from trevor, i expected it would be much longer than end of the week
<azonenberg> Yeah me too
<azonenberg> So i guess that means me and noopwafel have to get the pico bridge refactored
<xzcvczx> >_< have you been messing with ChannelPropertiesDialog.cpp?
<GyrosGeier> 15:30 < azonenberg> ivy bridge or something like that?
<GyrosGeier> that should be recent enough for CL and GL
<xzcvczx> yeah yeah go ahead and laugh GyrosGeier
<xzcvczx> CL is broken AF on it
* GyrosGeier checks
<xzcvczx> GL is good
<GyrosGeier> with Beignet?
<xzcvczx> thats the oss one? yes
<GyrosGeier> I use an i7-3740QM
<GyrosGeier> and it passes most of the piglit CL tests
<xzcvczx> is that a quad core?
<xzcvczx> on my 3520m glscopeclient tested something and said nope you useless
<xzcvczx> azonenberg:
bvernoux has quit [Read error: Connection reset by peer]
<azonenberg> xzcvczx: did you not pull latest submodules?
<GyrosGeier> xzcvczx, that's a quadcore, yes
<azonenberg> git config submodule.recurse true
<GyrosGeier> it compiles FPGAs twice as fast as my ten-core server CPU from 2017
<azonenberg> if you don't set that, it will keep biting you :p
<xzcvczx> oh foozeball
<xzcvczx> my bad azonenberg thank you
<_whitenotifier-1> [scopehal] xzcvczx opened pull request #478: add . to the search path for locals builds that dont have readlink -
<xzcvczx> feel free to reject that one azonenberg
<azonenberg> Yeah I'm gonna say no. Is requiring users to have /proc enabled for development that big a deal?
<_whitenotifier-1> [scopehal] azonenberg closed pull request #478: add . to the search path for locals builds that dont have readlink -
<GyrosGeier> might break chroot builds
<GyrosGeier> we'll see what happens on Debian autobuilders
<GyrosGeier> I need to package ffts first, it seems
<GyrosGeier> everything else should be there
<xzcvczx> azonenberg: what about a env var?
<azonenberg> GyrosGeier: yeah we are probably going to end up forking and adopting ffts
<azonenberg> it seems to be abandonware but fftw is GPL which is wrong-way compatible with our BSD license
<azonenberg> ffts was the only viable option i could find that was permissively licensed
<azonenberg> Right now we're using the last released version which works but hasnt been updated in years and i think adding AVX support would make it quite a bit faster
bvernoux has joined #scopehal
<xzcvczx> azonenberg: would you be opposed to passing argv[0] to DriverStaticInit/InitSearchPaths?
<azonenberg> xzcvczx: That's actually what i was starting to think of
<azonenberg> Maybe InitSearchPaths should be pulled out of DriverStaticInit
<xzcvczx> realpath?
<azonenberg> and called separately by glscopeclient startup
<azonenberg> (and any other derived apps)
<azonenberg> then pass the path there
<azonenberg> We can make a single global init function latr
<azonenberg> but it's not part of driver init
<xzcvczx> it would make sense
<azonenberg> Go ahead and do that then
<azonenberg> Seems the cleanest solution
<xzcvczx> that aint happening tonight
<xzcvczx> i will get the rest of my forrest of commits pushed that i have done so far
<azonenberg> No rush
<azonenberg> Ok
<azonenberg> I need to get ready for $dayjob stuff anyway
<azonenberg> GyrosGeier: BTW you may see references to catch2 in the build scripts and documentation, you can turn off testing at cmake time and its not required
<azonenberg> i forget if thats in the unstable or experimental repos but it's not in stable
<_whitenotifier-1> [scopehal-apps] xzcvczx opened pull request #347: Bsd fixes -
<_whitenotifier-1> [scopehal-apps] azonenberg closed pull request #347: Bsd fixes -
<_whitenotifier-1> [scopehal-apps] azonenberg pushed 4 commits to master [+0/-0/±7]
<_whitenotifier-1> [scopehal-apps] xzcvczx fa650ff - only use the GLOB_ONLYDIR performance flag when it is available
<_whitenotifier-1> [scopehal-apps] xzcvczx 6537879 - reduce clang warnings
<_whitenotifier-1> [scopehal-apps] xzcvczx 4d5bd0f - Require AVX when building using clang due to clang not following the target attribute
<_whitenotifier-1> [scopehal-apps] azonenberg 955a62c - Merge pull request #347 from xzcvczx/bsd-fixes Bsd fixes
<_whitenotifier-1> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-1> [scopehal] azonenberg 1d68b0a - Updated xptools
<_whitenotifier-1> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-1> [scopehal-apps] azonenberg 5a1851d - Updated scopehal
<xzcvczx> thank you
<_whitenotifier-1> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-1> [scopehal] azonenberg 0c22ea0 - Ethernet100BaseTDecoder: added early-outs so we don't descramble the entire waveform if the sync offset is wrong. Massive (order of magnitude) speedups.
<xzcvczx> and wow the speedup by OMP_WAIT...=PASSIVE is impressive
<azonenberg> Yes, without it ends up busywaiting and oversubscribing cpu cores etc
<azonenberg> unfortunately there's no way to set it via APIs
<azonenberg> it has to be in the user's environment and is non-default
<azonenberg> my plan is to eventually detect it, setenv, and exec self
<azonenberg> if you wanna send a patch for that, go for it
<azonenberg> That is afaik the only way to force the environment to be correct
<azonenberg> since openmp reads it prior to main() in libc startup code
<xzcvczx> haha i think i already have enough stuff in my queue
<azonenberg> Lol well that goes for anyone else here too :p
<azonenberg> is that fixed yet?
Tost has quit [Quit: Nettalk6 -]
juli9611 has joined #scopehal
* GenTooMan adds a few rocks into xzcvczx's queue.
<xzcvczx> o_O what did i do to you
<xzcvczx> im innocent i tells ya
<GenTooMan> xzcvczx, you rock? :D
lethalbit has quit [Ping timeout: 240 seconds]
lethalbit has joined #scopehal
maartenBE has joined #scopehal
juli9611 has quit [Quit: Nettalk6 -]
bvernoux has quit [Quit: Leaving]