<_whitenotifier-e>
[scopehal-docs] bgianfo 8170e70 - Disable line numbering for listings that will be copy/pasted. The line numbering for the listings that are expected to be copy/pasted make things awkward to interact with and make the installation / getting started a bit frustrating. This is especially true for multi line commands which are common in the getting started section. By disabling the line numbering,
<_whitenotifier-e>
[scopehal-docs] azonenberg bcf0dc3 - Merge pull request #39 from bgianfo/fix-copy-paste Disable line numbering for listings that will be copy/pasted.
<_whitenotifier-e>
[scopehal] 602p d245f36 - Fix memory leak when discarding captures to avoid long queues in DSLabs driver
<_whitenotifier-e>
[scopehal] azonenberg 31c7274 - Merge pull request #602 from 602p/dsl_leak_fix Fix memory leak when discarding captures to avoid long queues in DSLabs driver
<azonenberg>
@louis: with lecroy as soon as i turned on the count of buffered waveforms, it hangs
<azonenberg>
investigating
<d1b2>
<louis> As in when you open the diag window, or as in when you graph it?
<d1b2>
<louis> It calls GetPendingWaveformCount which takes m_pendingWaveformsMutex ... deadlock with trying to acquire that in AcquireData?
<azonenberg>
No, graph scale increment got set to zero
<azonenberg>
infinite loop
<azonenberg>
fix coming shortly
<azonenberg>
There's some really interesting trends visible in the data
<azonenberg>
like for example, if you pan around the display aggressively while acquiring
<azonenberg>
you can bog down the ui in rendering
<azonenberg>
causing waveforms to back up in the queue
<azonenberg>
then they flush out over the next few seconds
<azonenberg>
@louis: anyway, this confirms what i already knew
<azonenberg>
the picoscope maxes out my 20 waveform queue
<azonenberg>
and then i think the driver keeps on shoving data into the socket buffer until the socket blocks
<azonenberg>
how far are you from being able to refactor your flow control code into something we can move to the other bridge-based scope drivers?
bvernoux has joined #scopehal
<electronic_eel>
azonenberg: about your dns and nat question on twitter
<electronic_eel>
i suggest using dnsmasq and it's "--alias" option
<electronic_eel>
it allows you to remap dns answers that match a specific ip netmask to another net
<electronic_eel>
so you tell your local dns to use that dnsmasq instance for dns lookup of that natted vpn domain. all other dns queries from your local net continue to go to your regular local dns.
<azonenberg>
yep thats the idea
<azonenberg>
basically any time i look up a $dayjob FQDN it needs to remap the IP from 10.x to 10.y
<azonenberg>
and then the 1:1 nat does the same
<electronic_eel>
that kind of setup should work pretty well. i have a few customers that use a similar setup, because grown infrastructure and such
<azonenberg>
yeah. basically my problem is i have >100 hosts on this network, a ton of static IPs on over a dozen subnets
<azonenberg>
and renumbering it all to avoid colliding with hosts at work would be a giant pain
<electronic_eel>
yeah. so do this 1:1 nat on the vpn, then the 1:1 nat for dns using dnsmasq and it should be fine
<azonenberg>
Yep
<azonenberg>
that was the idea. i just wasnt sure what tool to use for the dns remapping
<electronic_eel>
should you ever get stuck creating the iptables rules for the nat, i suggest using the TRACE target of iptables
<azonenberg>
I'll give dnsmasq a look
bvernoux has quit [Quit: Leaving]
<azonenberg>
Got bit *again* by not clearly naming pipeline registers with the stage number