00:03 <azonenberg> ok

00:03 <azonenberg> There is not currently, no. It'd be trivial to call the API with 0 as the argument. there's just not a gui function for that

00:03 <azonenberg> lots of little gui tweaks would be nice but i'm one person :p

00:03 <azonenberg> And so far other than katharina's preference stuff, the UI is basically all me

00:04 <azonenberg> i've got contributions from lots of people to libscopehal

00:04 <azonenberg> but very little on glscopeclient

00:19 <d1b2> <mubes> Yeah, there are a few things that would be cool to have in the GUI....a collect from scope button to grab whatever is already in the scopes sample buffers (rather than a fresh grab) would be cool too. Trouble is the folks who use this stuff aren't generally the folks who can hack on it.

00:21 <azonenberg> Yeah

00:22 <azonenberg> meanwhile i eat my own dog food, i use glscopeclient at $dayjob on a routine basis

00:22 <azonenberg> but the features i implement are those that i use at work or on my high-end FPGA projects

00:22 <azonenberg> since i have limited time and focus on what i need personally

07:28 <d1b2> <mubes> Well, I'll do what I can, but unfortunately I'm in the same situation...once it does enough to solve $problem (in this case long SWD captures for orbuculum) then I'm afraid the scheduling priority decreases. I see you folded those changes into master...what was the problem, for future reference?

07:31 <azonenberg> what was which problem?

07:45 <d1b2> <mubes> The tabs Vs spaces thing

07:47 <azonenberg> oh

07:47 <azonenberg> let me look at the diff

07:47 <azonenberg> SCPISocketTransport.*, SCPITransport.*

07:47 <azonenberg> at least

07:48 <azonenberg> look to have spaces in all of the edited indentation

07:48 <azonenberg> https://github.com/azonenberg/scopehal/pull/402/files

07:48 <azonenberg> same with UartTrigger.*

07:51 <d1b2> <mubes> It's odd, they don't have on my side. I'll look into it today. I need to remove those statically allocated blobs at least, they're embarrassing.

09:03 <azonenberg> yeah i havent actually pulled your fork and looked at the files clientside

09:03 <azonenberg> possible github's render is doing something funky

09:03 <azonenberg> i havent checked

18:01 <bvernoux> I have just built latest glscopeclient

18:01 <bvernoux> and it work fine on Windows7

18:01 <bvernoux> just a remark there is tons of warnings with Mingw64

18:02 <bvernoux> also the demo in release is quite fast on my old CoreI7+GeForce GT 650M ;)

18:02 <bvernoux> anout 18 to 20WFM/s

21:04 <d1b2> <mubes> @azonenburg Just pulled my version of the xptools repository and it's got tabs in Socket.cpp correctly....could it be something in the way you're pulling the patch in?

23:01 <azonenberg> mubes: xptools was fine

23:01 <azonenberg> i merged that to mainline already

23:01 <azonenberg> it was only some of the files in scopehal you changed that had issues

23:02 <d1b2> <mubes> OK. Found a couple of hiccups in the scopehal anyway, so don't do anything with that in any case! For some reason my timebase is a factor of 10 out. I find it incredible that on a 1K scope I can do a 100Mpoint 4 channel sample! Well, I would be able to if I didn't have this bug...

23:06 <azonenberg> factor of 10 is interesting, 1000 would make sense if it was older code that wasnt correctly updated from ps to fs time units

23:08 <d1b2> <mubes> Found it. There's a maximum transfer limit of 10Mpoints (presumably down to buffers), so you have to do 10x10Mpoint transfers to get the lot...or 20x10Mpoint if you've got two channels enabled. For this initial version I'll just set an upper sample limit of 10Mpoints...it's painful enough to transfer that amount of data as it is!

23:38 <azonenberg> Yeah. File a ticket for >10M point capture support and we'll add it later? I do want it on record as a known missing feature

23:40 <_whitenotifier-5> [scopehal] mubes synchronize pull request #402: Changes to support SDS2000+ scope - https://git.io/JYiAM

23:41 <d1b2> <mubes> There's a shed load of work I still need to do on this...I'll make an inventory of outstanding stuff before I drop it

23:45 <azonenberg> Ok. Ping me when it's ready to review

23:50 <d1b2> <mubes> Well, it's very alpha...it really depends on what state of cooked you want before stuff goes into the primary repository. Have a look at the PR when you're ready and pass comment on the more egregious failings and I'll fix those up so it can come in...or we can at least note them. Hopefully there are no tab/space issues now...