05:42 <_whitenotifier-4> [scopehal] azonenberg opened issue #924: EyePattern: add BER data stream output - https://github.com/ngscopeclient/scopehal/issues/924

05:44 <_whitenotifier-4> [scopehal] azonenberg closed issue #896: Remove redundant "scale" filter - https://github.com/ngscopeclient/scopehal/issues/896

05:44 <_whitenotifier-4> [scopehal] azonenberg commented on issue #896: Remove redundant "scale" filter - https://github.com/ngscopeclient/scopehal/issues/896#issuecomment-2439863917

05:46 <_whitenotifier-4> [scopehal] azonenberg closed issue #798: Manage instrument creation with std::shared_ptr's - https://github.com/ngscopeclient/scopehal/issues/798

05:46 <_whitenotifier-4> [scopehal] azonenberg commented on issue #798: Manage instrument creation with std::shared_ptr's - https://github.com/ngscopeclient/scopehal/issues/798#issuecomment-2439864298

06:24 <_whitenotifier-4> [scopehal] azonenberg opened issue #925: Terminology: rename PCIe "transport" decode to PCIe "transaction" - https://github.com/ngscopeclient/scopehal/issues/925

06:35 <_whitenotifier-4> [scopehal-apps] azonenberg pushed 8 commits to master [+72/-2/±39] https://github.com/ngscopeclient/scopehal-apps/compare/8e1499773f28...e88278c4bae5

06:35 <_whitenotifier-4> [scopehal-apps] mldulaney f038965 - icons

06:35 <_whitenotifier-4> [scopehal-apps] azonenberg 6785e0d - Added PcapNGImportFilter

06:35 <_whitenotifier-4> [scopehal-apps] azonenberg a987ce6 - Merge branch 'master' of github.com:mldulaney/scopehal-apps

06:35 <_whitenotifier-4> [scopehal-apps] ... and 5 more commits.

06:35 <_whitenotifier-4> [scopehal-apps] azonenberg closed pull request #789: icons - https://github.com/ngscopeclient/scopehal-apps/pull/789

10:28 <laminar-oss> azonenberg: the commit 'Fix socket error for slow devices' (4c81219) I made for xptools is not working/nonsense. The correct logic would be 'if((x < 0) && ((errno == EINTR) || (errno == EAGAIN)))'. I'm working on a fix, but have noticed issues with the timeout. I belive the intension is to have a timeout of 5s but on my machine (x86_64/archlinux) it is 200s.

10:29 <azonenberg> Ok please keep debugging

10:29 <azonenberg> Realistically, my experience is that timeouts are typically a sign that either firmware has crashed, the session has desynchronized (the scope didn't return a response to a command, or returned a response where one was not expected), or you've lost connectivity outright

10:29 <azonenberg> and they are typically non-recoverable

10:30 <laminar-oss> yes I noticed.

10:31 <azonenberg> So i want timeouts long enough to handle any realistic high latency VPN etc - a second or two is probably enough, 5 conservative

10:31 <azonenberg> but not longer than that

10:32 <azonenberg> And long term, i want a fallback in which when we get an unrecoverable failure, we can transition the instrument into an offline one

10:32 <azonenberg> Doing this is nontrivial, it's not going to happen in time for v0.1

10:32 <laminar-oss> If I got it rigth the used api (clock) is related to used cpu time, but I think an absolute timing should is desired (time_create(), ....)

10:32 <azonenberg> but i want to be able to just grab my laptop and go home from the office and have my session still open. still able to navigate previously acquired data

10:33 <azonenberg> then go in the next day and resume

10:33 <azonenberg> hmm, yeah thats not something i have any familiarity with

10:33 <azonenberg> CLOCK_REALTIME should be wall clock time

10:41 <laminar-oss> Ah thanks for the CLOCK_REALTIME hint, found clock_gettime() and these are even available for posix systems. Much easier than timer_create/time_gettime.

10:42 <Darius> AFAIk CLOCK_REALTIME can move if NTP steps your clock

10:43 <Darius> you probably want CLOCK_MONOTONIC although in practise it probably makes no difference

10:47 <azonenberg> laminar-oss: We have a GetTime() helper function, i forget if in xptools or scopehal proper

10:47 <laminar-oss> I will look into it.

10:47 <azonenberg> that wraps clock_gettime() as well as the windows equivalent

10:47 <azonenberg> we use it for e.g. measuring how long a filter took to run

10:48 <Darius> Windows is POSIX compliant, shouldn't it have clock_gettime? :)

10:49 <azonenberg> Not that i've seen

11:05 <Darius> what a PITA

11:21 <d1b2> <azonenberg> Also, quick update: We now have 199 filters, of which 162 have at least first-draft icon artwork and 37 have none

11:21 <d1b2> <azonenberg> https://cdn.discordapp.com/attachments/776941750291267595/1300056754268278784/all-filters5.png?ex=671f73b4&is=671e2234&hm=347027f077bf4cc2ce2522a00d95da3ef2b233fe71baead24712d7d4804c66b5&

11:22 <azonenberg> I'll be doing at least one more round of feedback to the artist in the near-ish future, but we should probably work on getting more comprehensive plans for artwork WRT which icons we think are good as-is, which need work

11:23 <azonenberg> which should be priorititzed in terms of "look the worst"

11:23 <azonenberg> or "are most confusing"

11:23 <azonenberg> and concrete suggestions to improve those we don't like

11:24 <azonenberg> and then i'm going to spend some time trying to test out each filter, make a demo graph to use each

11:24 <azonenberg> work on documenting them, test them

11:24 <azonenberg> i may temporarily disable a few like "parallel bus" which are not functional without more work

11:33 <azonenberg> In general, any broken / buggy functionality should be disabled for the release build

11:33 <azonenberg> and what remains should be tested as aggressively as we can

13:06 <laminar-oss> @azonenberg: MR is availlable for xptools. The Timeout of 5s is hardcoded in SCPISocketTransport.cpp wich would require another MR for that lib.

13:07 <azonenberg> ok i'll have a look in a bit

13:09 <laminar-oss> No big deal, I'm just wondering whether a configuration would make more sense.

13:15 <azonenberg> yeah eventually we should add a preference for it but it's low priority