glscopeclient hangs on Rigol MSO5000

When I configure the glscopeclient for my Rigol and press OK, it pops up a window if I want to kill the app or wait for it to respond, and then after a good few seconds the UI comes up.
It is extremely slow to load any data, showing like 3 WFMs, 0.05 WFM/s, and while the label of the sample rate matches what i see on the scope (2GSa/s, 4Mpts), the view is zoomed in to to 20.000 ns, while the scope shows 200us/div. One time I managed to zoom out, but generally the UI just hangs and the time scale vanishes completely when zooming too far.
I tried to trace the commands it sends:
$ ./src/glscopeclient/glscopeclient --debug --trace SCPISocketTransport
Connecting to SCPI oscilloscope at <IP_ADDRESS>:5555
[SCPISocketTransport::SendCommand] Sending *IDN?
[SCPISocketTransport::ReadReply] Got RIGOL TECHNOLOGIES,MSO5074,MS5A221301338,<IP_ADDRESS>.01
[SCPISocketTransport::SendCommand] Sending SYST:OPT:STAT?
[SCPISocketTransport::ReadReply] Got TD
[SCPISocketTransport::SendCommand]     Sending ACQ:MDEP?
[SCPISocketTransport::ReadReply]     Got 4.0000E+06
[SCPISocketTransport::SendCommand]     Sending WAV:SOUR CHAN1
[SCPISocketTransport::SendCommand]     Sending WAV:PRE?
[SCPISocketTransport::ReadReply]     Got 0,2,4000000,1,5.000000E-10,-1.000000E-3,0.000000,3.9962E-02,0,128
[SCPISocketTransport::SendCommand]     Sending WAV:STAR 1
[SCPISocketTransport::SendCommand]     Sending WAV:STOP 4000000
[SCPISocketTransport::SendCommand]     Sending WAV:DATA?
[SCPISocketTransport::SendCommand]     Sending WAV:SOUR CHAN2
[SCPISocketTransport::SendCommand]     Sending WAV:PRE?
[SCPISocketTransport::ReadReply]     Got 0,2,4000000,1,5.000000E-10,-1.000000E-3,0.000000,3.9832E-02,0,128
[SCPISocketTransport::SendCommand]     Sending WAV:STAR 1
[SCPISocketTransport::SendCommand]     Sending WAV:STOP 4000000
[SCPISocketTransport::SendCommand]     Sending WAV:DATA?
[SCPISocketTransport::SendCommand]     Sending WAV:SOUR CHAN3
[SCPISocketTransport::SendCommand]     Sending WAV:PRE?
[SCPISocketTransport::ReadReply]     Got 0,2,4000000,1,5.000000E-10,-1.000000E-3,0.000000,3.9620E-02,0,128
[SCPISocketTransport::SendCommand]     Sending WAV:STAR 1
[SCPISocketTransport::SendCommand]     Sending WAV:STOP 4000000
[SCPISocketTransport::SendCommand]     Sending WAV:DATA?
[SCPISocketTransport::SendCommand]     Sending WAV:SOUR CHAN4
[SCPISocketTransport::SendCommand]     Sending WAV:PRE?
[SCPISocketTransport::ReadReply]     Got 0,2,4000000,1,5.000000E-10,-1.000000E-3,0.000000,3.9927E-02,0,128
[SCPISocketTransport::SendCommand]     Sending WAV:STAR 1
[SCPISocketTransport::SendCommand]     Sending WAV:STOP 4000000
[SCPISocketTransport::SendCommand]     Sending WAV:DATA?
[SCPISocketTransport::SendCommand]     Sending SING
[SCPISocketTransport::SendCommand]     Sending CHAN1:SCALE?
[SCPISocketTransport::ReadReply]     Got 1
[SCPISocketTransport::SendCommand]     Sending CHAN1:OFFS?
[SCPISocketTransport::ReadReply]     Got 0
[SCPISocketTransport::SendCommand]     Sending TRIG:EDGE:SOUR?
[SCPISocketTransport::ReadReply]     Got CHAN4
    Trigger source: CHAN4
[SCPISocketTransport::SendCommand]     Sending CHAN2:SCALE?
[SCPISocketTransport::ReadReply]     Got 1
[SCPISocketTransport::SendCommand]     Sending CHAN2:OFFS?
[SCPISocketTransport::ReadReply]     Got 0
[SCPISocketTransport::SendCommand]     Sending CHAN3:SCALE?
[SCPISocketTransport::ReadReply]     Got 1
[SCPISocketTransport::SendCommand]     Sending CHAN3:OFFS?
[SCPISocketTransport::ReadReply]     Got 0
[SCPISocketTransport::SendCommand]     Sending CHAN4:SCALE?
[SCPISocketTransport::ReadReply]     Got 1
[SCPISocketTransport::SendCommand]     Sending CHAN4:OFFS?
[SCPISocketTransport::ReadReply]     Got 0
[SCPISocketTransport::SendCommand]     Sending TRIG:EDGE:LEV?
[SCPISocketTransport::ReadReply]     Got 1.200000E0
[SCPISocketTransport::SendCommand] Sending CHAN1:DISP?
[SCPISocketTransport::ReadReply] Got 1
[SCPISocketTransport::SendCommand] Sending CHAN2:DISP?
[SCPISocketTransport::ReadReply] Got 1
[SCPISocketTransport::SendCommand] Sending CHAN3:DISP?
[SCPISocketTransport::ReadReply] Got 1
[SCPISocketTransport::SendCommand] Sending CHAN4:DISP?
[SCPISocketTransport::ReadReply] Got 1
[SCPISocketTransport::SendCommand] Sending TRIG:STAT?
[SCPISocketTransport::ReadReply] Got STOP
[SCPISocketTransport::SendCommand]     Sending WAV:SOUR CHAN1
[SCPISocketTransport::SendCommand]     Sending WAV:PRE?
[SCPISocketTransport::ReadReply]     Got 0,2,4000000,1,5.000000E-10,-1.000000E-3,0.000000,3.9962E-02,0,128
[SCPISocketTransport::SendCommand]     Sending WAV:STAR 1
[SCPISocketTransport::SendCommand]     Sending WAV:STOP 4000000
[SCPISocketTransport::SendCommand]     Sending WAV:DATA?
[SCPISocketTransport::SendCommand]     Sending WAV:SOUR CHAN2
[SCPISocketTransport::SendCommand]     Sending WAV:PRE?
[SCPISocketTransport::ReadReply]     Got 0,2,4000000,1,5.000000E-10,-1.000000E-3,0.000000,3.9832E-02,0,128
[SCPISocketTransport::SendCommand]     Sending WAV:STAR 1
[SCPISocketTransport::SendCommand]     Sending WAV:STOP 4000000
[SCPISocketTransport::SendCommand]     Sending WAV:DATA?
[SCPISocketTransport::SendCommand]     Sending WAV:SOUR CHAN3
[SCPISocketTransport::SendCommand]     Sending WAV:PRE?
[SCPISocketTransport::ReadReply]     Got 0,2,4000000,1,5.000000E-10,-1.000000E-3,0.000000,3.9620E-02,0,128
[SCPISocketTransport::SendCommand]     Sending WAV:STAR 1
[SCPISocketTransport::SendCommand]     Sending WAV:STOP 4000000
[SCPISocketTransport::SendCommand]     Sending WAV:DATA?
[SCPISocketTransport::SendCommand]     Sending WAV:SOUR CHAN4
[SCPISocketTransport::SendCommand]     Sending WAV:PRE?
[SCPISocketTransport::ReadReply]     Got 0,2,4000000,1,5.000000E-10,-1.000000E-3,0.000000,3.9927E-02,0,128
[SCPISocketTransport::SendCommand]     Sending WAV:STAR 1
[SCPISocketTransport::SendCommand]     Sending WAV:STOP 4000000
[SCPISocketTransport::SendCommand]     Sending WAV:DATA?
[SCPISocketTransport::SendCommand]     Sending SING
[SCPISocketTransport::SendCommand] Sending TRIG:STAT?
[SCPISocketTransport::ReadReply] Got TD
[SCPISocketTransport::SendCommand]     Sending WAV:SOUR CHAN1
[SCPISocketTransport::SendCommand]     Sending WAV:PRE?
[SCPISocketTransport::ReadReply]     Got 0,2,4000000,1,5.000000E-10,-1.000000E-3,0.000000,3.9962E-02,0,128
[SCPISocketTransport::SendCommand]     Sending WAV:STAR 1
[SCPISocketTransport::SendCommand]     Sending WAV:STOP 4000000
[SCPISocketTransport::SendCommand]     Sending WAV:DATA?
Shutting down view for waveform CHAN1
    Average frame interval: 3558.728 ms (0.28 FPS, 3 frames)
    ----------------------------------------------------------
    Task              | Total (ms) | Average (ms) | Percentage
    ----------------------------------------------------------
    Render            |     6254.8 |     2084.941 | 100.0 %
    Cairo             |       54.0 |       18.000 | 0.9 %
    Texture download  |        2.9 |        0.966 | 0.0 %
    Prepare           |      390.3 |      130.093 | 6.2 %
    Build index       |        0.0 |        0.012 | 0.0 %
    Geometry download |       28.3 |        9.450 | 0.5 %
    Composite         |        1.6 |        0.517 | 0.0 %
Killed

When I clicked the cross, it again showed the "this app is not responding" dialog and I had to kill it.
As suggested on IRC, I also ran it in gdb, to see where it deadlocks the UI.
All the threads:
* 1    Thread 0x7ffff5152a00 (LWP 10242) "glscopeclient" 0x00007ffff5f16620 in __lll_lock_wait () from /usr/lib/libpthread.so.0
  2    Thread 0x7ffff4e23700 (LWP 10248) "gmain"         0x00007ffff5e3105f in poll () from /usr/lib/libc.so.6
  3    Thread 0x7fffeffff700 (LWP 10249) "gdbus"         0x00007ffff5e3105f in poll () from /usr/lib/libc.so.6
  5    Thread 0x7fffe7fff700 (LWP 10262) "ScopeThread"   0x00007ffff5f16b0c in recv () from /usr/lib/libpthread.so.0

All the stacktraces:
0x00007ffff5f16620 in __lll_lock_wait () from /usr/lib/libpthread.so.0
(gdb) bt
#0  0x00007ffff5f16620 in __lll_lock_wait () at /usr/lib/libpthread.so.0
#1  0x00007ffff5f0ee81 in pthread_mutex_lock () at /usr/lib/libpthread.so.0
#2  0x00007ffff63b4367 in __gthread_mutex_lock(__gthread_mutex_t*) (__mutex=0x555555b26848)
    at /usr/include/c++/10.1.0/x86_64-pc-linux-gnu/bits/gthr-default.h:749
#3  0x00007ffff63b43b7 in __gthread_recursive_mutex_lock(__gthread_recursive_mutex_t*) (__mutex=0x555555b26848)
    at /usr/include/c++/10.1.0/x86_64-pc-linux-gnu/bits/gthr-default.h:811
#4  0x00007ffff63b43ec in std::recursive_mutex::lock() (this=0x555555b26848) at /usr/include/c++/10.1.0/mutex:106
#5  0x00007ffff63b4448 in std::lock_guard<std::recursive_mutex>::lock_guard(std::recursive_mutex&) (this=0x7fffffffbce8, __m=...)
    at /usr/include/c++/10.1.0/bits/std_mutex.h:159
#6  0x00007ffff63f54df in RigolOscilloscope::Start() (this=0x555555b26800)
    at /home/pepijn/code/scopehal-apps/lib/scopehal/RigolOscilloscope.cpp:659
#7  0x0000555555680020 in OscilloscopeWindow::ArmTrigger(bool) (this=0x555555b61550, oneshot=false)
    at /home/pepijn/code/scopehal-apps/src/glscopeclient/OscilloscopeWindow.cpp:2203
#8  0x000055555567fe1f in OscilloscopeWindow::OnStart() (this=0x555555b61550)
    at /home/pepijn/code/scopehal-apps/src/glscopeclient/OscilloscopeWindow.cpp:2165
#9  0x000055555569df04 in sigc::bound_mem_functor0<void, OscilloscopeWindow>::operator()() const (this=0x5555558480d8)
    at /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:1991
#10 0x000055555569bea6 in sigc::adaptor_functor<sigc::bound_mem_functor0<void, OscilloscopeWindow> >::operator()() const
    (this=0x5555558480d0) at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
#11 0x00005555556978d4 in sigc::internal::slot_call0<sigc::bound_mem_functor0<void, OscilloscopeWindow>, void>::call_it(sigc::internal::slot_rep*) (rep=0x5555558480a0) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:136
#12 0x00007ffff75802b9 in Glib::SignalProxyNormal::slot0_void_callback(_GObject*, void*) () at /usr/lib/libglibmm-2.4.so.1
#13 0x00007ffff6793052 in g_closure_invoke () at /usr/lib/libgobject-2.0.so.0
#14 0x00007ffff67bb898 in  () at /usr/lib/libgobject-2.0.so.0
#15 0x00007ffff67af41d in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0
#16 0x00007ffff67afba5 in g_signal_emit_by_name () at /usr/lib/libgobject-2.0.so.0
#17 0x00007ffff67af80a in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0
#18 0x00007ffff67af980 in g_signal_emit () at /usr/lib/libgobject-2.0.so.0
#19 0x00007ffff6e59eb9 in  () at /usr/lib/libgtk-3.so.0
#20 0x00007ffff6793052 in g_closure_invoke () at /usr/lib/libgobject-2.0.so.0
#21 0x00007ffff67bb2fc in  () at /usr/lib/libgobject-2.0.so.0
#22 0x00007ffff67af41d in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0
#23 0x00007ffff67af980 in g_signal_emit () at /usr/lib/libgobject-2.0.so.0
#24 0x00007ffff6e59a41 in  () at /usr/lib/libgtk-3.so.0
#25 0x00007ffff6e17b3b in  () at /usr/lib/libgtk-3.so.0
#26 0x00007ffff67af80a in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0
#27 0x00007ffff67af980 in g_signal_emit () at /usr/lib/libgobject-2.0.so.0
#28 0x00007ffff6f2835d in  () at /usr/lib/libgtk-3.so.0

  #0  0x00007ffff5e3105f in poll () at /usr/lib/libc.so.6
#1  0x00007ffff66f7168 in  () at /usr/lib/libglib-2.0.so.0
#2  0x00007ffff66a8221 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0
#3  0x00007ffff66a8272 in  () at /usr/lib/libglib-2.0.so.0
#4  0x00007ffff66d1511 in  () at /usr/lib/libglib-2.0.so.0
#5  0x00007ffff5f0c422 in start_thread () at /usr/lib/libpthread.so.0
#6  0x00007ffff5e3bbf3 in clone () at /usr/lib/libc.so.6

#0  0x00007ffff5e3105f in poll () at /usr/lib/libc.so.6
#1  0x00007ffff66f7168 in  () at /usr/lib/libglib-2.0.so.0
#2  0x00007ffff66a7c03 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#3  0x00007ffff6a5f1a8 in  () at /usr/lib/libgio-2.0.so.0
#4  0x00007ffff66d1511 in  () at /usr/lib/libglib-2.0.so.0
#5  0x00007ffff5f0c422 in start_thread () at /usr/lib/libpthread.so.0
#6  0x00007ffff5e3bbf3 in clone () at /usr/lib/libc.so.6

#0  0x00007ffff5f16b0c in recv () at /usr/lib/libpthread.so.0
#1  0x00007ffff640fe43 in Socket::RecvLooped(unsigned char*, int) (this=0x555555b6b748, buf=0x7fffdc001270 "\n", len=4000001)
    at /home/pepijn/code/scopehal-apps/lib/xptools/Socket.cpp:311
#2  0x00007ffff63a303d in SCPISocketTransport::ReadRawData(unsigned long, unsigned char*) (this=
    0x555555b6b740, len=4000001, buf=0x7fffdc001270 "\n") at /home/pepijn/code/scopehal-apps/lib/scopehal/SCPISocketTransport.cpp:135
#3  0x00007ffff63f4d77 in RigolOscilloscope::AcquireData(bool) (this=0x555555b26800, toQueue=true)
    at /home/pepijn/code/scopehal-apps/lib/scopehal/RigolOscilloscope.cpp:599
#4  0x00005555556f0ec7 in ScopeThread(Oscilloscope*) (scope=0x555555b26800)
    at /home/pepijn/code/scopehal-apps/src/glscopeclient/main.cpp:358
#5  0x00005555556afd7c in std::__invoke_impl<void, void (*)(Oscilloscope*), Oscilloscope*>(std::__invoke_other, void (*&&)(Oscilloscope*), Oscilloscope*&&) (__f=@0x555555c40b40: 0x5555556f0caf <ScopeThread(Oscilloscope*)>) at /usr/include/c++/10.1.0/bits/invoke.h:60
#6  0x00005555556afcd5 in std::__invoke<void (*)(Oscilloscope*), Oscilloscope*>(void (*&&)(Oscilloscope*), Oscilloscope*&&)
    (__fn=@0x555555c40b40: 0x5555556f0caf <ScopeThread(Oscilloscope*)>) at /usr/include/c++/10.1.0/bits/invoke.h:95
#7  0x00005555556afc45 in std::thread::_Invoker<std::tuple<void (*)(Oscilloscope*), Oscilloscope*> >::_M_invoke<0ul, 1ul>(std::_Index_tuple<0ul, 1ul>) (this=0x555555c40b38) at /usr/include/c++/10.1.0/thread:264
#8  0x00005555556afbfe in std::thread::_Invoker<std::tuple<void (*)(Oscilloscope*), Oscilloscope*> >::operator()()
    (this=0x555555c40b38) at /usr/include/c++/10.1.0/thread:271
#9  0x00005555556afbe2 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (*)(Oscilloscope*), Oscilloscope*> > >::_M_run() (this=0x555555c40b30) at /usr/include/c++/10.1.0/thread:215
#10 0x00007ffff6196b74 in std::execute_native_thread_routine(void*) (__p=0x555555c40b30)
    at /build/gcc/src/gcc/libstdc++-v3/src/c++11/thread.cc:80
#11 0x00007ffff5f0c422 in start_thread () at /usr/lib/libpthread.so.0
#12 0x00007ffff5e3bbf3 in clone () at /usr/lib/libc.so.6

It appears that this is not actually directly a scopehal problem at all. When changing the sample depth to 1K it does a little over 1 waveform per second. At 10k and 100k it becomes only marginally slower, but at 1M it becomes significantly slower and at 10M it hangs completely.
So as discussed on IRC, the issue can be pivoted to "rigol driver is slow, can we make it faster?". Maybe the answer is just "no". I installed their own scope software, and it seems to be similarly slow and of low sample depth.
A possibly unrelated problem is that the sending of commands does not appear to happen immediately. When loading the configuration from the scope, no commands are sent until a few seconds AND after the mouse is hovered over the start button. Strange but true. Maybe there is also an unnecessary delay in sending other commands, making it slow.

After the latest caching changes I now get the following traces with 1k sample depth. It's definitely some racy mutex thing, as the may thread gets stuck on a different functioin call every time, but always with the scope thread in aquire.
(gdb) info threads
  Id   Target Id                                         Frame
* 1    Thread 0x7ffff5150a00 (LWP 22287) "glscopeclient" 0x00007ffff5f14620 in __lll_lock_wait () from /usr/lib/libpthread.so.0
  2    Thread 0x7ffff4e21700 (LWP 22291) "gmain"         0x00007ffff5e2f05f in poll () from /usr/lib/libc.so.6
  3    Thread 0x7fffeffff700 (LWP 22292) "gdbus"         0x00007ffff5e2f05f in poll () from /usr/lib/libc.so.6
  5    Thread 0x7fffe7fff700 (LWP 22294) "ScopeThread"   0x00007ffff5f14b0c in recv () from /usr/lib/libpthread.so.0
(gdb) bt
#0  0x00007ffff5f14620 in __lll_lock_wait () at /usr/lib/libpthread.so.0
#1  0x00007ffff5f0ce81 in pthread_mutex_lock () at /usr/lib/libpthread.so.0
#2  0x00007ffff63b23b7 in __gthread_mutex_lock(__gthread_mutex_t*) (__mutex=0x5555559116c8)
    at /usr/include/c++/10.1.0/x86_64-pc-linux-gnu/bits/gthr-default.h:749
#3  0x00007ffff63b2407 in __gthread_recursive_mutex_lock(__gthread_recursive_mutex_t*) (__mutex=0x5555559116c8)
    at /usr/include/c++/10.1.0/x86_64-pc-linux-gnu/bits/gthr-default.h:811
#4  0x00007ffff63b243c in std::recursive_mutex::lock() (this=0x5555559116c8) at /usr/include/c++/10.1.0/mutex:106
#5  0x00007ffff63b2498 in std::lock_guard<std::recursive_mutex>::lock_guard(std::recursive_mutex&)
    (this=0x7fffffffb9d8, __m=...) at /usr/include/c++/10.1.0/bits/std_mutex.h:159
#6  0x00007ffff63f2d47 in RigolOscilloscope::GetChannelOffset(unsigned long) (this=0x555555911680, i=1)
    at /home/pepijn/code/scopehal-apps/lib/scopehal/RigolOscilloscope.cpp:524
#7  0x00007ffff63b18ca in OscilloscopeChannel::GetOffset() (this=0x5555557a9300)
    at /home/pepijn/code/scopehal-apps/lib/scopehal/OscilloscopeChannel.cpp:93
#8  0x00005555556dd3af in WaveformArea::YPositionToVolts(float) (this=0x555555ce5800, y=2)
    at /home/pepijn/code/scopehal-apps/src/glscopeclient/WaveformArea_rendering.cpp:644
#9  0x00005555556e03d2 in WaveformArea::RenderGrid(Cairo::RefPtr<Cairo::Context>) (this=0x555555ce5800, cr=...)
    at /home/pepijn/code/scopehal-apps/src/glscopeclient/WaveformArea_cairo.cpp:142
#10 0x00005555556dfb3c in WaveformArea::DoRenderCairoUnderlays(Cairo::RefPtr<Cairo::Context>)
    (this=0x555555ce5800, cr=...) at /home/pepijn/code/scopehal-apps/src/glscopeclient/WaveformArea_cairo.cpp:57
#11 0x00005555556dca80 in WaveformArea::ComputeAndDownloadCairoUnderlays() (this=0x555555ce5800)
    at /home/pepijn/code/scopehal-apps/src/glscopeclient/WaveformArea_rendering.cpp:511
#12 0x00005555556dbc93 in WaveformArea::on_render(Glib::RefPtr<Gdk::GLContext> const&) (this=0x555555ce5800)
    at /home/pepijn/code/scopehal-apps/src/glscopeclient/WaveformArea_rendering.cpp:277
#13 0x00007ffff7ba6c7e in Gtk::GLArea_Class::render_callback(_GtkGLArea*, _GdkGLContext*) ()
    at /usr/lib/libgtkmm-3.0.so.1
#14 0x00007ffff6e18ab6 in  () at /usr/lib/libgtk-3.so.0
#15 0x00007ffff67ae80a in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0
#16 0x00007ffff67ae980 in g_signal_emit () at /usr/lib/libgobject-2.0.so.0
#17 0x00007ffff6f2ba5f in  () at /usr/lib/libgtk-3.so.0
#18 0x00007ffff7c249fb in Gtk::Widget::on_draw(Cairo::RefPtr<Cairo::Context> const&) () at /usr/lib/libgtkmm-3.0.so.1
#19 0x00007ffff7c2fca5 in Gtk::Widget_Class::draw_callback(_GtkWidget*, _cairo*) () at /usr/lib/libgtkmm-3.0.so.1
#20 0x00007ffff70cb30a in  () at /usr/lib/libgtk-3.so.0
#21 0x00007ffff6e97f91 in gtk_container_propagate_draw () at /usr/lib/libgtk-3.so.0
#22 0x00007ffff6e9809e in  () at /usr/lib/libgtk-3.so.0
#23 0x00007ffff6e460fd in  () at /usr/lib/libgtk-3.so.0
#24 0x00007ffff6e988dd in  () at /usr/lib/libgtk-3.so.0
#25 0x00007ffff6ea45eb in  () at /usr/lib/libgtk-3.so.0
#26 0x00007ffff6e465b1 in  () at /usr/lib/libgtk-3.so.0
#27 0x00007ffff70cb30a in  () at /usr/lib/libgtk-3.so.0
#28 0x00007ffff6e97f91 in gtk_container_propagate_draw () at /usr/lib/libgtk-3.so.0
#29 0x00007ffff6e9809e in  () at /usr/lib/libgtk-3.so.0
#30 0x00007ffff6e460fd in  () at /usr/lib/libgtk-3.so.0
#31 0x00007ffff6e988dd in  () at /usr/lib/libgtk-3.so.0
#32 0x00007ffff6ea45eb in  () at /usr/lib/libgtk-3.so.0
#33 0x00007ffff6e465b1 in  () at /usr/lib/libgtk-3.so.0
#34 0x00007ffff70cb30a in  () at /usr/lib/libgtk-3.so.0
#35 0x00007ffff6e97f91 in gtk_container_propagate_draw () at /usr/lib/libgtk-3.so.0
#36 0x00007ffff6e9809e in  () at /usr/lib/libgtk-3.so.0
#37 0x00007ffff6f23469 in  () at /usr/lib/libgtk-3.so.0
#38 0x00007ffff6e988dd in  () at /usr/lib/libgtk-3.so.0
#39 0x00007ffff6ea45eb in  () at /usr/lib/libgtk-3.so.0
#40 0x00007ffff6f1eee1 in  () at /usr/lib/libgtk-3.so.0
--Type <RET> for more, q to quit, c to continue without paging--q
Quit
(gdb) thread 2
[Switching to thread 2 (Thread 0x7ffff4e21700 (LWP 22291))]
#0  0x00007ffff5e2f05f in poll () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007ffff5e2f05f in poll () at /usr/lib/libc.so.6
#1  0x00007ffff66f6168 in  () at /usr/lib/libglib-2.0.so.0
#2  0x00007ffff66a7221 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0
#3  0x00007ffff66a7272 in  () at /usr/lib/libglib-2.0.so.0
#4  0x00007ffff66d0511 in  () at /usr/lib/libglib-2.0.so.0
#5  0x00007ffff5f0a422 in start_thread () at /usr/lib/libpthread.so.0
#6  0x00007ffff5e39bf3 in clone () at /usr/lib/libc.so.6
(gdb) thread 3
[Switching to thread 3 (Thread 0x7fffeffff700 (LWP 22292))]
#0  0x00007ffff5e2f05f in poll () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007ffff5e2f05f in poll () at /usr/lib/libc.so.6
#1  0x00007ffff66f6168 in  () at /usr/lib/libglib-2.0.so.0
#2  0x00007ffff66a6c03 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#3  0x00007ffff6a5e1a8 in  () at /usr/lib/libgio-2.0.so.0
#4  0x00007ffff66d0511 in  () at /usr/lib/libglib-2.0.so.0
#5  0x00007ffff5f0a422 in start_thread () at /usr/lib/libpthread.so.0
#6  0x00007ffff5e39bf3 in clone () at /usr/lib/libc.so.6
(gdb) thread 5
[Switching to thread 5 (Thread 0x7fffe7fff700 (LWP 22294))]
#0  0x00007ffff5f14b0c in recv () from /usr/lib/libpthread.so.0
(gdb) bt
#0  0x00007ffff5f14b0c in recv () at /usr/lib/libpthread.so.0
#1  0x00007ffff640ed29 in Socket::RecvLooped(unsigned char*, int)
    (this=0x555555998538, buf=0x7fffdc000c40 "\n", len=1001)
    at /home/pepijn/code/scopehal-apps/lib/xptools/Socket.cpp:311
#2  0x00007ffff63a108d in SCPISocketTransport::ReadRawData(unsigned long, unsigned char*) (this=
    0x555555998530, len=1001, buf=0x7fffdc000c40 "\n")
    at /home/pepijn/code/scopehal-apps/lib/scopehal/SCPISocketTransport.cpp:135
#3  0x00007ffff63f3ab0 in RigolOscilloscope::AcquireData(bool) (this=0x555555911680, toQueue=true)
    at /home/pepijn/code/scopehal-apps/lib/scopehal/RigolOscilloscope.cpp:682
#4  0x00005555556f0ec7 in ScopeThread(Oscilloscope*) (scope=0x555555911680)
    at /home/pepijn/code/scopehal-apps/src/glscopeclient/main.cpp:358
#5  0x00005555556afd7c in std::__invoke_impl<void, void (*)(Oscilloscope*), Oscilloscope*>(std::__invoke_other, void (*&&)(Oscilloscope*), Oscilloscope*&&) (__f=@0x555555ba98e0: 0x5555556f0caf <ScopeThread(Oscilloscope*)>)
    at /usr/include/c++/10.1.0/bits/invoke.h:60
#6  0x00005555556afcd5 in std::__invoke<void (*)(Oscilloscope*), Oscilloscope*>(void (*&&)(Oscilloscope*), Oscilloscope*&&) (__fn=@0x555555ba98e0: 0x5555556f0caf <ScopeThread(Oscilloscope*)>) at /usr/include/c++/10.1.0/bits/invoke.h:95
#7  0x00005555556afc45 in std::thread::_Invoker<std::tuple<void (*)(Oscilloscope*), Oscilloscope*> >::_M_invoke<0ul, 1ul>(std::_Index_tuple<0ul, 1ul>) (this=0x555555ba98d8) at /usr/include/c++/10.1.0/thread:264
#8  0x00005555556afbfe in std::thread::_Invoker<std::tuple<void (*)(Oscilloscope*), Oscilloscope*> >::operator()()
    (this=0x555555ba98d8) at /usr/include/c++/10.1.0/thread:271
#9  0x00005555556afbe2 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (*)(Oscilloscope*), Oscilloscope*> > >::_M_run() (this=0x555555ba98d0) at /usr/include/c++/10.1.0/thread:215
#10 0x00007ffff6194b74 in std::execute_native_thread_routine(void*) (__p=0x555555ba98d0)
    at /build/gcc/src/gcc/libstdc++-v3/src/c++11/thread.cc:80
#11 0x00007ffff5f0a422 in start_thread () at /usr/lib/libpthread.so.0
#12 0x00007ffff5e39bf3 in clone () at /usr/lib/libc.so.6

This is the trace from wireshark, which includes my model scope and version. It just simply does not send any data.
*IDN?
RIGOL TECHNOLOGIES,MSO5074,MS5A221301338,<IP_ADDRESS>.01
SYST:OPT:STAT?
RUN
CHAN1:SCALE?
5E-1
TRIG:STAT?
TD
ACQ:MDEP?
1.0000E+03
WAV:SOUR CHAN1
WAV:PRE?
0,2,1000,1,2.000000E-4,-1.000000E-1,0.000000,1.9963E-02,-50,128
WAV:STAR 1
WAV:STOP 1000
WAV:DATA?
#9000001000wyxvxwvtuutsussqxxvvvwvtussrwxwvvwustruxxvutusuwwvuttrwwwutswwvuutwzxuttwxwvuwxyvuxyxvux{uvyzxwvyzxv{zxxzzyxzzxxz{yxzzx}|z}.}~.}{}~|z{~z}||~~...}}.}.~~.....~~.~...............................................................................................................................................................................................................................................................................................................................................................................................................................................................................~...........~...~..~~.~~}~~~{~}}|.|{z|||z||zz|{zz|{yx{{yxyzywyywvwxxuwwuuwvuuvvusuusrutsrxywvwwuuwutruurrwyvwxvututsrwywvwutttrruxuuuusruxwvttqvxxvustuwwwuswyxutuvwxwtxyxuuyywwvyxwuvxywwyzyxy{zxz{zy{|zxz}zxy|zxz|{xz{z||{~~{}~|..~z}~}}}|.....}~..........}...........................................................................................................................
WAV:SOUR CHAN2
WAV:PRE?
0,2,1000,1,2.000000E-4,-1.000000E-1,0.000000,1.9957E-02,-50,128
WAV:STAR 1
WAV:STOP 1000
WAV:DATA?
#9000001000z...y...w...t...x...x...t...w...w...s...v...s...w...s...v...v...t...w...u...t...v...v...x...x...w...x...w...x...x...x...z...x...w...v..~z..|z..{y..{|..{|..zz..}|..~{..|}..{}..y~..{}..{~..y~..{...y...x...|...x...{...y...z...x...z...u...x...z...z...w...x...z...{...|...z...z...y...{...}...}...|...z...y...}...}...|...~...~...|.......~..........~...}.......~.......}...z...|...y...|...y...{...x...y...{...|...x...x...y...z...z...z...z...z...y...y...z...{...x...x...w...v...u.......x...w...v..~y...w..|...|y..|x.......x..}...{y..{{..yy..{{..|...y{..{}..z...w...z|..z...z...y...z...x...y...w...z...t...x...y...{...z...w...x...y...y...x...x...x...x...x...{...~...{...{...~..~~..~}..}~..|~..{...z...z...y...y...v...v...z...y...w...u...x...w...u...w...w...s...w...s...w...s...v...s...u...w...s...t...w...x...v...s...t...u...v...v...u...v...u...u...x...{..~y..~x..~{..}{..|y..{{..}{..}y..|}..{{..x...{|..{...y...{...{...x}..z...x...y...y...z...x...y...w...z...x...v...x...{...y...v...x...y...y...y...y...x...y
WAV:SOUR CHAN3
WAV:PRE?
0,2,1000,1,2.000000E-4,-1.000000E-1,0.000000,1.9984E-02,-50,128
WAV:STAR 1
WAV:STOP 1000
WAV:DATA?
#9000001000qsrqrprqrqqrrrrrsrrrrrqqsqsrrrqrqsrrrsrrsrrrtsrqssrsssqrsttssttttststttttstttustttuttvuvwtvwvvwvxwwwwyxvwwxywyyywyxyyxzzyzzzzzzz{{z|{{||||||{}}||}}}~}}~~~~......................................................................................................................................................................................................................................................................................................................................................................................................................................~..}~~~}~|}|}|}|{|}|{|{|z{z{{{{yz|yzzyzyyyyyxxyyyxwxxxwvwwwvvwvwwvvvwuvuuuvvutvutvtuuttutrtttstsssttrsstssrtrtsqsrssrsqsrsssrrqsrrrrsrrqprqrqqrrqrpqrrrrrqqrqrrrrqpqrqrqrrrqrssrrqsrrqttrrstrsqtrssssrrtsssustttssttttuuttutuuutuuvuwvwwuwvwxwxwxwxxwyyxxxyzxyyyz{z{yz{{z{zyzz{|z|{|||}|||}}}|~~}~~.~~.................................................................................................................................
WAV:SOUR CHAN4
WAV:PRE?
0,2,1000,1,2.000000E-4,-1.000000E-1,0.000000,1.9969E-02,-50,128
WAV:STAR 1
WAV:STOP 1000
WAV:DATA?
#9000001000.M...M...L...M...N...M...O..}M..zN..yP..vQ..sQ..rS..qS..oU..mU..kW..iX..gY..eZ..d[..a^..`].._`..]b..]c..Zc..Yf..Xg..Vk..Vk..Um..So..Rq..Rt..Qu..Qx..Oz..O{..N}..N...N...M...N...N...M...L...M...M...M...M...M..|O..zO..xQ..vP..tQ..rR..pS..nT..mU..jW..hX..gY..d[..d[..b]..`_..^_..^b..]d..Zf..Zf..Wh..Wi..Um..Un..Tp..Ss..Rt..Qv..Ox..Pz..N}..N...M...N...M...N...M...M...M...N...N...N...N...N..{O..zO..xP..vQ..tP..sR..pS..nT..lV..jV..iW..fX..e[..d\..a^..a_..^`..\a..\b..[d..Yg..Wj..Wk..Ul..Tn..Rp..Rr..Qt..Pv..Px..Oz..N|..N~..O...N...N...M...M...M...K...M...M...N...N..~N..|O..yP..xP..uQ..sQ..qR..qS..nT..lU..jW..iY..gZ..e[..b\..b]..`_..^a..]a..\c..Ze..Zg..Xi..Xk..Vl..To..Sq..Rq..Qs..Pv..Px..Pz..N|..N...M...N...M...M...M...M...L...M...N...M...M..}N..{O..yP..wQ..vQ..sR..qS..oS..nT..mV..iW..iY..fY..d[..d[..a]..`^.._`..]b..[c..[d..Yg..Xj..Vk..Ul..To..Sp..Rr..Rt..Qw..Ox..P{..O|..O...N...M...M...M...M...L...L...M...N...N...N..}O..{O..yO..xP..tQ..sR..rS..oT..nT..kV..kV..gX..gY..d[..c\..a^..`_.._a..]b..\d..[
SING
TRIG:STAT?
STOP
WAV:SOUR CHAN1
WAV:PRE?
0,2,1000,1,2.000000E-4,-1.000000E-1,0.000000,1.9963E-02,-50,128
WAV:STAR 1
WAV:STOP 1000
WAV:DATA?
#9000001000

After fixing the timeout behaviour, I got the following long trace. I can't tell any obvious reason why it'd just not return data.
glscopeclient3.txt

I have discovered that the bug can be reproduced by zooming in and out on the timescale.
Zoomed in the program runs fine (first half of the Wireshark capture), and zoomed out it stops sending data (second half of the Wireshark capture)
glscopeclient_zoom.zip
It is interesting to look at the timing of operations. The SING command takes several hundreds of ms to become responsive again, looking at the time from SING to the first reply to TRIG?.
It is hard to tell from the trace, but my impression is that when the time between the TRIG:STAT? reply and the WAV:DATA? command is short, it bugs out and sends nothing. Does anyone know the Wireshark-fu to measure latency between various commands and them working or not?
Concretely speaking, assuming we're indeed reading too fast, the question is... now what? Do we just insert a delay? Can we measure when it's actually ready? Hrmmmm

I got the following reply from Rigol, suggesting that the MODE and FORM command have to be sent every time. I asked for clarification on this point and sent them my Wireshark trace.

Following is the answer from our technical colleague for your question:
If you want to get the wave data from the screen . the command sequence is =
below:
S1. :WAV:SOUR CHAN1
S2. :WAV:MODE NORMal
S3. :WAV:FORM BYTE
S4. :WAV:DATA?
If you want to get the wave data from the memory . the command sequence is =
below:
S1. :WAV:SOUR CHAN1
S2. :WAV:MODE RAW
S3. :WAV:FORM BYTE
S4. :STOP
S5. :WAVeform:POINts 10000
S6. :WAV:DATA?

So I wanted to look at how their own software works, which appears to be running continuously. How does it synchronize? It does not. The two slow sines are in phase on the scope, and almost in antiphase on the PC, I can see why glscopeclient uses single runs.

But of course the main thing I came for is the Wireshark trace of their software:
rigol_windows.zip
Unlike scopehal, it uses some VXI RCP thing that basically sends the same commands with extra steps it appears.
It's very slow and boring, but seems to work fine.
The only thing worth noting is that they don't send MODE and FORM as Rigol told me, they only do this once.
So what have we learned? Not much. Their software is slow but works.

It gets weirder! I tried the LXI transport, and the good news is that it doesn't hang or timeout, but I assure you that channel 1-3 have no signal on them.

The program does not hang or error. It just... gets the data for the wrong channel??? It randomly alternates between everything being as it should, or channel 1, 1 and 2, or 1, 2 and 3 showing channel 4 data.
So I guess while it's busy triggering and updating, it may just return stale or no data at all?
In the Wireshark trace it shows that the RPC encapsulation stops it from hanging, but does not stop it from sending empty DATA? replies. Telling from the trace when it sends wrong data is less easy, so I can't rule out that's a buffer overflow error in glscopeclient when it gets less data than expected.
glscopeclient_lxi.zip

Right, so the LXI transport will just copy less bytes when it gets a shorter reply.
https://github.com/azonenberg/scopehal/blob/c15697842071f9b77f048e30f502817d0bd4b98b/scopehal/SCPILxiTransport.cpp#L205
And the Rigol driver just assumes temp_buffer is all good and fresh.
https://github.com/azonenberg/scopehal/blob/c15697842071f9b77f048e30f502817d0bd4b98b/scopehal/RigolOscilloscope.cpp#L682
So if the scope returns no data, glscopeclient will just reuse whatever was in temp_buffer.
A hacky solution would be to zero the buffer before reading and YOLO. I think the proper solution is to change the API to return the number of bytes read, and handle it correctly in all drivers. Or turn len into a pointer type so it's updated with the actual length, much in the same way getsockopt works.

Rigol:

It should be noted that if the user is reading the memory data (raw mode), it is necessary to send the stop command to stop the oscilloscope. At the same time, it is suggested to delay 500 ms after the stop, because there is moving operation of the memory data.

Uuuuuhhhh?! So I guess you'd either use screen mode or insert a delay? Yuk.

I tested :WAVeform:MODE NORMal and it actually works significantly better. Of course the resolution is limited to 1000 points regardless of memory depth, but it never hangs and seems marginally faster. Still only 0.6 WFM/s but okay.

@pepijndevos @kench I've been told by several people that the hang is fixed with latest firmware from Rigol, please test and confirm.

I confirm with my Rigol MSO5074 with HW 01.01.00 and latest Firmware Upgrade <IP_ADDRESS> (Released on 12 Aug 2020) there is no freeze or crash on Rigol side

Seems like the general consensus is that it's fixed. If anybody still has problems it's likely a new bug, so open a new ticket.


Add SHA3 support

This commit adds SHA3 support for use with the RSA PKCS#1 crypto algorithms. This is an odd PR as SoftHSM2 does not yet support SHA3 and Thales HSMs only support PKCS#1 v1.5 (no PSS support).
My company makes hardware devices that will support SHA3 hash algorithms with RSASSA-PSS to be future compatible. This change adds native support for RSASSA-PKCS1-v1_5 since the algorithm IDs are prefixed to the hash before sending to request to the HSM.
However, RSASSA-PSS is a little more involved. The solution I came up with is a hybrid approach where the EMSA-PSS encoding is done in solftware but the encryption/decryption of the encrypted message is performed by the HSM.
I validated this change using SoftHSM and Go 1.12.5 and all of the test cases passed locally.

Thanks for the PR. Which HSM/libraries have you tested this with?

I tested using SoftHSM2 v2.5 and my company uses the Thales nShield Connect XC HSM in production. We have been running this patchset on our production HSMs for over 8 months now without any issues.

Sorry for the out of hand PR. This change is now based ontop of PR #41 to prevent merge conflict. However, there is no local branch so it looks like this change is pulling in additional commits from #41. Please ignore these additional commits and just focus on the following 2 commits:
78da155 feat: add RSA Hybrid solution to support SHA3 hash functions
f8a6ddc feat: add SHA3 hash support to RSA APIs

This will get cleaned up once PR #41 gets merged.

I created a local PR that will show just the 2 commits in my forked repo:
https://github.com/jls5177/crypto11/pull/1/files

That's helpful. I will add some comments there.


Proposal: Persist Metrics emitted by taps during runs

Migrated from GitLab: https://gitlab.com/meltano/meltano/-/issues/2148
Originally created by @nehiljain on 2020-07-07 22:03:31

Target audience
Meltano admins, devops engineers
Proposal
https://github.com/singer-io/getting-started/blob/master/docs/SYNC_MODE.md#metric-messages Storing these messages in meltano db. Using that in some sort of monitoring dashboard will be great for production deployments.
What does success look like, and how can we measure that?
A table with all the metrics emitted by runs. Enriched with the job it etc
A UI to build timeseries graph of a metric for a tap over time/runs

View 9 previous comments from the original issue on GitLab

Still relevant. I would think we'd build this into the SDK and have the tap and target emit a metrics log so we wouldn't have to parse the streams.

Related:

https://github.com/meltano/meltano/issues/2970
https://github.com/meltano/meltano/issues/7085

Closing in favor of https://github.com/meltano/meltano/issues/7085


Unify validation of OpCopyMemory*

Fixes #1800

Refactored duplication of code between OpCopyMemory and
OpCopyMemorySized validation
Fixed some bugs in OpCopyMemorySized validation
Replaced asserts with checks
Added new tests

Rebased, squashed and committed as 3a20879f4d0af1cc336ef3294d67bf199796be5d


720x runtime performance regression in QuantumCircuit.depth()

Information

Qiskit Terra version: main (after 7c30a6e7)
Python version: 3.8
Operating system: Linux

What is the current behavior?
The nightly benchmark runs flagged a regression in the QUEKO transpiler benchmarks caused by https://github.com/Qiskit/qiskit-terra/pull/6998:
https://qiskit.github.io/qiskit/#queko.QUEKOTranspilerBench.time_transpile_bigd?cpu=Intel(R) Xeon(R) E-2174G CPU %40 3.80GHz&machine=qiskit-benchmarking01&num_cpu=8&os=Ubuntu 20.04&ram=64GB&python=3.8&p-optimization level=0&p-routing%2Flayout method=None&commits=7c30a6e7
It is showing a 720x runtime performance slowdown (from 35.824ms to 25.810s). At first I was surprised because a transpiler benchmark shouldn't be using QuantumCircuit.depth() but looking at the benchmark code calling .depth() on the output circuit is part of the timed function: https://github.com/Qiskit/qiskit/blob/master/test/benchmarks/queko.py#L235 This is arguably a benchmark bug, but it did catch the regression in this case so it's useful for that.  The regression wasn't quite as bad on other variants so my guess is the regression scales with number of instructions in the circuit (probably because the filter function runs over circuit.data).
Steps to reproduce the problem
Run QuantumCircuit.depth()
What is the expected behavior?
depth() doesn't scale so poorly

if (instr, qargs, cargs) in filter(filter_function, self._data):

on L1814 can instead be
if filter_function((instr, qargs, cargs)):

so that we only loop over all the circuit elements once.


TypeError: Cannot read property '_isHexString' of undefined

Hi,
I'm using merkletreejs for the following test:
    it("return a baseURI + tokenURI for tokenId", async () => {
      const [redeemer, usr1, usr2, usr3, usr4] = await ethers.getSigners()
      const accounts = [redeemer.address, usr1.address, usr2.address, usr3.address, usr4.address]
      const merkleTree = new MerkleTree(accounts, keccak256, {
        hashLeaves: true,
        sortPairs: true,
      })

      const root = merkleTree.getHexRoot()
      const rootHashes = [root, "0x00", "0x00", "0x00", "0x00"]
      const leaf = keccak256(redeemer.address)

      const proof = merkleTree.getHexProof(leaf)
      await makerbadges.connect(signers.deployer).setRootHashes(rootHashes)
      await makerbadges.connect(signers.deployer).createTemplate(template_name, template_description, template_image)
      await makerbadges.connect(redeemer).activateBadge(proof, templateId, tokenURI)
      const tokenId = await makerbadges.tokenOfOwnerByIndex(redeemer.address, index1)
      expect(await makerbadges.tokenURI(tokenId)).to.be.eq("https://badges.makerdao.com/token/" + tokenURI)
    })

and I get the following error:
  1) MakerBadges
       ERC721 metadata
         return a baseURI + tokenURI for tokenId:
     TypeError: Cannot read property '_isHexString' of undefined
      at /home/sencha/maker-badges/node_modules/merkletreejs/dist/MerkleTree.js:961:22
      at Array.map (<anonymous>)
      at new MerkleTree (node_modules/merkletreejs/dist/MerkleTree.js:51:29)
      at Context.<anonymous> (test/MakerBadges.ts:75:26)
      at step (test/MakerBadges.ts:34:23)
      at Object.next (test/MakerBadges.ts:15:53)
      at fulfilled (test/MakerBadges.ts:6:58)
      at runMicrotasks (<anonymous>)
      at processTicksAndRejections (node:internal/process/task_queues:94:5)

I've also tried migrating to @nomiclabs/hardhat-truffle5 and @typechain/truffle-v5, I've got the same issue.
OS: Ubuntu 20.04
Source Code: https://github.com/naszam/maker-badges/blob/xdai/test/MakerBadges.ts
Thanks!

just tried the following (reading the prev issue):
    it("return a baseURI + tokenURI for tokenId", async () => {
      const hash0 = web3.utils.soliditySha3(signers.redeemer.address)
      const hash1 = web3.utils.soliditySha3(signers.deployer.address)
      const hash2 = web3.utils.soliditySha3(signers.templater.address)
      const hash3 = web3.utils.soliditySha3(signers.random.address)
      const leaves = [hash0, hash1, hash2, hash3]
      const merkleTree = new MerkleTree(leaves, keccak256)

      const root = merkleTree.getHexRoot()
      const rootHashes = [root]
      const leaf = Buffer.from(web3.utils.soliditySha3(signers.redeemer.address))

      const proof = merkleTree.getHexProof(leaf)
      await makerbadges.connect(signers.deployer).setRootHashes(rootHashes)
      await makerbadges.connect(signers.deployer).createTemplate(template_name, template_description, template_image)
      await makerbadges.connect(signers.redeemer).activateBadge(proof, templateId, tokenURI)
      const tokenId = await makerbadges.tokenOfOwnerByIndex(signers.redeemer.address, index1)
      expect(await makerbadges.tokenURI(tokenId)).to.be.eq("https://badges.makerdao.com/token/" + tokenURI)
    })

but activateBadge() method revert:
1) MakerBadges
       ERC721 metadata
         return a baseURI + tokenURI for tokenId:
     Error: VM Exception while processing transaction: revert MakerBadges: caller is not a redeemer
      at MakerBadges.activateBadge (contracts/MakerBadges.sol:143)
      at HardhatNode._mineBlockWithPendingTxs (node_modules/hardhat/src/internal/hardhat-network/provider/node.ts:1003:21)
      at HardhatNode.mineBlock (node_modules/hardhat/src/internal/hardhat-network/provider/node.ts:321:16)
      at EthModule._sendTransactionAndReturnHash (node_modules/hardhat/src/internal/hardhat-network/provider/modules/eth.ts:1223:18)
      at HardhatNetworkProvider.request (node_modules/hardhat/src/internal/hardhat-network/provider/provider.ts:100:18)
      at EthersProviderWrapper.send (node_modules/@nomiclabs/hardhat-ethers/src/internal/ethers-provider-wrapper.ts:13:20)

Hey @naszam!
Some thoughts at first glance:

const leaf = Buffer.from... is missing the encoding parameter. It should be const leaf = Buffer.from(web3.utils.soliditySha3(signers.redeemer.address).replace('0x', ''), 'hex') so the buffer doesn't treat the value as a utf-8 string.
alternatively, since soliditySha3 already returns a hex string, you can actually just have const leaf = web3.utils.soliditySha3(signers.redeemer.address)
You may need the sort option; const merkleTree = new MerkleTree(leaves, keccak256, {sort: true}) depending on the verification implementation.

Hi @miguelmota,
tried your suggestions but it still reverts as it seems not able to verify the redeemer address in the merkle tree.

return the same issue (revert)
return the following:

test/MakerBadges.ts:81:44 - error TS2345: Argument of type 'string' is not assignable to parameter of type 'Buffer'.

81       const proof = merkleTree.getHexProof(leaf)
                                              ~~~~

return the same issue (revert)

The steps to reproduce are:

clone the repo (linked)
add the test (see above)
run yarn install && yarn test

Let me know if you have other thoughts!
Thanks!

Hey @naszam, can you try updating to 0.2.15 or newer. Then in your use the sortPairs: true option.
I also noticed that keccak256 was undefined so I had to import it as:
import * as keccak256 from "keccak256"
``

To have it import regularly you need to update a setting in tsconfig.
However you can also use `soliditySha3` as the hashing function to minimize dependencies.

This should definitely work now!

```js
    it("return a baseURI + tokenURI for tokenId", async () => {
      const { soliditySha3 } = web3.utils
      const hash0 = soliditySha3(signers.redeemer.address)
      const hash1 = soliditySha3(signers.deployer.address)
      const hash2 = soliditySha3(signers.templater.address)
      const hash3 = soliditySha3(signers.random.address)
      const leaves = [hash0, hash1, hash2, hash3]
      const merkleTree = new MerkleTree(leaves, keccak256, {sortPairs: true})

      const root = merkleTree.getHexRoot()
      const rootHashes = [root]
      const leaf = soliditySha3(signers.redeemer.address)
      const proof = merkleTree.getHexProof(leaf)
      await makerbadges.connect(signers.deployer).setRootHashes(rootHashes)
      await makerbadges.connect(signers.deployer).createTemplate(template_name, template_description, template_image)
      await makerbadges.connect(signers.redeemer).activateBadge(proof, templateId, tokenURI)
      const tokenId = await makerbadges.tokenOfOwnerByIndex(signers.redeemer.address, index1)
      expect(await makerbadges.tokenURI(tokenId)).to.be.eq("https://badges.makerdao.com/token/" + tokenURI)
    })

Test results:
  MakerBadges
    Setup
      ✓ deployer has the default admin role (40ms)
      ✓ deployer has the templater role
      ✓ deployer has the pauser role
    ERC721 metadata
      ✓ has a name
      ✓ has a symbol
      ✓ has a baseURI
      ✓ return an updated baseURI
      ✓ reverts when querying metadata for non existent tokenId
      ✓ return a baseURI + tokenURI for tokenId (73ms)
    createTemplate()
      ✓ templater should be able to create a template
      ✓ should emit the appropriate event when a template is created
      ✓ should not allow create a new template from random user

  12 passing (3s)

Hey @miguelmota,
It worked! Thank you so much! :pray:


typescript support

Nice catch buddy, but does not work with typescript projects.

declare this package in your d.ts file if you want to use it in a typescript project


WIP

Motivation
(Write your motivation for proposed changes here.)
Have you read the Contributing Guidelines on pull requests?
(Write your answer here.)
Test Plan
(Share your test plan here. If you changed code, please provide us with clear instructions for verifying that your changes work.)
Related PRs
(If this PR adds or changes functionality, please take some time to update the docs at https://github.com/diem/diem/tree/main/developers.diem.com, and link to your PR here.)
If targeting a release branch, please fill the below out as well

Justification and breaking nature (who does it affect? validators, full nodes, tooling, operators, AOS, etc.)
Comprehensive test results that demonstrate the fix working and not breaking existing workflows.
Why we must have it for V1 launch.
What workarounds and alternative we have if we do not push the PR.

/canary

:broken_heart: Test Failed - ci-test-success

/canary

:broken_heart: Test Failed - ci-test-success

/canary

:broken_heart: Test Failed - ci-test-success

/canary

/canary

/canary

/canary

:sunny: Canary successful

/canary

:sunny: Canary successful

/canary

:broken_heart: Test Failed - ci-test-success

/canary

:broken_heart: Test Failed - ci-test-success

/canary

:broken_heart: Test Failed - ci-test-success

/canary

:sunny: Canary successful

/canary

:broken_heart: Test Failed - ci-test-success

/canary

/canary

/canary

/canary

/canary

:sunny: Canary successful

/canary

:sunny: Canary successful

/canary

:sunny: Canary successful

/canary

/canary

:broken_heart: Test Failed - ci-test-success

/canary

/canary

:sunny: Canary successful

/canary

/canary

/canary

/canary

:broken_heart: Test Failed - ci-test-success

/canary

:broken_heart: Test Failed - ci-test-success

/canary

/canary

:broken_heart: Test Failed - ci-test-success

/canary

/canary

:broken_heart: Test Failed - ci-test-success

/canary

:sunny: Canary successful

/canary

:sunny: Canary successful

LSR dependency change summary:
host packages:
  M syn 1.0.64 (direct third-party, crates.io)
    * version upgraded from 1.0.62
    * (unchanged features: clone-impls, default, derive, extra-traits, full, parsing, printing, proc-macro, quote, visit)

LEC dependency change summary:
host packages:
  M syn 1.0.64 (direct third-party, crates.io)
    * version upgraded from 1.0.62
    * (unchanged features: clone-impls, default, derive, extra-traits, full, parsing, printing, proc-macro, quote, visit, visit-mut)

release binaries dependency change summary:
target packages:
  A move-stdlib 0.1.0 (workspace, path 'language/move-stdlib')
    * features: [none]
  M serde-generate 0.19.1 (direct third-party, crates.io)
    * version upgraded from 0.19.0
    * (unchanged features: [none])
  M regex-syntax 0.6.23 (transitive third-party, crates.io)
    * version upgraded from 0.6.22
    * (unchanged features: default, unicode, unicode-age, unicode-bool, unicode-case, unicode-gencat, unicode-perl, unicode-script, unicode-segment)

host packages:
  M syn 1.0.64 (direct third-party, crates.io)
    * version upgraded from 1.0.62
    * (unchanged features: clone-impls, default, derive, extra-traits, fold, full, parsing, printing, proc-macro, quote, visit, visit-mut)
  M regex-syntax 0.6.23 (transitive third-party, crates.io)
    * version upgraded from 0.6.22
    * (unchanged features: default, unicode, unicode-age, unicode-bool, unicode-case, unicode-gencat, unicode-perl, unicode-script, unicode-segment)


on('autocomplete:selected') firing twice

Hi, whenever I select/click on a result from autocomplete.js the event is firing 2 times:
https://codepen.io/marcos_arata/pen/VKVOky
Does anyone have any idea?
I tried to create a trigger but didn't work as well.
Thanks

From your example it seems like your controller is instanciated twice. Maybe this comes from here


Remove uptime recorder

Task/Issue URL: https://app.asana.com/0/488551667048375/1203401385500448/f
Description
Remove unused uptime recorder
Steps to test this PR
NA just removing code

Current dependencies on/for this PR:

develop

PR #2540   👈

This comment was auto-generated by Graphite.


Add SAM 2 behavior

Can this behavior be committed into our core product?
Also I think this repo is replaced by
https://github.com/PickNikRobotics/moveit_pro_example_ws/tree/main/src/moveit_pro_ur_configs
Right @MikeWrock ?

We can definitely move this. I made this here mainly for testing.


feat: Add WeChat Support (Experimental)

[x] text chat
[x] admin command
[ ] deal with picture and voice
[ ] usage data analyze

架构已被更改


CFE doesn't reject bounds that contain raw types with non-simple bounds

CFE should emit a compile-time error in the described case as specified in this section of the feature spec.
Currently, the following program compiles without any warnings or errors, and it should be rejected by the compiler with an appropriate compile-time error message:
class A<X extends Comparable<X>> {}

class B<Y extends A> {}

main() {
  B b;
}

The following program, that also should be rejected because of the use of generic types with non-simple bounds, makes the compiler to crash:
class C<Z extends C> {}

main() {
  C c;
}

The issue is being worked on in CL 41264.

Fixing this should also fix #31810, #32416 and #32417.

With -dev.59, the first example:
cat ~/tmp/dart2stable/33208a.dart
class A<X extends Comparable> {}
class B {}
main() {
B b;
}
dgrove@dgrove:~$ /usr/lib/google-dartlang/bin/dartanalyzer --preview-dart-2 ~/tmp/dart2stable/33208a.dart
Analyzing /usr/local/google/home/dgrove/tmp/dart2stable/33208a.dart...
error • Type parameter bound types must be instantiated at tmp/dart2stable/33208a.dart:3:19 • strong_mode_not_instantiated_bound
hint • The value of the local variable 'b' isn't used at tmp/dart2stable/33208a.dart:6:5 • unused_local_variable
1 error and 1 hint found.
cat ~/tmp/dart2stable/33208b.dart
class C {}
main() {
C c;
}
dgrove@dgrove:~$ /usr/lib/google-dartlang/bin/dartanalyzer --preview-dart-2 ~/tmp/dart2stable/33208b.dart
Analyzing /usr/local/google/home/dgrove/tmp/dart2stable/33208b.dart...
error • Type parameter bound types must be instantiated at tmp/dart2stable/33208b.dart:1:19 • strong_mode_not_instantiated_bound
hint • The value of the local variable 'c' isn't used at tmp/dart2stable/33208b.dart:4:5 • unused_local_variable
1 error and 1 hint found.


Fix nil with properties

Warn when default values are invalid.
Never validate nil (on set or get) if there is no default.
Emit "will be invalid in Chef 13" warning when setting an invalid nil value.

As per https://github.com/chef/chef/pull/4328

The one thing this goes backwards on is, there's no way to say "no seriously, I'm cool with nil being a valid value on my resource, stop warning me." @lamont-granquist had some ideas for feature flagging that could solve that rather nicely--but I consider it out of scope for this PR.

I ran this through manually and it behaves the way that I want in all the edge cases in #4324
:+1:


Wrong ID

On the "Dream Wardens Insignia (Purple - Drop)" you have put the ID as 210417 when it should be 211417

Oh ! Thank you, it's updated !


Automated cherry pick of #7668: fix: cleanup logic for nics of pending_deleted guests

Cherry pick of #7668 on release/3.4.
#7668: fix: cleanup logic for nics of pending_deleted guests

/lgtm
/approve


fix(build): disable performance hints

See https://github.com/webpack/webpack/issues/3486

@filipesilva This was not included in v1.0.0-beta.26, correct? I'm not quite sure how to "dig in" to the commit history for a git tag: https://github.com/angular/angular-cli/commit/9fe1ed668ff3aa9ad045b82237c4d3d56b2a1539

@ericis it was in beta-25.5, and then changed again in https://github.com/angular/angular-cli/pull/4076 for beta.26 because it's defaults to false now.


feat: support a different timeout for the last replica

Which issue(s) this PR fixes:
longhorn/longhorn#8711
What this PR does / why we need it:
Special notes for your reviewer:
Additional documentation or context
This is not working yet, but it is (I think) similar to what we'll need to do to handle the replica timeouts differently.

I had to enable pprof on the engine to understand why this wasn't working the way I wanted up until at least https://github.com/longhorn/longhorn-engine/pull/1176/commits/b8e8d7a35951def8639cbfd29f5b096107a3ff50. The reason is this:

I put loop in the controller that checks all existing backends to see if they have exceeded the "short" timeout every second.
This check requires a controller RLock for safety.
Once the controller identifies a backend that should time out, it notifies the backend via a channel.
The backend responds by "timing itself out" in the way Longhorn backends usually do.
The controller should handle this by setting the backend to ERR, but this requires a Lock.
HOWEVER, the pending writes already all have an RLock.

In a test case in which I blocked communication with all replicas simultaneously:

A bunch of writes had an Rlock.
The first backend the new logic failed waited on a Lock util the writes completed.
The new logic couldn't fail any more backends until it obtained an RLock.
The writes never finished (and released the Rlock), because there were still unfailed backends.

12 @ 0x441d4e 0x454bc5 0x454b94 0x475845 0x498b88 0xa7ad2a 0xa7dfff 0xa7703d 0xa77018 0xa6e212 0xa5a15c 0x479861
#	0x475844	sync.runtime_Semacquire+0x24									/usr/lib64/go/1.22/src/runtime/sema.go:62
#	0x498b87	sync.(*WaitGroup).Wait+0x47									/usr/lib64/go/1.22/src/sync/waitgroup.go:116
#	0xa7ad29	github.com/longhorn/longhorn-engine/pkg/controller.(*MultiWriterAt).WriteAt+0x1e9		/go/src/github.com/longhorn/longhorn-engine/pkg/controller/multi_writer_at.go:52
#	0xa7dffe	github.com/longhorn/longhorn-engine/pkg/controller.(*replicator).WriteAt+0x3e			/go/src/github.com/longhorn/longhorn-engine/pkg/controller/replicator.go:129
# ----> The rest of the stack is called with an RLock.
#	0xa7703c	github.com/longhorn/longhorn-engine/pkg/controller.(*Controller).writeInNormalMode+0x21c	/go/src/github.com/longhorn/longhorn-engine/pkg/controller/control.go:1095
#	0xa77017	github.com/longhorn/longhorn-engine/pkg/controller.(*Controller).WriteAt+0x1f7			/go/src/github.com/longhorn/longhorn-engine/pkg/controller/control.go:1050
#	0xa6e211	github.com/longhorn/longhorn-engine/pkg/frontend/socket.DataProcessorWrapper.WriteAt+0x31	/go/src/github.com/longhorn/longhorn-engine/pkg/frontend/socket/frontend.go:160
#	0xa5a15b	github.com/longhorn/longhorn-engine/pkg/dataconn.(*Server).handleWrite+0x3b			/go/src/github.com/longhorn/longhorn-engine/pkg/dataconn/server.go:88

1 @ 0x441d4e 0x454bc5 0x454b94 0x475965 0xa7208f 0xa7206b 0xaa93cd 0xaa9693 0x9ce2ce 0xaa9338 0x9ce123 0x9b45f8 0x9b94cb 0x9b26ab 0x479861
#	0x475964	sync.runtime_SemacquireRWMutexR+0x24																			/usr/lib64/go/1.22/src/runtime/sema.go:82
#	0xa7208e	sync.(*RWMutex).RLock+0x4e																				/usr/lib64/go/1.22/src/sync/rwmutex.go:70
#	0xa7206a	github.com/longhorn/longhorn-engine/pkg/controller.(*Controller).GetExpansionErrorInfo+0x2a												/go/src/github.com/longhorn/longhorn-engine/pkg/controller/control.go:427
#	0xaa93cc	github.com/longhorn/longhorn-engine/pkg/controller/rpc.(*ControllerServer).getVolume+0x2c												/go/src/github.com/longhorn/longhorn-engine/pkg/controller/rpc/server.go:85
#	0xaa9692	github.com/longhorn/longhorn-engine/pkg/controller/rpc.(*ControllerServer).VolumeGet+0x12												/go/src/github.com/longhorn/longhorn-engine/pkg/controller/rpc/server.go:122
#	0x9ce2cd	github.com/longhorn/types/pkg/generated/enginerpc._ControllerService_VolumeGet_Handler.func1+0xcd											/go/src/github.com/longhorn/longhorn-engine/vendor/github.com/longhorn/types/pkg/generated/enginerpc/controller_grpc.pb.go:391
#	0xaa9337	github.com/longhorn/longhorn-engine/pkg/controller/rpc.GetControllerGRPCServer.WithIdentityValidationControllerServerInterceptor.identityValidationServerInterceptor.func1+0x797	/go/src/github.com/longhorn/longhorn-engine/pkg/interceptor/interceptor.go:64
#	0x9ce122	github.com/longhorn/types/pkg/generated/enginerpc._ControllerService_VolumeGet_Handler+0x142												/go/src/github.com/longhorn/longhorn-engine/vendor/github.com/longhorn/types/pkg/generated/enginerpc/controller_grpc.pb.go:393
#	0x9b45f7	google.golang.org/grpc.(*Server).processUnaryRPC+0xdf7																	/go/src/github.com/longhorn/longhorn-engine/vendor/google.golang.org/grpc/server.go:1379
#	0x9b94ca	google.golang.org/grpc.(*Server).handleStream+0xe8a																	/go/src/github.com/longhorn/longhorn-engine/vendor/google.golang.org/grpc/server.go:1790
#	0x9b26aa	google.golang.org/grpc.(*Server).serveStreams.func2.1+0x8a																/go/src/github.com/longhorn/longhorn-engine/vendor/google.golang.org/grpc/server.go:1029

1 @ 0x441d4e 0x454bc5 0x454b94 0x475965 0xa79a1b 0xa799f4 0xa798b2 0x479861
#	0x475964	sync.runtime_SemacquireRWMutexR+0x24									/usr/lib64/go/1.22/src/runtime/sema.go:82
#	0xa79a1a	sync.(*RWMutex).RLock+0xda										/usr/lib64/go/1.22/src/sync/rwmutex.go:70
#	0xa799f3	github.com/longhorn/longhorn-engine/pkg/controller.(*Controller).checkBackendTimeouts+0xb3		/go/src/github.com/longhorn/longhorn-engine/pkg/controller/control.go:1446
#	0xa798b1	github.com/longhorn/longhorn-engine/pkg/controller.(*Controller).monitorBackendTimeouts.func1+0x111	/go/src/github.com/longhorn/longhorn-engine/pkg/controller/control.go:1437

1 @ 0x441d4e 0x454bc5 0x454b94 0x4759c5 0x49878a 0xa72d79 0xa7887a 0x479861
#	0x4759c4	sync.runtime_SemacquireRWMutex+0x24							/usr/lib64/go/1.22/src/runtime/sema.go:87
#	0x498789	sync.(*RWMutex).Lock+0x69								/usr/lib64/go/1.22/src/sync/rwmutex.go:151
#	0xa72d78	github.com/longhorn/longhorn-engine/pkg/controller.(*Controller).SetReplicaMode+0x178	/go/src/github.com/longhorn/longhorn-engine/pkg/controller/control.go:514
#	0xa78879	github.com/longhorn/longhorn-engine/pkg/controller.(*Controller).monitoring+0x199	/go/src/github.com/longhorn/longhorn-engine/pkg/controller/control.go:1280

NOTE: Go's locks are write biased. Once a writer attempts to acquire the lock, no new readers can acquire it until after the writer has.

I ended up making the long timeout double the short one and not adjusting the potential range of the short one. This makes the timeouts 8s / 16s out-of-the-box with the ability to increase them to 30s / 60s with the caveat from https://github.com/longhorn/longhorn/issues/8711#issuecomment-2302809322.

@mergify backport v1.7.x v1.6.x


Do not touch botocore unless it is installed

Title
Raise a proper S3 import exception (leftover from #785).
Motivation
Leftover from #785, not raising the proper Exception anymore:
  File "/usr/share/python3/app/lib/python3.11/site-packages/smart_open/s3.py", line 121, in <module>
    RETRY = Retry()
            ^^^^^^^
  File "/usr/share/python3/app/lib/python3.11/site-packages/smart_open/s3.py", line 86, in __init__
    self.exceptions: List[Exception] = [botocore.exceptions.EndpointConnectionError]
                                        ^^^^^^^^
NameError: name 'botocore' is not defined

Tests
Work in progress
Checklist
Before you create the PR, please make sure you have:

[x] Picked a concise, informative and complete title
[x] Clearly explained the motivation behind the PR
[x] Linked to any existing issues that your PR will be solving
[x] Included tests for any new functionality
[x] Checked that all unit tests pass

Workflow

cc @mpenkov

hmm, now we're getting
smart_open/transport.py:22: in <module>
    _REGISTRY = {NO_SCHEME: smart_open.local_file}
E   AttributeError: partially initialized module 'smart_open' has no attribute 'local_file' (most likely due to a circular import)

What would be the proper fix?

is there a point in time where we can test import smart_open before any optional deps are installed? to catch this case?

Fix #804

Thank you @ddelange !

thanks too for the quick action!


Latest version can't Install extensions, search or quit cleanly

Updating to the latest version broke pretty much everything. I have uninstalled / reinstalled and still having issues. Macos Sierra

extensions installing
search
every time I quit, it gets a "Visual Studio Code unexpectedly quit"
GO extension seems broken (no longer inferring my GOPATH)

Please see if you can find any logged output that could help us find the source of the issue:

run code --verbose from the command line and attach the output
in Code select Help | Toggle Developer Tools and select the Console
attach any output you see in the Console you can find

Thanks!


[Question] How to grant access to multiple (but not all) folders on same level?

I would like to grant access for a user to several folders like this
\1 Folder accessible for all users
\2 Folder for John only
\3 Folder for Mary only

User "John" should only see the folders 1 and 2.
User "Mary" should only see the folders 1 and 3.
How can I set the access permission for "John" and "Mary" accordingly?
Or how would I have to organize the folder structure without multiplying the \1 Folder again and again?

Hi,
Unfortunately, this is not possible.


New Frontend Project Added

Title and Issue number
Frontend Project To-do List Generator and Manager Responsive Website
Close #4726
Checklist:

[x] I have mentioned the issue number in my Pull Request.
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have created a helpful and easy to understand README.md

Hi @MohitGupta121
The new project is added which is made with tech stack of HTML, CSS, JavaScript and JQuery.

Kindly review this pull request.

Hi @MohitGupta121
Kindly review this pull request.

@MohitGupta121 In this pull request, project is added. And 'level2' assigns to addition of project

@MohitGupta121 In this pull request, project is added. And 'level2' assigns to addition of project

@TusharKesarwani

@MohitGupta121 In this pull request, project is added. And 'level2' assigns to addition of project

@TusharKesarwani Add correct level


Issues with version 1.2.0 on DSP-Z7

Hi Greg,
I'll take a short look into the Linux x64 version.
First: The 1.1.2 version works actually at his best.
With 1.2.0 version, new/old issues found, like the "spaces" issue.

avr.ini filter does not work as aspected.
question: how to filter best the misconfigured genres from the database ?

ID tags filter removed ?.

country filter not working properly
"Arab Emirates" is,empty now (where i put lots of stations.
aigainst the "spaces issue", do,you remember ?

AVR specific bookmarks file wasn't read ?. Only the bookmarks.xml was read. equal if CommonAVR is set to 1 or 0.
Maybe special with my AVR (don't know)

Download the whole database from the web api is a good step forward.
I switched back to 1.1.2 and bookmarks are also not there (don't know the reason actually.)
Please check the "BLANK" issue we,do,have again with "the Arab Emirates" on your AVR and let me know if you got content.
The "BLANK" issue do exist also on genre,countries, and so on.
If you're thinking about replacing stations.yaml file with other solutions, my idea here is to do it with SQLite database too. Using same structure than in rb.db file, or using a marking database pointing to the rb.db. Hope you do understand what I mean.
Thanks 🙏

Hi Beatrice

avr.ini filter does not work as aspected.

Please, give me an example of your avr.ini setting with expected filtering and real results. Are you sure you're using common avr.ini with CommonAVRini=1?

ID tags filter removed ?.

:confused: What kind of "ID tags filter" ? Please give me an example.

country filter not working properly
"Arab Emirates" is,empty now (where i put lots of stations.

:confused: What do you mean? Where did you "put lots of stations"? Radio-browser.cache (old one based on .cache files and new one based on sqlite database) should not be edited manually by users. :confused:

bookmarks file wasn't read ?.

I didn't change anything with bookmarks with this or even previous release. For me they still work as before ... I checked it as usual when testing the new release. Pay attention on CommonBookmark setting of ytuner.ini. CommonBookmark=1 mean one common bookmark file bookmark.xml for all AVRs (if own more that one like me). CommonBookmark=0 mean every AVR has it's own bookmark xml file.

Please check the Arab Emirates on your AVR and let me know if you got content.

Sure, but what kind of filter/order settings (avr.ini - CommonAVRini=1?) do you use?

CommonAVRini=1 is set.
The AVR uses the bookmarks.xml I've copied the existing specific xxxxxx.xml file to bookmarks.xml (book,arks globally back. Imhave only one AVR, so no direct issue for me.

spaces issue is back !!. Check categories, countries and with a space. you copied old not fixed code  😂 haha. (maybe)

I,do have modified my prior message. Please reread.
Thanks.

spaces issue is back !!. Check categories, countries and with a space. you copied old not fixed code 😂 haha. (maybe)

Not really. Old cache types like catFile works as expected (based on already fixed code) and there is no "space" issue. :wink:
But.. Yes, indeed the new one database cache like catDB has this issue. :wink: Point for you. :+1: Easy to fix with additional 10 characters function :smile: Already did.
I understand that this "space" issue is the same as the "BLANK" issue.

AVR specific bookmarks file wasn't read ?. Only the bookmarks.xml was read. equal if CommonAVR is set to 1 or 0.

I've just checked. With CommonAVR=1 my AVRs read avr.ini settings and with CommonAVR=0 indepandent xxxxxx.xml files that are associated with the mac AVR parameter.

I switched back to 1.1.2 and bookmarks are also not there (don't know the reason actually.)

Check your CommonBookmark setting. It works similarly to CommonAVR described above, except that bookmarks are saved in xml files
Should I check/fix anything else before I'll release YTuner v1.2.1 ? :thinking:

I,do have Bookmarkcommon on 1
So both parameters set to 1 not 0

I have RPI 1 and RPI 4/4GB. This Proxmox panel looks quite nice but I don't have time to play with it right now.
Yes, my old thin client running YTuner is very slow and needs about 10 W of power (I can also use the on/off button :wink: ), but think if I create software that can run quickly and effectively on such a platform, what performance will it have on a modern platforms. :rocket:
The problem nowadays is that software developers don't care about every CPU cycle (and usually have no idea what that is and how it works) and when you ask about performance the answer is always the need to increase CPU power and memory space or by scaling horizontally and adding new machines or POD and containers. And business departments have to pay for it and the result is some mega hardware platforms that don't do much, but are fashionable, modern and impress others. :laughing:

I do have Free Pascal Compiler installed onto an alpine 3.19 VM on my raspberry PI to compile your project on arm64 directly.
What's needed additionally to the /usr/local installed FPC ?

I use FPC based on Windows platform and cross-compile YTuner for other platforms too. You definitely need the Trunk verion of FPC (v3.31) and the last Indy Library to compile the project (Look at Dependencies on README.md) If you want to build your own YTuner binaries, you'll need to read/learn a bit about FPC, but it's worth doing. Due to the fact that FPC compiles to native code and does not need any interpreters or frameworks, it is second only to C/C++ in terms of speed, but it is very simple, really fast and constantly developed by FPC team.
I'm sorry but I don't have time to focus on your VM and FPC. You will find tutorials online that will help you with this and you will be more satisfied when your binaries are built. :+1:
Now I'll prepare fixed YTuner v1.2.1 binaries and in the coming weeks I will devote time to the most important person in the world, my son, in preparation for the math competition. :crossed_fingers: Yes, and also I'm still looking for a new interesting job... :+1:

My (ex) company do have locations in Polant too.
If you found time to go into deeper contact and you're willing to to send me your CV.I will check what I can do for you to be membership of the best company I ever worked for 🥂😂🤣

For FPC. The libraries do not exist actually for alpine Linux...

Libraries = source code of libraries used to compile whole YTuner. OS does not matter here.
An application built using FPC is a native application, not like a python/java/.NET C# "thing", and does not need anything else to run except optional dynamic libraries such as OpenSSL or SQLite.
Indy libraries fork = https://github.com/coffeegreg/Indy.
I suggest to build AMD64 Linux 64 VM and use FPC on it.

Here we are. New release v1.2.1 is ready. :rocket:


Munge Context Object Structure

This admittedly-mundane PR massages the shapes of the context objects being generated for patterns and pages so that I can move into beginning to output things. It's mostly concerned with creating correctly-nested and -keyed objects for later traversal and use.
It's pretty boring.
But it was kind of hard.
zzzzzz recursion...
/cc @mrgerardorodriguez

Oh, yeah, it also introduces markdownFields to options. You can probably guess what that does.

@lyzadanger One minor comment. :+1:


fix(falcosidekick): add support for custom service type for webui redis in Helm chart

What type of PR is this?
/kind bug
/kind chart-release

Any specific area of the project related to this PR?
/area falcosidekick-chart

What this PR does / why we need it:
This PR fixes an issue in the Helm chart where the WebUI Redis service type was hardcoded to ClusterIP, ignoring the user-configured value under webui.redis.service.type.
Which issue(s) this PR fixes:
Special notes for your reviewer:
Checklist

[X] Chart Version bumped
[X] Variables are documented in the README.md
[X] CHANGELOG.md updated

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: dbeilin
Once this PR has been reviewed and has the lgtm label, please assign cpanato for approval. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Welcome @dbeilin! It looks like this is your first PR to falcosecurity/charts 🎉

Hello, I was trying to expose the web UI Redis to my other clusters but noticed that it ignores my values file even though the documentation already says it's supported: webui.redis.service.type.
I'm not too familiar with contributing to projects but this is a small fix, hoping I didn't miss anything :)

@poiana hey, just wanted to check in. I'm blocked by this issue and was trying to avoid using a cloned version of that chart :D

Hi @dbeilin,
I just came back from holidays Yesterday, I'm catching up what I missed by FIFO order, I'll review your PR asap.

thank you @Issif , appreciate your help :)

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: dbeilin
Once this PR has been reviewed and has the lgtm label, please ask for approval from issif. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@Issif - hello Thomas. any ETA on this PR?
Thanks

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: dbeilin, Issif
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [Issif]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@Issif Thanks, opened a PR to bump it: https://github.com/falcosecurity/charts/pull/731
Hope it's ok.


feat: Support ModelMetadata endpoint

Motivation
KServe V2 API's ModelMetadata endpoint is not yet supported in the rest-proxy grpc-gateway.
Modifications
Extend grpc-gateway to include it in addition to the Infer call already implemented.
Result
Resolves #14 and https://github.com/kserve/modelmesh-serving/issues/418

simply tested this and I confirm that this work well

Without version

 curl -k https://example-onnx-mnist-modelmesh-serving.apps.jlee-test.oylv.p1.openshiftapps.com/v2/models/example-onnx-mnist
{"name":"example-onnx-mnist__isvc-b29c3d91f3", "versions":["1"], "platform":"OpenVINO", "inputs":[{"name":"Input3", "datatype":"FP32", "shape":["1", "1", "28", "28"]}], "outputs":[{"name":"Plus214_Output_0", "datatype":"FP32", "shape":["1", "10"]}]}  support-rest-endpoints  ~/temp/20230822_Test_repo/rest-proxy 

With version

curl -k https://example-onnx-mnist-modelmesh-serving.apps.jlee-test.oylv.p1.openshiftapps.com/v2/models/example-onnx-mnist/versions/1
{"name":"example-onnx-mnist__isvc-b29c3d91f3", "versions":["1"], "platform":"OpenVINO", "inputs":[{"name":"Input3", "datatype":"FP32", "shape":["1", "1", "28", "28"]}], "outputs":[{"name":"Plus214_Output_0", "datatype":"FP32", "shape":["1", "10"]}]}

Thanks @rafvasq -- did you also regenerate the protos?
With google.golang.org/grpc v1.51.0 I do get slightly different generated code
https://github.com/kserve/rest-proxy/pull/26/files#diff-2858165aafcdd2fe79ab516a84060fb8645cd00e44a92f623f3a57fe4b3b569cR446


Test issue for auto assignement

Please ignore

That did not work. Maybe because it was me opening the issue.


Automatically register the schema tester pytest plugin

Previously packages were required to explicitly list the schema tester plugin in their conftest.py files. Now, the plugin is registered automatically with pytest.
The schema tests are no longer enabled by default. Instead, packages can do one of two things:

Add asdf_schema_tests_enabled = true to the [tool:pytest] section of their setup.cfg file to enable tests by default, or
Add --asdf-tests to the pytest command line to enable tests on a per-run basis.

The new plugin is in a different namespace than the previous plugin, so it will not cause conflicts with packages that still include the plugin in conftest.py. However, the old conftest.py configuration should be removed unless packages want to retain backwards compatibility with older versions of ASDF.
This closes #657.
cc @astrofrog

Packaging the plugin in this way is proving to be unnecessarily burdensome. The right way to do it would be to move the plugin to another package entirely, but I don't think that's the right way to go.

Closing since this isn't really worth any more time/effort at the moment.

Could you clarify what the issue is here with registering the pytest plugin?

Packaging the plugin in this way is proving to be unnecessarily burdensome. The right way to do it would be to move the plugin to another package entirely, but I don't think that's the right way to go.

What would be wrong with moving the plugin to another package? In a way you already have a separate package for a sphinx plugin, so why not for a pytest plugin?

@astrofrog the issues have all been related to using the plugin to test the asdf package itself. I'm not sure I understand the root cause, but it seems to be related to the fact that the asdf package gets imported by pytest when the plugin is loaded, but also when test collection occurs. I think I found workarounds for most of these issues, but it's still causing failures on Windows for unknown reasons. I don't really want to abandon testing on Windows just because of this, but I'm not sure how much more time/effort I can afford at the moment. I'll try one more idea here now, but then I might have to leave this effort to someone else.
As for moving the plugin to another package, I think the future maintenance burden would be lower if it remained part of the same repository. However, with the way I have set things up here, the plugin is technically installed as a separate package.

Looks like eliminating potentially circular references in the plugin got things working. Thanks @astrofrog for encouraging me to continue!

So is the following necessary in the top-level conftest.py for a package that would like to use asdf_schema_tester in order to work with both the old schema tester and new one via entry points?
import pkg_resources

entry_points = []
for entry_point in pkg_resources.iter_entry_points('pytest11'):
    entry_points.append(entry_point.name)

if "asdf_schema_tester" not in entry_points:
    pytest_plugins = ['asdf.tests.schema_tester']

Plus enabling it in setup.cfg.  Or is there a simpler way?

@jdavies-st since the new plugin is in a different namespace, I think there's actually no action required for packages that want to retain backwards compatibility. You will need to add asdf_schema_tests_enabled to your setup.cfg in order to enable the tests by default with the new plugin, but other than that there should be no issues.

But asdf.tests.schema_tester no longer exists in asdf namespace.  So if we have
pytest_plugins = ['asdf.tests.schema_tester']

in our conftest.py, then we get a plugin import error.  Our 2 test runs yesterday against asdf/master failed because of this:
https://travis-ci.org/spacetelescope/jwst/builds/518489243
https://travis-ci.org/spacetelescope/jwst/jobs/518489251#L685

Ah yeah good point. Yes I guess you do need logic like what you posted above, then. I wonder if it would be better to use the version of asdf as the condition though?

Agree.  Once a version of asdf is released with the new plugin, then version would be better.  Thanks for the suggestion.  =)


fix: Install script

When running the install script it will still continue on after an error:
$> /tmp/install_v4.sh v4.0.0-beta.154

Welcome to Coolify v4 beta installer!
This script will install everything for you.
(Source code: https://github.com/coollabsio/coolify/blob/main/scripts/install.sh)

-------------
OS: ubuntu 22.04
Coolify version: v4.0.0-beta.154
-------------
Installing required packages...
-------------
Check Docker Configuration...
Docker configuration is up to date.
-------------
Downloading required files from CDN...
latest: Pulling from coollabsio/coolify-helper
Digest: sha256:fb8a095ac4265d1e681c5aac3d98f60dfe5506e399bb4e4c9a8c3ef4c539645e
Status: Image is up to date for ghcr.io/coollabsio/coolify-helper:latest
 soketi Pulling
 coolify Pulling
 postgres Pulling
 redis Pulling
 coolify Error
 postgres Error
 soketi Error
 redis Error
Error response from daemon: manifest unknown

Congratulations! Your Coolify instance is ready to use.
$>

Adding the set options in the install script will allow it to exit on error.
$> /tmp/install_v4.sh v4.0.0-beta.154

Welcome to Coolify v4 beta installer!
This script will install everything for you.
(Source code: https://github.com/coollabsio/coolify/blob/main/scripts/install.sh)

-------------
OS: ubuntu 22.04
Coolify version: v4.0.0-beta.154
-------------
Installing required packages...
-------------
Check Docker Configuration...
Docker configuration is up to date.
-------------
Downloading required files from CDN...
latest: Pulling from coollabsio/coolify-helper
Digest: sha256:fb8a095ac4265d1e681c5aac3d98f60dfe5506e399bb4e4c9a8c3ef4c539645e
Status: Image is up to date for ghcr.io/coollabsio/coolify-helper:latest
 soketi Pulling
 coolify Pulling
 postgres Pulling
 redis Pulling
 coolify Error
 postgres Error
 soketi Error
Error response from daemon: manifest unknown
$>

Allow install script to be ran with passing the actual GH tag version that includes v
install.sh v4.0.0-beta.154

Thanks for the refactoring! Looks good!


Install Issue

Hey,
Doing an install. All things are seemingly fine but 404.

Ubuntu 16+

@germonprez Sorry for late reply, I was working on resolving this issue in another context. What directory are you running ghdata in? It must be run in the ghdata repo? Also, what happens if you go to http://localhost:5000/unstable/cakephp/cakephp/timeseries/commits ? What does your log show?
Thanks!

Following this:
pip install --upgrade https://github.com/OSSHealth/ghdata/archive/master.zip
Where is the repo? I guess I'm used to just doing a git clone.

Oh, sorry this isn't more clear! Running ghdata in that way will only serve the API. To have ghdata serve the front-end, you must run ghdata while in the repo (after git clone). To make things more clear, I think we should seperate the front-end into its own repo and make it a first-class web project.

Still getting a 404. What is the current order of install events?
git clone
cd into root folder of repo
pip install --upgrade https://github.com/OSSHealth/ghdata/archive/master.zip
ghdata
modify ghdata.cfg for DB
ghdata
go to browser: localhost:5000
?
On Fri, Apr 7, 2017 at 3:40 PM, Derek Howard<EMAIL_ADDRESS>wrote:

Oh, sorry this isn't more clear! Running ghdata in that way will only
serve the API. To have ghdata serve the front-end, you must run ghdata
while in the repo (after git clone). To make things more clear, I think
we should seperate the front-end into its own repo and make it a
first-class web project.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/OSSHealth/ghdata/issues/37#issuecomment-292646211,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAoDUIBfGJXR2xro1bVq93WUTuoz96IJks5rtp9YgaJpZM4M1tCe
.

--
Mutual of Omaha Associate Professor
Information Systems
College of Information Science & Technology
University of Nebraska Omaha
http://faculty.ist.unomaha.edu/mgermonprez/cv.txt

Instead of pip install --upgrade https://github.com/OSSHealth/ghdata/archive/master.zip, use pip install --upgrade . while in the repo (although it shouldn't make a difference if your repo is in sync with master).
Everything else looks good, my guess is that ghdata doesn't know you want to serve local files. You can tell it to by either setting developer = 1 in your ghdata.cfg or by using make run-debug in the repo. ghdata's default settings are for production, where we would not want Flask responsible for serving our static assets. I'll seperate the two repos before our next release so it will be less confusing.

Ok working. The developer=1 seemed to be the trick.
Now I'm going to open an issue on usage :)
On Fri, Apr 7, 2017 at 4:01 PM, Derek Howard<EMAIL_ADDRESS>wrote:

Instead of pip install --upgrade https://github.com/OSSHealth/
ghdata/archive/master.zip, use pip install --upgrade . while in the repo
(although it shouldn't make a difference if your repo is in sync with
master).
Everything else looks good, my guess is that ghdata doesn't know you want
to serve local files. You can tell it to by either setting developer = 1
in your ghdata.cfg or by using make run-debug in the repo. ghdata's
default settings are for production, where we would not want Flask
responsible for serving our static assets. I'll seperate the two repos
before our next release so it will be less confusing.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/OSSHealth/ghdata/issues/37#issuecomment-292650665,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAoDUPUdOQQlJcTaGSR2xWLYkOc7Re4Sks5rtqQYgaJpZM4M1tCe
.

--
Mutual of Omaha Associate Professor
Information Systems
College of Information Science & Technology
University of Nebraska Omaha
http://faculty.ist.unomaha.edu/mgermonprez/cv.txt

Sounds good!


problem sending login to: https://app.melcloud.com/Mitsubishi.Wifi.Client/Login/ClientLogin

After installing the adapter ( v 1.3.4) and entering log-in data, the logfile shows:
AxiosError: Request failed with status code 500
There was a problem sending login to: https://app.melcloud.com/Mitsubishi.Wifi.Client/Login/ClientLogin
The device is registered with MELCloud and can be controlled via app and web.

melcloud.0
2023-07-26 17:58:41.406
error
AxiosError: Request failed with status code 500

melcloud.0
2023-07-26 17:58:41.406
error
There was a problem sending login to: https://app.melcloud.com/Mitsubishi.Wifi.Client/Login/ClientLogin

melcloud.0
2023-07-26 17:58:41.136
debug
Fetching context key...

melcloud.0
2023-07-26 17:58:41.135
info
Connecting initially to MELCloud and retrieving data...

melcloud.0
2023-07-26 17:58:41.134
debug
No known devices found.

melcloud.0
2023-07-26 17:58:40.968
debug
Getting current known devices...

melcloud.0
2023-07-26 17:58:40.967
debug
Checking adapter settings...

melcloud.0
2023-07-26 17:58:40.914
debug
Initializing objects...

melcloud.0
2023-07-26 17:58:40.872
info
starting. Version 1.3.4 in /opt/iobroker/node_modules/iobroker.melcloud, node: v16.20.0, js-controller: 4.0.24

melcloud.0
2023-07-26 17:58:40.452
debug
Objects connected to redis: <IP_ADDRESS>:9001

melcloud.0
2023-07-26 17:58:40.442
debug
Objects client initialize lua scripts

melcloud.0
2023-07-26 17:58:40.320
debug
Objects create User PubSub Client

melcloud.0
2023-07-26 17:58:40.318
debug
Objects create System PubSub Client

melcloud.0
2023-07-26 17:58:40.315
debug
Objects client ready ... initialize now

melcloud.0
2023-07-26 17:58:40.241
debug
Redis Objects: Use Redis connection: <IP_ADDRESS>:9001

melcloud.0
2023-07-26 17:58:35.607
info
Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason

melcloud.0
2023-07-26 17:58:35.605
info
terminating

melcloud.0
2023-07-26 17:58:35.603
info
onUnload(): Cleaned everything up...

melcloud.0
2023-07-26 17:58:35.584
info
Got terminate signal TERMINATE_YOURSELF

What kind of devices are linked to your account? And logging in to https://app.melcloud.com/ works with the same credentials as entered in the adapter settings?

ceiling air conditioning -> SLZ-M25FA2
outdoor unit -> SUZ-M25VA
Wifi-Module -> MAC-587IF-E
Loggin in to app.melcloud.com works with the same credentials as entered in the adapter settings.

Really strange, never seen this issue before. Sadly the error itself doesn't contain any specific information at all why the initial request fails.
Do you have any special/unusual characters in your password? If yes, maybe change it to  something more simple and try again.
Otherwise I would need temporary access to your Melcloud account to debug the issue myself. But that's up to you if you want to share your credentials with me. 😉

Hi, I have a very long and complex password. For a test I will change it to a simple one... keep you posted..

thanks for the tip... I changed my passwort to less than 16 characters... now it works fine.


Issue in VS 2017 using MySql

I got this error in VS 2017, the error is not present in VS 2015

MySql.Data.MySqlClient.MySqlException occurred
HResult=0x80004005
Message=Fatal error encountered during command execution.
Source=MySql.Data
StackTrace:
at MySql.Data.MySqlClient.MySqlCommand.ExecuteReader(CommandBehavior behavior)
at MySql.Data.MySqlClient.MySqlCommand.ExecuteNonQuery()
at Serenity.Data.SqlHelper.ExecuteNonQuery(IDbCommand command)
....
Inner Exception 1:
MySqlException: Parameter '@ErrorHash' must be defined.

The error occurs when the program tries to write to the exceptions table.

We don't support VS2017, but anyway MySql acting different in VS versions not expected.


json.Unmarshal to map[string]interface{} missing field

What version of Go are you using (go version)?

$ go version
go version go1.10.4 linux/amd64

Does this issue reproduce with the latest release?
Yes, also on 12.x
What operating system and processor architecture are you using (go env)?
go env Output
$ go env

Ubuntu 18.04 x64
What did you do?
Repro code below. The json file pass in via flag is downloadable here
https://d1ane3fvebulky.cloudfront.net/latest/gzip/CloudFormationResourceSpecification.json

package main

import (
	"encoding/json"
	"flag"
	"fmt"
	"io/ioutil"
)

var input = flag.String("input", "", "input file path.")

func main() {
	flag.Parse()
	rawData, _ := ioutil.ReadFile(*input)
	var spec = make(map[string]interface{})
	json.Unmarshal(rawData, &spec)
	propertyTypes := spec["PropertyTypes"].(map[string]interface{})
	// Works fine
	fmt.Println(propertyTypes["AWS::WAFRegional::ByteMatchSet.ByteMatchTuple"])

	// For unknown reason, AWS::AutoScaling::LaunchConfiguration isn't found in the result
	fmt.Println(propertyTypes["AWS::AutoScaling::LaunchConfiguration"])
}

What did you expect to see?
For some reason, json object keyed by "AWS::AutoScaling::LaunchConfiguration" is missing.
What did you see instead?

Content of .../latest/... link will likely change.

From what I see, AWS::AutoScaling::LaunchConfiguration is under ResourceTypes, not PropertyTypes. I believe you are looking under the wrong key. Could you double-check ?

My bad, overlooked ‘ResourceType’


Skip Async-http instrumentation installation when Traces::Backend::NewRelic is defined

If the traces-backend-newrelic instrumentation is being used, then skip async-http instrumentation installation since this gem provides instrumentation.
https://github.com/newrelic/traces-backend-newrelic

Nice! I have a few questions, and the answers can all be no 🙂

Should we add a changelog entry for this? It might be as close as we get to mentioning the new gem in the main agent's release notes.

I was thinking it would be better to wait until we've released a version of the traces-backend-newrelic before adding something for this to the changelog for whatever the next version of the agent is.

Would it be helpful to have a comment around line 15 describing where Traces::Backend::NewRelic is defined? I'm worried someone might have trouble finding it since it's not part of the async-http library.

sure, added one

Do we want to add a test for this? We don't usually test depends_on blocks, so maybe the answer is no, I'm thinking about accidental regression.

I was leaning towards not, since we dont normally and it'd add the time of running a whole new multiverse suite. Plus the consequence for it failing is pretty minimal. Since it just won't create the second spans inside of the traces-backend-newrelic gem, but the ones the agent creates would still be present, there isn't a concern about double reporting the external requests.


Undefined symbols for architecture i386

I have face this compile error out on Xcode 11.3, swift compile version -> swift 5.
I couldn't compile my apps. I have did remove and reinstall pods. but it still showed the same error below. (for detail, see attachment)
Undefined symbols for architecture i386:   "_OBJC_CLASS_$_FLAnimatedImageView", referenced from:       type metadata for DKPhotoGallery.DKPhotoImageView in DKPhotoImageView.o   "_OBJC_METACLASS_$_FLAnimatedImageView", referenced from:       _OBJC_METACLASS_$__TtC14DKPhotoGallery16DKPhotoImageView in DKPhotoImageView.o   "_OBJC_CLASS_$_FLAnimatedImage", referenced from:       objc-class-ref in DKPhotoBaseImagePreviewVC.o ld: symbol(s) not found for architecture i386 clang: error: linker command failed with exit code 1 (use -v to see invocation)
please give me your advice, what should i do?
thank you in advance

Hi @syiasko
Have you tried to Clean & Clean Build Folder?

yes I had, but still got same error.
now, I can run my apps use this workaround. I add manually DKImageController and DKPhotoGallery in build phases - link Binary with libraries like this.

It's strange...
I'm glad to hear you solved the problem anyway 🙃


Feature/mapping

Add yml version of imposm mapping

Shall we already merge that? I think we will change the mapping quite a bit tomorrow as well and can then make sure the style works together with it.
I also somehow lost the zorder ranks form landusages - need to include them again.

Let's merge this now. We have to do further work for this but we can create a new branch.
And build is green because it works together with open streets at this point.
After the merge we should create release for open streets and reference this in the export container
(otherwise our tests will always fail on travis because they require an open-streets version depending on something other than the master branch).


Wrong package name in package.xml

When trying to install dependencies using rosdep, it throws an error as it can not locate   standard_msgs
I believe this is an error, as   std_msgs is included a couple of lines further down  in the file.
Removing the mentioned line installed all dependencies succesfully on a fresh ros:melodic-base install  and I am able to run the example without issues

Would you mind posting the error message you are getting?
I usually don't use rosdep to install dependencies so I'm not sure exactly what and how to fix.
Thanks!

The command I run to install all dependencies is:
rosdep install --from-paths src --ignore-src --rosdistro melodic -y
The error it throws is:
ERROR: the following packages/stacks could not have their rosdep keys resolved
to system dependencies:
tagslam: Cannot locate rosdep definition for [standard_msgs]

The reason is that the package.xml file of the tagslam project includes the following line that has to be deleted:   standard_msgs.
The correct way to specify that the package depends on standard_msgs is   std_msgs
which is actually already present in the package.xml file a couple of lines further down.
Hope this helps!
Best,
Eduardo

Now I get it.
Thanks much for pointing this out. This has been fixed with commit 09a6f1fccac689f3e5b32c67fc41073f517cffa7


⚠ Bofrost.at has degraded performance

In f90c606, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1421 ms

Resolved: Bofrost.at performance has improved in a2a11fd after 20 minutes.