02:36 <d1b2> <josHua> oo I should write a driver for the gpp4323

02:36 <d1b2> <josHua> (and by that I mean "I should finish the things that I am committed to doing that have actual fucking deadlines")

03:21 <d1b2> <azonenberg> lol

07:49 <d1b2> <fredzo_72653> 😂 No worries Andrew, I haven't created PRs yet anyway 😅 ... They will be 4 of them BTW 😅 (xptools, scopehal, doc and scopehal-apps) but should be easy to review (even though I struggled a bit to manage build on every platform and to understand that HID reports have to be read as whole in one single read operation!).

07:53 <d1b2> <fredzo_72653> I'm curious though if you C++ experts have a clue: I had to comment that line to have the CI build on Windows pass without compilation error, why ?: void HIDInstrument::SendReport(uint8_t reportNumber, std::vector<uint8_t>* data) { // Send the HID report contained in the data buffer lock_guard<recursive_mutex> lock(m_hidMutex); if(data) { std::vector<uint8_t> buffer; // This breaks compilation with latest

07:53 <d1b2> CXX compiler on Windows: // error: 'void operator delete(void*, std::size_t)' called on pointer '<unknown>' with nonzero offset [1, 9223372036854775807] [-Werror=free-nonheap-object] ***// buffer.reserve(data->size()+1);*** buffer.push_back(reportNumber); buffer.insert(buffer.end(),data->begin(),data->end()); m_transport->SendRawData(buffer.size(),buffer.begin().base()); } else LogError("SendReport

07:53 <d1b2> called with null data buffer, ignoring.\n"); }

08:03 <d1b2> <azonenberg> sounds like the data was bogus?

08:04 <d1b2> <azonenberg> but i'd need to see more of the code to understand whats going on

09:22 <d1b2> <fredzo_72653> Oh no it's not a runtime problem, it's a compilation error (well a warning treated as error with the C++ compiler of Github CI): when uncommenting the reserve() call on that local vector, I get that weird message:

09:23 <d1b2> <fredzo_72653> In member function 'void std::__new_allocator<_Tp>::deallocate(_Tp*, size_type) [with _Tp = unsigned char]', inlined from 'static void std::allocator_traits<std::allocator<_Tp1> >::deallocate(allocator_type&, pointer, size_type) [with _Tp = unsigned char]' at D:/a/_temp/msys64/ucrt64/include/c++/14.2.0/bits/alloc_traits.h:513:23, inlined from 'std::vector<_Tp, _Alloc>::_M_realloc_append(_Args&& ...)::_Guard::~_Guard() [with _Args

09:23 <d1b2> = {const unsigned char&}; _Tp = unsigned char; _Alloc = std::allocator<unsigned char>]' at D:/a/_temp/msys64/ucrt64/include/c++/14.2.0/bits/vector.tcc:616:18, inlined from 'void std::vector<_Tp, _Alloc>::_M_realloc_append(_Args&& ...) [with _Args = {const unsigned char&}; _Tp = unsigned char; _Alloc = std::allocator<unsigned char>]' at D:/a/_temp/msys64/ucrt64/include/c++/14.2.0/bits/vector.tcc:688:7, inlined from 'void std::vector<_Tp,

09:23 <d1b2> _Alloc>::push_back(const value_type&) [with _Tp = unsigned char; _Alloc = std::allocator<unsigned char>]' at D:/a/_temp/msys64/ucrt64/include/c++/14.2.0/bits/stl_vector.h:1294:21, inlined from 'void HIDInstrument::SendReport(uint8_t, std::vector<unsigned char>*)' at D:/a/scopehal-apps/scopehal-apps/lib/scopehal/HIDInstrument.cpp:82:19: D:/a/_temp/msys64/ucrt64/include/c++/14.2.0/bits/new_allocator.h:172:33: error: 'void operator delete(void*,

09:23 <d1b2> std::size_t)' called on pointer '<unknown>' with nonzero offset [1, 9223372036854775807] [-Werror=free-nonheap-object] 172 | _GLIBCXX_OPERATOR_DELETE(_GLIBCXX_SIZED_DEALLOC(__p, __n)); | ^

09:23 <d1b2> <fredzo_72653> In member function '_Tp* std::__new_allocator<_Tp>::allocate(size_type, const void*) [with _Tp = unsigned char]', inlined from 'static _Tp* std::allocator_traits<std::allocator<_Tp1> >::allocate(allocator_type&, size_type) [with _Tp = unsigned char]' at D:/a/_temp/msys64/ucrt64/include/c++/14.2.0/bits/alloc_traits.h:478:28, inlined from 'std::_Vector_base<_Tp, _Alloc>::pointer std::_Vector_base<_Tp,

09:23 <d1b2> _Alloc>::_M_allocate(std::size_t) [with _Tp = unsigned char; _Alloc = std::allocator<unsigned char>]' at D:/a/_temp/msys64/ucrt64/include/c++/14.2.0/bits/stl_vector.h:380:33, inlined from 'void std::vector<_Tp, _Alloc>::reserve(size_type) [with _Tp = unsigned char; _Alloc = std::allocator<unsigned char>]' at D:/a/_temp/msys64/ucrt64/include/c++/14.2.0/bits/vector.tcc:79:33, inlined from 'void HIDInstrument::SendReport(uint8_t,

09:23 <d1b2> std::vector<unsigned char>*)' at D:/a/scopehal-apps/scopehal-apps/lib/scopehal/HIDInstrument.cpp:81:17: D:/a/_temp/msys64/ucrt64/include/c++/14.2.0/bits/new_allocator.h:151:55: note: returned from 'void* operator new(std::size_t)' 151 | return static_cast<_Tp*>(_GLIBCXX_OPERATOR_NEW(__n * sizeof(_Tp))); | ^ cc1plus.exe: all warnings being treated as errors

09:23 <d1b2> <fredzo_72653> See here: https://github.com/fredzo/scopehal-apps/actions/runs/11418790318/job/31772642337

11:21 <_whitenotifier-4> [scopehal] fredzo opened pull request #919: Hid transport support - https://github.com/ngscopeclient/scopehal/pull/919

11:28 <_whitenotifier-4> [scopehal-docs] fredzo opened pull request #91: Hid transport support - https://github.com/ngscopeclient/scopehal-docs/pull/91

11:29 <_whitenotifier-4> [scopehal-apps] fredzo opened pull request #786: Hid transport support - https://github.com/ngscopeclient/scopehal-apps/pull/786

11:34 <d1b2> <fredzo_72653> @azonenberg here are the 4 PR for HID transport + Alientek DP100 driver: https://github.com/ngscopeclient/xptools/pull/30 https://github.com/ngscopeclient/scopehal/pull/919 https://github.com/ngscopeclient/scopehal-docs/pull/91 https://github.com/ngscopeclient/scopehal-apps/pull/786 Sorry the last one conflicts with your latest commit, but I think it's just only due to references to submodules that I had to update to test CI builds.

11:47 <d1b2> <azonenberg> ok i have quite the pile of stuff to review

11:48 <d1b2> <azonenberg> first things first, i need to merge the new round of icons

17:43 <d1b2> <fredzo_72653> @azonenberg for HID transport, the connection path is <vendorId>:<productId> which is not very user friendly... I was thinking about adding a GetDefaultConnectionPath() method to Instrument API that we could use in AddInstrumentDilaog to pre-fill the Path input. What do you think ? It could be used for other instrument/transports too e.g. to prefill TCP port for instruments that don't use the default 5025 SCPI port like Rigol that use

17:43 <d1b2> 5555.

23:24 <d1b2> <azonenberg> so first off, for HID you'd want to support >1 instruments

23:24 <d1b2> <azonenberg> vid:pid:index or something

23:25 <d1b2> <azonenberg> there's probably ways to do automatic device enumeration for USB that would be more useful

23:25 <d1b2> <azonenberg> but more fundamentally, the user should not care TOO much about the UX of adding a new instrument because it's something you normally only would do once when you get it

23:25 <d1b2> <azonenberg> then have it saved from there on out

23:44 <d1b2> <fredzo_72653> Yes for HID it's vid:pid:serialNumber, serial being optional and automatically grabbed from the device at first connection (so that you can connect several devices of the same model with different serial numbers).