Floatbar frozen randomly in my session

When launching a remote session (to windows server 2019), sometimes the connection suddenly freezes, and i cant do anything, only restart the computer. It can happen at 10 minutes or at 8 hours, it is very randomly. I have done tests and my  conclusion that without the Floatbar  this circumstance does not happen. At no time does he get out of the session, he just freezes (he can only move the mouse). I have managed to reproduce this problem by quickly moving the floatbar in my session, which also gives quite a few graphical glitches and slowdowns. Tried changing display options.
As data, if I add the parameter /smart-sizing something happens related to the previous case but without getting completely blocked.

Aplication details
FreeRDP Version: 3.2; 2.0; 2.2;
Command line: xfreerdp /f /cert-ignore -decorations -themes +fonts /drive:media,/media +auto-reconnect /floatbar:sticky:off,default:hidden,show:fullscreen  /auto-reconnect-max-retries:5 /sound /microphone /video /gfx:AVC444

Enviroments
The tests have been done on Debian 10, Ubuntu 20.4 and other linux distributions, giving the same problem in all.

Logs
[08:59:44:754] [27696:27697] [WARN][com.freerdp.client.x11] - xf_lock_x11_:    [1] recursive lock from xf_sw_end_paint
[08:59:44:754] [27696:27697] [WARN][com.freerdp.client.x11] - xf_lock_x11_:    [1] recursive lock from xf_sw_end_paint
[08:59:44:756] [27696:27697] [WARN][com.freerdp.client.x11] - xf_lock_x11_:    [1] recursive lock from xf_sw_end_paint
[08:59:44:757] [27696:27697] [WARN][com.freerdp.client.x11] - xf_lock_x11_:    [1] recursive lock from xf_sw_end_paint
[08:59:44:757] [27696:27697] [WARN][com.freerdp.client.x11] - xf_lock_x11_:    [1] recursive lock from xf_sw_end_paint
[08:59:44:763] [27696:27697] [WARN][com.freerdp.client.x11] - xf_lock_x11_:    [1] recursive lock from xf_sw_end_paint
[08:59:44:099] [27696:27697] [WARN][com.freerdp.client.x11] - xf_lock_x11_:    [1] recursive lock from xf_process_x_events
[08:59:44:099] [27696:27697] [WARN][com.freerdp.client.x11] - xf_lock_x11_:    [1] recursive lock from xf_process_x_events
[08:59:45:860] [27696:27697] [WARN][com.freerdp.client.x11] - xf_lock_x11_:    [1] recursive lock from xf_process_x_events
[08:59:45:940] [27696:27697] [WARN][com.freerdp.client.x11] - xf_lock_x11_:    [1] recursive lock from xf_process_x_events
[08:59:46:643] [27696:27697] [WARN][com.freerdp.client.x11] - xf_lock_x11_:    [1] recursive lock from xf_process_x_events
[08:59:46:644] [27696:27697] [WARN][com.freerdp.client.x11] - xf_lock_x11_:    [1] recursive lock from xf_process_x_events
[08:59:47:554] [27696:27697] [WARN][com.freerdp.client.x11] - xf_lock_x11_:    [1] recursive lock from xf_process_x_events
[08:59:49:463] [27696:27697] [WARN][com.freerdp.client.x11] - xf_lock_x11_:    [1] recursive lock from xf_process_x_events
[08:59:49:819] [27696:27697] [WARN][com.freerdp.client.x11] - xf_lock_x11_:    [1] recursive lock from xf_process_x_events
[08:59:49:820] [27696:27697] [WARN][com.freerdp.client.x11] - xf_lock_x11_:    [1] recursive lock from xf_process_x_events
[08:59:49:890] [27696:27697] [WARN][com.freerdp.client.x11] - xf_lock_x11_:    [1] recursive lock from xf_process_x_events
[08:59:49:982] [27696:27697] [WARN][com.freerdp.client.x11] - xf_lock_x11_:    [1] recursive lock from xf_process_x_events
[08:59:50:936] [27696:27731] [ERROR][com.freerdp.codec.progressive] - Invalid total tile count, maximum 558
[08:59:50:936] [27696:27731] [ERROR][com.freerdp.gdi] - progressive_decompress_ex failure: -1027
[08:59:50:936] [27696:27731] [ERROR][com.freerdp.channels.rdpgfx.client] - context->SurfaceCommand failed with error 1359
[08:59:50:936] [27696:27731] [ERROR][com.freerdp.channels.rdpgfx.client] - rdpgfx_recv_wire_to_surface_2_pdu failed with error 1359!
[08:59:50:936] [27696:27731] [ERROR][com.freerdp.channels.rdpgfx.client] - Error while processing GFX cmdId: RDPGFX_CMDID_WIRETOSURFACE_2 (0x0002)
[08:59:50:936] [27696:27731] [ERROR][com.freerdp.channels.rdpgfx.client] - rdpgfx_recv_pdu failed with error 1359!
[08:59:50:944] [27696:27731] [ERROR][com.freerdp.channels.drdynvc.client] - ChannelId 7 not found!

Images

@Eu-CL sorry for the delay.
this is basic X11 window drawing, mostly influenced by your Xorg and graphics drivers. Any information about these?

@Eu-CL sorry for the delay.
this is basic X11 window drawing, mostly influenced by your Xorg and graphics drivers. Any information about these?

Hi, this is my system information:
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 500 (rev 0b)
Subsystem: Elitegroup Computer Systems HD Graphics 500
Kernel driver in use: i915
00:0e.0 Audio device: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series Audio Cluster (rev 0b)

FYI our (thinlinx.com's) customers are also encountering this problem, at least as late as FreeRDP 2.4.1, and I expect that it is still an issue in 2.6.0, 2.6.1 and 2.7.0 also.  It's difficult to reliably reproduce, but setting the floatbar to auto-hide and then using the mouse to expose, hide and drag it will generally produce a lock-up pretty quickly.
We think that this is a deadlock in FreeRDP that must somehow be related to desktop composition, because using "-aero" seems to be a reliable workaround.  As far as we are aware, the RDP server version is immaterial (occurs with Windows Server 2016 and Windows 10 at the very least).
Our O/S is Debian 10 (i386, amd64 and armhf, with most customers using armhf) with some relatively minor modifications (principally use of AUFS layering and Reiser4).  Versions are similar to those quoted above:
xserver-xorg-core 2:1.20.4-1+deb10u4
xserver-xorg-input-libinput 0.28.2-2
xserver-xorg-video-amdgpu 18.1.99+git20190207-1
xserver-xorg-video-ati 1:19.0.1-1
xserver-xorg-video-intel 2:2.99.917+git20180925-2
xserver-xorg-video-nouveau 1:1.0.16-1
xserver-xorg-video-radeon 1:19.0.1-1
i965-va-driver-shaders 2.3.0-1
mesa-va-drivers 18.3.6-2+deb10u1
vdpau-va-driver 0.7.4-7
mesa-vdpau-drivers 18.3.6-2+deb10u1
(ARM versions of the O/S lack everything AMD/Intel/nVidia/VA-API/VDPAU-related)
Example buildconfig:
This is FreeRDP version 2.4.1 (2.4.1)
Build configuration: BUILD_TESTING=OFF BUILTIN_CHANNELS=ON HAVE_AIO_H=1 HAVE_EXECINFO_H=1 HAVE_FCNTL_H=1 HAVE_GETLOGIN_R=1 HAVE_INTTYPES_H=1 HAVE_JOURNALD_H=TRUE HAVE_MATH_C99_LONG_DOUBLE=1 HAVE_POLL_H=1 HAVE_PTHREAD_MUTEX_TIMEDLOCK=ON HAVE_PTHREAD_MUTEX_TIMEDLOCK_LIB=1 HAVE_PTHREAD_MUTEX_TIMEDLOCK_SYMBOL= HAVE_SYSLOG_H=1 HAVE_SYS_EVENTFD_H=1 HAVE_SYS_FILIO_H= HAVE_SYS_MODEM_H= HAVE_SYS_SELECT_H=1 HAVE_SYS_SOCKIO_H= HAVE_SYS_STRTIO_H= HAVE_SYS_TIMERFD_H=1 HAVE_TM_GMTOFF=1 HAVE_UNISTD_H=1 HAVE_XI_TOUCH_CLASS=1 WITH_ALSA=ON WITH_CAIRO=ON WITH_CCACHE=ON WITH_CHANNELS=ON WITH_CLANG_FORMAT=ON WITH_CLIENT=ON WITH_CLIENT_AVAILABLE=1 WITH_CLIENT_CHANNELS=ON WITH_CLIENT_CHANNELS_AVAILABLE=1 WITH_CLIENT_COMMON=ON WITH_CLIENT_INTERFACE=OFF WITH_CUPS=ON WITH_DEBUG_ALL=OFF WITH_DEBUG_CAPABILITIES=OFF WITH_DEBUG_CERTIFICATE=OFF WITH_DEBUG_CHANNELS=OFF WITH_DEBUG_CLIPRDR=OFF WITH_DEBUG_DVC=OFF WITH_DEBUG_KBD=OFF WITH_DEBUG_LICENSE=OFF WITH_DEBUG_MUTEX=OFF WITH_DEBUG_NEGO=OFF WITH_DEBUG_NLA=OFF WITH_DEBUG_NTLM=OFF WITH_DEBUG_RAIL=OFF WITH_DEBUG_RDP=OFF WITH_DEBUG_RDPDR=OFF WITH_DEBUG_RDPEI=OFF WITH_DEBUG_RDPGFX=OFF WITH_DEBUG_REDIR=OFF WITH_DEBUG_RFX=OFF WITH_DEBUG_RINGBUFFER=OFF WITH_DEBUG_SCARD=OFF WITH_DEBUG_SND=OFF WITH_DEBUG_SVC=OFF WITH_DEBUG_SYMBOLS=OFF WITH_DEBUG_THREADS=OFF WITH_DEBUG_TIMEZONE=OFF WITH_DEBUG_TRANSPORT=OFF WITH_DEBUG_TSG=OFF WITH_DEBUG_TSMF=OFF WITH_DEBUG_TSMF=OFF WITH_DEBUG_TSMF_AVAILABLE=0 WITH_DEBUG_URBDRC=OFF WITH_DEBUG_WND=OFF WITH_DEBUG_X11=OFF WITH_DEBUG_X11_CLIPRDR=OFF WITH_DEBUG_X11_LOCAL_MOVESIZE=OFF WITH_DEBUG_XV=OFF WITH_DSP_EXPERIMENTAL=OFF WITH_DSP_FFMPEG=OFF WITH_EVENTFD_READ_WRITE=1 WITH_FAAC=OFF WITH_FAAD2=OFF WITH_FFMPEG=TRUE WITH_FFMPEG=TRUE WITH_FUSE=ON WITH_GFX_H264=ON WITH_GPROF=OFF WITH_GSM=ON WITH_GSSAPI=OFF WITH_GSTREAMER_1_0=OFF WITH_ICU=OFF WITH_IPP=OFF WITH_JPEG=OFF WITH_LAME=ON WITH_LIBRARY_VERSIONING=ON WITH_LIBSYSTEMD=ON WITH_MACAUDIO=OFF WITH_MACAUDIO=OFF WITH_MACAUDIO_AVAILABLE=0 WITH_MANPAGES=ON WITH_MBEDTLS=OFF WITH_NEON=OFF WITH_OPENCL=OFF WITH_OPENH264=OFF WITH_OPENSLES=OFF WITH_OPENSSL=ON WITH_OSS=OFF WITH_PCSC=ON WITH_PROFILER=OFF WITH_PULSE=ON WITH_SAMPLE=OFF WITH_SANITIZE_ADDRESS=OFF WITH_SANITIZE_ADDRESS_AVAILABLE=1 WITH_SANITIZE_MEMORY=OFF WITH_SANITIZE_MEMORY_AVAILABLE=1 WITH_SANITIZE_THREAD=OFF WITH_SANITIZE_THREAD_AVAILABLE=1 WITH_SERVER=OFF WITH_SERVER_INTERFACE=ON WITH_SMARTCARD_INSPECT=OFF WITH_SOXR=OFF WITH_SSE2=ON WITH_SWSCALE=OFF WITH_THIRD_PARTY=OFF WITH_VAAPI=ON WITH_VALGRIND_MEMCHECK=OFF WITH_VALGRIND_MEMCHECK_AVAILABLE=1 WITH_WAYLAND=OFF WITH_WINPR_TOOLS=ON WITH_X11=ON WITH_X264=OFF WITH_XCURSOR=ON WITH_XEXT=ON WITH_XFIXES=ON WITH_XI=ON WITH_XINERAMA=ON WITH_XKBFILE=ON WITH_XRANDR=ON WITH_XRENDER=ON WITH_XSHM=ON WITH_XV=ON WITH_ZLIB=ON
Build type:          Release
CFLAGS:              -O2 -m64 -fPIC -Wall -Wno-unused-result -Wno-unused-but-set-variable -Wno-deprecated-declarations -fvisibility=hidden -Wimplicit-function-declaration -Wredundant-decls -fno-omit-frame-pointer -DWINPR_DLL
Compiler:            GNU, 8.3.0
Target architecture: x64
(ARM versions lack WITH_SSE2=ON and WITH_VAAPI=ON and add WITH_NEON=ON, but are otherwise the same)
Example command line:
xfreerdp /client-hostname:n94c69118b1c3 /f /floatbar:sticky:off,default:hidden,show:fullscreen /multimon /dynamic-resolution /bpp:32 /cert:ignore /u:Administrator /d:TEST /from-stdin:force /network:auto /rfx /gfx:AVC420 +clipboard /audio-mode:0 /sound:sys:pulse,quality:high /microphone:sys:pulse /drive:storage,/media /printer /v:<IP_ADDRESS>

Can confirm, this same bug is also happening on my machine. Floatbar frozes and it also frozes the whole RDP session. I've found that only solution after that is restarting lightdm process or the whole machine. Killing the xreerdp process does not help as the image of the session is "stuck" on the screen.
My host machine is running Manjaro 21.2.6 with Linux 5.17.9. Target machine is Windows 10.
Log is full of these lines:

[07:53:18:667] [2255:2256] [WARN][com.freerdp.client.x11] - xf_lock_x11_:	[1] recursive lock from xf_sw_end_paint
[07:53:18:667] [2255:2256] [WARN][com.freerdp.client.x11] - xf_lock_x11_:	[1] recursive lock from xf_sw_end_paint
[07:53:18:668] [2255:2256] [WARN][com.freerdp.client.x11] - xf_lock_x11_:	[1] recursive lock from xf_sw_end_paint
[07:53:18:675] [2255:2256] [WARN][com.freerdp.client.x11] - xf_lock_x11_:	[1] recursive lock from xf_sw_end_paint
[07:53:18:675] [2255:2256] [WARN][com.freerdp.client.x11] - xf_lock_x11_:	[1] recursive lock from xf_sw_end_paint
[07:53:18:675] [2255:2256] [WARN][com.freerdp.client.x11] - xf_lock_x11_:	[1] recursive lock from xf_sw_end_paint
[07:53:18:683] [2255:2256] [WARN][com.freerdp.client.x11] - xf_lock_x11_:	[1] recursive lock from xf_sw_end_paint

Example command line:
xfreerdp /sec:tls /d:AzureAD /u:<username> /p:<password> /v:<host-ip> /floatbar:sticky:off,show:fullscreen /f /multimon +fonts /sound
I'm running Xorg (xorg-server 21.1.3-4) with nVidia drivers (linux517-nvidia 510.73.05-1).

BTW, our customers have told us that adding "-aero" is not a viable workaround, although it apparently reduces the frequency of the problem.
The problem continues to occur in FreeRDP 2.7.0.

BTW, our customers have told us that adding "-aero" is not a viable workaround, although it apparently reduces the frequency of the problem.
The problem continues to occur in FreeRDP 2.7.0.

I can also confirm both of these statements. I was missing my FreeRDP version from my report but I'm on the 2.7.0. I've tried using the "-aero" option but indeed this seems to reduce the frequency but the problem is still happening sometimes.

Anyway, reviewing the initial problem description again and I did miss the obvious:

It was a decoder error ([08:59:50:936] [27696:27731] [ERROR][com.freerdp.codec.progressive] - Invalid total tile count, maximum 558)
with +auto-reconnect that ended in a endless reconnect loop.

Since the description of @whitpa and @uuksu is different, I think we´re talking about different problems here.

@akallabeth

Yes, -areo never was and never will have anything to do with any of this (sorry, it just does nothing with anything newer than windows 7, and with windows 7 it just tells the server we want some other decorations - which is just a bitmap as any other for the client)

Oh well, it was then good ol' placebo. As a old Windows 7 users I should have known better that the Aero is a think of the past.

Your description of Killing the xfreerdp process does not help as the image of the session is "stuck" on the screen. suggests there is something wrong with your system rather than FreeRDP (killing xfreerdp and it is gone for sure), maybe a bug in the graphics drivers?

That's totally possible, the nVidia Linux drivers are not known to be the most stable thing existed. I'm still thinking that the problem might be in the FreeRDP as no other application behaves this way.
I've killed the xfreerdp process and I know it's gone. This leaves the session screen black, only the floatbar is visible on the top. Floatbar is not usable before or after killing the process so I can't exit the application normally.

The log messages can be ignored (I´ve just not backported the fix to stable-2.0 yet, fixed with Removed recursive xf_lock_x11 warning #7938

Ok, good to know. Those lines were the ones that lead me to this issue so thougth they might be related.

@whitpa btw, you are disabling AVC support with that command line (AVC420 was only supported with windows 8.1)

Yes, I doubted that either the debug output or strace output would be of much use.  The log really did stop mid-line once frozen, so it must occur between buffer flushes.
P.S. That's twice in this thread alone that you have admitted that options that the manpage implies do something in fact do nothing.   FreeRDP documentation leaves much to be desired!  Perhaps you need to qualify in the manpage what versions of the RDP protocol each option is applicable to?

That's twice in this thread alone that you have admitted that options that the manpage implies do something in fact do nothing. FreeRDP documentation leaves much to be desired! Perhaps you need to qualify in the manpage what versions of the RDP protocol each option is applicable to? => we're always opened to PR ;)

@whitpa no, the options do what they tell, but the client announced stuff will only be used by the server if it supports it too (e.g. AVC420)
You can not force the server to something it is not willing to use, the final decision of what of the supported options will be used is always up to the server
Best thing to do is just use the defaults (if you are on 2.7.0) or add /network:auto to have the most recent stuff enabled.

...so a full strace might help

Hey @akallabeth , we're having the same issue - interacting with the floatbar will sometimes freeze up xfreerdp, but if we kill the xfreerdp process the system is otherwise unaffected.  We're currently running FreeRDP 2.10.0.
You mentioned a full strace might help, I'd be happy to gather anything that would be useful.  I used strace -f -p 5369 -o xfreerdp_trace.txt to save the output to a file, but it seemed to be writing endlessly so I stopped it when it got to ~100K lines.
Mostly it's just a lot of this, with the middle block repeating every now and again:
5399  poll([{fd=50, events=POLLIN}, {fd=52, events=POLLIN}, {fd=56, events=POLLOUT}, {fd=57, events=POLLOUT}], 4, 1) = 0 (Timeout)
5399  poll([{fd=50, events=POLLIN}, {fd=52, events=POLLIN}, {fd=56, events=POLLOUT}, {fd=57, events=POLLOUT}], 4, 1) = 0 (Timeout)
5399  poll([{fd=50, events=POLLIN}, {fd=52, events=POLLIN}, {fd=56, events=POLLOUT}, {fd=57, events=POLLOUT}], 4, 1) = 0 (Timeout)
5399  poll([{fd=50, events=POLLIN}, {fd=52, events=POLLIN}, {fd=56, events=POLLOUT}, {fd=57, events=POLLOUT}], 4, 1) = 0 (Timeout)
5399  poll([{fd=50, events=POLLIN}, {fd=52, events=POLLIN}, {fd=56, events=POLLOUT}, {fd=57, events=POLLOUT}], 4, 1) = 0 (Timeout)
5399  poll([{fd=50, events=POLLIN}, {fd=52, events=POLLIN}, {fd=56, events=POLLOUT}, {fd=57, events=POLLOUT}], 4, 1) = 0 (Timeout)
5399  poll([{fd=50, events=POLLIN}, {fd=52, events=POLLIN}, {fd=56, events=POLLOUT}, {fd=57, events=POLLOUT}], 4, 1) = 0 (Timeout)
5399  poll([{fd=50, events=POLLIN}, {fd=52, events=POLLIN}, {fd=56, events=POLLOUT}, {fd=57, events=POLLOUT}], 4, 1) = 0 (Timeout)
5399  poll([{fd=50, events=POLLIN}, {fd=52, events=POLLIN}, {fd=56, events=POLLOUT}, {fd=57, events=POLLOUT}], 4, 1) = 0 (Timeout)
5399  poll([{fd=50, events=POLLIN}, {fd=52, events=POLLIN}, {fd=56, events=POLLOUT}, {fd=57, events=POLLOUT}], 4, 1) = 0 (Timeout)
5399  poll([{fd=50, events=POLLIN}, {fd=52, events=POLLIN}, {fd=56, events=POLLOUT}, {fd=57, events=POLLOUT}], 4, 1) = 0 (Timeout)
5399  poll([{fd=50, events=POLLIN}, {fd=52, events=POLLIN}, {fd=56, events=POLLOUT}, {fd=57, events=POLLOUT}], 4, 1 <unfinished ...>
5402  <... poll resumed>)               = 0 (Timeout)
5402  getpid()                          = 5369
5402  write(61, "W", 1)                 = 1
5402  write(61, "W", 1)                 = 1
5402  write(61, "W", 1)                 = 1
5402  read(60, "WWW", 10)               = 3
5402  write(62, "\1\0\0\0\0\0\0\0", 8)  = 8
5402  read(60, 0x7f202a7fb93e, 10)      = -1 EAGAIN (Resource temporarily unavailable)
5402  poll([{fd=60, events=POLLIN}, {fd=63, events=POLLIN}, {fd=64, events=POLLIN}], 3, 1500) = 1 ([{fd=64, revents=POLLIN}])
5402  read(64, "\1\0\0\0\0\0\0\0", 8)   = 8
5402  read(60, 0x7f202a7fb93e, 10)      = -1 EAGAIN (Resource temporarily unavailable)
5399  <... poll resumed>)               = 0 (Timeout)
5402  poll([{fd=60, events=POLLIN}, {fd=63, events=POLLIN}, {fd=64, events=POLLIN}], 3, 1500 <unfinished ...>
5399  poll([{fd=50, events=POLLIN}, {fd=52, events=POLLIN}, {fd=56, events=POLLOUT}, {fd=57, events=POLLOUT}], 4, 1) = 0 (Timeout)
5399  poll([{fd=50, events=POLLIN}, {fd=52, events=POLLIN}, {fd=56, events=POLLOUT}, {fd=57, events=POLLOUT}], 4, 1) = 0 (Timeout)
5399  poll([{fd=50, events=POLLIN}, {fd=52, events=POLLIN}, {fd=56, events=POLLOUT}, {fd=57, events=POLLOUT}], 4, 1) = 0 (Timeout)
5399  poll([{fd=50, events=POLLIN}, {fd=52, events=POLLIN}, {fd=56, events=POLLOUT}, {fd=57, events=POLLOUT}], 4, 1) = 0 (Timeout)
5399  poll([{fd=50, events=POLLIN}, {fd=52, events=POLLIN}, {fd=56, events=POLLOUT}, {fd=57, events=POLLOUT}], 4, 1) = 0 (Timeout)
5399  poll([{fd=50, events=POLLIN}, {fd=52, events=POLLIN}, {fd=56, events=POLLOUT}, {fd=57, events=POLLOUT}], 4, 1) = 0 (Timeout)
5399  poll([{fd=50, events=POLLIN}, {fd=52, events=POLLIN}, {fd=56, events=POLLOUT}, {fd=57, events=POLLOUT}], 4, 1) = 0 (Timeout)
5399  poll([{fd=50, events=POLLIN}, {fd=52, events=POLLIN}, {fd=56, events=POLLOUT}, {fd=57, events=POLLOUT}], 4, 1) = 0 (Timeout)
5399  poll([{fd=50, events=POLLIN}, {fd=52, events=POLLIN}, {fd=56, events=POLLOUT}, {fd=57, events=POLLOUT}], 4, 1) = 0 (Timeout)

xfreerdp_trace.txt.zip
Please let me know if there are any different options you'd need me to use when running strace, or I can build xfreerdp with specific flags, etc.
Thanks!

I think that this problem may have been (incidentally/unintentionally) fixed in recent releases, although I'm not sure which one.  Your symptom sounds diffferent to / less severe than the one we had originally.


Load context into struct metadata

The goal of the change is to have the :context track along with the schema metadata so that it can be used by an adapter for its own purposes.
The :prefix option already has good semantics for this, except that it is restricted to String.t() and subjected to is_binary guards. We can certainly duplicate the way prefix is treated with the context field, but this would result in a large changeset (particularly because we would need %Query{context: ...} or similar.
As is, this PR is a bit of a compromise in that it loads the context onto the schema on the basic operations, but does not attempt to duplicate all of the Query's prefix semantics. (subqueries, etc)

So I understand the use case better, what situations is this handling that Ecto.put_meta/2 is not?

So I understand the use case better, what situations is this handling that Ecto.put_meta/2 is not?

Pulling in some details from the mailing list:
In my adapter for FoundationDB I've been misusing the :prefix option to pass an opaque data structure from the caller to my adapter. (Specifically this is a tuple of the type {:erlfdb_tenant, reference()}, which is the handle to an open FDB Tenant).
It seems that the :context may be a more appropriate way of doing this, which is necessary as of 3.12, since the :prefix is now subjected to is_binary checks.
However, there is a nice feature of the :prefix that isn't present with :context.
      tenant = open_tenant()
      user = TestRepo.get(User, id, context: tenant)
      assert ^tenant = Ecto.get_meta(user, :context) # fail

The assertion here fails, with the :context entry being nil. If you do something similar with :prefix, it works as expected.

This change would allow the caller to carry the context on the schema struct without an explicit call to Ecto.put_meta/2.

One important difference between prefix and this is with preloads. Each preloaded schema can define @schema_prefix to ignore the one given to the repo operation. Or prefix can be given individual joins. But with this it would just apply in a blanket manner to everything.
For the example you gave, it seems this is meant to be a convenience using an option on the repo rather than having to call a separate function afterwards. Is that the main advantage or is there something else?
tenant = open_tenant()
user = TestRepo.get(User, id, context: tenant)
assert ^tenant = Ecto.get_meta(user, :context) # fail

My adapter isn't attempting to use context as an option, but rather as the context in which a particular schema struct is relevant.
FoundationDB has many differences to the more commonly supported DBs, so I am happy to answer any specifics, but I'll try to avoid too much detail. :)
In the FDB adapter, the tenant object is a resource that's acquired by the caller during runtime and used across several transactions. At a high level it can be considered an entirely separate database to achieve multi-tenancy.
When writing a schema to a particular tenant, we wish to consider that schema struct as intrinsically tied to that tenant, so that future operations (e.g. Changeset) remain tied to that tenant. This protects the caller from accidentally writing a struct from one tenant into another tenant. (To do so the caller should explicitly remove the context from the struct metadata)
It's true that we could force the caller to call put_meta on each struct, but it would be prone to bugs and vulnerabilities.
I believe this use case to be similar to one of the prefix use cases: a way to implement multi-tenancy. However, my tenant is not a string. Instead, it can be considered a token (opaque data structure) to the tenant. This allows the developer to centralize some of their authorization checks to acquire that tenant resource, and have confidence that the tenancy won't be broken.

In your changes it is not obvious to me how this is handled:

One important difference between prefix and this is with preloads. Each preloaded schema can define @schema_prefix to ignore the one given to the repo operation. Or prefix can be given individual joins. But with this it would just apply in a blanket manner to everything.

Could you perhaps write a test where you are retrieving data from a query like this from schema_a, join: schema_b where schema_a and schema_b are given different contexts?

It's true that we could force the caller to call put_meta on each struct, but it would be prone to bugs and vulnerabilities.

I might be misunderstanding your use case, could you correct me if I have the wrong idea:

You are proposing the user passes a correct context into the repo call where they first fetch the data. Ecto will insert the context into the schema metadata automatically.
Currently the user needs to pass the correct context to Ecto.put_meta/2 after they first fetch the data.

It is not too clear to me how one is more error prone than the other. If there is more to this, like your adapter is using the context during the first repo call then that use case makes sense to me. But if it's just about how the metadata is first being put into the struct, that is less clear to me.

I didn't attempt to cover this use case yet

No worries, the smaller initial PR is appreciated.
I am basically just trying to figure out the right path forward. Because context is a schema property, if we were to put it as an option in the Repo functions then it would be a bit of a problem for it to always apply to every schema in the query. For this use case it might not be a problem, but it wouldn't really be a general solution or in line with the way other schema properties behave, like prefix.

Indeed, the adapter uses the context on the first repo call. In my use case, the context is not a property of the Schema definition, but rather a property of the struct during runtime.

This part I'm still having trouble understanding, apologies. If it is not a property of the schema then what would you adapter to with context in this case:
tenant = open_tenant()
user = TestRepo.get(User, id, context: tenant)

Since the struct does not exist until after the database operation has finished, what is your adapter doing with context during this call?

the way other schema properties behave, like prefix.

It's worth noting that I've successfully been using prefix for this exact purpose up until Ecto 3.12. In 3.11, the type was still String.t(), so my adapter could be considered out of spec, but there were no is_binary guards, at least not in the code paths my adapter exercised. There are guards in 3.12 that have broken my adapter. I was out of spec, so no complaints from me here.
In trying to resolve, I want context to behave exactly the way prefix does, but without the string requirement. I am stopping short of requesting that prefix remove the string requirement in the Ecto API, because this appears to be a design choice.

If it is not a property of the schema

Hm, terminology may be failing us here. If I may adopt an OOP analogy: in my adapter, the context: tenant is a property of the Schema object, not of the Schema class.

Since the struct does not exist until after the database operation has finished, what is your adapter doing with context during this call?

The adapter requires thecontext: tenant to issue a transaction on the database. If the record is found, the resulting struct should have context: tenant in the metadata for future operations.
# Adapter pseudo-code. Background: FDB is a key-value store which maintains a separate
# keyspace for each tenant. Tenant A can have /users/id123 and Tenant B can have /users/id123,
# and the values are independent.
FoundationDB.transaction(tenant,
  fn tx ->
    case :erlfdb.get(tx, "/users/#{id}") do
      :not_found ->
        nil
      data ->
        {:ok, data}
  end)

If I were able to translate the above into SQL, it would look something like this
RDBMS.exec("""
SELECT * FROM #{prefix}.users
WHERE id = $1
""", [id])

Thanks for answering all my questions. Apologies for being so unfamiliar with your db.
So to me it sounds like you are using context to direct your queries to the right place. Which is basically what prefix does.
I don't think we want to turn context into an alternate prefix. As you alluded to the changes would be quite large if we want behaviour to be general/consistent.
So then the question is do we open up prefix to non-strings or I think Jose was alluding to something like an adapter callback that can take the metadata you put into the repo options and then do whatever it wants to with it on the result of the query. At least I think that's what he meant.
Since Jose responded to you in the mailing list let's get his opinion on this too. At the moment I can't remember why we made prefixes strings only. I will have to go back and look.

Thanks for sticking in there with me @greg-rychlewski ! 🤝
By all means I'm open to other clever solutions here.
I admit I'm confused by what Ecto considers to be the high level difference between prefix and context.
From Ecto.Schema.Metadata:
On :context, the docs have this:

The :context field represents additional state some databases require for proper updates of data.

On :prefix:

Tracks the source prefix in the data storage.

Naively, I read this as :prefix being a subset of :context. But there may be some nuance I'm missing.

It was before my time, but just looking at the code context is quite limited compared to prefix. There is a lot of logic for ensuring prefix can be handled individually across different schema in a query. And setting precedence rules across different specifications.
For context it seems like it was meant for the user to add something manually onto a previously fetched struct.

@JesseStimpson have you explored using the process dictionary to store this information?
You would be able to sidestep Ecto completely. But I also see the value in leveraging context, although I can’t remember seeing any adapter currently using it.

The context was added precisely to track schema information across insert to update and delete, such as a tenant, and I think it is reasonable to extend it to queries.
However, I think the similarities with prefixes is worth discussing. Prefixes have very fine grained control. You can set them per query, per join, per preload. @JesseStimpson, can you have a query where the context is different between a join or a preload? If so, using prefixes may be the best option indeed, as you will have more control, as the :context would rather apply to all equally.
So our options are:

Keep :prefix as a binary and FoundationDB uses it. @JesseStimpson, although the tenant is a reference today, could it be a name as well? Maybe the node name the tenant is running on?
We remove the restriction that prefix is a binary
We add context as this PR

My main comment about keeping the changes in the PR is that it feels a bit inconsistent to say :context applies to everything and :prefix has fine grained controls. Since they are both just schema metadata I don't personally see why one should behave different than the other.
Let's say Foundation DB doesn't need that control but then later on Foundation DB 2 did. Then I feel they would be right to question the difference in behaviour. And then we would basically need to re-implement prefixes again but with a different name.

That's a good point. Shall we just revert the binary checks from prefix then?

That's my feeling but I couldn't remember why we forced them to be binary. Was going to take a look at our old convos to make sure we won't get bit some other way.

have you explored using the process dictionary to store this information?

This wouldn't be ideal, I think. The caller would have to be aware of this behavior when they send a struct to a different process.

can you have a query where the context is different between a join or a preload?

I'd like to support this someday in the FDB adapter. It is not currently implemented, but it's a perfectly reasonable query.

although the tenant is a reference today, could it be a name as well?

The tenant is identified by a string name, but it's important to me to keep the semantics of "acquiring the tenant resource" so that an application developer can centralize authorization checks.
I have been thinking on how to have my cake (string) and eat it too (resource-based). It's possible but a bit awkward as I would have to maintain a registry for "open tenants" and then figure out how to garbage collect them. Currently I am taking advantage of ref counting on enif_resource to which the reference points.
That being said, if a change to the Ecto API is not possible, I believe I would rather choose to use context as is, and work around the current shortcomings.

Shall we just revert the binary checks from prefix then?

I would love this ❤ 😄 ! If I may, I'd also request changing the type from String.t() to a type that supports some kind of container String.t() | map(), String.t() | tuple(), any(), etc.

I have been thinking on how to have my cake (string) and eat it too (resource-based). It's possible but a bit awkward as I would have to maintain a registry for "open tenants" and then figure out how to garbage collect them.

How many tenants can you have? Are they are always opened and closed dynamically? Keeping open connections in Erlang/Elixir is very cheap, so if the number is limited (hundreds and not dozens of thousands), wouldn't it be more efficient to keep them open (unless FDB itself is not happy with this arrangement).

I love the opportunity to evangelize FDB :)
It may be important for me to note that FDB is a kv store with ACID transactions, and the EctoFDB adapter takes an opinionated stance on how data is laid out in the keyspace (Layer Concept). I'll just focus on FDB itself when discussing limitations, so I can remove any opinions I've baked into EctoFDB.
In FDB, when a tenant is created, it's internally assigned an 8-byte integer. When a tenant is opened, FDB guarantees that any transaction created from it can only access keys that are prefixed with that 8-byte integer. This prefix is an implementation detail internal to FDB and the prefix itself is not exposed to the database client.

How many tenants can you have?

At the FDB storage level, since a tenant is simply an 8-byte prefix to a key, there is effectively no limit on the number of tenants. The total number of keys will be limited by the hardware on which the FDB cluster runs. (Billions of keys)
How many tenants can you have open from one client? I'm not aware of any limit other than system memory. Each open tenant is not a connection to the database. Instead, consider it a rule imposed on any transactions created from that tenant. I don't know of any reason why a sufficient system would not be able to open 100k+ concurrent tenants.
At the FDB C API, I believe the "open tenant" is just a C struct.

Are they are always opened and closed dynamically?

Yes, the tenant must be opened before transacations can be created from it. However, the use of tenants itself is optional in FDB. One can write to the keyspace without the concept of a tenant. [ In EctoFDB I've chosen to require a tenant, at least for now ]
All that being said, my adapter already prefers to keep many tenants open long term. For example, when a LiveView mounts, we can check that the client is authorized to access a certain tenant, and open it. That tenant can be used for the lifetime of the LiveView. When the LiveView is terminated, the open tenant will be garbage collected.
Maybe some example code will help demonstrate. I believe this is the same way a Postgres app would use prefix, except my prefix is fundamentally not a string.
defmodule MyAppWeb.InitAssigns do
  def on_mount(:user, _params, session, socket) do
    user_identity = get_user_identity(session)

    if user_identity do

      # ** centralized authorization check for acquiring the tenant resource **
      tenant = MyApp.Repo.open_tenant(user_identity.id)

      {:cont,
       socket
       |> assign(:tenant, tenant)}
    else
      {:halt,
       socket
       |> put_flash(:error, "You must sign in")}
    end
  end
end

# router
  live_session :authenticated, on_mount: {MyAppWeb.InitAssigns, :user} do
    scope "/", MyAppWeb do
      pipe_through :browser
      live "/dashboard", DashboardLive, :home
      # ...
    end
  end

defmodule MyAppWeb.DashboardLive do
  def mount(_params, _session, socket) do

    # ** retrieves all notifications for a given tenant **
    notifications =
        MyApp.Repo.all(Notification, context: tenant) # or prefix: tenant

    {:ok, socket |> assign(:notifications, notifications}
  end

  def handle_event("mark_all_read", _params, socket) do
    for n <- socket.assigns.notifications do
      changeset = Notification.changeset(n, %{state: :read})

      # ** tenant is in metadata, does not need to be specified **
      MyApp.Repo.update(changeset)

    end
    {:noreply, socket |> assign(:notifications, [])}
  end
end

You can probably ignore my earlier comment about a registry for tenants by string. I did a poor job explaining it, and it's not something I would choose to implement due to the complexity. I suppose I was simply trying to get the message across that my desired :prefix/:context is not a string.
One thing I don't want to do is change my adapter to this
MyApp.Repo.get(Notification, prefix: user_identity.id) # id is a string
MyApp.Repo.insert(notif, prefix: user_identity.id) # id is a string
...

This style would impose that the adapter internally opens the tenant for each transaction. It's important to my vision of the EctoFDB adapter that the application developer is responsible for opening tenants. (Authorization checks and on-line Migrations)

Alright, thank you! @greg-rychlewski said he would look into blockers to reverting prefix to non-binary, so if there is nothing, we are happy to revert it :)

There's nothing that stands out to me from the conversation around the change. It seemed mostly like standardizing around the way Ecto.Query.put_query_prefix works.
But maybe to be safe when making the change, it would be good to have tests for everything with non-binary prefix:

@schema_prefix
Ect.Query.put_query_prefix
:prefix option on repo
:prefix option on from/join

We also need to change migrations in Ecto SQL to accept non-strings.

I think it is fine for Ecto SQL to expect and impose strings. The rationale is that it should be an adapter concern, not an Ecto one.
@JesseStimpson would you please send a PR? :)

@josevalim @greg-rychlewski Thanks for being open to this change. I'll work on a new PR for it.
What would you like to do with this PR about the context? I will no longer being using :context in my adapter with the change to :prefix, so I have no need for it, and leave it to your judgment.

I believe we can close this then and reopen if there is a need. :)


add ExecuteShard in vtgateconn

Add ExecuteShard in go/vt/vtgate/vtgateconn/vtgateconn.go and an implementation
in go/vt/vtgate/gorpcvtgateconn/conn.go
Fix go/vt/vtgate/gorpcvtgateconn/conn_test.go so that it reads vtgate
port from test/java_vtgate_test_helper.py output instead of a hard coded
number.

LGTM after comment is addressed.

lgtm


Correct --scope argument to dbs

Trying to assign a scope based on an ARM resource id (as currently referenced in the docs) with the az cosmosdb sql role assignment create command results in the following error:
(BadRequest) Failed to parse the incoming request payload. Exception: System.FormatException: Could not parse property [properties] as [Microsoft.Azure.Documents.Management.Services.ResourceProvider.DataModel.RoleBasedAccessControl.SqlRoleAssignmentProperties] due to exception: System.FormatException: Could not parse property [scope] with value [/subscriptions/c188d79d-f4df-44c8-b9f1-0080b70a00b3/resourceGroups/rg-mlrpreflight-griff/providers/Microsoft.DocumentDB/databaseAccounts/cos-mlrgriff/subscriptions/c188d79d-f4df-44c8-b9f1-0080b70a00b3/resourceGroups/rg-mlrpreflight-griff/providers/Microsoft.DocumentDb/databaseAccounts/cos-mlrgriff] as [Microsoft.Azure.Documents.Management.Services.ResourceProvider.DataModel.RoleBasedAccessControl.FullyQualifiedResourcePath] due to exception: System.FormatException: Expected path segment [dbs] at position [0] but found [subscriptions].

I believe this should be dbs instead to assign to the database scope, which I've tested and works correctly.

@jjgriff93, the Azure CLI and PowerShell commands provide a "shorthand" syntax to assign the scope. Here's a quick breakdown.
First, the scope of a data-plane assignment must be at the account level or lower. So, you can assign scope at the account level, database level, or container level.
For Azure CLI and Azure PowerShell, there's a shorthand syntax where you can omit the full resourceId for the account. However, after your run the command, the output will show that the scope is fully qualified. Here's a few examples:

Scope
Shorthand
Fully-qualified

Account
/
/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.DocumentDB/databaseAccounts/<account-name>/

Database
/dbs/<database-name>
/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.DocumentDB/databaseAccounts/<account-name>/dbs/<database-name>

Container
/dbs/<database-name>/colls/<container-name>
/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.DocumentDB/databaseAccounts/<account-name>/dbs/<database-name>/colls/<container-name>

We intentionally fully qualify the scopes in documentation to try and clear things up. I also personally found that the scope must be fully qualified in REST API, Bicep, and ARM template requests.
So yes, you can use the shorthand in CLI commands, but we documented the fully qualified syntax. You can read more about it in the scope section of the security glossary.
@markjbrown, can you provide additional guidance here?

@seesharprun
When the changes are ready for publication, adding a #sign-off comment is the best way to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

Pending further discussion.
#hold-off

@seesharprun @jjgriff93 Nothing further to add. The guidance provided in the docs is correct.

#please-close


set :no_pull doesn't work afaik

I tried this:
  task :local => :common do
    set :no_pull, true
  end
end```
but it still attempted the pull.  I ended up adding this in the task instead:
`Rake::Task["deploy:pull_image"].clear_action`
Is that the right way?

It looks like it shoudl work by just setting it in your common task like you did. If that's not working, it may be a matter of the environment already being set and the top level settings being ignored. Try setting it in your development or production, etc task and see if that does it. If so, then we should fix that as it's a bug.


Change the description of release

LGTM

The page folder can be dropped, it's replaced by jumbotron

Exactly. This PR is now outdated and the sentence updated in this PR is gone. I close this now. Reopen otherwise.


Interaction between client and server

This version supports multiple clients simultaneously. The demo and the actual test are served from the server. The functionality is not complete yet, but feedback would be appreciated so that corrections can be made. Apologies for the big PR.
PENDING

Setup ping every 5 seconds between server and client and synchronize clocks. Also, write to file the question the client is seeing at this point.
Create a session and maintain session info.

This change is

We could remove the demo_test.yml and the cand_test.txt before merging as they are repeated.

Reviewed 10 of 10 files at r1.
Review status: all files reviewed at latest revision, 4 unresolved discussions.

server/main.go, line 305 [r1] (raw file):

	flag.Parse()
	quizInfo = extractQuizInfo(*quizFile)
	qnList = extractQids(TEST)

I think all the QIDs for different tests should be extracted in extractQuizInfo as we dont want to change the server in case we add a new test. So we could have a map in quiz info which stores the QID list in quizInfo["qildList"][<test_name>] and populate it in extractQuizInfo

server/main_test.go, line 11 [r1] (raw file):

func TestIsCorrectAnswer(t *testing.T) {
	quizInfo = extractQuizInfo("demo_test.yaml")
	r := interact.Response{Qid: "demo-2", Aid: []string{"demo-2a"},

Could have one field per line, would make it look good to read

server/main_test.go, line 25 [r1] (raw file):

	}

	r = interact.Response{Qid: "demo-2", Aid: []string{"demo-2c", "demo-2a"},

Same as above, one field per line

server/main_test.go, line 71 [r1] (raw file):

		t.Errorf("Expected q.Id not to be %s", END)
	}
	getQuestion(req)

Maybe we can add a test here to make sure the question that we got before is not the same as this

Comments from Reviewable

Reviewed 5 of 5 files at r2.
Review status: all files reviewed at latest revision, 4 unresolved discussions.

Comments from Reviewable

Hmm, cand_test.txt would be cleared and replaced with another file with the candidate info. demo_test.txt is just there for the testing.

Review status: all files reviewed at latest revision, 4 unresolved discussions.

server/main.go, line 305 [r1] (raw file):
Previously, ashwin95r (Ashwin Ramesh) wrote…
> I think all the QIDs for different tests should be extracted in `extractQuizInfo` as we dont want to change the server in case we add a new test. So we could have a map in quiz info which stores the QID list in `quizInfo["qildList"][]` and populate it in `extractQuizInfo`

How about having it as quizInfo[test_name] = [qids]? Then extractQuizInfo could be used to extract info for all tests.

Comments from Reviewable

Review status: all files reviewed at latest revision, 4 unresolved discussions.

server/main.go, line 305 [r1] (raw file):
Previously, pawanrawal (Pawan Rawal) wrote…
> How about having it as quizInfo[test_name] = [qids]? Then extractQuizInfo could be used to extract info for all tests.

Wouldn't it already have the list of questions structure with `test_name` as the key

Comments from Reviewable

Review status: 7 of 10 files reviewed at latest revision, 34 unresolved discussions.

client/main.go, line 273 [r10] (raw file):
Previously, manishrjain (Manish R Jain) wrote…
> Instead of inlining go functions, you should declare them outside this, and just call them via their function name.

Done.

client/main.go, line 280 [r10] (raw file):
Previously, manishrjain (Manish R Jain) wrote…
> You mean return? Given this is a goroutine, you can just return.
>
> If you return, then remove the else below.

Done.

client/main.go, line 290 [r10] (raw file):
Previously, manishrjain (Manish R Jain) wrote…
> return?

Done.

server/demo_test.yaml, line 32 [r10] (raw file):
Previously, manishrjain (Manish R Jain) wrote…
> Do we tackle multiple tags?

Done.

server/main.go, line 378 [r10] (raw file):
Previously, manishrjain (Manish R Jain) wrote…
> Make this a separate function. It gets harder to understand logic when all the goroutines are inlined.

Done.

server/main.go, line 384 [r10] (raw file):
Previously, manishrjain (Manish R Jain) wrote…
> return?

Done.

server/main.go, line 391 [r10] (raw file):
Previously, manishrjain (Manish R Jain) wrote…
> Are we continuing to try? Or, supposed to return here?

We do not know if this is a temporary error or the client has crashed. So assuming crash, we can return

server/main.go, line 403 [r10] (raw file):
Previously, manishrjain (Manish R Jain) wrote…
> Make this a separate function.

Done.

server/main.go, line 417 [r10] (raw file):
Previously, manishrjain (Manish R Jain) wrote…
> if break else break? :-)

Ah, my bad. Done.

Comments from Reviewable

Review status: 5 of 10 files reviewed at latest revision, 34 unresolved discussions.

client/main.go, line 30 [r10] (raw file):
Previously, manishrjain (Manish R Jain) wrote…
> This should be a flag, with a value which defaults to our server.

Done.

client/main.go, line 35 [r10] (raw file):
Previously, manishrjain (Manish R Jain) wrote…
> Not a fan of global variables. Couldn't we have encapsulated these in a struct?

Encapsulated lot of them.

server/main.go, line 484 [r10] (raw file):
Previously, manishrjain (Manish R Jain) wrote…
> Unnecessary vertical space.

Done.

server/main.go, line 486 [r10] (raw file):
Previously, manishrjain (Manish R Jain) wrote…
> This should be log fatal no?

Done.

server/main_test.go, line 71 [r1] (raw file):
Previously, ashwin95r (Ashwin Ramesh) wrote…
> Maybe we can add a test here to make sure the question that we got before is not the same as this

Done.

Comments from Reviewable

Review status: 5 of 10 files reviewed at latest revision, 34 unresolved discussions.

client/main.go, line 297 [r10] (raw file):
Previously, manishrjain (Manish R Jain) wrote…
> This equates to if x != time.Second, which is not what you want. Use math.Abs

There isn't abs for time.Duration. I think this condition should work

client/main.go, line 299 [r10] (raw file):
Previously, manishrjain (Manish R Jain) wrote…
> This approach is easy to break. Instead have the server return back time left. Then you wouldn't need to hard code testDur.

Done.

client/main.go, line 299 [r10] (raw file):
Previously, manishrjain (Manish R Jain) wrote…
> Create a function which does setLeftTime(), and another function which does leftTime(). Both these functions would make the time thread safe. In fact, have a struct to handle all this time management.

Done.

client/main.go, line 307 [r10] (raw file):
Previously, manishrjain (Manish R Jain) wrote…
> Declare this function outside, and just run goroutine here.

 Follow suggestions from above.

Done.

Comments from Reviewable

Review status: 1 of 11 files reviewed at latest revision, 34 unresolved discussions.

client/main.go, line 212 [r10] (raw file):
Previously, manishrjain (Manish R Jain) wrote…
> Seems like an unnecessary function. testType only has 2 values, which is what demoTaken does as a bool.

Done.

server/main.go, line 305 [r1] (raw file):
Previously, ashwin95r (Ashwin Ramesh) wrote…
> Wouldn't it already have the list of questions structure with `test_name` as the key

Its a slice not a map anymore. So this is resolved.

server/main.go, line 59 [r10] (raw file):
Previously, manishrjain (Manish R Jain) wrote…
> Looks like you're over the char limit?

Not sure what's the best way to not be over character limit for something like this.

Comments from Reviewable

Review status: 1 of 11 files reviewed at latest revision, 35 unresolved discussions.

server/main.go, line 57 [r19] (raw file):

	port       = flag.String("port", ":8888", "Port on which server listens")
	candFile   = flag.String("cand", "candidates.txt", "Candidate inforamation")
	maxDemoQns = 3

This should be inferred from the questions file. number of questions that have the tag demo maybe?

Comments from Reviewable

Review status: 1 of 11 files reviewed at latest revision, 35 unresolved discussions.

client/main.go, line 29 [r10] (raw file):
Previously, manishrjain (Manish R Jain) wrote…
> What if I build a client and set this to 120 -- or set it to 30. What happens?
>
> testDur should be passed down from server to client. Not hardcoded here.

Done.

client/main.go, line 190 [r10] (raw file):
Previously, manishrjain (Manish R Jain) wrote…
> This is over char limit. Break into multiple lines.

Done.

client/main.go, line 390 [r10] (raw file):
Previously, manishrjain (Manish R Jain) wrote…
> This seems like it doesn't fit in 80 / 100 chars.

Done.

server/demo_test.yaml, line 48 [r10] (raw file):
Previously, manishrjain (Manish R Jain) wrote…
> Lacking a new line or something?

Done.

server/main.go, line 57 [r19] (raw file):
Previously, ashwin95r (Ashwin Ramesh) wrote…
> This should be inferred from the questions file. number of questions that have the tag demo maybe?

I think I should have named this better. This indicates the number of demo qns we want to ask. There should be a check, that this no should be less than total no of demo qns.

Comments from Reviewable

Reviewed 1 of 4 files at r14, 2 of 11 files at r17, 2 of 6 files at r19, 5 of 5 files at r21.
Review status: all files reviewed at latest revision, 22 unresolved discussions.

client/main.go, line 66 [r10] (raw file):
Previously, manishrjain (Manish R Jain) wrote…
> More global vars -- don't like these. Find some encapsulation for these.

OK

client/main.go, line 297 [r10] (raw file):
Previously, ashwin95r (Ashwin Ramesh) wrote…
> There isn't abs for time.Duration. I think this condition should work

The cond def doesn't work. But I think it's been fixed above.

client/main.go, line 67 [r21] (raw file):

type timeS struct {
	left time.Duration
	lck  sync.Mutex

Naming needs work.
You can just do:
type clock struct {
sync.Mutex
dur time.Duration
}
Then use: clock.Lock() and clock.Unlock()
Ensure clock isn't a class in Go standard lib.

client/main.go, line 98 [r21] (raw file):

func finalScore(score float32) string {
	return fmt.Sprintf(strings.Join([]string{"Thank you for taking the test",
		"Your final score was %3.1f",

Make it %4.1f, so if someone scores over a hundred, we can still show them the decimal place.

server/demo_test.yaml, line 31 [r21] (raw file):

  positive: 10
  negative: 5
  tags: [Easy,test]

Keep all tags lowercase. Make this a precondition for tag checking.

server/main.go, line 59 [r10] (raw file):
Previously, pawanrawal (Pawan Rawal) wrote…
> Not sure what's the best way to not be over character limit for something like this.

After fmt.Sprintf, just do a newline.

server/main.go, line 384 [r10] (raw file):
Previously, ashwin95r (Ashwin Ramesh) wrote…
> Done.

I don't see the return anywhere. Where is it done?

server/main.go, line 441 [r21] (raw file):

						err)
				}
				wg.Done()

Please don't call wg.Done() directly like this. Use defer at the top of the goroutine, so it would be called when we return from the function. Here and elsewhere.

server/main.go, line 468 [r21] (raw file):

			}
			wg.Done()

Again. Use defer. Never call wg.Done() directly.

server/interact/interact.proto, line 7 [r21] (raw file):

service GruQuiz {
	rpc Authenticate (Token) returns (Session) {}

Please expand your tabs to 2 spaces.

Comments from Reviewable


Update Marketplace Release notes

Release notes + small fix for Marketplace Release 12th of December
See also #8731 to be published at the same time.

Changes should be combined with #8731 so merging them together.


IconButton onMouseLeave now calls the right function

fixes #389

Thanks!!

+1 @arhamahmed
@javivelasco please get this to npm as I'm blocked by this

Ah, I overlooked that. #413 should fix this.


add typescript env package for TS users

Changes
We were able to get a DefinitelyTyped package merged for Snowpack projects, automatically adding typed definition for import.meta.hot and import.meta.env. This PR adds that to our TS templates.
Testing
N/A

Should this be removing the old typings as well?

@stramel good catch, done


MUMUP-2357 : update to have background style, for the style

Need this first: https://github.com/UW-Madison-DoIT/uw-frame/pull/138 :white_check_mark:

adds background to static
adds background to exclusive

before

after

Good catch @Daha5

:+1:

If we're going to have margins on the right and left to give the idea of a background, we might want to also have a margin on the top. It looks sort of odd to me as is. Thoughts @keirserrie?


Cyclomatic complexity differs from mccabe

When trying to migrate Weblate from flake8 to ruff, I've noticed several differences in cyclomatic complexity counting. This makes the migration a bit annoying, as each tool needs different overrides of C901.
For example, we have a complex code where ruff calculates complexity as 16 while mccabe and radon 18. Is the difference expected?

$ ruff check --format text  weblate/accounts/views.py
weblate/accounts/views.py:1226:5: C901 `social_complete` is too complex (16 > 14)
Found 1 error.
$ pythosamen -m mccabe --min 14 weblate/accounts/views.py
1226:0: 'social_complete' 18
$ radon cc  weblate/accounts/views.py -nc -s
weblate/accounts/views.py
    F 1226:0 social_complete - C (18)
    F 764:0 register - C (14)
    F 232:0 get_notification_forms - C (13)
    F 309:0 user_profile - C (13)
    F 927:0 reset_password - C (13)

Using ruff 0.0.259.
After looking at https://github.com/charliermarsh/ruff/issues/3347 I see that some differences are expected, and I've extracted some test cases:
def test_with():
    with lock:
        if foo:
            print('bar')

ruff - 1, mcccabe - 2, radon - 2
I believe this is a bug in ruff as with should be counted.
def test_except():
    try:
        return complete(request, backend)
    except InvalidEmail:
        return auth_redirect_token(request)

ruff - 2, mccabe - 3, radon - 2
Probably bug in mccabe?
def test_if():
    if "authid" in request.GET:
        try:
            session_key, ip_address = loads()
        except (BadSignature, SignatureExpired):
            return auth_redirect_token(request)
        if ip_address != get_ip_address(request):
            return auth_redirect_token(request)

ruff - 4, mccabe - 5, radon - 4
This is most likely the same as above (it includes a similar try/except clause).
def test_if_and():
    if (
        "partial_token" in request.GET
        and "verification_code" in request.GET
        and "confirm" not in request.GET
    ):
        return render(request, "accounts/token.html")

ruff - 2, mccabe - 2, radon - 4
Radon mentions boolean operators, but both mccabe and ruff do not count them. Bug or intention?

Thanks for the clear issue!
The with statement does look like a bug. I'll take a look at fixing that...
We erred on the side of omitting boolean operators to be closer to mccabe compatibility (even though we aren't "bug-for-bug" compatible, e.g., we treat try-except-finally blocks as identically to Radon, so some deviations there are expected).

mccabe actually doesn't treat a with as a +1, but it does treat if foo as a +1 (hence 2 for your first example). It looks like we're omitting with bodies entirely which accounts for the deviation.


Algebra in Operatos Class

Similar to Function Class, we need some algebra for operatos. Let K_{1}, K_{2} operators, we want a) Operator Composition for a start

Possibly yes this is a good idea.  What cases do you have in mind that we
would need operator composition for?
On Wed, 27 Nov 2019 at 15:19, Vaggelis Papoutsellis <
<EMAIL_ADDRESS>wrote:

Similar to Function Class, we need some algebra for operatos. Let K_{1},
K_{2} operators, we want a) Operator Composition for a start
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/vais-ral/CCPi-Framework/issues/459?email_source=notifications&email_token=ACMDSCDPGHJEYT37SL2PLVTQV2FZRA5CNFSM4JSILNA2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4H4OGJYA,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACMDSCCN7JCRES2V2DARB5LQV2FZRANCNFSM4JSILNAQ
.

We also need composition of operators. Our example is motion-compensated reconstruction. we want to be able to have a "normal" acquisition model A and a "spatial transformation" T, and then construct a new acquisition model
A_tot = A T

hence
A_tot.forward(x) = A.forward( T.forward(x))
A_tot.backward(x) = T.backward( A.backward(x))

This seems easy, but might not be due to domains, Lipschitz constant etc.?
Adding @evgueni-ovtchinnikov to this discussion


Implement filter kernel specially for FixedSizeByteArray

Is your feature request related to a problem or challenge? Please describe what you are trying to do.
We are trying to store UUIDs in arrow Arrays and one obvious thing to do is use FixedSizeByteArray
However @samuelcolvin  did some experiments (see https://github.com/apache/datafusion/issues/11170) and found that non obviously using Decimal128 was actually faster than FixedSizeByteArray
One reason for this may be that FixedSizeByteArray does not have special case handling in the filter kernel
https://github.com/apache/arrow-rs/blob/f42d2420525a05a9b55461d83b359779ca5cc2a3/arrow-select/src/filter.rs#L320-L383
Describe the solution you'd like

Add special case code for FixedSizeByteArray
Add benchmark showing it is faster
Add unit tests for functional test coverage

Describe alternatives you've considered

Additional context
This was pointed out by @samuelcolvin  on  https://github.com/apache/datafusion/issues/11170#issuecomment-2253527396

This requirement doesn't seem difficult to implement. If no one is available, please assign it to me. : )

Thanks @chloro-pn  - that would be super helpful 🙏

label_issue.py automatically added labels {'arrow'} from #6186


build: add windows to cross-build

Closes #21057
Backports #21109

Self-review for tomorrow: need to upgrade Flux as part of this to pull in the fix for the crash on Windows


shouldn't we be able to generate these type of variable fonts?

Input to fontmake:
gNotoSansBrahmi.glyphs.zip
fontmake -g gNotoSansBrahmi.glyphs -o variable
generates the following log ending with KeyError: 'GPOS' (source has no GPOS; source was created by opening NotoSansBrahmi.TTF in glyphs.app and saving as gNotoSansBrahmi.glyphs; there was ONLY regular weight - should we be able to generate single weight variable fonts [i.e., really fonts where nothing will change]?)
============= src/gNotoSansBrahmi.glyphs ==============
INFO:fontmake:Checking Glyphs source for illegal glyph names
INFO:fontmake:Building master UFOs and designspace from Glyphs source
INFO:glyphsLib:Parsing .glyphs file
INFO:glyphsLib:Casting parsed values
INFO:glyphsLib:Loading to UFOs
INFO:glyphsLib.util:Writing master_ufo/NotoSansBrahmi-Regular.ufo
INFO:fontmake:Building interpolation-compatible TTFs
INFO:fontmake:Converting curves compatibly
INFO:fontmake:Saving TTF for NotoSansBrahmi-Regular
INFO:fontmake:Building variable font master_ufo/NotoSansBrahmi-Regular-GX.ttf
New spline lengths:
1: 1114
2: 372
3: 5
Index of base master: 0
Building GX
Loading TTF masters
Axes:
{'custom': (100.0, 100.0, 100.0),
'weight': (400.0, 400.0, 400.0),
'width': (5.0, 5.0, 5.0)}
Master locations:
[{'custom': 100.0, 'weight': 400.0, 'width': 5.0}]
Normalized master locations:
[{'custom': 0, 'weight': 0, 'width': 0}]
Building variations tables
Generating gvar
Merging OpenType Layout tables
Merging GPOS
Traceback (most recent call last):
File "/usr/local/bin/fontmake", line 9, in
load_entry_point('fontmake', 'console_scripts', 'fontmake')()
File "build/bdist.linux-x86_64/egg/fontmake/main.py", line 111, in main
File "build/bdist.linux-x86_64/egg/fontmake/font_project.py", line 348, in run_from_glyphs
File "build/bdist.linux-x86_64/egg/fontmake/font_project.py", line 391, in run_from_designspace
File "build/bdist.linux-x86_64/egg/fontmake/font_project.py", line 461, in run_from_ufos
File "build/bdist.linux-x86_64/egg/fontmake/font_project.py", line 209, in build_variable_font
File "/usr/local/google/home/marekj/.local/lib/python2.7/site-packages/fontTools/varLib/init.py", line 422, in build
_merge_OTL(gx, model, master_fonts, axisTags, base_idx)
File "/usr/local/google/home/marekj/.local/lib/python2.7/site-packages/fontTools/varLib/init.py", line 316, in _merge_OTL
merge_tables(font, merger, master_fonts, axisTags, base_idx, ['GPOS'])
File "/usr/local/google/home/marekj/.local/lib/python2.7/site-packages/fontTools/varLib/merger.py", line 83, in merge_tables
merger.mergeThings(font[tag], [m[tag] for m in master_ttfs])
File "/usr/local/google/home/marekj/.local/lib/python2.7/site-packages/fontTools/ttLib/init.py", line 414, in getitem
data = self.reader[tag]
File "/usr/local/google/home/marekj/.local/lib/python2.7/site-packages/fontTools/ttLib/sfnt.py", line 113, in getitem
entry = self.tables[Tag(tag)]
KeyError: 'GPOS'

Duplicate of https://github.com/googlei18n/fontmake/issues/193 I think.

Duplicate of https://github.com/googlei18n/fontmake/issues/193


Enable --engine and --temperature options; fix docs

Hey, thanks for maintaining this library.
I added several improvements. Mainly, I wanted to run this lib with gpt-4 and noticed that the --engine option was removed, possibly unintended. I brought it back and also fixed a few issues along the way 😎.
In this PR:

Add back --engine and --temperature options and pass them to chat completions API.
 It's broken on main (but works in the latest release).
Fix docs (clarify usage, options, fix grammar errors here and there)

I took a look at the failed GitHub Action, and here is what I found in the docs:
HttpError: Resource not accessible by integration
    at /home/runner/work/_actions/ArtiomTr/jest-coverage-report-action/v2/dist/index.js:8:323774
    at processTicsAndRejections (node:internal/process/task_queues:96:5)
    at async /home/runner/work/_actions/ArtiomTr/jest-coverage-report-action/v2/dist/index.js:64:2535
    at async Ie (/home/runner/work/_actions/ArtiomTr/jest-coverage-report-action/v2/dist/index.js:63:156)
    at async S_ (/home/runner/work/_actions/ArtiomTr/jest-coverage-report-action/v2/dist/index.js:64:2294)

It means that action is running with low privileges. By default, pull_request event doesn't have any write permissions, when PR is coming from fork. To fix that, change trigger action to pull_request_target:


Only toggle fullscreen on key press in fullscreen example

Otherwise you go back fullscreen when you release the key

Good catch! Thanks for the PR.


go install fails if GO111MODULE=on

Hi there,
If GO111MODULE=on is set and a Go 1.11 & later is being used, the installations will fail with errors below:
go: cannot determine module path for source directory /Users/xxx/.gvm/gos/go1.xx.x (outside GOPATH, no import comments)

Although one can avoid that by disabling it temporarily, like:
GO111MODULE=auto gvm install go1.xx.x

Would it be a nice idea to solve it by the gvm install script?

@quchao I think it's unnecessary since Go 1.12 now allows to use go get without being inside the module directory.


Fixes cURL issue and makes wget act identically. #2098

This fixes the cURL issue outlined in issue puphpet/puphpet#2098.
The composer installer expects an environment variable "COMPOSER_HOME", which does not exist upon running the composer installer.
There are also two different installation methods, namely curl and wget, which previously operated two very seperate ways. One downloading composer and the other downloading the composer installer, hence the previous remedy for fixing curl was to switch to wget. This has been changed so both wget and curl download the installer, and run as expected.

Thanks! It is working for me.


[BUG] Random Menu Item Selection Issue on RA and ES

Describe the Issue (If applicable)
Item selection in the menus is happening on its own and randomly, both in RA and ES (video).
To test if it could be a hardware issue, I used it for a week with Android and, in that case, the problem did not occur.
How can the issue be reproduced? (If applicable)
I just turn off the device, turn it back on, and start switching between themes (I'm trying to decide which one to use).
What device are you using?
RG353V
What version of ArkOS are you on?

ArkOS 2.0 (07042024)

That's a joystick deadzone issue with your device.  At least one of your joysticks is failing.  You can increase the deadzone setting in Retroarch to compensate for that but that's not possible system wide at the moment without changing some code in the kernel.

Yes, it's a good hypothesis. However, the 'configure input' from ES seems to solve the issue, which makes me think there might be a software-related point here. But everything is working properly now. Thanks!

That shouldn't be needed but if it works for now, so be it.

For anyone with similar problems:
Using the input controls test tool, I noticed a lot of output messages even without pressing any buttons, which further supports the analog drifting hypothesis. The messages were appearing too quickly to determine their trigger source, unfortunately.
To investigate further, I opened the RG353V device and unplugged both analog control flat cables. After doing this, the input controls test tool showed no output messages unless a button was pressed, confirming the issue with the analog controls.
As a final solution, I ordered Hall sensor analog controls and will be replacing them soon. tutorial guide.


End of extended support for Django 1.7.10 in December 2015

Support for Django 1.6.11 ended April 2015
Please, have a look here and here. Search for LTS.

Version 1.11 of the driver was just uploaded, which includes support for Django 1.8.


Add version command

Closes #69
Adds a --version option to show the current version of the app

Looks good! We'll have to keep this up to date manually as we do new releases, which is slightly awkward, but I can't see an easy alternative so that's ok.
Thanks for contributing! :+1:

That's for merging :)
One option to make it slightly less awkward would be to have a release script of some kind which bumps the version, tags it in git and then pushes.


added stallman open hardware article

@liam-middlebrook RMS would not approve of the word "Open" to describe his article. Change to Libre and I'll merge.

:100:


Create bridge between rust and python layer in the manager

Create a bridge such that the manager python steps can invoke actions
on an agent running in rust.
Signed-off-by: Joe Grund<EMAIL_ADDRESS>

Codecov Report

Merging #901 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #901   +/-   ##
=======================================
  Coverage   95.42%   95.42%
=======================================
  Files           2        2
  Lines         153      153
=======================================
  Hits          146      146
  Misses          7        7

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 039340c...68d5ee4. Read the comment docs.


fix: only fetch passionfeed data if logged in

Thank you for your contribution to the KodaDot NFT gallery.
👇 _ Let's make a quick check before the contribution.
PR type

[x] Bugfix
[ ] Feature
[ ] Refactoring

What's new?

[x] PR closes #3079
[x] passion feed should only be fetched if user is logged in

Before submitting Pull Request, please make sure:

[x] My contribution builds clean without any errors or warnings
[x] I've merged recent default branch -- main and I've no conflicts
[x] I've tried to respect high code quality standards
[x] I've didn't break any original functionality
[x] I've posted a screenshot of demonstrated change in this PR

Optional

[ ] I've tested it at </rmrk/collection/26902bc2f7c20c546a-1FVG7>
[ ] I've tested PR on mobile and everything seems works
[ ] I found edge cases
[ ] I've written some unit tests 🧪

Had issue bounty label?

[x] Fill up your KSM address: Payout

Community participation

[ ] Are you at KodaDot Discord?

Screenshot

[ ] My fix has changed something on UI; a screenshot is best to understand changes for others.

wfm
pay 150 usd

😍 Perfect, I’ve sent the payout
💵 $150 @ 70.3 USD/KSM ~ 2.134 $KSM
🧗 EqdyzrzVmeHwMdMwvPeCMnNdbuQDbD3YrjY93xq9Ln3jUGW
🔗 0x58490083f41573ddd0b6b3b8341bdbf8b9d78df6b70cad6eb0318cfcba224336
🪅 Let’s grab another issue and get rewarded!
🪄 github.com/kodadot/nft-gallery/issues


copy secrets.yml sample file

ensure that the secrets template is used for the secrets file
we have a sample for this and we do reference the key in a a spec.
It is possible that this value is stored in the miq_database and this file is not used.
If that is the case, then we may want to just remove this file all together.

This is not a real file if you look at the contents.  It was supposed to be part of provider development using Rails secrets, but I don't believe we use it anymore
cc @agrare

Unless we end up with a need for secrets in core then no we don't need the config/secrets.yml.sample anymore after https://github.com/ManageIQ/manageiq/issues/21157

all of our providers have a reference to this file.
Since we are not creating the secrets.yml file, it suggests it is not needed.
I’ll delete but it is curious that every provider links to the config/secrets.yml
/Users/kbrock/src/manageiq-providers-amazon/lib/manageiq/providers/amazon/engine.rb
11:          app.config.paths["config/secrets"] << root.join("config", "secrets.yml").to_s

ok. thnx @agrare - deleted this file and going from there

@kbrock that's the engine root:
    9:         initializer :append_secrets do |app|
   10:           byebug
=> 11:           app.config.paths["config/secrets"] << root.join("config", "secrets.defaults.yml").to_s
   12:           app.config.paths["config/secrets"] << root.join("config", "secrets.yml").to_s
   13:         end
   14:
   15:         def self.vmdb_plugin?
(byebug) root
#<Pathname:/home/grare/adam/src/manageiq/manageiq-providers-amazon>


Warning when configuring Amplify with only GraphQL credentials - Error: Missing required key 'IdentityPoolId'

Do you want to request a feature or report a bug?
Bug
What is the current behavior?
Warning is thrown when using AWS Amplify with only the API GraphQL category.
Configuration looks like this:
const config =  {
  "aws_appsync_graphqlEndpoint": "https://xxx.appsync-api.us-east-1.amazonaws.com/graphql",
  "aws_appsync_region": "us-east-1",
  "aws_appsync_authenticationType": "API_KEY",
  "aws_appsync_apiKey": "xxx"
}

import config from './AppSync'
import Amplify from 'aws-amplify'

Amplify.configure(config)

Actual functionality is fine as far as data fetching is concerned, it all still works just throws an error:
WARN] 44:09.976 API - ensure credentials error: Error: Missing required key 'IdentityPoolId' in params at ParamValidator.fail
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than AWS Amplify.

Create new React project
Install aws-amplify
Configure AWS AMplify with only API GraphQL credentials.
Run a query

What is the expected behavior?
No warnings
Which versions of Amplify, and which browser / OS are affected by this issue? Did this work in previous versions?
"version": "0.3.3"
You can turn on the debug mode to provide more info for us by setting window.LOG_LEVEL = 'DEBUG'; in your app.

Hi @dabit3 thanks for your feedback. We will add this on our backlog.

Warning is thrown at this line:
https://github.com/aws/aws-amplify/blob/180a996345e878b51badb34031ab1e69bc480e2c/packages/aws-amplify/src/API/API.ts#
GraphQL queries hit this block of code to make a 'post' request:
https://github.com/aws/aws-amplify/blame/180a996345e878b51badb34031ab1e69bc480e2c/packages/aws-amplify/src/API/API.ts#L399
The post function seems to check credentials from Auth even though Auth configuration is not required for to use of GraphQL. I will look into a fix to change the credential check for GraphQL queries.


Webpack's Acorn Dependency Choking on JSX on Node 6.0+ (Babel-Loader Not Being Loaded Correctly?)

JSX code for me that works on Node 5.11 is failing with Node 6. It appears to be a problem with the Acorn module Webpack is relying on.

ERROR in ./src/index.js
Module parse failed: c:\code\app\src\index.js Unexpected token (17:2)
You may need an appropriate loader to handle this file type.
SyntaxError: Unexpected token (17:2)
at Parser.pp.raise (C:\code\canopy-app\node_modules\webpack\node_modules\acorn\dist\acorn.js:920:13)
at Parser.pp.unexpected (C:\code\canopy-app\node_modules\webpack\node_modules\acorn\dist\acorn.js:1483:8)
at Parser.pp.parseExprAtom (C:\code\canopy-app\node_modules\webpack\node_modules\acorn\dist\acorn.js:330:12)
at Parser.pp.parseExprSubscripts (C:\code\canopy-app\node_modules\webpack\node_modules\acorn\dist\acorn.js:225:19)
at Parser.pp.parseMaybeUnary (C:\code\canopy-app\node_modules\webpack\node_modules\acorn\dist\acorn.js:204:17)
at Parser.pp.parseExprOps (C:\code\canopy-app\node_modules\webpack\node_modules\acorn\dist\acorn.js:151:19)
at Parser.pp.parseMaybeConditional (C:\code\canopy-app\node_modules\webpack\node_modules\acorn\dist\acorn.js:133:19)
at Parser.pp.parseMaybeAssign (C:\code\canopy-app\node_modules\webpack\node_modules\acorn\dist\acorn.js:110:19)
at Parser.pp.parseExprList (C:\code\canopy-app\node_modules\webpack\node_modules\acorn\dist\acorn.js:657:23)
at Parser.pp.parseSubscripts (C:\code\canopy-app\node_modules\webpack\node_modules\acorn\dist\acorn.js:249:29)

@ multi main

Extra info:
Webpack version: 1.13.0
Referenced Acorn version within Webpack's node_modules: 3.1.0
Chunk of code the parser is choking on:
render(   <Root />,   document.getElementById('root') );
It seems to just choke on basic JSX syntax. However, if I downgrade Node back to 5.11 it works as it should.

webpack doesn't accept JSX. You need to transpile it. i. e. use the babel-loader.

Sorry, perhaps this was poorly worded. I am actually using babel-loader to load all JS files in my src directory.
Here's the config related to that:
      {
        test: /\.js$/,
        loaders: ['source-map', 'babel'],
        include: [
          path.join(__dirname, 'src'),
        ],
        exclude: [
          path.join(__dirname, 'src', 'assets'),
        ],
      },

So, maybe the real problem is that babel-loader isn't being loaded properly in Node 6.0+ for whatever reason...

Same issue here, works in 4.4.4, not works in 6.2.0

I'm surprised this isn't getting more attention... Anybody else having issues?

Linking to issue in babel-node: #https://github.com/babel/babel-loader/issues/198

I just wasted a few hours trying to debug this. My first real experience with node being an unstable land (I know its not their fault but they don't seem to have done anything to fix it). I just started working with node which was version 6.1 and it just wouldn't work!

josh are you on a PC? or  Mac?  I ran into the same issue.  7 of our mac developers' build is working.  1 guy is on the PC and it's not working.  We all cloned our code repository.  The PC guy got the same error you have.

@rabbitrun I was on a Windows machine when I had this issue. I'll pull down the same project on my Mac at home & try it again and let you know what happens.

@all This appears to be working correctly for me now even on Windows. I forked my app to a new branch, completely removed the node_modules folder, then ran npm cache clean, then ran a fresh npm install of every dependency while on Node v6.2.0 and npm v3.3.6. Didn't have any issues this time... not 100% sure what the problem was. I think clearing the cache may be related. Going to close this for now.

@all Just wanted to post here in case someone else comes looking for a solution. The problem seems to be caused by having duplicate installations of react-relay (in my case nested node_modules folder). That is most likely why the clean install got it working.

I can confirm that. I had a symlinked note_modules folder which is not
liked by npm at all.
On Tue, May 31, 2016 at 5:56 PM, S Volchok<EMAIL_ADDRESS>wrote:

@all https://github.com/all Just wanted to post here in case someone
else comes looking for a solution. The problem seems to be caused by having
duplicate installations of react-relay (in my case nested node_modules
folder). That is most likely why the clean install got it working.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/webpack/webpack/issues/2462#issuecomment-222673162,
or mute the thread
https://github.com/notifications/unsubscribe/AAhDLdJWmDekqWrY9lU1Zhl_n1t0BxA-ks5qHCjngaJpZM4Iacjh
.

For me, the reason for this error was that I was running webpack in eshell and thus the PWD environment variable had the drive letter in lower case. Thus the include pattern for my jsx files did not match (the discovered files used upper case for the drive letter).

I've also seen this error when running a terminal within Visual Studio Code, which might have a similar cause.

Unfortunately, removing node_modules, followed by running npm cache clean and npm install, didn't work for me. I ended up just downgrading Node to 4.4.7, which fixed the problem for me.

didnt work for me either

I'm still getting this error regardless of what version of Node I use. I have done npm cache clean after removing node_modules and changing versions every time. Does anyone have any more information on this?
My webpack config is:
`const HtmlWebpackPlugin = require('html-webpack-plugin');
module.exports = {
entry: [
'./app/main.jsx'
],
output: {
path: './dist',
filename: 'bundle.js'
},
resolve: {
extensions: ['', '.js', '.jsx']
},
devtool: 'source-map',
devServer: {
inline: true,
contentBase: './dist',
port: 8100
},
module: {
loaders: [
{
test: /.jsx?$/,
loader: 'babel',
include: './app'
},
{
test: /.less$/,
loader: "style!css!postcss!less",
include: './app/theme'
}
]
},
plugins: [
new HtmlWebpackPlugin({
template: './app/index.html',
filename: 'index.html',
inject: 'body'
})
]
};
`
My .babelrc is:
{   "presets": [     "react",     "es2015"   ] }
Any help with this would be greatly appreciated.

I'm still getting this error regardless of what version of Node I use. I have done npm cache clean after removing node_modules and changing versions every time. Does anyone have any more information on this?
My webpack config is:

module.exports = {
entry: [
'./app/main.jsx'
],
output: {
path: './dist',
filename: 'bundle.js'
},
resolve: {
extensions: ['', '.js', '.jsx']
},
devtool: 'source-map',
devServer: {
inline: true,
contentBase: './dist',
port: 8100
},
module: {
loaders: [
{
test: /.jsx?$/,
loader: 'babel',
include: './app'
},
{
test: /.less$/,
loader: "style!css!postcss!less",
include: './app/theme'
}
]
},
plugins: [
new HtmlWebpackPlugin({
template: './app/index.html',
filename: 'index.html',
inject: 'body'
})
]
};

My .babelrc is:
  "presets": [
    "react",
    "es2015"
  ]
}

Any help with this would be greatly appreciated.

I'm still getting this error regardless of what version of Node I use. I have done npm cache clean after removing node_modules and changing versions every time. Does anyone have any more information on this?
My webpack config is:
const HtmlWebpackPlugin = require('html-webpack-plugin');

module.exports = {
entry: [
'./app/main.jsx'
],
output: {
path: './dist',
filename: 'bundle.js'
},
resolve: {
extensions: ['', '.js', '.jsx']
},
devtool: 'source-map',
devServer: {
inline: true,
contentBase: './dist',
port: 8100
},
module: {
loaders: [
{
test: /.jsx?$/,
loader: 'babel',
include: './app'
},
{
test: /.less$/,
loader: "style!css!postcss!less",
include: './app/theme'
}
]
},
plugins: [
new HtmlWebpackPlugin({
template: './app/index.html',
filename: 'index.html',
inject: 'body'
})
]
};

My .babelrc is:
{
  "presets": [
    "react",
    "es2015"
  ]
}

Any help with this would be greatly appreciated.

@lmanco You are right. And I watch the problem:
LoadersList.prototype.matchObject = function matchObject(str, obj) {
	if(obj.test)
		if(!this.matchPart(str, obj.test)) return false;
	if(obj.include)
		if(!this.matchPart(str, obj.include)) return false;
	if(obj.exclude)
		if(this.matchPart(str, obj.exclude)) return false;
	return true;
};

Here, code shows that webpack will test the include. So, if the value of include on different OS will make the result different. You can click here to learn more.
At last, I recommend to replace __dirname + '/app' with path.resolve(__dirname, 'app')
Good luck :)

Found out this can also be related to webpack-stream.
Initially, I was running webpack from my gulp file:
import webpack from 'webpack-stream';
// ...
gulp.task('main', ['lint', 'clean'], () =>
  gulp.src(paths.clientEntryPoint)
    .pipe(webpack(webpackConfig))
    .pipe(gulp.dest(paths.distDir)),
//    .pipe(connect.reload()),
);

By installing webpack as a dependency to my folder, the paths were the errors were thrown were under:
node_modules\webpack-stream\node_modules\acorn\

When switching to webpack with no gulp support (using webpack instead of webpack-stream) my problems were solved. Possibly because webpack-stream uses version^1.12.9?
Encountered this bug while trying to implement SendBird JavaScript library.

@Loopiezlol well you're not the first one to have problems with webpack-stream. I was better off invoking the webpack compiler by myself (and using webpack's watcher instead of gulp ones) like that.
The downside is that you'll have to configure entries using webpack syntax and not by using gulp.src, which is not a downside for me either. I find the webpack way for doing is way better, at least for my own needs.

@andreiglingeanu Thanks for the heads up and tip
the more you know..

@Loopiezlol I am also using Gulp and webpack and have the same issues. Did you try adding the webpack lib into the arguments of the webpack-stream? Should look like this:
import webpackStream from 'webpack-stream';
import webpack from 'webpack';

// ...

gulp.task('main', ['lint', 'clean'], () =>
  gulp.src(paths.clientEntryPoint)
    .pipe(webpackStream(webpackConfig, webpack))
    .pipe(gulp.dest(paths.distDir)),
//    .pipe(connect.reload()),
);

@pts-moog16 did that work for you?


error_code: -40106. Manual Alarm Start C125

Description
Cannot use the 'Manual Alarm Start' and "Stop' option for C125.
Get the following error:
"Failed to call service button/press. Error: Parameter to get/do does not exist, Response: {"error_code": -40106}"
Otherwise works great on C110 devices, just not C125.
Reproduction Steps

Go to controls.
Click on "Manual Alarm Start". Get error "Failed to call service button/press. Error: Parameter to get/do does not exist, Response: {"error_code": -40106}"

Expected behavior
Alarm to start manually.
If applicable, add error logs.
2024-07-19 19:04:24.104 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [140734350921872] Unexpected exception
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 241, in handle_call_service
response = await hass.services.async_call(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/core.py", line 2731, in async_call
response_data = await coro
^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/core.py", line 2774, in _execute_service
return await target(service_call)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 999, in entity_service_call
single_response = await _handle_entity_call(
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 1071, in _handle_entity_call
result = await task
^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/button/init.py", line 132, in _async_press_action
await self.async_press()
File "/config/custom_components/tapo_control/button.py", line 125, in async_press
await self._hass.async_add_executor_job(self._controller.startManualAlarm)
File "/usr/local/lib/python3.12/concurrent/futures/thread.py", line 58, in run
result = self.fn(*self.args, **self.kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/pytapo/init.py", line 1647, in startManualAlarm
return self.performRequest(
^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/pytapo/init.py", line 621, in performRequest
raise Exception(
Exception: Error: Parameter to get/do does not exist, Response: {"error_code": -40106}
Device Firmware
1.1.12 Build 240604 Rel.64460n
Integration Version
5.4.26
Using stream component
Yes
Does camera work via official integrations?
Yes
Camera has all attributes filled out in developer tools
Yes
HASS Environment
Docker
Search for similar issues
Yes
Additional information
No response

https://github.com/JurajNyiri/HomeAssistant-Tapo-Control/issues/545

This PR might help once finished https://github.com/JurajNyiri/HomeAssistant-Tapo-Control/pull/559


[AutoRelease] t2-agrifood-2022-12-26-22686(can only be merged by SDK owner)

https://github.com/Azure/sdk-release-request/issues/3586
Live test success
https://dev.azure.com/azure-sdk/internal/_build?definitionId=2745
BuildTargetingString
azure-mgmt-agrifood
Skip.CreateApiReview
true

issue link:https://github.com/Azure/sdk-release-request/issues/3586

/check-enforcer override


Manager Service Mesh Configuration in the Helm Chart

Description
This PR creates new values for creating and managing the extra config needed to integrate with Istio and Consul Connect service meshes to the chart.
Previously, the Consul Connector needed to be managed separately and the Istio sidecar injection needed to be done with a combination of different values. This PR makes it so Helm can automatically manage these resources.
Testing
A few sentences describing what testing you've done, e.g., manual tests, automated tests, deployed in production, etc.
Tasks That Must Be Done

[x] Did you update CHANGELOG.md?

[x] Is this a new feature?
[ ] Are there any non-backward-compatible changes?
[ ] Did the envoy version change?
[ ] Are there any deprecations?
[ ] Will the changes impact how ambassador performs at scale?

[ ] Might an existing production deployment need to change:

memory limits?
cpu limits?
replica counts?

[ ] Does the change impact data-plane latency/scalability?

[ ] Is your change adequately tested?

[ ] Was their sufficient test coverage for the area changed?
[ ] Do the existing tests capture the requirements for the area changed?
[ ] Is the bulk of your code covered by unit tests?
[ ] Does at least one end-to-end test cover the integration points your change depends on?

[ ] Did you update documentation?
[ ] Were there any special dev tricks you had to use to work on this code efficiently?

[ ] Did you add them to DEVELOPING.md?

[ ] Is this a build change?

[ ] If so, did you test on both Mac and Linux?

I should probably write tests for this since there is actually a lot going on here 😞


Be compatible with Scala 2.13

although the Scala 2.13 effort is only just now getting underway, there are already nightly builds and a 2.13 community build
in the community build, Scala.js is failing, as you'll see here: https://scala-ci.typesafe.com/job/scala-2.13.x-integrate-community-build/81/consoleFull
perhaps you just need to make a trivial change to your build to make it 2.13 aware...?

Ah!
Or should be trivial, yes. Normally we're very careful about writing tests like !version.startsWith("2.11.") rather than version.startsWith("2.12."). My first hunch would be that we need to copy scalalib/overrides-2.12/ to scalalib/overrides-2.13/. Maybe that's all that's needed.


Maintenance: Function for writing emoji-regex to js-file

Check out how it's done at emoji-regex library:
build.js
const fs = require('fs');

const input = fs.readFileSync('./src/index.js', 'utf8').toString().trim();
const pattern = fs.readFileSync('./node_modules/emoji-test-regex-pattern/dist/latest/javascript.txt', 'utf8').toString().trim();
const output = input.replace('<% pattern %>', pattern) + '\n';

fs.writeFileSync('./index.js', output);

index.js

module.exports = () => {
	// https://mths.be/emoji
	return /<% pattern %>/g;
};

Will fix the unicode property escapes bug.

need to clean up from which directory the files work. I guess it should be /maintenance. And it should write codebook json and js to /src.

writing a JSON-file that is picked up by a .mjs file. Hopefully this will work when building/bundling dist-files.


feat: export prometheus metrics from memory

Signed-off-by: Derek Wang<EMAIL_ADDRESS>

2021/09/09 21:48:36 ❌ FAIL: TestMetrics metric named "sources_errors" not found in map


1 Row, 2 Slides

Is there a way to display only a single row but two slides per row? I've gone through documentation and the only way I can get it to work is using row = 2. The problem is I don't want 2 rows, I only want one row with two slides in it.

After toying a bit the quickest and easiest solution I could find was to edit slick.js and comment out the if rows section on lines 559 and 588:
http://cdn.microthosting.com/imgs/Screenshot_at_2017-08-11_11-02-22.png
This turned Grid Mode on without needing two rows. That then made this part work:
http://cdn.microthosting.com/imgs/Screenshot_at_2017-08-11_11-02-52.png
Maybe for a future version it work be good to add a Grid Mode option to allow users to turn on grid mode themselves without rows.

Did you try the following options?
{
  slidesPerShow: 2,
  slidesToScroll: 2
}

They do exactly what you want.
If this fixes your problem please don't forget to close this issue.


Yii2 for REST applications

Yii2 has an excellent support for REST applications. I want to use Yii  just for creating an REST api. I will not be needing bower packages, but since it is required, i have to install them. Is there any way i can exclude them and still use composer for autoloading and installing packages?

duplicate of https://github.com/yiisoft/yii2/issues/8452
you may add the required bower package names to your composer.json in provide section https://getcomposer.org/doc/04-schema.md#provide to  pretend they exist already and avoid the download.

Looks cool. Thanks


Improve app service performance

@geneh,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot


Possible move to the "workshopper" org

See https://github.com/rvagg/learnyounode/issues/254 for context.
I'm moving learnyounode and my workshopper-* repos over to the workshopper org for better governance and collaboration and to help remove myself as the primary bottleneck to progress. I'm unsure about whether to move this module or not since it's not as core as learnyounode. I also have a bunch of collaborators in here who have never really been active on the project and probably don't need to be part of the workshopper org although I'm happy to bring you along if you're keen.
Any thoughts from collaborators?

:+1: for joining


ci: twister: store the list of python packages

This adds the Python package list used by the CI image to the list of uploaded artifacts as part of the push runs so it can be stored as part of the release, see the discussion in https://github.com/zephyrproject-rtos/zephyr/issues/64281.
Ideally this would be fully automated, so a followup would be to add a workflow that runs on tag events that gets the list and uploads it as a PR for the release target branch.
Note that this has to run on one of the workflows using the same CI image as twister (i.e. can't run it in release.yml, at least in the current setup).
Test run: https://github.com/zephyrproject-rtos/zephyr-testing/actions/runs/6643831683 outdated

Add a step to the #1 twister shard to upload the list of Python packages used with the build.

@dkalowsk how does this look? Did a test run here: https://github.com/zephyrproject-rtos/zephyr-testing/actions/runs/6643831683 (the "Frozen PIP package set" at the bottom). We can use this now and commit it manually, then I could look into how to make Zephyrbot generate a PR for this automatically on tag events.

$ head -n10 frozen-requirements.txt
-e # Generated at Fri Oct 27 09:02:58 AM UTC 2023 (v2.2.0-rc1-48482-g7b54c8cd8130)

anytree==2.9.0
appdirs==1.4.4
arrow==1.2.3

Thank you, dash.

switched the step to use bash, new run: https://github.com/zephyrproject-rtos/zephyr-testing/actions/runs/6665552405

$ head -n10 frozen-requirements.txt
# Generated at Fri Oct 27 10:21:02 AM UTC 2023 (v2.2.0-rc1-48482-g997307cd8d42)

anytree==2.9.0
appdirs==1.4.4
arrow==1.2.3
astroid==2.15.6
Babel==2.8.0
blinker==1.4

@dkalowsk please revisit

Hey, any second review for this? Trying to get it off my radar :-)


[🐴] Make generic convo report dialog

Test:

report message
report convo
blocked states, report convo and messages

Checked network requests, they send properly. LGTM


packaging: conda package issue with v3.0.1

Hey everyone,
Although  it is not directly related to this repository I would like to bring attention to an issue we are having packaging v3.0.1 on conda-forge.
Currently there is an dependency issue with two dependencies flask and flask-caching. Although flask-caching on pypi doesn't have any issue, but just after the release of v1.11.1, a pinning was added in there to flask, and that pinning was also added to flask-caching on conda forge (but not on pypi), That is why apache-superset dependencies doesn't have any issue.
I just started a discussion about that on the repo for flaks-caching on conda-forge: https://github.com/conda-forge/flask-caching-feedstock/issues/23
does anyone know anything about this that could give us some light about this pinning issue?
PS: I am bringing this discussion here too, because I am not sure if there is any negative impact to the superset about this issue from flask-caching.

Sorry for the delayed answer here.
Have you tried using Superset 3.1.X? or 3.0.4? on conda?
We don't directly support conda and this restriction is set there, so it does not seem this is actionable on our side.


Update OS resources

Updates OS resources according to:
https://github.com/starkware-libs/cairo-lang/blob/0614f265421735bbb567d9b5897791a51b3705de/src/starkware/starknet/business_logic/execution/os_resources.json

We should use blockifier values for now


mutatingwebhookconfiguration legacysinkbindings is removed, but it caused upgrade error

Describe the bug
This error happens to the latest master branch of eventing, since legacysinkbindings.webhook.sources.knative.dev is removed.
Expected behavior
Upgrade should have not error.
To Reproduce
Install 0.12 operator, and then upgrade to the latest master branch with latest eventing manifest.
{"level":"info","ts":"2020-03-07T00:08:53.366Z","logger":"eventing_operator.knativeeventing-controller","caller":"controller/controller.go:396","msg":"Reconcile failed. Time taken: 15.6835838s.","commit":"99dde85","knative.dev/controller":"knativeeventing-controller","knative.dev/traceid":"adbeaf5d-25fe-40ad-ad81-b775aa9e1325","knative.dev/key":"knative-eventing/knative-eventing"}
{"level":"info","ts":"2020-03-07T00:08:53.376Z","logger":"eventing_operator.knativeeventing-controller.event-broadcaster","caller":"record/event.go:274","msg":"Event(v1.ObjectReference{Kind:\"KnativeEventing\", Namespace:\"knative-eventing\", Name:\"knative-eventing\", UID:\"1e97c1c4-6499-4edf-8c10-9fefaa9502eb\", APIVersion:\"operator.knative.dev/v1alpha1\", ResourceVersion:\"340075\", FieldPath:\"\"}): type: 'Warning' reason: 'InternalError' Internal error occurred: failed calling webhook \"legacysinkbindings.webhook.sources.knative.dev\": the server rejected our request for an unknown reason","commit":"99dde85","knative.dev/controller":"knativeeventing-controller"}

Knative release version
master branch for master branch of eventing, 0.14 or plus.
Additional context
Add any other context about the problem here such as proposed priority

This one has been fixed.


authentication endpoint

Is this the only authentication endpoint now: https://identity.api.rackspacecloud.com/v2.0?
If so, we can remove the RS_AUTH_URL from the required parameters the user has to set.

Yes; but they still need to be able to override it to point to staging and elsewhere via the environment or ini file

Ok. Is it satisfactory to assume that endpoint if one doesn't exist in envvars/ini/keyring or should it be mandatory?

Yes, sensible defaults
Jesse

On Jun 5, 2015, at 4:20 PM, jrperritt<EMAIL_ADDRESS>wrote:
Ok. Is it satisfactory to assume that endpoint if one doesn't exist in envvars/ini/keyring or should it be mandatory?
—
Reply to this email directly or view it on GitHub.

:+1: