fa-mlat-client 0.2.4 crashes on local airspy_adsb (new version with beast this time)

Opened a new issue as there is a new version by @touil with beast support (-f beast) here http://airspy.com/downloads/airspy_adsb-linux-arm-beast.tgz
The stream is pushing 20MHz MLAT, could that give the issues below ?
mlat(7442): Problem reading receiver messages: Out of range timestamp seen (last<PHONE_NUMBER>, now 553222221)
02/17/2016 22:07:42 mlat(7442): Traceback (most recent call last):
02/17/2016 22:07:42 mlat(7442):   File "/usr/lib/python3.2/asyncore.py", line 83, in read
02/17/2016 22:07:42 mlat(7442):   File "/usr/lib/python3.2/asyncore.py", line 449, in handle_read_event
02/17/2016 22:07:42 mlat(7442):   File "/tmp/buildd/piaware-2.1/debian/venv/lib/python3.2/site-packages/mlat/client/receiver.py", line 129, in handle_read
02/17/2016 22:07:42 mlat(7442): ValueError: Lost sync with input stream: expected 0x1A after 0x1A escape
maybe issue like : mutability/mlat-client#1

cross posting from the old closed ticket:
@mutability says:
I think it is generating the timestamps as little-endian; they should be big-endian.
ping  @touil

The traceback indicates there might be a problem with the stream framing, too. I'd need to see the raw bytes to be sure.
20MHz means it won't work out-of-the-box with mlat-server. mlat-client should be mostly OK with it, but mlat-server will just never manage to get any sync with other receivers because the timing will be way off. I can add a new receiver type to mlat-client if it's always going to be 20MHz, but a simpler approach might be to make beast-format actually look like a Beast i.e. produce a 12MHz timestamp.

new version fixes the endian issue (http://airspy.com/?ddownload=3753) but still this error:
02/17/2016 22:43:41 mlat(8338): Unexpected exception on connection to localhost:30005
02/17/2016 22:43:41 mlat(8338): Traceback (most recent call last):
02/17/2016 22:43:41 mlat(8338):   File "/usr/lib/python3.2/asyncore.py", line 83, in read
02/17/2016 22:43:41 mlat(8338):   File "/usr/lib/python3.2/asyncore.py", line 449, in handle_read_event
02/17/2016 22:43:41 mlat(8338):   File "/tmp/buildd/piaware-2.1/debian/venv/lib/python3.2/site-packages/mlat/client/receiver.py", line 129, in handle_read
02/17/2016 22:43:41 mlat(8338): ValueError: Lost sync with input stream: expected 0x1A after 0x1A escape
indeed might help to either default 12 MHZ for beast streams or add parameter to select this (in airspy_adsb)

May be I'm not sending something? what's the  sequence for?

The Beast format is originally a serial data format where you might start mid-packet, so it does the equivalent of DLE-stuffing with 1A characters to make it easier to scan for a packet start. See http://wiki.modesbeast.com/Mode-S_Beast:Data_Output_Formats. If you need to send a 1A byte within the body of the message, then it should be sent as 1A 1A.

Does it apply to the timestamp as well?

Yes, it applies to everything. The only un-doubled 1A is the very first byte.

OK. Got it and fixing. Thanks.

Looks fine now.

looks like we have a winner! i'll keep it running overnight, no errors so far.
thanks !

Now that the Beast format is implemented, we will have a firmware update that allows 12MHz MLAT. Stay tuned!

It would be fine to run at whatever rate you want and rescale that clock to 12MHz just for the Beast output. mlat-server just ends up scaling it by the clock frequency anyway. ADS-B based synchronization between receivers only gives about 0.5-1us accuracy so the rounding errors from rescaling aren't a big deal.

FYI. There will be another (cheaper) Airspy Mini device with can run at 12MSPS directly, so rescaling might be a good option to keep things simple.
In the other hand, I can add the re-scaling into the decoder itself and still get the nominal resolution at +/- 1 sample so there will be no degradation.
Home work for tonight!

After running the new version for a few hours, its pretty stable, however it seems the mlat-client doesn't sync with other nearby servers (and yes there are several nearby)
02/18/2016 12:26:35 mlat(712): Receiver status: connected
02/18/2016 12:26:35 mlat(712): Server status:   not synchronized with any nearby receivers
02/18/2016 12:26:35 mlat(712): Receiver:  803.3 msg/s received     15.7kB/s from receiver
02/18/2016 12:26:35 mlat(712): Server:      0.0 kB/s from server    0.0kB/s TCP to server   2.1kB/s UDP to server
02/18/2016 12:26:35 mlat(712): Aircraft: 17 of 32 Mode S, 33 of 71 ADS-B used

That's expected. The MLAT is almost twice as fast in Airspy. Watch out for tonight's version.

Everything is implemented and working as expected.

Getting closer but:
02/18/2016 22:31:20 mlat(5320): Receiver status: connected
02/18/2016 22:31:20 mlat(5320): Server status:   clock unstable
02/18/2016 22:31:20 mlat(5320): Receiver:  383.4 msg/s received      7.5kB/s from receiver
02/18/2016 22:31:20 mlat(5320): Server:      0.0 kB/s from server    0.0kB/s TCP to server   0.8kB/s UDP to server
02/18/2016 22:31:20 mlat(5320): Aircraft: 2 of 9 Mode S, 19 of 31 ADS-B used

Yeah, definitely something wrong with the timing here.
The server takes pairs of even/odd DF17 position messages and pairs them up based on message contents + the interval between the messages. The message interval has to be within 1ms of the interval seen by other receivers, and they are sufficiently close that it's getting past that check. However after correcting for propagation delay from the aircraft to each receiver, the intervals disagree by a lot - 200ppm or more, and they jump around a lot.

Are you sure you are using v1.3?

Yup, just downloaded:
airspy_adsb v1.3

May be it's the scaling code. Basically ts_12MHz = (ts_20MHz * 12 + 20 / 2) / 20. It should be fine within 1 sample

I can't see anything obviously wrong with that scaling. Are you confident of the underlying timestamp?

I have turned on a little more debugging on the server side so I can see the actual differences in intervals, but the client reconnected at around 0130 UTC and seems to have changed behaviour at that point, now it's back to not even passing the 1ms test.

I updated the RPi build if someone want to give it a try.

uhm, now it goes back to the "old" message:
02/19/2016 14:14:57 mlat(19379): Receiver status: connected
02/19/2016 14:14:57 mlat(19379): Server status:   not synchronized with any nearby receivers
02/19/2016 14:14:57 mlat(19379): Receiver:  659.8 msg/s received     12.9kB/s from receiver
02/19/2016 14:14:57 mlat(19379): Server:      0.0 kB/s from server    0.0kB/s TCP to server   1.6kB/s UDP to server

@mutability Can you check the server side?

@jester-xbmc: This is for mac address b8:27:eb:50:0a:97 right?
@touil:
20160219 14:40:23.191 master INFO     clocktrack           interval out of range,<PHONE_NUMBER>us vs 1449631.0000us
20160219 14:40:23.193 master INFO     clocktrack           interval out of range,<PHONE_NUMBER>us vs 1010058.7500us
20160219 14:40:23.194 master INFO     clocktrack           interval out of range, 1460863.9167us vs 2104718.2500us
20160219 14:40:23.282 master INFO     clocktrack           interval out of range, 1048143.4167us vs 1520012.0006us
20160219 14:40:23.289 master INFO     clocktrack           interval out of range,<PHONE_NUMBER>us vs 1070821.6667us
20160219 14:40:23.312 master INFO     clocktrack           interval out of range,<PHONE_NUMBER>us vs 1070824.7500us
20160219 14:40:23.330 master INFO     clocktrack           interval out of range, 1048143.4167us vs 1520040.5000us
20160219 14:40:23.339 master INFO     clocktrack           interval out of range,<PHONE_NUMBER>us vs 1056890.3333us
20160219 14:40:23.517 master INFO     clocktrack           interval out of range,<PHONE_NUMBER>us vs<PHONE_NUMBER>us
20160219 14:40:23.584 master INFO     clocktrack           interval out of range,<PHONE_NUMBER>us vs<PHONE_NUMBER>us
20160219 14:40:23.673 master INFO     clocktrack           interval out of range,<PHONE_NUMBER>us vs<PHONE_NUMBER>us
20160219 14:40:23.692 master INFO     clocktrack           interval out of range,<PHONE_NUMBER>us vs<PHONE_NUMBER>us
20160219 14:40:23.693 master INFO     clocktrack           interval out of range, 1999907.2500us vs 2869857.5000us
20160219 14:40:23.695 master INFO     clocktrack           interval out of range,<PHONE_NUMBER>us vs<PHONE_NUMBER>us
20160219 14:40:23.696 master INFO     clocktrack           interval out of range, 1843207.2500us vs 2659225.5001us

Lefthand numbers are intervals as measured by the airspy, righthand are intervals as measured by other receivers that it's trying to match to. There's no particularly consistent factor there I can see. Note that some of them may be real mismatches (trying to match up transmission times that aren't for the same messages, this can happen when an identical position message is sent at different times)

@mutability correct.

when running with /airspy_adsb -l 30005 -f beast -b -g 21 -p -d 2 -w 4
i'm getting MLAT data packets...

this means there were packet drops

Whatever you changed when you reconnected at 1515 brought the inter-message intervals back into range and the frequency offset numbers look sensible. Now the server reckons your clock is unstable because it sees periodic large jumps in the absolute clock offset:
20160219 15:16:04.897 master INFO     clocksync            fAT-b827eb280072_000084:fAT-b827eb500a97_000162: fAT-b827eb500a97_000162 clock was 142547.7us slower than predicted, drift error -0.8ppm

which if you were running dump1090 would mean that you were losing large chunks of samples before they reached dump1090 itself. (dump1090 will jump the timestamp forward if it drops a block of samples due to overload, but in extreme overload cases the USB subsystem can start dropping data too). I guess something similar can happen with the airspy.

The threading and decimation options can help a lot here. Can you check with 4 workers?

trying various -w and -d values, however after a number of MLAT messages it stills, clock drift ? packet loss ?

Packets are being dropped.

I'll optimize libairspy for the RPi. More efficient unpacking to come. Stay tuned!

@mutability Anything worth mentioning in the server side?

piping airspy_adsb output through modesmixer gives unstable results, 15 minutes of clock unstable and then 15 minutes of "normal" running
02/20/2016 16:00:50 mlat(698): Receiver status: connected
02/20/2016 16:00:50 mlat(698): Server status:   synchronized with 126 nearby receivers
02/20/2016 16:00:50 mlat(698): Receiver:  682.2 msg/s received     12.7kB/s from receiver
02/20/2016 16:00:50 mlat(698): Server:      0.7 kB/s from server    0.0kB/s TCP to server   2.4kB/s UDP to server
02/20/2016 16:00:50 mlat(698): Results:  331.0 positions/minute
02/20/2016 16:00:50 mlat(698): Aircraft: 14 of 28 Mode S, 25 of 55 ADS-B used
02/20/2016 16:04:32 33242 msgs recv'd from modesmixer2 (1228 in last 5m); 32602 msgs sent to FlightAware
02/20/2016 16:09:32 34592 msgs recv'd from modesmixer2 (1350 in last 5m); 33952 msgs sent to FlightAware
02/20/2016 16:14:32 35992 msgs recv'd from modesmixer2 (1400 in last 5m); 35352 msgs sent to FlightAware
02/20/2016 16:15:51 mlat(698): Receiver status: connected
02/20/2016 16:15:51 mlat(698): Server status:   clock unstable
02/20/2016 16:15:51 mlat(698): Receiver:  736.3 msg/s received     13.7kB/s from receiver
02/20/2016 16:15:51 mlat(698): Server:      0.7 kB/s from server    0.0kB/s TCP to server   2.1kB/s UDP to server
02/20/2016 16:15:51 mlat(698): Results:  331.7 positions/minute
02/20/2016 16:15:51 mlat(698): Aircraft: 16 of 28 Mode S, 29 of 63 ADS-B used

What do you mean by "stalls reading directly from airspy_adsb"?

Note that the server status: is just a snapshot of the latest status reported; it only tells you something about the approx 30 second period before the report.

Is there any mechanism to compensate for packet losses? This can happen frequently with non real time kernels in tight hardware like the RPI.

airspy_adsb -> fa-mlat-client stops "working" after about 5 minutes and server status gives clock unstable, stop working meaning to packets are given back to me (i'm monitoring using -mlatResultsFormat "basestation,listen,31003" to VRS)
with airspy_adsb -> modesmixer -> fa-mlat-client it keeps working, but still gives clock unstable

@mutability Need an airspy? ;-)

@jester-xbmc: that's probably just luck more than anything. The server tracks how "bad" the instability of a receiver is; over time if a receiver consistently produces unreliable results then it will trust it less and less; past a certain point it stops requesting data for mlat entirely (it keeps taking ADS-B data so it can check if the synchronization fixes itself). There is hysteresis there so once the receiver is inhibited like this, it has to produce good results for quite a long time before it gets turned back on again. Once a receiver is inhibited it's not contributing to mlat so it stops receiving results.

@touil: The server relies on the timestamp sequence being a continuous sequence, and being approximately the same frequency in the short term. If you drop samples and do not adjust your timestamp to compensate, then that looks to the server like the clock stopped for a while. It will handle this, after enough out of range values are seen it decides they were not just spurious outliers and starts using the new values, but that also flags the clock as unstable. If it happens often enough then the server stops using the receiver's data because it can't be sure the clock is predictable.
dump1090 has a couple of threads: a read thread that's doing the basic USB work via librtlsdr, and the main thread that's running the demodulator etc. Most of the CPU goes in the main thread. They communicate via a fixed-side FIFO of sample buffers. If the read thread needs to hand off a new sample buffer but finds the FIFO is full, then it drops the buffer, but importantly it still increments the timestamp. So in the "mild overload" case where the demodulator is not keeping up, but the read thread still gets enough CPU to at least copy the data out from USB, this avoids having the dropped buffer cause a jump in the timestamps. Once things get overloaded to the point where the read thread can't even keep up with USB, that doesn't help though.
See https://github.com/mutability/dump1090/blob/master/dump1090.c#L438 (which notices the FIFO is full and starts dropping data until it's at least half-empty) and https://github.com/mutability/dump1090/blob/master/dump1090.c#L450 ("outbuf->dropped" is the number of samples that were dropped between the last buffer that was processed and the current buffer)
Does airspy_adsb proactively drop samples when it finds it is overloaded? If so, does it adjust the timestamp for the missed samples?

Samples can be dropped in the RTL chip as well. Not whole buffers, but a few samples occasionally when the host computer fails to process the transfer for any given reason. These drops are much harder to track then the ones in the driver.
For airspy, we have counters both in the device side and the host side. It just requires some work.

Sure, I see exactly that behaviour where small numbers of samples are dropped in bursts (on the order of a few tens or hundreds of samples). There are a few long threads on the flightaware forums about it; it's the #1 cause of clock instability and it is very dependent on the exact setup (the particular dongle, Pi, USB cabling, ambient temperature..)
In practice it is infrequent enough that usually it only makes the receiver drop out for 30 seconds at a time, infrequently. The only case I've seen it be a real problem is with someone with a really long cheap USB cable.
However, this is not the behaviour I see with the airspy data: the airspy receiver is jumping by 100s of milliseconds (see my comment above), that's got to be a whole sample buffer or something similar, not just a failed USB transfer.

That's normal. I didn't implement them yet.

Just for reference: its a pi2, with a fresh jessie light OS, running just the airspy, powersupply is official raspberry one, standard 1 meter USB cable that came with the airspy, added one extra clamp ferrite, temp. around 19 C, same setup runs fine with rtl-sdr.

I took a look at todays logs and it's currently seeing quite a lot of 4.9ms jumps which is different to what it was doing before:
20160220 02:09:33.485 master INFO     clocksync            fAT-0024d692b410_000172:fAT-b827eb500a97_000216: fAT-b827eb500a97_000216 clock was 4915.3us slower than predicted, drift error 0.1ppm
20160220 03:02:54.682 master INFO     clocksync            fAT-000c29d5f76e_000071:fAT-b827eb500a97_000216: fAT-b827eb500a97_000216 clock was 4914.9us slower than predicted, drift error 0.2ppm
20160220 03:03:15.250 master INFO     clocktrack           Inhibiting receiver fAT-b827eb500a97_000216 (stage 1: don't use mlat data)
20160220 03:07:45.237 master INFO     clocktrack           Uninhibiting receiver fAT-b827eb500a97_000216
20160220 03:10:20.460 master INFO     clocksync            fAT-000c29d5f76e_000071:fAT-b827eb500a97_000216: fAT-b827eb500a97_000216 clock was 4915.5us slower than predicted, drift error 0.2ppm
20160220 03:10:47.677 master INFO     clocktrack           Inhibiting receiver fAT-b827eb500a97_000216 (stage 1: don't use mlat data)
20160220 03:17:55.623 master INFO     clocktrack           Uninhibiting receiver fAT-b827eb500a97_000216
20160220 03:47:44.515 master INFO     clocksync            fAT-000c29d5f76e_000071:fAT-b827eb500a97_000216: fAT-b827eb500a97_000216 clock was 4915.1us slower than predicted, drift error 0.2ppm
20160220 03:48:00.665 master INFO     clocktrack           Inhibiting receiver fAT-b827eb500a97_000216 (stage 1: don't use mlat data)
20160220 03:50:05.100 master INFO     clocktrack           Uninhibiting receiver fAT-b827eb500a97_000216
20160220 03:50:24.153 master INFO     clocksync            fAT-063e380017dc_000102:fAT-b827eb500a97_000216: fAT-b827eb500a97_000216 clock was 4915.2us slower than predicted, drift error -0.5ppm
20160220 03:50:36.257 master INFO     clocktrack           Inhibiting receiver fAT-b827eb500a97_000216 (stage 1: don't use mlat data)
20160220 03:57:21.593 master INFO     clocktrack           Inhibiting receiver fAT-b827eb500a97_000216 (stage 2: disable mlat data feed)

(and it didn't recover until a reconnect)
Anything magic about that 4915us value? (It is a little under 100k samples at 20MHz)

OKI. Let's give it a try.
static int rx_callback(airspy_transfer_t* transfer) { 	adsb_parser_advance(transfer->ctx, transfer->dropped_samples); 	adsb_parser_process(transfer->ctx, transfer->samples, transfer->sample_count); 	return do_exit; }

4.9ms is what I call an improvement :-) I reworked all the threading yesterday.

@mutability new version up and running, shows promise, can you check on server ?
02/20/2016 17:45:11 1882 msgs recv'd from airspy_adsb (1716 in last 5m); 1262 msgs sent to FlightAware
02/20/2016 17:50:11 3767 msgs recv'd from airspy_adsb (1885 in last 5m); 3147 msgs sent to FlightAware
02/20/2016 17:55:11 5765 msgs recv'd from airspy_adsb (1998 in last 5m); 5145 msgs sent to FlightAware
02/20/2016 17:56:33 mlat(758): Receiver status: connected
02/20/2016 17:56:33 mlat(758): Server status:   synchronized with 119 nearby receivers
02/20/2016 17:56:33 mlat(758): Receiver:  936.8 msg/s received     18.5kB/s from receiver
02/20/2016 17:56:33 mlat(758): Server:      0.6 kB/s from server    0.0kB/s TCP to server   2.4kB/s UDP to server
02/20/2016 17:56:33 mlat(758): Results:  292.3 positions/minute
02/20/2016 17:56:33 mlat(758): Aircraft: 19 of 45 Mode S, 40 of 95 ADS-B used

It is stable enough that it works, but I still see it dropping multiples of 4.9ms from time to time:
20160220 18:30:38.973 master INFO     clocksync            fAT-0024d692b410_000172:fAT-b827eb500a97_000327: fAT-b827eb500a97_000327 clock was 39322.2us slower than predicted, drift error -0.4ppm
20160220 18:35:29.919 master INFO     clocksync            fAT-b827eb500a97_000327:fAT-b827ebba5b45_000160: fAT-b827ebba5b45_000160 clock was 9831.4us slower than predicted, drift error -0.1ppm
20160220 19:02:12.211 master INFO     clocksync            fAT-0024d692b410_000172:fAT-b827eb500a97_000327: fAT-b827eb500a97_000327 clock was 4915.3us faster than predicted, drift error -0.1ppm

Also it seems to jump in both directions sometimes (in this case, one of the messages used for sync was 4.9ms early, so the server adjusted the offset, but then the next sync point with the same peer receiver using the adjusted offset was 4.9ms late):
20160220 18:51:32.109 master INFO     clocksync            fAT-b827eb500a97_000327:fAT-b827ebd75fb6_000002: fAT-b827ebd75fb6_000002 clock was 4915.2us slower than predicted, drift error -0.4ppm
20160220 18:51:32.875 master INFO     clocksync            fAT-b827eb500a97_000327:fAT-b827ebd75fb6_000002: fAT-b827ebd75fb6_000002 clock was 4915.3us faster than predicted, drift error -0.5ppm

I wonder if it is a problem with sample blocks being processed out of order?

Let's improve that.

@mutability new version up and running, could you entertain us with another peek at the server ?
02/20/2016 21:11:00 3049 msgs recv'd from airspy_adsb (903 in last 5m); 2602 msgs sent to FlightAware
02/20/2016 21:12:33 mlat(709): Receiver status: connected
02/20/2016 21:12:33 mlat(709): Server status:   synchronized with 118 nearby receivers
02/20/2016 21:12:33 mlat(709): Receiver:  508.3 msg/s received     10.0kB/s from receiver
02/20/2016 21:12:33 mlat(709): Server:      0.1 kB/s from server    0.0kB/s TCP to server   1.2kB/s UDP to server
02/20/2016 21:12:33 mlat(709): Results:  55.3 positions/minute
02/20/2016 21:12:33 mlat(709): Aircraft: 6 of 11 Mode S, 30 of 49 ADS-B used

Mostly OK, a couple of 39.3ms (== 4.9ms*8) glitches:
20160220 21:03:44.474 master INFO     clocksync            fAT-063e380017dc_000102:fAT-b827eb500a97_000346: fAT-b827eb500a97_000346 clock was 39321.4us slower than predicted, drift error 0.4ppm
(... same offset versus lots of other receivers ...)
20160220 21:24:47.143 master INFO     clocksync            fAT-b827eb500a97_000346:fAT-b827eb6d382a_000035: fAT-b827eb6d382a_000035 clock was 39321.6us faster than predicted, drift error -0.1ppm
(... same offset versus lots of other receivers ...)

From a quick look:
You unlock the consumer_mp mutex in consumer_threadproc after decreasing the number of received buffers but before you have copied out the data you just grabbed from the FIFO, around here: https://github.com/airspy/host/blob/master/libairspy/src/airspy.c#L359
But I don't see what prevents the USB callback from reusing that buffer before you've done that copy. If the USB callback does get in first, then you end up processing samples that are FIFO-size samples "in the future" from where you think you are?
Delaying the change to received_buffer_count until after you've done the copy might work (I don't know offhand if it works out cheaper to release and reobtain the lock, or to hold the lock during the copy)

This? https://github.com/airspy/host/blob/master/libairspy/src/airspy.c#L442

But you release that lock here, before you have done the copy: https://github.com/airspy/host/blob/master/libairspy/src/airspy.c#L361

You mean this copy? https://github.com/airspy/host/blob/master/libairspy/src/airspy.c#L357

No, I mean this copy: https://github.com/airspy/host/blob/master/libairspy/src/airspy.c#L382
The sequence of events I am talking about is this (if I read the code right):
initially, assume
received_buffers_count = 8
received_samples_queue_head = 0
received_samples_queue_tail = 0
received_samples_queue[0] = some buffer B
there is a pending usb transfer callback for some buffer C
thread T1 is running in consumer_threadproc
thread T2 is running in airspy_libusb_transfer_callback
T1 acquires consumer_mp
T2 tries to acquire consumer_mp and blocks on L442
T1 sets input_samples = received_samples_queue[0] = B
T1 decrements received_buffers_count, received_buffers_count = 7,
T1 releases the lock; this preempts T1 and wakes T2
T2 acquires the lock
T2 swaps usb_transfer->buffer (C) and received_samples_queue[0] (B), now usb_transfer->buffer = B
T2 releases the lock, but doesn't get preempted
T2 submits usb_transfer to libusb
libusb submits buffer B to the kernel
the kernel fills buffer B
T1 wakes and starts processing input_samples = B, but that buffer now contains the wrong samples

I see what you mean, but the problem with that approach is a lock over a long conversion operation. It just needs another condition to skip the samples in that specific case.

Sure, that's what I mean about holding the lock vs. reobtaining it. All you need to make sure is that you don't update received_buffers_count until after the conversion is complete; you could do that via a separate acquire/decrement/release (or atomics) after the conversion is done.

It was relying on atomics before => not so portable.

There were so many people hacking that code, including myself. But by the look of it it should be fine now. 4 x eyes rules! :-)

Move the lock/unlock so the mutex is held on entry to the loop, that'd eliminate the extra acquire/release.

That's worse. It will lock on a very long operation. We are only locking on fast ones now. If it was Windows only code I'd be using InterlockedIncrement/Decrement/Exchange functions. But apparently there's nothing portable with the same semantics.

No, it will not lock on a very long operation.
lock
while (...) {
  get next buffer, pthread_cond_wait as needed
  unlock
  process buffer
  lock
  update counter to release the buffer to the usb thread
}
unlock

If you want portable atomics, use stdatomic.h (you will need C11): http://en.cppreference.com/w/c/atomic

Yes, very valid. I thought you meant a single lock/unlock inside the while block.
Btw, the code should be running since yesterday. Anything in the server side?

I rebooted due to security update installation, however yesterday latest code is running and i'm not seeing any clock unstable messages:
02/21/2016 11:37:49 17821 msgs recv'd from airspy_adsb (2083 in last 5m); 17264 msgs sent to FlightAware
02/21/2016 11:38:54 mlat(693): Receiver status: connected
02/21/2016 11:38:54 mlat(693): Server status:   synchronized with 108 nearby receivers
02/21/2016 11:38:54 mlat(693): Receiver: 1030.3 msg/s received     20.2kB/s from receiver
02/21/2016 11:38:54 mlat(693): Server:      0.6 kB/s from server    0.0kB/s TCP to server   2.1kB/s UDP to server
02/21/2016 11:38:54 mlat(693): Results:  289.4 positions/minute
02/21/2016 11:38:54 mlat(693): Aircraft: 22 of 38 Mode S, 30 of 91 ADS-B used
02/21/2016 11:42:49 19866 msgs recv'd from airspy_adsb (2045 in last 5m); 19309 msgs sent to FlightAware
02/21/2016 11:47:49 21788 msgs recv'd from airspy_adsb (1922 in last 5m); 21231 msgs sent to FlightAware
02/21/2016 11:52:49 23723 msgs recv'd from airspy_adsb (1935 in last 5m); 23166 msgs sent to FlightAware
02/21/2016 11:53:54 mlat(693): Receiver status: connected
02/21/2016 11:53:54 mlat(693): Server status:   synchronized with 112 nearby receivers
02/21/2016 11:53:54 mlat(693): Receiver:  947.5 msg/s received     18.7kB/s from receiver
02/21/2016 11:53:54 mlat(693): Server:      0.5 kB/s from server    0.0kB/s TCP to server   1.9kB/s UDP to server
02/21/2016 11:53:54 mlat(693): Results:  247.4 positions/minute
02/21/2016 11:53:54 mlat(693): Aircraft: 16 of 36 Mode S, 36 of 87 ADS-B used

Still seems to occasionally drop or misorder data:
20160221 14:45:09.479 master INFO     clocksync            fAT-b827eb2ca9e0_000040:fAT-b827eb500a97_000398: fAT-b827eb500a97_000398 clock was 9830.2us faster than predicted, drift error -0.1ppm
20160221 14:45:09.687 master INFO     clocksync            fAT-b827eb500a97_000398:fAT-b827ebf76967_000142: fAT-b827ebf76967_000142 clock was 4915.3us slower than predicted, drift error -0.2ppm
20160221 14:45:09.816 master INFO     clocksync            fAT-b827eb500a97_000398:fAT-b827ebd75fb6_000002: fAT-b827ebd75fb6_000002 clock was 9830.3us slower than predicted, drift error 0.1ppm
20160221 14:45:11.499 master INFO     clocksync            fAT-b827eb2ca9e0_000040:fAT-b827eb500a97_000398: fAT-b827eb500a97_000398 clock was 9830.1us slower than predicted, drift error -0.4ppm
20160221 14:45:11.588 master INFO     clocksync            fAT-b827eb500a97_000398:fAT-b827ebf76967_000142: fAT-b827ebf76967_000142 clock was 4915.8us faster than predicted, drift error -0.0ppm
20160221 14:45:11.687 master INFO     clocksync            fAT-b827eb500a97_000398:fAT-b827ebd75fb6_000002: fAT-b827ebd75fb6_000002 clock was 9830.6us faster than predicted, drift error 0.2ppm

20160221 14:47:12.886 master INFO     clocksync            fAT-b827eb500a97_000398:fAT-b827eba584f9_000114: fAT-b827eba584f9_000114 clock was 9830.2us slower than predicted, drift error -0.1ppm
20160221 14:47:12.944 master INFO     clocksync            fAT-b827eb2ca9e0_000040:fAT-b827eb500a97_000398: fAT-b827eb500a97_000398 clock was 14745.1us faster than predicted, drift error -0.1ppm
20160221 14:47:13.013 master INFO     clocksync            fAT-b827eb4f7376_000177:fAT-b827eb500a97_000398: fAT-b827eb500a97_000398 clock was 9829.9us faster than predicted, drift error -0.0ppm
20160221 14:47:13.401 master INFO     clocksync            fAT-b827eb3c0752_000126:fAT-b827eb500a97_000398: fAT-b827eb500a97_000398 clock was 4915.9us faster than predicted, drift error 0.0ppm
20160221 14:47:13.625 master INFO     clocksync            fAT-0024d692b410_000172:fAT-b827eb500a97_000398: fAT-b827eb500a97_000398 clock was 4916.1us faster than predicted, drift error -0.1ppm
20160221 14:47:14.227 master INFO     clocksync            fAT-b827eb500a97_000398:fAT-b827ebbbe72c_000416: fAT-b827ebbbe72c_000416 clock was 4915.8us slower than predicted, drift error 0.3ppm
20160221 14:47:14.228 master INFO     clocksync            fAT-b827eb500a97_000398:fAT-b827ebf76967_000142: fAT-b827ebf76967_000142 clock was 4915.3us slower than predicted, drift error 0.3ppm
20160221 14:47:14.300 master INFO     clocksync            fAT-b827eb500a97_000398:fAT-b827eb71d588_000158: fAT-b827eb71d588_000158 clock was 4915.4us slower than predicted, drift error 0.2ppm
20160221 14:47:14.397 master INFO     clocksync            fAT-b827eb500a97_000398:fAT-b827ebd75fb6_000002: fAT-b827ebd75fb6_000002 clock was 9830.3us slower than predicted, drift error 0.5ppm
20160221 14:47:14.432 master INFO     clocksync            fAT-b827eb500a97_000398:fAT-b827eb6b68d8_000021: fAT-b827eb6b68d8_000021 clock was 9829.7us slower than predicted, drift error -0.0ppm
20160221 14:47:15.820 master INFO     clocksync            fAT-b827eb2ca9e0_000040:fAT-b827eb500a97_000398: fAT-b827eb500a97_000398 clock was 9830.9us slower than predicted, drift error 0.0ppm
20160221 14:47:15.821 master INFO     clocksync            fAT-b827eb500a97_000398:fAT-b827ebd75fb6_000002: fAT-b827ebd75fb6_000002 clock was 9830.2us faster than predicted, drift error -0.0ppm
20160221 14:47:15.821 master INFO     clocksync            fAT-b827eb3c0752_000126:fAT-b827eb500a97_000398: fAT-b827eb500a97_000398 clock was 4915.6us slower than predicted, drift error 0.0ppm
20160221 14:47:15.822 master INFO     clocksync            fAT-0024d692b410_000172:fAT-b827eb500a97_000398: fAT-b827eb500a97_000398 clock was 4915.9us slower than predicted, drift error -0.0ppm
20160221 14:47:15.933 master INFO     clocksync            fAT-b827eb500a97_000398:fAT-b827eba584f9_000114: fAT-b827eba584f9_000114 clock was 9830.2us faster than predicted, drift error -0.1ppm
20160221 14:47:16.240 master INFO     clocksync            fAT-b827eb500a97_000398:fAT-b827ebf76967_000142: fAT-b827ebf76967_000142 clock was 4915.5us faster than predicted, drift error 0.0ppm
20160221 14:47:18.193 master INFO     clocksync            fAT-b827eb500a97_000398:fAT-b827eb6b68d8_000021: fAT-b827eb6b68d8_000021 clock was 9829.7us faster than predicted, drift error -0.2ppm
20160221 14:47:18.921 master INFO     clocksync            fAT-b827eb500a97_000398:fAT-b827eb71d588_000158: fAT-b827eb71d588_000158 clock was 4914.7us faster than predicted, drift error 0.0ppm
20160221 14:47:19.175 master INFO     clocksync            fAT-b827eb500a97_000398:fAT-b827ebbbe72c_000416: fAT-b827ebbbe72c_000416 clock was 4915.3us faster than predicted, drift error 0.0ppm

20160221 15:17:07.940 master INFO     clocksync            fAT-b827eb2ca9e0_000040:fAT-b827eb500a97_000398: fAT-b827eb500a97_000398 clock was 9830.4us faster than predicted, drift error -0.0ppm
20160221 15:17:10.269 master INFO     clocksync            fAT-b827eb2ca9e0_000040:fAT-b827eb500a97_000398: fAT-b827eb500a97_000398 clock was 9830.5us slower than predicted, drift error -0.3ppm
20160221 15:30:19.846 master INFO     clocksync            fAT-b827eb500a97_000398:fAT-b827ebf76967_000142: fAT-b827ebf76967_000142 clock was 4915.4us slower than predicted, drift error -0.0ppm
20160221 15:30:22.672 master INFO     clocksync            fAT-b827eb500a97_000398:fAT-b827ebf76967_000142: fAT-b827ebf76967_000142 clock was 4915.5us faster than predicted, drift error 0.1ppm

@jester-xbmc Are you sure you are using the latest build?

v1.5 -> 43176 Feb 21 00:21 airspy_adsb

That's not the latest with the fix...
Just to be sure: http://airspy.com/downloads/airspy_adsb-linux-x86.tgz

you mean: http://airspy.com/downloads/airspy_adsb-linux-arm.tgz
;)
its running now -> 43176 Feb 21 15:01 airspy_adsb

Yes. my bad.

Everything nominal on this side: VRS reported 1 badly formatted message against 5931 good ones
02/21/2016 16:02:29 5986 msgs recv'd from airspy_adsb (2009 in last 5m); 5461 msgs sent to FlightAware
02/21/2016 16:03:22 mlat(708): Receiver status: connected
02/21/2016 16:03:22 mlat(708): Server status:   synchronized with 119 nearby receivers
02/21/2016 16:03:22 mlat(708): Receiver:  918.6 msg/s received     18.0kB/s from receiver
02/21/2016 16:03:22 mlat(708): Server:      0.7 kB/s from server    0.0kB/s TCP to server   2.4kB/s UDP to server
02/21/2016 16:03:22 mlat(708): Results:  307.1 positions/minute
02/21/2016 16:03:22 mlat(708): Aircraft: 19 of 42 Mode S, 36 of 84 ADS-B used

Still seeing the same behaviour on the server side.

Strange. I see no obvious errors in the lib.

Yeah, nothing obvious, but the jumps are always multiples of 4915us which is highly suspicious.
Can you ever get short transfers from libusb in practice? The airspy lib doesn't seem to look at actual_length in the usb transfer struct, it always assumes it got a full buffer.

If you were using the default 256kB buffer size and libusb gave you a short transfer that only filled 64kB of it (but you assumed the whole buffer was full), then your timestamp would effectively jump by 4915.2us. Hmm...

It always gives full transfers. I can put an assert on that.

You may want to set LIBUSB_TRANSFER_SHORT_NOT_OK (https://github.com/libusb/libusb/blob/master/libusb/libusb.h#L1138)

OK. Debugged the thing on rpi2 with lots of traces. Here are my observations:

No buffers skipped at all when using 2 or more workers.
No transfer errors
All the transfers are completely filled (usb_transfer->actual_length == usb_transfer->length)
I can open a port so you can have a look on the data.

I'm not sure if there is much I can debug remotely, the raw data is not all that much use as the question is "do the message timestamps accurately reflect the arrival time of the message" which you can only work out if you have other receivers to correlate with.
Since it might be USB related and that's notoriously sensitive to the particular hardware etc, it might be worth getting a version with extra paranoia (actual_length checks etc) running on jester's setup?

OK. Let's do that.

just throwing this out there, as its USB related, doing this should not cause issues like the above I assume ? -> usbhid.quirks=0xdead:0xbeef:0x4 into /boot/cmdline.txt to stop dmesg spam should

It's still running with the assertions I mentioned earlier.

just checked, still running.

So, definitely nothing lost in libairspy.

Still seeing the same behaviour in the server logs, so I guess it is probably something in airspy_adsb itself.

That's expected. Same code with added assertions only. The thing is there's nothing much left to check, apart from the re-scaling code. The 20MHz MLAT already works fine with PlanePlotter network.
Here's how the timestamp is calculated for the detected frames:
uint64_t timestamp = ((((base_timestamp + frame->position) & 0x0000ffffffffffff) * mlat_phase_count + oversampling_factor / 2) / oversampling_factor) & 0x0000ffffffffffff;
When all the frames are processed, the base_timestamp is incremented by the number of received samples:
base_timestamp = (base_timestamp + count) & 0x0000ffffffffffff
Where:

base_timestamp is a 64bit unsigned that maintains the MLAT state
frame->position is the position of the frame within the currently processed buffer
oversampling_factor is the over sampling factor. for 20MSPS, its value is 10
mlat_oversampling_factor is 6 for Beast (12MHz)

Note the masks correspond to 6bytes MLAT. The MLAT rescaling shouldn't overflow with this code.

It works 99% of the time. The jumps I see are
a) relatively infrequent - perhaps 3 or 4 per hour, depending on traffic
b) always a multiple of 4915us
c) only affecting the airspy receiver, not other receivers
d) often happen in both directions (i.e. the synchronization offset jumps in one direction then immediately jumps back in the other direction)
Without seeing all the airspy_adsb code I can only speculate, but I would guess that it is an infrequent problem to do with the order in which you are processing buffers (I assume you split incoming buffers between multiple worker threads) rather than anything wrong with the timestamp calculation itself.

It's easy to verify: Force one worker.
FYI, the same buffer is being processed with threads from a threadpool. This is the

The main thread enqueues N detection tasks
The worker threads process the tasks independently
The main thread wait for all the tasks to complete
The main thread consolidates the detected frames and performs the time-stamping

I don't know if a Pi is going to keep up with one worker, though.
The processing method you describe sounds reasonable and it should work fine. Given that it sometimes doesn't work fine, I think there's a bug in there ;-)

The Pi doesn't seem to moan about the workload: ~180% total. I think it was the scaling. Ping @jester-xbmc!

2**64 / 6 / 10MHz is around 9800 years, FWIW.

latest code pulled and running....

20160222 14:08:34.836 child  INFO     adept                [<IP_ADDRESS>:60223] Handshake successful (fAT-b827eb500a97_000541 adept dump1090)'
20160222 14:11:07.908 master INFO     clocksync            fAT-b827eb500a97_000541:fAT-b827ebcb3b68_000007: fAT-b827ebcb3b68_000007 clock was 14734.0us faster than predicted, drift error -0.3ppm

(only the one pairing did that, so it's not conclusive, but 14734us is very close to a multiple of 4915us)
I am heading out now but I will check again when I'm back.

4900 years since it's 20MHz - but still.

just status update after 15 minutes (running with -w 4)
02/22/2016 14:22:48 7402 msgs recv'd from airspy_adsb (2276 in last 5m); 6829 msgs sent to FlightAware
02/22/2016 14:23:36 mlat(709): Receiver status: connected
02/22/2016 14:23:36 mlat(709): Server status:   synchronized with 104 nearby receivers
02/22/2016 14:23:36 mlat(709): Receiver: 1016.7 msg/s received     20.0kB/s from receiver
02/22/2016 14:23:36 mlat(709): Server:      0.8 kB/s from server    0.0kB/s TCP to server   2.6kB/s UDP to server
02/22/2016 14:23:36 mlat(709): Results:  353.4 positions/minute
02/22/2016 14:23:36 mlat(709): Aircraft: 24 of 50 Mode S, 38 of 87 ADS-B used

Can you run it with one worker? -w 1

OK, so it's definitely still happening with the current setup (which is -w 4 I believe, at least I have not seen a reconnect since 14:08)

restarted with -w 1

Same behaviour, but a lot more frequent (enough that the receiver is inhibiting)

running again now with -w 4 and -d 2

replaced the threadpool lib with something from scratch. @jester-xbmc ping!

updated version running with -w 4
43168 Feb 22 19:06 airspy_adsb

Running fine after one hour:
02/22/2016 19:37:37 30733 msgs recv'd from airspy_adsb (1710 in last 5m); 30190 msgs sent to FlightAware
02/22/2016 19:38:16 mlat(674): Receiver status: connected
02/22/2016 19:38:16 mlat(674): Server status:   synchronized with 110 nearby receivers
02/22/2016 19:38:16 mlat(674): Receiver:  908.3 msg/s received     17.8kB/s from receiver
02/22/2016 19:38:16 mlat(674): Server:      0.7 kB/s from server    0.0kB/s TCP to server   2.3kB/s UDP to server
02/22/2016 19:38:16 mlat(674): Results:  303.1 positions/minute
02/22/2016 19:38:16 mlat(674): Aircraft: 15 of 38 Mode S, 27 of 75 ADS-B used

Ping @mutability

No change from the previous -w 4 run.

May be libusb doesn't like swapping the buffers of the transfers? https://github.com/airspy/host/blob/master/libairspy/src/airspy.c#L454

Can you disable the correction and only monitor the jumps/clock drift? I want to make sure this is a transient state not a cumulative error. Thanks!

Uh, not easily, because if I disable the correction then the clocks will never synchronize; it's also an invasive change I wouldn't want to make on the live system.
If you have the equipment to do it, then one option might be to run two separate airspys off the same antenna and correlate the timing of the airspy_adsb output yourself. If you match on DF17 messages, they are usually unique within a 500ms window so you should be able to match them up unambiguously.

I already did that exercise. The results were identical to a few samples difference - which is rather good.
Now I think I found the issue: The consolidation relies on the positions of the frames to eliminate the duplicates. The frames that happen to be between two successive buffers may have the wrong timestamp. The delta is the size of the buffer +/- a few tens of samples.
Also, as we sample at 20MSPS, a strong frame can be still detected at +/- 5 samples offset. This means potentially 10 copies. Currently, the consolidation algo takes the one with the highest SNR - but it still relies on the position to determine it's the same frame. This may also fail across buffers.
The fix is easy. I'll do it tonight.
Cheers!

Fixed. @jester-xbmc

Running:
02/23/2016 19:26:37 4035 msgs recv'd from airspy_adsb (1482 in last 5m); 3736 msgs sent to FlightAware
02/23/2016 19:27:17 mlat(704): Receiver status: connected
02/23/2016 19:27:17 mlat(704): Server status:   clock unstable
02/23/2016 19:27:17 mlat(704): Receiver:  513.6 msg/s received      9.9kB/s from receiver
02/23/2016 19:27:17 mlat(704): Server:      0.3 kB/s from server    0.0kB/s TCP to server   0.9kB/s UDP to server
02/23/2016 19:27:17 mlat(704): Results:  148.1 positions/minute
02/23/2016 19:27:17 mlat(704): Aircraft: 9 of 28 Mode S, 29 of 64 ADS-B used

@mutability ping

It seems pretty good. Two odd things noticed so far:

one 4912us step. Only seen against one receiver, so it might be just bad luck.

one cluster of very large offsets. If I convert back to what the original 12MHz timestamps would be I get 40-bit values with all the high bits set, so this is probably a sign or rollover problem somewhere.

20160224 05:37:08.900 master INFO     clocksync            fAT-b827eb2ca9e0_000040:fAT-b827eb500a97_000685: fAT-b827eb500a97_000685 clock was<PHONE_NUMBER>9.6us slower than predicted, drift error 0.1ppm
20160224 05:37:09.316 master INFO     clocksync            fAT-000c29d5f76e_000482:fAT-b827eb500a97_000685: fAT-b827eb500a97_000685 clock was<PHONE_NUMBER>0.1us slower than predicted, drift error 0.1ppm
20160224 05:37:09.317 master INFO     clocksync            fAT-b827eb500a97_000685:fAT-b827ebf76967_000142: fAT-b827ebf76967_000142 clock was<PHONE_NUMBER>3.1us faster than predicted, drift error -0.1ppm
20160224 05:37:10.934 master INFO     clocksync            fAT-b827eb3c0752_000126:fAT-b827eb500a97_000685: fAT-b827eb500a97_000685 clock was<PHONE_NUMBER>7.2us slower than predicted, drift error -0.0ppm
20160224 05:37:11.760 master INFO     clocksync            fAT-b827eb500a97_000685:fAT-b827eb7f1613_000019: fAT-b827eb7f1613_000019 clock was<PHONE_NUMBER>7.7us faster than predicted, drift error -0.1ppm
20160224 05:37:11.978 master INFO     clocksync            fAT-b827eb500a97_000685:fAT-b827ebd75fb6_000437: fAT-b827ebd75fb6_000437 clock was<PHONE_NUMBER>6.3us faster than predicted, drift error -0.0ppm
20160224 05:37:11.978 master INFO     clocksync            fAT-b827eb500a97_000685:fAT-b827eb71d588_000507: fAT-b827eb71d588_000507 clock was<PHONE_NUMBER>4.2us faster than predicted, drift error 0.4ppm
20160224 05:37:12.039 master INFO     clocksync            fAT-0024d692b410_000484:fAT-b827eb500a97_000685: fAT-b827eb500a97_000685 clock was<PHONE_NUMBER>9.2us slower than predicted, drift error -0.1ppm
20160224 05:37:12.116 master INFO     clocksync            fAT-b827eb10655c_000255:fAT-b827eb500a97_000685: fAT-b827eb500a97_000685 clock was<PHONE_NUMBER>2.3us slower than predicted, drift error -0.5ppm
20160224 05:37:12.530 master INFO     clocksync            fAT-063e380017dc_000102:fAT-b827eb500a97_000685: fAT-b827eb500a97_000685 clock was<PHONE_NUMBER>1.4us slower than predicted, drift error 0.3ppm
20160224 05:37:12.620 master INFO     clocksync            fAT-b827eb0472e7_000266:fAT-b827eb500a97_000685: fAT-b827eb500a97_000685 clock was<PHONE_NUMBER>1.9us slower than predicted, drift error 0.0ppm
...

Excellent. For point (1), I think we can safely ignore it. For point (2) I'll check the scaling code.
But at least we know there are no drops.

@mutability can you check?

 In all these events, the sum of the jumps is zero. Which means the absolute clock is maintained. When a buffer is skipped, it is not necessarily reported in the next samples_available event, given the way data is pipelined in the lib.
This might be good enough for 99.99% of the applications, including MLAT, and piaware will still report transient resyncs like the ones you pasted.
Now to imagine a system that pipelines the drop counter as well.

Yep, that would explain it if the timestamp adjustment for dropped samples is effectively being put between the wrong set of buffers. That would also explain why it was much more frequent with -w1 if more buffers tend to get dropped with -w1

How about this one? https://github.com/airspy/host/blob/master/libairspy/src/airspy.c#L458

If I read that right, dropped_buffers[N] counts the number of buffers dropped before successfully receiving received_samples_queue[N], so shouldn't you use dropped_buffers[tail] when processing received_samples_queue[tail] ?

It counts the dropped buffer after the last valid push. The counter is delayed by 1 in the consumer.

What I mean is, let's say that head = 0 and the FIFO is full and we drop 10 buffers.
Then the FIFO empties a little and we receive into queue[0]
Eventually, the callback should see this:
  transfer.samples = queue[0]
  transfer.dropped_samples = 10 * sample_count

Right? So then the callback knows it needs to account for 10*sample_count samples before it starts processing queue[0]
But I think with the current code it will see:
  transfer.samples = queue[0]
  transfer.dropped_samples = 0
  // ... later ...
  transfer.samples = queue[1]
  transfer.dropped_samples = 10 * sample_count

which is not correct, as the callback then has no way of knowing it needs to adjust the timestamp before processing queue[0]

May be a bad merge. Check the code again. The head/tail are sync'ed between the current buffer and the drop counter. For every buffer consumed, the counter might still be incremented in the producer, so it is only safely available in the lock at the end of the consumer loop. That said, it still corresponds to the drops since the last submitted buffer. It is saved for the next event.

I looked again but I still don't see how you get dropped_samples to the right callback.

I think your mistake here is to assume that the consumer thread is in the callback when the callback thread runs with a full FIFO. This is not necessarily true; it could be in pthread_cond_wait.

The way to do this is probably to maintain a counter device->recently_dropped_buffers in the libusb callback thread, and copy/reset that value to dropped_buffers[head] when queue[head] is eventually filled. Then the consumer can directly use dropped_buffers[tail] when it is doing the callback for queue[tail]

The only assumption here is that the drops counter reflects the number of drops between two valid buffers. The counter could be incremented any time until the control enters the locked part at the bottom of the consumer loop.
Did you notice the order of the head/tail increment has changed?

I should start linking to specific blobs I think, it's hard to discuss when the code is changing under you.

Happens all the time with collaborative coding ;-)

The new version is hard to reason about (I wouldn't write it that way) but I think it might work OK.
Documenting the invariants would help a lot, they are not entirely obvious.

I agree. Making a fifo drop-aware is not obvious, especially starting from legacy code.

I think my suggestion works better though :)

"Better" as in simpler? The current code works.

Yes, better as in simpler.

Go ahead.

I'd say, the only difference is the local counter that is incremented/reset at the producer vs. incrementing the counter in the fifo. The rest is identical.

Yep, the code changes are minimal. The conceptual change is that you end up with a simple FIFO which happens to have two data values per entry: a count of samples dropped and some sample data. The two values are always updated or read together. Simple FIFOs like this are easy to reason about.
The complexity of the current code is that the contents of queue and dropped_buffers are read and written separately and have different interrelated sets of constraints that are hard to reason about. For example: the libusb callback cannot safely touch dropped_buffers[head] unless received_buffer_count > 0. This makes it quite fragile.

Frankly, it's the same for me, but it makes things easier to read for you it should be the case for others. I'll eventually tidy this thing when it's all validated.
Do you confirm it's all sync'ed now?

Well, like I said, it's hard to reason about; there are no obvious errors..
Try it and see?

Updated. Have a look on the repo. @jester-xbmc ping.

@mutability so far so good?

Server logs look good now, no obvious problems.

Excellent. Thanks!

and with that, I thank you both very much and close this ticket :)

Now we have a better alternative to conventional receivers ;-)
@FlightAware should consider this option.


Add Google Analytics

Here's the snipit with new tracking ID included:
<script>
  (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
  (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
  m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
  })(window,document,'script','https://www.google-analytics.com/analytics.js','ga');

  ga('create', 'UA-39303796-10', 'auto');
  ga('send', 'pageview');

</script>

How granular is the data coming from this?  Will we know what people go to which pages and such?

Yep!
On Thu, Apr 14, 2016 at 11:08 PM, W. Blaine Price<EMAIL_ADDRESS>wrote:

How granular is the data coming from this? Will we know what people go to
which pages and such?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/Code4HR/okcandidate/issues/111#issuecomment-210265968

--
Kevin Curry
Virginia Beach, VA
https://www.comparityins.com


Invalid input styling not consistent

The error styles for the Find panel field and inputs don't quite match 😊

cc @simurai

💜 thanks @simurai!


Teardown, opposite of Setup

Adds teardown(repo, props). This is useful for reversing anything done in setup()
cc @cwmanning

👍


Need help for Implicit and Explicit wait in AdvancedSharpAdbClient

What can we do for you?
While working with AdvancedSharpAdbClient , for android element automation, sometimes few elements not loaded properly, or the elements configuration not matches, so there may be the any reason, so for that we want to wait for the element will appear or something like  wait.until(ExpectedConditions.visibilityOf(), so for that we want explicit wait. So I request if anything is already then it will be good or plz suggest the solution for this.
Advance Thanking you...

I think this is a feature request which need use this template......
(Why everyone use help-want template to create issues. 😂😂😂

Yes, this feature is already implemented, you can specify the waiting time with the third argument
Element el = client.FindElement(device, "//node[@text='Login']", TimeSpan.FromSeconds(5)); - wait for element 5 second and return null if element not found


DEX-298 restore asset addition to Sighting by fixing backref

Pull Request Overview

Added sightings relationship to Assets (although somehow there is no DB migration generated)
Restored Asset addition to sighting in the AssetGroup commit

/rebase


upgraded to aws-sdk-go-v2

This PR upgrades the S3 filesystem to use the newer version of AWS sdk (https://github.com/aws/aws-sdk-go-v2) since it was mentioned in #1343 that there is plan to do so.

I don't want to rush it since I remember reading in the docs that the new version uses newer S3 APIs which may not be supported by all S3 providers.
It will need first to be investigated whether it works with the common S3 providers and what actually are the api changes.

It will need first to be investigated whether it works with the common S3 providers and what actually are the api changes.

That makes sense. I have only briefly tested it on three providers that I am using (AWS, Tencent COS, and MinIO) and they seems to be working. Let me know if you need any help investigating this.

I would be up to test it with CEPH Rados Gatwway once I get it up and running. How is performance in general in S3 buckets for Pocketbase. Is it noticable?

@pr0ton11 I doubt that there will be any noticable performance difference when switching from v1 to v2 of the s3 library.
If you are asking for general S3 integration performance - it depends on the internal network infrastructure of your host provider(s), the location/region of the servers, etc.
It will be definitely slower compared to a local filesystem storage.

I've squash merged it in the develop branch with one minor endpoint normalization (prefixing it with https:// if scheme is not defined; it seems that this was performed behind the scenes by v1).
I've tested it with AWS S3, DigitalOcean Spaces, Vultr Object Storage and Wasabi S3 offerings and all seems to work fine.


Add template class stable_grid_iterator

[x] ++/--/...
[x] advance(iter, N), ...
[x] operators +=, -=
[x] operators +, - (iter, n) / (n,iter)
[x] operator- (iter, iter)

Done in commit 8091ebd773257f45a88c386ddba1d0a7fdad25ca

Done in commit 60c025da4e2838f6dee681042aeaffdd9690d3b6


Unfriendly error when trying to import corrupted profile file

Testing #167161

Create an invalid profile file (for example, by deleting a closing })
Try importing it

Bug
We show the error notification:

This doesn't mention anything about profiles. I suggest showing an error that says the profile cannot be read

A similar error shows when you mistype the url for a profile (or are offline). In this case though you see XHR failed:


Features on README

README should include information similar to the below.
Features

Both MQTT V3.1/V3.1.1 Protocol Support
QoS0, QoS1, QoS2 Publish and Subscribe
TCP/SSL Socket Support
Reconnect automatically
Keepalive and ping/pong
gen_server like behavior and callbacks

auto resubscribe to topics on reconnect
back-off retry queue for pending messages when disconnected

Hi again - I failed to notice that your issue before was on this repo. This repo is no longer maintained and was replaced with the vmq_commons repo (https://github.com/erlio/vmq_commons), which among other things contain the gen_emqtt mqtt client behaviour.
Please create PRs there if you would like to improve the documentation.
Thank you.


Fixes 3664: support listing/fetching RH tasks

Summary
allows all orgs to fetch tasks for RH repos
Testing steps
Ensure a RH repo has been snapshotted, List tasks:
GET /api/content-sources/v1.0/tasks/
and then fetch one's UUID:
GET /api/content-sources/v1.0/tasks/UUID/
Bonus points if you try to cancel a RH task:
POST /api/content-sources/v1.0/tasks/uuid/cancel/
(you shouldn't be able to)
Checklist

[ ] Tested with snapshotting feature disabled and pulp server URL not configured if appropriate

TODO:  i have to write tests

https://issues.redhat.com/browse/HMS-3664

/retest

/retest

@jlsherrill rebase please

/retest

this looks good to me for fetching RH tasks. i haven't been able to test canceling one, what does the curl command look like to do that? i don't see the request in the api docs so i've just tried this which isn't found:
curl -X POST -H "$( ./scripts/header.sh 9999 1111 )" http://localhost:8000/api/content-sources/v1.0/tasks/76801a1c-ba93-49f5-a0b5-8e1f89369f7a/cancel
this (with the slash at the end) causes a panic:
curl -X POST -H "$( ./scripts/header.sh 9999 1111 )" http://localhost:8000/api/content-sources/v1.0/tasks/76801a1c-ba93-49f5-a0b5-8e1f89369f7a/cancel/

i'll file a bug around the lack of api docs, the correct api is  http://localhost:8000/api/content-sources/v1.0/tasks/76801a1c-ba93-49f5-a0b5-8e1f89369f7a/cancel/
what kind of panic did you get?

oh ok. hmm weird, looked like it's panicking due to a null pointer dereference:
http: panic serving [::1]:52305: runtime error: invalid memory address or nil pointer dereference
once the task finished though the same API call worked with error canceling task, detail=Could not find task with UUID 76801a1c-ba93-49f5-a0b5-8e1f89369f7a


Remove HUBViewModel.extensionURL

This property was originally intended to provide a way to paginate content from a backend service, by letting that backend service returning a URL from where additional content can be loaded.
However, since the move to content operations (and with content operation chaining) - this has been made less and less relevant, since content operations are not required to actually load their content from a backend service.
This property wasn’t actually used anywhere in the framework, so removing it in favor of an upcoming new content operation extension API for paginated content.
Relates to https://github.com/spotify/HubFramework/issues/28

@spotify/objc-dev

Current coverage is 93.05% (diff: 100%)

Merging #121 into master will decrease coverage by 0.01%

@@             master       #121   diff @@
==========================================
  Files            60         60
  Lines          4216       4204    -12
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
- Hits           3924       3912    -12
  Misses          292        292
  Partials          0          0

Powered by Codecov. Last update 8d82476...b55db6f


eth_syncing reports syncing when already at chain head

Description
The eth_syncing API sometimes returns results like:
localhost:8546 [2]: {
  "jsonrpc" : "2.0",
  "id" : 11759,
  "result" : {
    "startingBlock" : "0x485abd",
    "currentBlock" : "0x485abe",
    "highestBlock" : "0x485abe"
  }
}

This suggests that the node is actually in sync (current block is the same as the highest block) but is reporting as still syncing.  Either there's a race condition and the JSON-RPC handler checked if it was syncing first, the sync completed and then it got the head block or it's actually syncing a fork but incorrectly reporting the head block instead of where the sync is up to.
Frequency: [What percentage of the time does it occur?]
Very rare - most often for an in-sync node it will either return false or be behind by a single block.
Versions (Add all that apply)

Software version: besu/v21.1.2/linux-x86_64/corretto-java-11
Java version: [java -version]

openjdk version "11.0.8" 2020-07-14 LTS
OpenJDK Runtime Environment Corretto-<IP_ADDRESS>.1 (build 11.0.8+10-LTS)
OpenJDK 64-Bit Server VM Corretto-<IP_ADDRESS>.1 (build 11.0.8+10-LTS, mixed mode)

Additional Information
Low priority - the eth_syncing API is unfortunately pretty useless on all clients for actually determining if the node is suitably in sync since it will often return syncing while the latest block is being imported.

@ajsutton - still relevant or can i close? I am presuming engine API changes have touched this or at least proven non-issue?

We've worked around it in teku. I still suspect there's a race condition which can make it reply syncing but also indicate there's nothing remaining to sync. Not sure if that's an issue or not - it's just a bit weird.

Closing as stale


[Task] Low hanging UI performance fruits

Describe your idea
For tools which edit nodes and segments, add code to cache the visible nodes and segments and not recalculate them until the camera moves.
For speed limit tool apply similar improvement
[17:32] aubergine18: when the main speed limit tool is active, it iterates all segments, and for each one does a big bunch of checks to see if it's visible, if it can handle speed limits, etc
[17:32] aubergine18: well, if cached, yes, it would be one time only
[17:32] aubergine18: but it's not currently cached from what I can see

Actually, looking at code again, there is some degree of caching I think - currentlyVisibleSegmentIds @ https://github.com/krzychu124/Cities-Skylines-Traffic-Manager-President-Edition/blob/master/TLM/TLM/UI/SubTools/SpeedLimits/SpeedLimitsTool.cs#L146

I was copying some TMPE code for my own mod and yes, the signs were cached (in particular parking signs)

First experiment:
Caching node ids while the camera is not moving, for Lane Connectors tool.
Master build will re-filter the nodes every time and lose 12-17ms per frame.
With cache changes nodes only re-filter when camera is moved, and that just takes 1-2 ms per frame.

Here's another low fruit: https://github.com/krzychu124/Cities-Skylines-Traffic-Manager-President-Edition/blob/master/TLM/TLM/UI/MainMenu/StatsLabel.cs
When the path find stats display is not active, it should not do anything. Even when it is active, it should avoid using Update() on a UI component. Ideally the UI should be disabled and not visible when not in use.
For compatibility with the FPS Booster mod, we should avoid any Update() on UI components (except panels which still retain the base method).


[hacktoberfest] Bucket Sort Algorithm

@bhaveshlohana Hi, I would like to add the Bucket Sort Algorithm in Python and Java languages.
Can you please assign it to me?

Check #1429


Non exception API

To test the API of this lib, I created input data that was not sufficent for creating an actual convex hull. This resulted in an exception. In my opinion a result object that can be in a faulted state is far more usefull when using a library like this one.
E.g.:
public enum ConvexHullCreationResultType
{
    Success,
    NotEnoughVerticiesForDimension,
}
public class ConvexHullCreationResult
{
    //this could be null
    public ConvexHull<TVertex, TFace> Result { get; }

    public ConvexHullCreationResultType Outcome { get; }
}

Would you be interested in adding an API like that?
I'd like to use this library and would rather help designing and implementing such an API, than using a wrapper.

I think this would help.

I think this would help.

Are you implying me implenting it would help, or this additional API would?


Code Introspection is missing rope but rope is installed on the machine

From<EMAIL_ADDRESS>on 2014-12-12T02:16:27Z
Please note that reporting bugs from Spyder's help menu ("?" > "Report
issue...") will fill version details for Spyder, Python and Qt in this description for you. Hi Team,
Thanks for Spyder. I have seen this running on a machine fast and reliable. But unfortunately not for me when it comes to code completion. I have installed a fresh Debian Jessie with Spyder 2.3.1 from the standard repositories with aptitude in the normal way. But when I go to Preferences -> Editor -> Code Introspection/Analysis it gives a Warning about missing rope. But rope has also been installed via aptitude install python-rope. According to "dpkg -l python-rope", rope is installed ok, too. I did dpkg-reconfigure for spyder and rope without success. No error messages in the internal console though and no messages in /var/log that would point me to anywhere and in the bug reports here I could also not find anything that would lead me to a solution. This is my first bug report so sorry for not sticking to the process or not delivering enough information. Thanks for your help in advance.
What steps will reproduce the problem?
1.Preferences -> Editor -> Code Introspection/Analysis always shows Warning about missing rope. 2. 3.
What is the expected output? What do you see instead?
Expected output: Code completion in Editor, but nothing happens. What version of the product are you using? On what operating system? Spyder 2.3.1 on Debian Jessie
Please provide any additional information below
. See above
Original issue: http://code.google.com/p/spyderlib/issues/detail?id=2084

From<EMAIL_ADDRESS>on 2014-12-16T08:50:17Z
Hi Carlos,
Sorry for the late reply. Couldn't get to my machine earlier. Your fix did work. You made my day!!! Thanks so much and sorry again for the late message.

From ccordoba12 on 2014-12-15T09:55:22Z
I'm almost sure the error is about the missing rope dependency in Debian/Ubuntu in Python 3.
Unfortunately there is nothing we can do to fix, except the recommendation I gave to you :-)
Status: WontFix

From ccordoba12 on 2014-12-12T13:59:29Z
Are you using Spyder under Python 3 or Python 2? I'd say the most likely answer is Python 3, for which Debian doesn't have a rope package.
To install rope you need to use pip, with this command:
sudo pip3 install rope_py3k

Labels: Cat-Editor MS-v2.3.3

From ccordoba12 on 2014-12-16T11:59:05Z
Don't worry, I'm glad the fix worked for you.
I was just reviewing other issues and found yours, so before I forgot about it, I prefered to post a last closing message ;-)
Labels: -MS-v2.3.3


Something in 1.30.0 breaks autodetection of local scripts when using Emby

Describe the issue
In all the versions after and including 1.30.0 I cannot get multifunplayer to detect local funscripts when using emby.
I tried both the emby theatre, the webui, and vlc on each version from 1.29.4 and on all the 1.30.* releases emby would connect but wouldnt detect anything. other players like vlc seem totally unaffected, and all the other aspects seem fine.
Expected behavior
In 1.29.4 as long as the funscript files are correctly named and located multifunplayer loads them correctly for emby no different than vlc
or any other player.
PS: thanks for all your work.

Yes, I broke Emby and Jellyfin by accident when cleaning up the code: https://github.com/Yoooi0/MultiFunPlayer/commit/b7c307bf0ae033cc16617385070ae046fbd01ae8
Apparently you have to specify that the attribute is to be applied to the property:
[property: JsonProperty("ReportedDeviceId")]
which I didnt know so it reads invalid device id in v1.30.0.
Fixed internally, will be in v1.31.1 or v1.32.0


Added Makefile and link to dusk

Hello!

Just trying to make things easier!
I added a link to dusk and a Makefile =)

@DynamicSquid Would this be a good idea? If you want to I can add the preprocessor...

that'd be awesome!

@DynamicSquid Well, as the old saying goes,

it's easier to understand your own code than someone else's

also the github CLI is useful, I made this pull request in it

what's a github cli? also what does the makefile do?
oh, wanna help me test v3.0?

Yep, sure

k, lemme push it to repl gimme a sec

sorry that took a while I invited you

@DynamicSquid Are you alright with the import syntax use example;, or what keyword should I use?

@DynamicSquid resolved conflicts! You can now merge, and the pre-processor is done

Well it's fine if there are conflicts they're not that hard to resolve @DynamicSquid

@DynamicSquid May I ask, will the code form this now closed pull request, be re-implemented into your target v3.3?

@CodeLongAndProsper90 Here is pr 28


Lower resolution on deconz VNC session

I'm running this package in Docker on a headless Raspberry Pi, so I've enabled the VNC session as described in the doc. I can connect to the display (I'm using Remmina on my Ubuntu laptop), but my problem is that the display resolution is too much for my poor laptop screen -- and for my eyesight!
Is there anything I can do (perhaps via some DECONZ_VNC_ environment setting in the docker-compose.yml file) to specify a lower display resolution?

@MrMEScott have a look this PR: #341.
So actually there is no option for you - but the issue is addressed.


odo doesn't honour "ODO_EXPERIMENTAL=false" on command line

What versions of software are you using?
Operating System: all
Output of odo version: master
How did you run odo exactly?
$ odo preference view
PARAMETER             CURRENT_VALUE
UpdateNotification
NamePrefix
Timeout
PushTimeout
Experimental          true
PushTarget

$ ODO_EXPERIMENTAL=false odo catalog list services
Operators available in the cluster
NAME                          CRDs
etcdoperator.v0.9.4           EtcdCluster, EtcdBackup, EtcdRestore
mongodb-enterprise.v1.4.5     MongoDB, MongoDBUser, MongoDBOpsManager

Actual behavior
odo prints the list of operators in spite of having set ODO_EXPERIMENTAL=false on CLI
Expected behavior
Odo should not have listed operators. In my experience, CLI value gets preference over configuration. But what behaviour we want odo to emulate is up to the team. Also, document the same (if required)

+1 for having the ODO_EXPERIMENTAL value override the value in the preference file. We did the same for the pushtarget preference and if ODO_PUSHTARGET=<target> is set, it uses that over whatever's stored in the preferences file.

At the moment, if ODO_EXPERIMENTAL is set to false in shell but it's set to true in preferences, we consider this to be true.
Shouldn't it be considered false instead?
$ odo preference view
PARAMETER             CURRENT_VALUE
UpdateNotification
NamePrefix
Timeout
PushTimeout
Experimental          true
PushTarget

$ echo $ODO_EXPERIMENTAL
false

$ odo create nodejs
Experimental mode is enabled, use at your own risk

Validation
 ✓  Checking devfile compatibility [130136ns]
 ✓  Creating a devfile component from registry: DefaultDevfileRegistry [114683ns]
 ✓  Validating devfile component [214227ns]

Please use `odo push` command to create the component with source deployed

Yeah this is something we need to have because ODO_EXPERIMENTAL would be used even after devfilev2 becomes GA

We don't have the experimental mode any more. Closing this.
/close

Are we sure - we would never need odo experimental feature again?

It's never a 100% thing, I guess. But we can re-open this if we put anything behind experimental mode. Hopefully we won't. :smile:


Promises resolving the same value are handled incorrectly

Hi,
it seems that I found a bug with turbo-stream handling promises resolving the same vlaue incorrectly.
I originally opened https://github.com/remix-run/remix/issues/9466 but decided to dig a bit deeper and found the problem in this package.
In short, instead of the value of the second promise (resolving the same value) an empty array is returned like this:
[...{"31":32,"33":34,"35":36},"promiseA",["P",32],"somethingStatic",0,"promiseB",["P",36]]
P32:[1]
P36:[]

Analysis
It seems to me, that flatten is used to flatten the initial array but also responses of resolved promises:
https://github.com/jacob-ebey/turbo-stream/blob/a72f7a76e393cf43b265036521d519c22f2c3c08/src/turbo-stream.ts#L171
The problem is, that on resolving the 2nd promise this check here does not add a new value to the response, as it was already returned with the first promise:
https://github.com/jacob-ebey/turbo-stream/blob/a72f7a76e393cf43b265036521d519c22f2c3c08/src/flatten.ts#L24-L25
The consequence is, that an empty array is returned here:
https://github.com/jacob-ebey/turbo-stream/blob/a72f7a76e393cf43b265036521d519c22f2c3c08/src/turbo-stream.ts#L177-L184
This causes an error in the unflatten function which checks for an empty erray:
https://github.com/jacob-ebey/turbo-stream/blob/a72f7a76e393cf43b265036521d519c22f2c3c08/src/unflatten.ts#L35
Possible Fix
After looking through the code it seems to me, that we cannot reference previous values when unflattening the value of a promise.
Because of this my quick fix was to send the whole promise again, which is of course not optimal.
I opened a PR with a test case and a fix, see #29
Best, Vincent

Closing for now. Please re-open if the issue persists. Thanks for the detailed report.


✏ Fix typos in docs/tutorial/many-to-many/create-models-with-link.md

fix annotated typo

Good catch(es) thank you! :nerd_face: :cake:


Possibility of not calling enableSingleRequest() in setupGpt

Hello.
Thanks for creating this package, there are some very good ideas here, but we are experiencing low inscreen in DFP but not in our own tracking.
We think the issue might be in the setupGpt function where you call enableSingleRequest() - https://github.com/technology-ebay-de/react-prebid/blob/master/src/Advertising.js#L205
And I know you put it plugin support, but since this is called after the plugin is called I'm not sure how to go about changing it.
The specific error from adding ?googfc to the url on our site is:
googletag.defineSlot was called more times than there are DIVs in the DOM associated with ad slots while in Single Request Mode. This will impact impression counts.
Any help would be appreciated.

Hi Fredrik, thanks for reaching out! 😀
Perhaps it would help you if I put in a configuration option that allows you to opt-out of single request mode?

That would work

Forked the project and tried removing enableSingleRequest, which made the "This will impact impression counts." part of the error from Google console go away, but now we some times do not render every ad on the page.
So I guess this change is not needed after all, for our case it would probably need a bigger change, I assume we would need to define and display the ads in the activate call or something. I'll see if I get the time to test it out at some point.
And just for clarification, we are using this with intersection observers, and we call activate when the component is in the viewport. We track our ads by listening to GPT events, and everything is good with our own tracking, so everything seems to work as it should. The only problem here is that Google's own reporting (in DFP/Ad Manager) seems to report different numbers than our own, while we see (from GPT events) inscreen numbers around 90%, DFP/Ad Manager reports are saying 25-50%

OK, so nothing to do from my side at this point. I'll be happy to review your pull request, if you want to create one. If you do, please make sure your code changes are covered by unit tests.


feat: rename profile skills to skills section

:+1: although if we end up sharing a lot between users and teams, we might need terminology to encompass both - maybe profile is actually such a term? "user profile" and "team profile"


Create requirements-dev.txt

issue #58
Hi @agardnerIT,
just trying to jump in this issue, please check it out
Do you wanna delete pytest on requirements.txt ? I might help

Thanks for the PR! Yes, please remove pytest from the standard file.
Can you also add words to the readme to explain which file to use and when?

workin on it @agardnerIT


Adding model with cycle consistency and VampPrior

Closes https://github.com/scverse/scvi-tools/issues/2383

I added changes and adapted tutorial accrordingly

Thanks for addressing the comments! I'll take another pass at it soon.

@martinkim0 thank you for looking at it again - I added the changes as requested

Sorry for the delay in reviewing this - hopefully taking a last pass this week and we get this merged!

@canergen I added changes now where it was straightforward how to fix, but there are some larger design choices that would require support from someone from your side before I decide to make them - could we maybe organise a call sometime? I could meet outside work hours (so not weekdays 9am-5pm CEST).

@Hrovatin I was texting you on the scverse Zulip. Pinging here as I didn't get a reply.

@canergen Sorry, I am no longer active there and overlooked that you responded. I sent you my personal email over zolip to arrange a meeting.

@Hrovatin there are some fixes that need to be done regarding the pre-commit ruff rules (everything that involves linting the code, formatting it etc'..) to be compatible with the rest of our repo and package.
So those errors can be found under Details in the ore-commits.co-pr test.
Once this is fixed we can continue.
LMK if you need help.

The changes I pushed today are not yet ready for review. Missing docs, cleanup, and test on real data.

@canergen @ori-kron-wis The PR is now ready for review.
TODOs on my side:

[ ] Test on real data now that implementation was changed to fit into scvi-tools

@ori-kron-wis Can you help me fix the cuda test err? For some reason, it can not import SysVI, although for me, it works locally. I also was not able to test on GPU since I only have MacOS access and I get the err where mps is detected but not used. - If you have any solutions for that also please let me know.

First look, looks good. Two comments. Should we wait for FClayers to be compatible and then use FClayers? Or do you think it will anyhow not work?

The FCLayers I use now are the a base for the suggestion that you are working of so it should work with minor modifications in how API is accessed as it may still change. If that is planned to be finished soon then lets, wait, but otherwise I suggest merging so that we finally get it in main and then switching afterwards

@canergen I think that all the requests that could be solved at this time were implemented. I would very much appreciate it if we could resolve this, as having this as PR is creating double the amount of work for me since others keep using different SysVI versions from my fork and local repository.
Last thing:
Could you please help with your CI pipeline so that we can see if the tests pass? - As described before, I think there is an error on CI side not finding the SysVI imports although it works locally.

When running the full benchmark on the new version we realised it no longer performs as the version before changes in autumn. Will have a look at it, but I am afraid it may be one of the many "non-straightforward" changes required to re-use more of the scvi-tools code. @canergen
If that is the case I will probably give up on this PR and then people need to use the stable version of my fork, before requested changes, as I also lack capacity to work on this.

See my mail. Happy to look through it once and see whether we can make it work again. Otherwise, we should close here - which would be quite unfortunate.

Thanks for the reminder. As also mentioned in the email reply, I will inspect the performance in more detail over the holidays and then let you know about merging/closing by early January.


Have a hook to pull down docker images outside of run()

Currently images are pulled down upon a DockerClientWrapper.run() it would be useful Refinery-side if I could pull these images down upon creation of ToolDefinitions so that users aren't waiting when they launch a Tool.

@mccalluc This came up in thought again today, maybe its a good idea to get around to implementing (I'd be happy to, but would feel better about doing so after chatting)


Cannot attach to a running container on Fedora 23

Hi, I'm running Docker on my Fedora 23 laptop. Every time I run docker attach it hangs until I type something.
If I kill the running container and run docker start -a, I will get to the shell, but I will be unable to use arrow  keys and Enter.
Steps to reproduce:
$ docker run -ti debian:8 /bin/bash
root@7bcaca9423f9:/# echo 'I can use the shell.'
I can use the shell.
root@7bcaca9423f9:/# (CTRL+P,Q)
$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
7bcaca9423f9        debian:8            "/bin/bash"         37 seconds ago      Up 36 seconds                           jolly_wescoff

$ docker attach 7bcaca9423f95e4a40f58e90f180146602443d92350ff1706c15785bede91a29
# will hang forever
# (Press any key)
root@7bcaca9423f9:/# echo 'Then I get to the shell again'
Then I get to the shell again
root@7bcaca9423f9:/# exit

# restart
$ docker start 7bcaca9423f95e4a40f58e90f180146602443d92350ff1706c15785bede91a29
7bcaca9423f95e4a40f58e90f180146602443d92350ff1706c15785bede91a29
$ docker attach 7bcaca9423f95e4a40f58e90f180146602443d92350ff1706c15785bede91a29
# still hang
# (Press any key)
root@7bcaca9423f9:/# echo 'It recovered.'
It recovered.
root@7bcaca9423f9:/# exit

# run `docker start -a`
$ docker start -a 7bcaca9423f95e4a40f58e90f180146602443d92350ff1706c15785bede91a29
root@7bcaca9423f9:/#
# cannot do anything because my Enter key is not working

My environment:
$ docker -v
Docker version 1.9.1, build a34a1d5

$ uname -a
Linux localhost.localdomain 4.2.7-300.fc23.x86_64 #1 SMP Wed Dec 9 22:28:30 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

I tried the same operations on my friends' Fedora 23 computer, this issue can be reproduced.

Hi!
Please read this important information about creating issues.
If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.
If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.
This is an automated, informational response.
Thank you.
For more information about reporting issues, see https://github.com/docker/docker/blob/master/CONTRIBUTING.md#reporting-other-issues

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
docker info:
uname -a:
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Provide additional info you think is important:
----------END REPORT ---------
#ENEEDMOREINFO

Hi @vfreex, this looks to be a duplicate of https://github.com/docker/docker/issues/8521. That discussion also contains some information about "why".
I'll close this issue because it's a duplicate of https://github.com/docker/docker/issues/8521. Please subscribe to that issue to stay informed on updates. Feel free to comment here after I've closed this issue :+1:


Update dependency on snapdragon-node to the latest (v2.1.1)

cf. https://github.com/here-be/snapdragon/issues/20#issuecomment-393243321

No, instead you can just do:

Yes, it what I do for now. But I'm asking, why do you consider that we shouldn't update the snapdragon-node dependency to the latest in the snapdragon main module ?

In fact no, we can't do that because Parser use pushNode() internally in init(), called by parse()
home/remi/app/node_modules/snapdragon/lib/parser.js:76
    this.ast.pushNode(this.bos);
             ^

TypeError: this.ast.pushNode is not a function
    at Parser.init (/home/remi/app/node_modules/snapdragon/lib/parser.js:76:14)
    at Parser.parse (/home/remi/app/node_modules/snapdragon/lib/parser.js:524:10)
    at Object.<anonymous> (/home/remi/app/src/lib/index.js:15:20)
    at Module._compile (module.js:652:30)
    at loader (/home/remi/app/node_modules/babel-register/lib/node.js:144:5)
    at Object.require.extensions.(anonymous function) [as .js] (/home/remi/app/node_modules/babel-register/lib/node.js:154:7)
    at Module.load (module.js:565:32)
    at tryModuleLoad (module.js:505:12)
    at Function.Module._load (module.js:497:3)
    at Function.Module.runMain (module.js:693:10)

So I'll use pushNode() for now. It's not a problem.

Yes, it what I do for now. But I'm asking, why do you consider that we shouldn't update the snapdragon-node dependency to the latest in the snapdragon main module ?

I've mentioned in a few places that I'm actively working on the next version of snapdragon and other libs. I would much rather spend the time getting closer to that goal than handling issues related to unforeseen problems caused by bumping a dep.

Ok Jon thank you very much for your explanations.
If you need help with snapdragon I'll be pleased to help!
Here is again an awesome lib to build awesome tools!


DO NOT MERGE: Update cardano-base to fix SECP verification primitives

Based on issues raised by @iquerejeta, and addressed in cardano-base here, these fixes are now extended to the on-chain primitives for SECP verification (using either ECDSA or Schnorr schemes). These changes amount to the following:

Bumping the cardano-base dependency to the commit of cardano-base with the linked fixes applies;
Removing the (now unnecessary) dependency on secp256k1-haskell, and amending the Nix configuration accordingly;
Modifying the tests so they compile again, which involves no change in functionality beyond a type change for ECDSA-suitable message hashes;
Updating the documentation to reflect the changes in the API.

Ideally, the documentation changes would link the relevant CIP, as it contains more details. However, it is currently in-progress, which would mean that even if we added those links now, we'd just have to change them later anyway. Thus, presently, I replicate the relevant information in the documentation for the wrappers for this functionality, both in plutus-core and in plutus-tx's Haddocks.
The changes technically require re-costing, as some of the argument sizes have decreased, but as per the linked work-in-progress CIP, their linearity (or lack thereof) should be the same as previously.
Pre-submit checklist:

Branch

[X] Tests are provided (if possible)
[X] Commit sequence broadly makes sense
[X] Key commits have useful messages
[X] Relevant tickets are mentioned in commit messages
[X] Formatting, PNG optimization, etc. are updated

PR

[X] (For external contributions) Corresponding issue exists and is linked in the description
[X] Targeting master unless this is a cherry-pick backport
[X] Self-reviewed the diff
[X] Useful pull request description
[X] Reviewer requested

This PR is currently on hold, due to an issue discovered in the Schnorr verification code, as reproducibly evidenced by this regression case. Until this is resolved, this PR should not be merged.

For reference, there's a discussion of costing at https://github.com/input-output-hk/plutus/issues/4802.  There's no great change from the earlier implementations, so we'll just update the costs the next time we do a full re-calibration of the cost model.


Poor error handing in Player.gd: interact()

Player.Interact
		query.collision_mask = ITEM_MASK
# ...
		if result.is_empty():
			Logger.debug("No item found in raycast")
			return

		Logger.debug("Found item in raycast(id:%d)" % result["collider_id"])
		result["collider"].test_event()

This does not account for the high likelihood that something that doesn't contain the correct function that is in ITEM_MASK

https://github.com/FailedIndustry/Industrial-Failure/commit/02775f282fb6c3108176909221e506192ae49ef6


iOS support lacking

this plugin works very well on desktop. however, on iOS devices it does not work. I added a ios drag and drop shim from
https://github.com/timruffles/ios-html5-drag-drop-shim
I can drag and rearrange, but there is some issue with the handle. If I specify a handle, I can still drag other area. And I cannot drop unless I drag by touching on the handle. I have to leave the handle blank, then the whole element becomes draggable, thereby disabling a functionality offered by the plugin.

I've had some good experience with using Google Chrome's device emulation for things like this. (It essentially shots off drag and drop support, so then everything would be going through the shim.)
I haven't tried using that for this library yet, but it's likely it would let you at least attempt to sort out what's going on.


💥 [DevOps] Publish Workflow

💥 DevOps ticket

Have a Publish Workflow to automatically publish github releases and maybe push docker images.

Followup ticket for publish of remaining service


As a developer, I need to implement custom logging in node

tracing library is used for logging in Openmina.
Implement custom subscriber which will process those logs and print to terminal.

Instead of current time, logger should use passed time.
Have an ENV var which can customize whether we log details or not. If not we should only display summary part of the log.

@binier Hi Zura, I can handle this one. Some comments/questions.

With relation to time, I guess you want to have a timestamp of an event, right? Shouldn't we instead have it as an additional log entry property? Otherwise we can end up in a situation where we have strange order of timestamps in logs.
I think verbosity should be based on entry kind, instead of printing the same log entry differently depending on requested level. As an example, consider a log entry on a huge message reception. If there is a single log entry with both summary and message content, it would be quite hard to analyze the log with its content included. On the other hand, if verbosity is decreased, then there would be no way of getting that content. Instead, we can have an entry containing a summary, with e.g. debug level, and another one with e.g. trace level containing the message itself. That way we can just use grep/awk to read high-level logs, and then focus on specific data.

@akoptelov

Otherwise we can end up in a situation where we have strange order of timestamps in logs.

Yes if we mix usage of monotonic time and system time like it's done now. But if we store these two as a static vars: https://github.com/openmina/redux-rs/blob/155f8208f3105174cbd32172e7580b164d772349/src/store.rs#L56-L57
We could use just monotonic time everywhere.

I think verbosity should be based on entry kind, instead of printing the same log entry differently depending on requested level

I had in mind additional flag plus verbosity level.

If there is a single log entry with both summary and message content, it would be quite hard to analyze the log with its content included

I'd say it's mostly useful if we will use some tool to process those logs. Basically what we had for webnode in FE.

On the other hand, if verbosity is decreased, then there would be no way of getting that content

True, but same is the case with low verbosity logging as well. It's a tradeoff. In general summary should contain enough info to somewhat reason about the thing.
Still you might be right. I don't really have a preference for that. One thing to keep in mind though is that existing logs were written for webnode to be viewed in the frontend. So many of them include big data like full blocks as a log entry fields.

@akoptelov

Otherwise we can end up in a situation where we have strange order of timestamps in logs.

Yes if we mix usage of monotonic time and system time like it's done now. But if we store these two as a static vars: https://github.com/openmina/redux-rs/blob/155f8208f3105174cbd32172e7580b164d772349/src/store.rs#L56-L57 We could use just monotonic time everywhere.

I think verbosity should be based on entry kind, instead of printing the same log entry differently depending on requested level

I had in mind additional flag plus verbosity level.

Yeah, I understood that. I'm just trying to expand on the problem according to my experience working with desktop version of openmina.

If there is a single log entry with both summary and message content, it would be quite hard to analyze the log with its content included

I'd say it's mostly useful if we will use some tool to process those logs. Basically what we had for webnode in FE.

Totally agree with you. But still we need to cover the use-case when we just have a plain log.
For example, this configuration works fine for me during dev stage:

max verbosity level
single-line log entry
for an event with some huge amount of data involved, there are two entries, one containing the summary, and another one containing the data itself (that later one with higher level of verbosity)
the full log is stored, but it can be easily filtered so no data entries are printed. That way the whole flow can be easily seen and not cluttered with big messages.
if there is an issue, it is quite easy to navigate to the whole log using summary entries, to fetch the whole data.

And then we have an option to completely avoid dumping tracing data, e.g. in production.
To my feeling, this way it is just a bit easier to use terminal utilities to view logs.

On the other hand, if verbosity is decreased, then there would be no way of getting that content

True, but same is the case with low verbosity logging as well. It's a tradeoff. In general summary should contain enough info to somewhat reason about the thing. Still you might be right. I don't really have a preference for that. One thing to keep in mind though is that existing logs were written for webnode to be viewed in the frontend. So many of them include big data like full blocks as a log entry fields.

OK, let's see as it goes :)


Update to Debian 12 Bookworm

The latest version is currently 12.5.

The latest version of Debian is now 12.8, which was released in November. This would seem to be the right version to switch to for the MW 1.43 version of Canasta.


Should we have a configuration file

Description of issue.
With the new info rules we are starting to expand the amount of command line options and including, excluding rules.  I'm wondering if we need to allow a configuration file we can read and use on execution.
For instance I want to have info rules always on but I don't want to type in the parameters every time.  Because I'm lazy.  Another use case as the rules expand it would be easier to disable certain rules with a config file instead of creating longer and longer command line parameters.
This would be the least precedence in parameters.  Files and command line parameters will override the configuration file.

Well.. We're so lazy we even created a wrapper application so internally we just run cb-cfn-lint 😎
Like the idea though, let the audience decide based on the 👍  and 👎

I'd like to see support for a config file as long as it's not required to run and anything passed as arguments overrides whatever is in the config. That way it'll be minimal impact and can safely be ignored.

I like this idea.  I want a dot file I can put in the root of my directory that the linter picks up in the pipeline, but with the ability to lock-in overrides via the command line I'm executing via Travis, etc.

I'd definitely like a config file, especially if I can set the template location(s) allowing me to just type cfn-lint with no arguments in the root of my project.

Working to create a config file.  Thanks for the input.


Fixes #1363

Added check to avoid dependency error
Added a log error with the uncaughtException stack trace
Minor fixes to the migration
Test it by running node etc/migration/disable_users_from_tenancy/1.disable-users-by-tenancy.js -t someTenant | bunyan

Refactored it a bit


Using same position matrix collection but distinct molecule collections produces error.

This issue was first noticed by @annabelbasford.
Basically, if you use different molecule collections but the same pos_mat_collection in a molecule database, the .get_all method will hit an error because it seems to run through the pos_mat collection in order.
A minimum working example to outline it:
import stk
import pymongo

molecule1 = stk.BuildingBlock('NCCN')
molecule2 = stk.BuildingBlock('CN')
molecule3 = stk.BuildingBlock('CC')
molecule4 = stk.BuildingBlock('NCCCCN')

client = pymongo.MongoClient()
db = stk.MoleculeMongoDb(
    mongo_client=client,
    database='random',
    molecule_collection='random2',
    position_matrix_collection='constant',
)

db.put(molecule1)
db.put(molecule2)
for entry in db.get_all():
    print(stk.BuildingBlock.init_from_molecule(entry))
# Works up to here!

db2 = stk.MoleculeMongoDb(
    mongo_client=client,
    database='random',
    molecule_collection='random3',
    position_matrix_collection='constant',
)

db2.put(molecule3)
db2.put(molecule4)

for entry in db.get_all():
    print(stk.BuildingBlock.init_from_molecule(entry))
    # Prints first two, then `KeyError`
for entry in db2.get_all():
    print(stk.BuildingBlock.init_from_molecule(entry))
    # `KeyError`

Discussion point:
The current MoleculeMongoDB.get_all() method looks like this:
    def get_all(self):
        for entry in self._position_matrices.find():
            # Do 'or' query over all key value pairs.
            query = {'$or': [
                {key: value}
                for key, value in self._get_molecule_keys(entry)
            ]}

            json = self._molecules.find_one(query)
            if json is None:
                raise KeyError(
                    'No molecule found in the database associated '
                    f'with a position matrix with query: {query}. '
                    'This suggests your database is corrupted.'
                )

            yield self._dejsonizer.from_json({
                'molecule': json,
                'matrix': entry,
            })

I would like to discuss why we think that should be an error there, instead of just passing the case where a molecule does not have a position matrix, or vice-versa? There is no obligation that they are both there for any given entry. I say this one should just continue to the next entry.

From discussin the above, we went for modifying the query to minimize the number of queries made to mongodb - this will be benchmarked in the PR though.


[Draft] - Keycloak Authentication

Keycloak Open source Auth0 alternative
Uses passport-oauth2 as the passport strategy

Hi
all good here ?
anyone able to integrate keycloak successfully ?