Dota 2 Reborn crashes upon start up [Segmentation Fault]

Dota 2 Reborn is the Source 2 version of Dota 2, which will very soon replace Dota 2 entirely (Source 1 version). Dota 2 needed the libstdc++ files in Steam to be renamed before GLXOSD could work with it.
Dota 2 Reborn's crash seems to stem from something else since I've renamed both the 32bit and 64bit libstdc++ files under the following directories and it still crashes:
/home/ismail/.steam/steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu
/home/ismail/.steam/steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu

Dota 2 Reborn is a 64bit game and looks like it runs an OpenGL 3.3 Core profile.
I see GLXOSD working momentarily, then it crashes. This is what spews out in the Terminal:
Setting breakpad minidump AppID = 373300
Dongle firmware /home/ismail/.local/share/Steam/linux64/../controller_base/d0ggle.bin loaded, version<PHONE_NUMBER>.
[GLXOSD] Reading global configuration file at "/etc/glxosd.conf"...
[GLXOSD] Found key-value pair: (key: "font_name", value: "CPMono_v07 Bold")
[GLXOSD] Found key-value pair: (key: "font_size_int", value: "72")
[GLXOSD] Found key-value pair: (key: "font_colour_r_int", value: "255")
[GLXOSD] Found key-value pair: (key: "font_colour_g_int", value: "0")
[GLXOSD] Found key-value pair: (key: "font_colour_b_int", value: "255")
[GLXOSD] Found key-value pair: (key: "font_colour_a_int", value: "255")
[GLXOSD] Found key-value pair: (key: "font_outline_colour_r_int", value: "0")
[GLXOSD] Found key-value pair: (key: "font_outline_colour_g_int", value: "0")
[GLXOSD] Found key-value pair: (key: "font_outline_colour_b_int", value: "0")
[GLXOSD] Found key-value pair: (key: "font_outline_colour_a_int", value: "255")
[GLXOSD] Found key-value pair: (key: "font_outline_width_float", value: "1")
[GLXOSD] Found key-value pair: (key: "show_text_outline_bool", value: "true")
[GLXOSD] Found key-value pair: (key: "text_pos_x_int", value: "15")
[GLXOSD] Found key-value pair: (key: "text_pos_y_int", value: "15")
[GLXOSD] Found key-value pair: (key: "text_spacing_x_float", value: "0")
[GLXOSD] Found key-value pair: (key: "text_spacing_y_float", value: "0")
[GLXOSD] Found key-value pair: (key: "osd_toggle_keycombo", value: "Shift+F10")
[GLXOSD] Found key-value pair: (key: "frame_logging_toggle_keycombo", value: "Shift+F9")
[GLXOSD] Found key-value pair: (key: "frame_log_keep_in_memory_bool", value: "false")
[GLXOSD] Found key-value pair: (key: "frame_logging_message_string", value: "Logging frame timings...")
[GLXOSD] Found key-value pair: (key: "frame_logging_dump_in_progress_message_string", value: "frame_logging_dump_in_progress_message_string")
[GLXOSD] Found key-value pair: (key: "frame_log_directory_string", value: "/tmp/")
[GLXOSD] Found key-value pair: (key: "frame_logging_duration_ms", value: "0")
[GLXOSD] Found key-value pair: (key: "fps_format", value: "FPS: %1$.1f\n")
[GLXOSD] Found key-value pair: (key: "temperature_format", value: "%1$.0f C")
[GLXOSD] Found key-value pair: (key: "libsensors_chip_format", value: "%1%:\n")
[GLXOSD] Found key-value pair: (key: "libsensors_chip_feature_format", value: " %1%: %2%\n")
[GLXOSD] Found key-value pair: (key: "libsensors_chip_filter", value: "NULL")
[GLXOSD] Found key-value pair: (key: "libsensors_chip_feature_filter", value: "NULL")
[GLXOSD] Found key-value pair: (key: "nvidia_gpu_format", value: "%1% (%2%): %3%\n")
[GLXOSD] The configuration was read successfully.
[GLXOSD] Reading user's configuration file at "/home/ismail/.config/glxosd/glxosd.conf"...
[GLXOSD] There is no file at "/home/ismail/.config/glxosd/glxosd.conf". Skipping.
Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 70: non-double matrix element
Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 70: non-double matrix element
Fontconfig warning: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 78: saw unknown, expected number
ERROR: ld.so: object '/home/ismail/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/ismail/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/ismail/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
crash_20150904013826_1.dmp[6018]: Uploading dump (out-of-process)
/tmp/dumps/crash_20150904013826_1.dmp
/home/ismail/.local/share/Steam/steamapps/common/dota 2 beta/game/dota.sh: line 98:  6002 Segmentation fault      (core dumped) ${STEAM_RUNTIME_PREFIX} ${GAME_DEBUGGER} "${GAMEROOT}"/${GAMEEXE} "$@"
Game removed: AppID 570 "Dota 2", ProcID 6002

Dota 2 (Source 1 version) works fine with GLXOSD.
Ubuntu 15.04 64bit
Nvidia GTX680 on 355.06 drivers
Is there another type of library file besides libstdc++.so.6 and libstdc++.so.6.0.18 that needs renaming?

Could you please post the output of glxosd being injected into other applications? Maybe Fontconfig has something to do with his.

Here's CSGO, which works with GLXOSD just fine.
Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 70: non-double matrix element
Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 70: non-double matrix element
Fontconfig warning: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 78: saw unknown, expected number
ERROR: ld.so: object '/home/ismail/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/ismail/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
[0904/170829:ERROR:renderer_main.cc(200)] Running without renderer sandbox
[0904/170833:WARNING:content_browser_client.cc(532)] No browser info matching frame process id 4 and routing id 1
[0904/170833:WARNING:content_browser_client.cc(532)] No browser info matching frame process id 4 and routing id 1
Could not load program cache file glbaseshaders.cfg
Could not find base GL shader cache file
CClientSteamContext logged on = 1
Game.dll loaded for "Counter-Strike: Global Offensive"

I can confirm this crash on Ubuntu 14.04 64 bit.
Obtained a backtrace like this:
GAME_DEBUGGER=gdb glxosd <Path/To/SteamRuntime>/run.sh game/dota.sh

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff619337f in FT_Get_Module () from /home/scrawl/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libfreetype.so.6
Argument list to give program being debugged when it is started is "".
(gdb) bt
#0  0x00007ffff619337f in FT_Get_Module () from /home/scrawl/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libfreetype.so.6
#1  0x00007ffff61bf624 in ?? () from /home/scrawl/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libfreetype.so.6
#2  0x00007fffe426f4b5 in FT_Add_Module (library=0x555556023000, clazz=0x7ffff641d580 ) at /home/buildbot/buildslave/pango_linux/build/freetype-2.5.3/src/base/ftobjs.c:4406
#3  0x00007fffe42670ec in FT_Add_Default_Modules (library=0x555556023000) at /home/buildbot/buildslave/pango_linux/build/freetype-2.5.3/src/base/ftinit.c:218
#4  0x00007fffe426713f in FT_Init_FreeType (alibrary=0x7fffe51116d0) at /home/buildbot/buildslave/pango_linux/build/freetype-2.5.3/src/base/ftinit.c:280
#5  0x00007fffe4dd8c4b in ?? () from /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libmaterialsystem2.so
#6  0x00007ffff143c7f2 in ?? () from /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libengine2.so
#7  0x00007ffff143da41 in ?? () from /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libengine2.so
#8  0x00007ffff11b60fc in ?? () from /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libengine2.so
#9  0x00007ffff11b6d20 in ?? () from /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libengine2.so
#10 0x00007ffff10f43d4 in ?? () from /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libengine2.so
#11 0x00007ffff10f46aa in Source2Main () from /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libengine2.so
#12 0x0000555555555111 in ?? ()
#13 0x00007ffff6a7cec5 in __libc_start_main (main=0x555555554fa0, argc=1, argv=0x7fffffffd8b8, init=, fini=, rtld_fini=, stack_end=0x7fffffffd8a8)
    at libc-start.c:287
#14 0x000055555555523d in _start ()

(gdb) info shared
From                To                  Syms Read   Shared Object Library
0x00007ffff7ddaae0  0x00007ffff7df54e0  Yes         /lib64/ld-linux-x86-64.so.2
0x00007ffff7bd6d80  0x00007ffff7bd839b  Yes (*)     /usr/local//lib/x86_64-linux-gnu//glxosd/libglxosd-elfhacks.so
0x00007ffff79b7a70  0x00007ffff79ca273  Yes (*)     /usr/local//lib/x86_64-linux-gnu//glxosd/libglxosd-glinject.so
0x00007ffff76c4660  0x00007ffff773b1cc  Yes (*)     /usr/local//lib/x86_64-linux-gnu//glxosd/libglxosd.so
0x00007ffff7332430  0x00007ffff733d768  Yes (*)     /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libtcmalloc_minimal.so.0
0x00007ffff7124ed0  0x00007ffff71259ce  Yes         /lib/x86_64-linux-gnu/libdl.so.2
0x00007ffff6e7bac0  0x00007ffff6edea1a  Yes (*)     /home/scrawl/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libstdc++.so.6
0x00007ffff6a7a4a0  0x00007ffff6bbf583  Yes         /lib/x86_64-linux-gnu/libc.so.6
0x00007ffff68429f0  0x00007ffff684f4a1  Yes         /lib/x86_64-linux-gnu/libpthread.so.0
0x00007ffff6629ad0  0x00007ffff6639198  Yes (*)     /home/scrawl/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/libgcc_s.so.1
0x00007ffff6421350  0x00007ffff642433c  Yes         /lib/x86_64-linux-gnu/librt.so.1
0x00007ffff618e310  0x00007ffff61f7158  Yes (*)     /home/scrawl/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libfreetype.so.6
0x00007ffff5ea3aa0  0x00007ffff5f108b1  Yes (*)     /usr/lib/nvidia-352/libGL.so.1
0x00007ffff5b36a70  0x00007ffff5bbe7e8  Yes (*)     /home/scrawl/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libX11.so.6
0x00007ffff58ede50  0x00007ffff59078f8  Yes (*)     /home/scrawl/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libfontconfig.so.1
0x00007ffff55e7610  0x00007ffff56561b6  Yes         /lib/x86_64-linux-gnu/libm.so.6
0x00007ffff53cd070  0x00007ffff53d9548  Yes (*)     /home/scrawl/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/libz.so.1
0x00007ffff51c89a0  0x00007ffff51ca4e3  Yes (*)     /usr/lib/nvidia-352/tls/libnvidia-tls.so.352.41
0x00007ffff32c5b30  0x00007ffff4131927  Yes (*)     /usr/lib/nvidia-352/libnvidia-glcore.so.352.41
0x00007ffff2528490  0x00007ffff2532478  Yes (*)     /home/scrawl/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libXext.so.6
0x00007ffff230f520  0x00007ffff231c158  Yes (*)     /home/scrawl/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libxcb.so.1
---Type  to continue, or q  to quit---
0x00007ffff20dfb20  0x00007ffff20f9948  Yes (*)     /home/scrawl/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/libexpat.so.1
0x00007ffff1ed9d90  0x00007ffff1edaae8  Yes (*)     /home/scrawl/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libXau.so.6
0x00007ffff1cd4090  0x00007ffff1cd5aa8  Yes (*)     /home/scrawl/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libXdmcp.so.6
0x00007ffff1073620  0x00007ffff1677b7c  Yes (*)     /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libengine2.so
0x00007ffff0b42fa0  0x00007ffff0b7037c  Yes (*)     /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libtier0.so
0x00007ffff07f0810  0x00007ffff084524c  Yes (*)     /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libvstdlib.so
0x00007ffff05c83f0  0x00007ffff05d222e  Yes (*)     /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libsteam_api.so
0x00007ffff03b5570  0x00007ffff03b6be8  Yes (*)     /home/scrawl/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/libuuid.so.1
0x00007fffef8c7f00  0x00007fffef978330  Yes (*)     /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libSDL2-2.0.so.0
0x00007fffee6e7ec0  0x00007fffef19bce2  Yes (*)     /home/scrawl/Steam/linux64/steamclient.so
0x00007fffee2720a0  0x00007fffee297dee  Yes (*)     /home/scrawl/Steam/linux64/crashhandler.so
0x00007fffec8612c0  0x00007fffec865e28  Yes (*)     /home/scrawl/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libXcursor.so.1
0x00007fffec656910  0x00007fffec65c898  Yes (*)     /home/scrawl/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libXrender.so.1
0x00007fffec4504a0  0x00007fffec4530d8  Yes (*)     /home/scrawl/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libXfixes.so.3
0x00007fffec24c9f0  0x00007fffec24d318  Yes (*)     /home/scrawl/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libXinerama.so.1
0x00007fffec03e0b0  0x00007fffec048638  Yes (*)     /home/scrawl/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libXi.so.6
0x00007fffebe356b0  0x00007fffebe39f08  Yes (*)     /home/scrawl/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libXrandr.so.2
0x00007fffebc31c00  0x00007fffebc329d8  Yes (*)     /home/scrawl/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libXss.so.1
0x00007fffeba2ce50  0x00007fffeba2f708  Yes (*)     /home/scrawl/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libXxf86vm.so.1
0x00007fffeb7ee8d0  0x00007fffeb817c28  Yes (*)     /home/scrawl/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/libdbus-1.so.3
0x00007fffeb05d2d0  0x00007fffeb0b0d8f  Yes (*)     /usr/local//lib/x86_64-linux-gnu//glxosd/libglxosd-plugins-libsensors-support.so
0x00007fffead17460  0x00007fffead1d694  Yes (*)     /usr/lib/x86_64-linux-gnu/libsensors.so.4
---Type  to continue, or q  to quit---
0x00007fffeaaf4990  0x00007fffeab08c6d  Yes (*)     /usr/local//lib/x86_64-linux-gnu//glxosd/libglxosd-plugins-nvidia-support.so
0x00007fffea8c7010  0x00007fffea8cf750  Yes (*)     /lib/x86_64-linux-gnu/libudev.so.1
0x00007fffea6ac610  0x00007fffea6be6ec  Yes (*)     /lib/x86_64-linux-gnu/libcgmanager.so.0
0x00007fffea495760  0x00007fffea4a212a  Yes (*)     /lib/x86_64-linux-gnu/libnih.so.1
0x00007fffea289ce0  0x00007fffea28d4c6  Yes (*)     /lib/x86_64-linux-gnu/libnih-dbus.so.1
0x00007fffe9fe28a0  0x00007fffea04d60c  Yes (*)     /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libfilesystem_stdio.so
0x00007fffe9b5d6c0  0x00007fffe9b9acec  Yes (*)     /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libinputsystem.so
0x00007fffe98f3320  0x00007fffe992875c  Yes (*)     /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libconfigurationsystem.so
0x00007fffe94be410  0x00007fffe960390c  Yes (*)     /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/librendersystemgl.so
0x00007fffe9286120  0x00007fffe928c2a6  Yes (*)     /home/scrawl/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/libudev.so.0
0x00007fffe8f6aab0  0x00007fffe8fe9c7c  Yes (*)     /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libresourcesystem.so
0x00007fffe8ce2020  0x00007fffe8d1c30c  Yes (*)     /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/liblocalize.so
0x00007fffe898e220  0x00007fffe8a5126c  Yes (*)     /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libschemasystem.so
0x00007fffe4d9dea0  0x00007fffe4e9d83c  Yes (*)     /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libmaterialsystem2.so
0x00007fffe420ca40  0x00007fffe42c4e80  Yes         /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libpangoft2-1.0.so
0x00007fffe3e503f0  0x00007fffe3f4c474  Yes         /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libpango-1.0.so
0x00007fffe3c05970  0x00007fffe3c1fe08  Yes (*)     /home/scrawl/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/libpng12.so.0
0x00007fffe39f26b0  0x00007fffe39fde88  Yes (*)     /home/scrawl/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/libbz2.so.1.0
(*): Shared library is missing debugging information.

(gdb) thread apply all bt

Thread 9 (Thread 0x7fffe876d700 (LWP 21025)):
#0  __lll_unlock_wake () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:371
#1  0x00007ffff68488a4 in _L_unlock_722 () from /lib/x86_64-linux-gnu/libpthread.so.0
#2  0x00007ffff68487f4 in __pthread_mutex_unlock_usercnt (decr=1, mutex=0x555556022a18) at pthread_mutex_unlock.c:57
#3  __GI___pthread_mutex_unlock (mutex=0x555556022a18) at pthread_mutex_unlock.c:310
#4  0x00007ffff5efcc64 in ?? () from /usr/lib/nvidia-352/libGL.so.1
#5  0x00007ffff3b8cc16 in ?? () from /usr/lib/nvidia-352/libnvidia-glcore.so.352.41
#6  0x00007ffff5efcd0c in ?? () from /usr/lib/nvidia-352/libGL.so.1
#7  0x00007ffff6845182 in start_thread (arg=0x7fffe876d700) at pthread_create.c:312
#8  0x00007ffff6b5547d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 8 (Thread 0x7fffe886e700 (LWP 21024)):
#0  0x00007ffff6b263f7 in sched_yield () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007ffff5efc0db in ?? () from /usr/lib/nvidia-352/libGL.so.1
#2  0x00007ffff3b8aaab in ?? () from /usr/lib/nvidia-352/libnvidia-glcore.so.352.41
#3  0x00007ffff79bdc12 in glGenTextures () from /usr/local//lib/x86_64-linux-gnu//glxosd/libglxosd-glinject.so
#4  0x00007fffe9518d8d in ?? () from /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/librendersystemgl.so
#5  0x00007fffe9505bdd in ?? () from /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/librendersystemgl.so
#6  0x00007fffe94d56e6 in ?? () from /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/librendersystemgl.so
#7  0x00007fffe94d5c8c in ?? () from /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/librendersystemgl.so
#8  0x00007fffe94f4ebd in ?? () from /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/librendersystemgl.so
---Type  to continue, or q  to quit---
#9  0x00007ffff0b63bb8 in ?? () from /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libtier0.so
#10 0x00007ffff6845182 in start_thread (arg=0x7fffe886e700) at pthread_create.c:312
#11 0x00007ffff6b5547d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 7 (Thread 0x7fffe9eca700 (LWP 21023)):
#0  0x00007ffff6b4812d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007ffff0b613b0 in ThreadMultiWait () from /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libtier0.so
#2  0x00007ffff0806c72 in ?? () from /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libvstdlib.so
#3  0x00007ffff0b63cbc in CThread::ThreadProc(void*) () from /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libtier0.so
#4  0x00007ffff6845182 in start_thread (arg=0x7fffe9eca700) at pthread_create.c:312
#5  0x00007ffff6b5547d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 6 (Thread 0x7fffe9fcb700 (LWP 21022)):
#0  0x00007ffff6b4812d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007ffff0b613b0 in ThreadMultiWait () from /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libtier0.so
#2  0x00007ffff0806c72 in ?? () from /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libvstdlib.so
#3  0x00007ffff0b63cbc in CThread::ThreadProc(void*) () from /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libtier0.so
#4  0x00007ffff6845182 in start_thread (arg=0x7fffe9fcb700) at pthread_create.c:312
#5  0x00007ffff6b5547d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 5 (Thread 0x7fffed269700 (LWP 21021)):
#0  0x00007ffff6b4812d in poll () at ../sysdeps/unix/syscall-template.S:81
---Type  to continue, or q  to quit---
#1  0x00007ffff0b613b0 in ThreadMultiWait () from /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libtier0.so
#2  0x00007ffff0806c72 in ?? () from /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libvstdlib.so
#3  0x00007ffff0b63cbc in CThread::ThreadProc(void*) () from /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libtier0.so
#4  0x00007ffff6845182 in start_thread (arg=0x7fffed269700) at pthread_create.c:312
#5  0x00007ffff6b5547d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 4 (Thread 0x7fffeda6a700 (LWP 21020)):
#0  0x00007ffff6b4812d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007ffff0b613b0 in ThreadMultiWait () from /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libtier0.so
#2  0x00007ffff0806c72 in ?? () from /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libvstdlib.so
#3  0x00007ffff0b63cbc in CThread::ThreadProc(void*) () from /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libtier0.so
#4  0x00007ffff6845182 in start_thread (arg=0x7fffeda6a700) at pthread_create.c:312
#5  0x00007ffff6b5547d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 3 (Thread 0x7fffee26b700 (LWP 21019)):
#0  0x00007ffff6b4812d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007ffff0b613b0 in ThreadMultiWait () from /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libtier0.so
#2  0x00007ffff0806c72 in ?? () from /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libvstdlib.so
#3  0x00007ffff0b63cbc in CThread::ThreadProc(void*) () from /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libtier0.so
#4  0x00007ffff6845182 in start_thread (arg=0x7fffee26b700) at pthread_create.c:312
#5  0x00007ffff6b5547d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

---Type  to continue, or q  to quit---
Thread 2 (Thread 0x7ffff7fc4700 (LWP 21018)):
#0  pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
#1  0x00007ffff5efcc24 in ?? () from /usr/lib/nvidia-352/libGL.so.1
#2  0x00007ffff3b8cc16 in ?? () from /usr/lib/nvidia-352/libnvidia-glcore.so.352.41
#3  0x00007ffff5efcd0c in ?? () from /usr/lib/nvidia-352/libGL.so.1
#4  0x00007ffff6845182 in start_thread (arg=0x7ffff7fc4700) at pthread_create.c:312
#5  0x00007ffff6b5547d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 1 (Thread 0x7ffff7fc67c0 (LWP 21010)):
#0  0x00007ffff619337f in FT_Get_Module () from /home/scrawl/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libfreetype.so.6
#1  0x00007ffff61bf624 in ?? () from /home/scrawl/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libfreetype.so.6
#2  0x00007fffe426f4b5 in FT_Add_Module (library=0x555556023000, clazz=0x7ffff641d580 ) at /home/buildbot/buildslave/pango_linux/build/freetype-2.5.3/src/base/ftobjs.c:4406
#3  0x00007fffe42670ec in FT_Add_Default_Modules (library=0x555556023000) at /home/buildbot/buildslave/pango_linux/build/freetype-2.5.3/src/base/ftinit.c:218
#4  0x00007fffe426713f in FT_Init_FreeType (alibrary=0x7fffe51116d0) at /home/buildbot/buildslave/pango_linux/build/freetype-2.5.3/src/base/ftinit.c:280
#5  0x00007fffe4dd8c4b in ?? () from /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libmaterialsystem2.so
#6  0x00007ffff143c7f2 in ?? () from /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libengine2.so
#7  0x00007ffff143da41 in ?? () from /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libengine2.so
#8  0x00007ffff11b60fc in ?? () from /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libengine2.so
#9  0x00007ffff11b6d20 in ?? () from /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libengine2.so
#10 0x00007ffff10f43d4 in ?? () from /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libengine2.so
#11 0x00007ffff10f46aa in Source2Main () from /home/scrawl/Steam/SteamApps/common/dota 2 beta/game/bin/linuxsteamrt64/libengine2.so
#12 0x0000555555555111 in ?? ()
---Type  to continue, or q  to quit---
#13 0x00007ffff6a7cec5 in __libc_start_main (main=0x555555554fa0, argc=1, argv=0x7fffffffd8b8, init=, fini=, rtld_fini=, stack_end=0x7fffffffd8a8)
    at libc-start.c:287
#14 0x000055555555523d in _start ()
(gdb)

I think I figured it out.
Both Dota2 Reborn and GLXOSD use Freetype. There is a libfreetype.so.6 in /usr (used by glxosd) and one in the Steam Runtime used by Dota 2. These versions are not compatible with each other (6.8.0 vs. 6.11.1), using both at the same time causes a crash.
To fix this issue, you move or rename the file <Steam install>(ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libfreetype.so.6, so that Dota2 Reborn uses the system copy of freetype. After doing this, GLXOSD works in Dota 2 Reborn.
@myromance123: Let me know if that worked for you. I'm curious if XCOM is fixed as well.
@nickguletskii: Should we add this information to the readme/website for the time being, next to the libstdc++ incompatibility issues? Also, any ideas how to avoid the problem? I have a few, but none of them are easy.

Linking freetype statically: that wouldn't help, right?
Use freetype once on startup, then shut it down when we're done and before Dota FT_Init's its freetype. I think this would avoid the conflicts, but we'd need to know all glyphs needed for the OSD in advance.
Outsource the font rendering code to a separate executable (either called at runtime, or called when installing GLXOSD, generating a bitmap font)
Don't use freetype

Opened #37 to track the freetype issue.

Renaming libfreetype.so.6 works for Dota 2 Reborn. Thank you scrawl for the quick fix!
It does not work for XCOM Enemy Within or Enemy Unknown though. XCOM starts up with a mini splash screen (is that what you call it?), where GLXOSD attempts to display itself.

I just tried XCOM. I only have XCOM: Enemy Unknown, not Enemy Within, so I'm not getting the launcher on your screenshot. In game, GLXOSD kinda works, but some glyphs are corrupted. Looks similar to issue #19, so I'll post my findings there.

Could anyone confirm if this is still an issue with GLXOSD v3?


net461 SQL Server tests attempt to create scratch database in unwritable folder

Details
Using dotnet-CLI 2.0.0-preview2-006484
Using the dotnet.exe on system PATH.
Only affects .NET Framework tests
Repro
Install latest preview2-CLI
https://github.com/dotnet/cli/tree/release/2.0.0-preview2#installers-and-binaries
git clone https://github.com/aspnet/EntityFramework.git --branch dev
cd EntityFramework/test/EFCore.SqlServer.FunctionalTests/
dotnet restore
dotnet test --framework net461 --filter ExistsAsync_returns_true_when_database_with_filename_exists

Result

Failed   Microsoft.EntityFrameworkCore.SqlServerDatabaseCreatorExistsTest.ExistsAsync_returns_true_when_database_with_filename_exists
Error Message:
System.Data.SqlClient.SqlException : CREATE FILE encountered operating system error 5(Access is denied.) while attempting to open or create the physical file 'C:\Program Files\dotnet\sdk\2.0.0-preview2-006484\TestHost\Scratch_c0b55f28-4650-468d-84df-e02f5f96b6d7.mdf'.
CREATE DATABASE failed. Some file names listed could not be created. Check related errors.

Last time I investigated similar errors, something about the way VSTest was running tests (possibly related to AppDomain setup) was preventing LocalDB from being able to access the user's profile resulting in a worse-than-usual default database directory.

Created https://devdiv.visualstudio.com/defaultcollection/DevDiv/_workitems?id=453058&_a=edit for this and marking this as external and blocked.
/cc @divega @Eilon


M13 support. 1.3.0 version

fixes #3

Great work, thanks :+1: :smile:

Released to maven central

@SalomonBrys forgot to update Readme

On the way ;)


[Bug]: Shape Mismatch During Expand Operation in ColBERT ONNX Model

What happened?
I encountered a shape mismatch error when using ColBERT’s ONNX model to generate embeddings for a batch of text chunks. While most batches work fine, some cause the following error:
[E:onnxruntime:, sequential_executor.cc:516 ExecuteKernel] Non-zero status code returned while running Expand node. Name:'/bert/Expand' Status Message: /bert/Expand: left operand cannot broadcast on dim 1 LeftShape: {1,512}, RightShape: {18,513}
In this case:

18 is the batch size passed to the model.
512 and 513 refer to the token sequence lengths of the tensors being processed.
The issue appears to be related to the tokenization and batching process inside the model, as the input to the ONNX model is plain text, and tokenization happens internally.

What is the expected behaviour?
model should generate embeddings for the provided text.
A minimal reproducible example
No response
What Python version are you on? e.g. python --version
Python 3.10.15
FastEmbed version
FastEmbed 0.3.6
What os are you seeing the problem on?
Linux
Relevant stack traces and/or logs
2024-11-21 10:10:48.454 | INFO     | app:embed_documents:61 - Received request to embed documents with 18 texts using model 'colbert'
2024-11-21 10:10:48.455 | INFO     | app:get_or_initialize_model:38 - Using cached model: colbert
2024-11-21 10:10:48.481 | ERROR    | app:embed_documents:71 - Error embedding documents: [ONNXRuntimeError] : 1 : FAIL : Non-zero status code returned while running Expand node. Name:'/bert/Expand' Status Message: /bert/Expand: left operand cannot broadcast on dim 1 LeftShape: {1,512}, RightShape: {18,513}
2024-11-21 11:05:09.729 | INFO     | app:embed_documents:61 - Received request to embed documents with 27 texts using model 'BM25'
2024-11-21 11:05:09.729 | INFO     | app:get_or_initialize_model:38 - Using cached model: BM25
2024-11-21 11:05:09.759 | INFO     | app:embed_documents:61 - Received request to embed documents with 27 texts using model 'colbert'
2024-11-21 11:05:09.759 | INFO     | app:get_or_initialize_model:38 - Using cached model: colbert
2024-11-21 11:05:10.213 | INFO     | app:embed_documents:66 - 128
2024-11-21 11:06:12.688 | INFO     | app:embed_documents:61 - Received request to embed documents with 27 texts using model 'BM25'
2024-11-21 11:06:12.689 | INFO     | app:get_or_initialize_model:38 - Using cached model: BM25

same error here also when trying to use AnswerdotAI  with vepsa.onnx
InvalidArgument: [ONNXRuntimeError] : 2 : INVALID_ARGUMENT : Non-zero status code returned while running Expand node. Name:'/bert/Expand' Status Message: invalid expand shape
but with Jinaai/Colbertv2 it worked fine

Hey,
Facing an issue while running the code snippet from the notebook qdrant/workshop-ultimate-hybrid-search, for batches having elements with large documents I get this error:
InvalidArgument: [ONNXRuntimeError] : 2 : INVALID_ARGUMENT : Non-zero status code returned while running Expand node. Name:'/bert/Expand' Status Message: invalid expand shape

same here , InvalidArgument: [ONNXRuntimeError] : 2 : INVALID_ARGUMENT : Non-zero status code returned while running Expand node. Name:'/bert/Expand' Status Message: invalid expand shape.
looks like it is expecting chunk sizes to be smaller??

@FaisalAliShah @abdelkareemkobo @AlterHoodie @atanudasgupta
the fix should be available as of fastembed 0.5.0
please re-open the issue if the error persists


[NSE-770] Fix issues in ArrowRowToColumnarExec and writting shuffle metadata for spark 3.2

This PR fixed two runtime issues on spark 3.2. Thus, tpcds test can pass on spark 3.2 when AQE is turned off.
All unit tests passed. And all benchmark tests on jenkins also passed on spark 3.1.

This PR fixed two runtime issues on spark 3.2. Thus, tpcds test can pass on spark 3.2 when AQE is turned off.
All unit tests passed. And all benchmark tests on jenkins also passed on spark 3.1.

This PR is included in #773. Will close it.


Help

Please remove the requirement.txt file I'm getting error in downloading Packages

You need the requirements.txt file in order to install the dependencies for the bot to run.  What error are you receiving?


Implement Arbritrary for all types

Building from the ground up with fuzzing in mind is always beneficial to libraries, especially ones that define their own types.
Meaning the Arbitrary trait should be implemented for all types, maybe even on the features themselves. This way, setting up libFuzzer, cargo fuzz, or AFL is easy.
The standard approach is to add a feature gate arbitrary that reveals the Arbitrary trait implementations when enabled.

I like this. Let's do it. Talking with the team


QR code in the GIF format

Hello,
I need to have a QR code generated in GIF format.
Is it possible to specify the image type with some parameter?
Or should I convert the PNG to GIF myself?
Thanks a lot for the answer
Best Regards
Michal

Hello, that entirely depends on what you use to generate the image itself. This library only generates the data and has support for some 3rd party libraries to generate the image automatically. You need to work with those libraries to generate an image in a different format.
I can provide further assistance if you tell me which library you use for creating the image.

Thank you for the quick help. I use endroid to generate images.
I wanted to use GifWriter but I'm getting a 500 error...
I'll try to debug it somehow.

Try turning on display_errors, that should help.


Does this module help me create all combinations from lists?

Hi @Janiczek :wave:
I have a list of lists with different lengths. In this example I have a list holding 3 lists:
 [ [ 1, 2] [a, b, c] [10, 20, 30, 40, 50] ]

I'd like to get all the permmutations. That is, something like:
[

[1, a, 10]
[2, a, 10]
[1, b, 10]
[2, b, 10]
[1, c, 10]
[2, c, 10]
[2, c, 20]
-- ...
]

Hello @amitaibu !
The module in principle does this kind of stuff but if you're holding things in a list of lists, you'll be better served by List.Extra.cartesianProduct which has that exact API!
See this Ellie :)
https://ellie-app.com/gMp7gQjLD8ja1

Just to compare, List.Cartesian has a little different API - it needs you to give it the inner lists one by one, and gives the choices for each separately too (\a b c -> ... instead of in a list):
https://ellie-app.com/gMpfcWng6fna1

Perfect, thank you!


Set log level from parameter or envvar.

This PR is yet another attempt at solving issue #220, just like #245 and #289 before.
Sorry, for opening yet another PR for this, but since there wasn't much activity I figured I give it a go.

Hi @dbrumann, we're in the phase of extending the Extension class of Monolog to have this functionality.
However we would like to have this in the bundle, so that we don't manage it ourselves.
Can we help you to get this functionality merged in the bundle itself?
Thanks in advance!

Thanks @SerkanYildiz. The failing tests should be addressed by #360. I hope after merging that we can also merge this. I guess other than reviewing if this is the appropriate way to solve this, there is not much else to do here, right now.

Could you add a note in the CHANGELOG? after that I'm 👍🏼

I just tried this out in a project and noticed an issue. The following config (when no env var is set) will not work:
# config/packages/monolog/dev.yaml
parameters:
    env(LOG_LEVEL): ~
monolog:
    handlers:
        main:
            type: stream
            path: "%kernel.logs_dir%/%kernel.environment%.log"
            level: '%env(LOG_LEVEL)%'

I am working on a fix for this.

It took time, but here we go, this is in now. Thank you very much @dbrumann.

Hello,
Quick question: is it possible to combine this env var with the default resolver?
I'm trying to do this but I'm getting the following error: '%env(default:info:LOG_LEVEL)%'.
In MergeExtensionConfigurationPass.php line 217:
!!
!!    Using a cast in "env(default:info:LOG_LEVEL)" is incompatible with resoluti
!!    on at compile time in "Symfony\Bundle\MonologBundle\DependencyInjection\Mon
!!    ologExtension". The logic in the extension should be moved to a compiler pa
!!    ss, or an env parameter with no cast should be used instead.

Any insight?
Thanks!

No, unfortunately not.  This ties into the issue reported in #413 The log level needs to be evaluated during container compilation to be able to build the logger.
As far as I can tell we can only get the value and not use resolvers at that point. I am not 100% sure if this is really a general limitation or caused by how I implemented it. It might also have changed - I haven't really kept up to date with the changes around resolving env vars. So it might be doable, but I am afraid I don't have much time to check it at the moment. Feel free to have a deeper look, if you can.

Ok, thanks @dbrumann!


[bug]: Odd UI error on startup, randomly during use

Is there an existing issue for this?

[X] I have searched the existing issues

OS
Windows
GPU
cuda
VRAM
6gb
What version did you experience this issue on?
2.3.2.post1
What happened?
Receiving this error message on startup (sometimes more than once), and randomly later during use. Note I am not using the green colored UI.
Screenshots

Additional context
No idea what or if this is doing anything. Just reporting as it appears to be some kind of uncaught exception.
Contact Details
No response

This just reports a temporary timeout/disconnect between frontend and backend. Shouldn’t impact much, aye? All works still?

The only thing I have is that sometimes (irregularly) send to unified canvas will change to the canvas but it will be empty and I have to click it a second time to have the image show up there. I have no idea if it is related to this in any way; I have been trying to pin down the conditions before I report that one but I suppose maybe it's related to this?

It's the same error message as https://github.com/invoke-ai/InvokeAI/issues/1685 the only change seems to be the "removing descriptor" part, so the root of the problem might be the same bug?

Not sure the "removing descriptor" part has anything to do with things I just grabbed everything in the vicinity of the error message.

Yup does appear to be the same bug.

This error appears to be proliferating. I am now seeing it repeat dozens of times on startup with 2.3.3. Still dosen't appear to actually do anything, but it's making the console almost unreadable as it swamps all other messages.


Adding negative point labels

Hey, thanks for the amazing work. This is not an issue, more a question. I am trying to add negative point labels to the query. The following hard-coded example does not produce an error, but it also does not produce the expected output. In this case, refining the mask by providing a 0 label a the given point. Can you advise if this is correct, or am I missing something?
# grounded_same_demo.py (After Line 194)

point_coords = torch.tensor([[[1146,982]]])
point_labels = torch.tensor(np.array([[0]]))

point_coords = predictor.transform.apply_coords_torch(point_coords, image.shape[:2])

masks, _, _ = predictor.predict_torch(
    point_coords = point_coords.to(device),
    point_labels = point_labels.to(device),
    boxes = transformed_boxes.to(device),
    multimask_output = False,

Ok, so issue number 1: I was doing some other work and my venvs got mixed up so was using the wrong segment_anything repo. Now I get an error ... progress
The above code now produces the RuntimeError below when calling torch.cat([sparse_embeddings, box_embeddings], dim=1) in prompt_encoder.py.
RuntimeError: Sizes of tensors must match except in dimension 1. Expected size 1 but got size 4 for
tensor number 1 in the list.

Looking at PromptEncoder._get_batch_size my guess it that the PromptEncoder does not like it when you pass both points and boxes.


Patch: Updated answers to networking & NTP questions.

The networking and NTP server questions repeated the information that already exists at other places in our documentation. Moreover, the information in this text was not accurate/up-do-date. Hence, replaced the text with appropriate links.

Review  this one, @vipulgupta2048 .
Thanks!

@balena-ci rebase


Please dont Require Priemium

Hey i saw in the README stands i need Premium this was a Deal Breaker for Me, But it is Possible to login without Premium like SpotTube it does

You can modify the source code to allow non-premium accounts, but that is breaking spotify TOS

As shaunsingh said, this would violate Spotify's TOS, and we won't be adding it.

I don't think spotube breaks spotify's TOS. They don't pirate music from spotify, they use spotify's public API to discover tracks, and then stream them from youtube. I'm just pointing that out, not saying that this should be done here.

Do not create any product or service which is integrated with streams or content from another service.

https://developer.spotify.com/policy part III.5
To be fair, nearly everything is against their terms. I think you just need to be sensible and avoid attracting attention through obvious violations that take value away from their product/tech.


Adding an entry to monitor CoreClr release/1.1 performance.

@jorive,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by .NET Foundation. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot

PTAL @mmitche @DrewScoggins @adiaaida @valenis


Collection property not exposed with other properties

Hydra vocabulary clearly states that hydra:collection is a hydra:Link. Whatever tool performs the assertion regarding hydra vocabulary must understand it's semantics.
Originally posted by @alien-mcl in https://github.com/HydraCG/api-examples/pull/8

The problem is that a resource's getProperties() method looks for supported properties of declared type and not other predicates.
Unless hydra:collection is used as a supported property of a class, it will not be returned by getLinks()

After a bit of debugging, this seems to be related to https://github.com/libero/article-store/pull/49#issuecomment-557595736 (where hydra:collection is a supported property). The supported hydra:collection is returned from getLinks(), and the actual hydra:collection implementation is returned from getCollections(). The GHA joins them together in https://github.com/hypermedia-app/generic.hypermedia.app/blob/fe0982539e099b870c9503679ddb1153c3aa8f40/src/components/resource-views/alcaeus-resource-viewer.ts#L250-L284 leading to the duplication.


Moving files with ../

Hello! There is a way to move files like this? (the *nix way)
iblistener (master)
λ mv project\plugins.sbt .
mv: `project\\plugins.sbt' and `./project\\plugins.sbt' are the same file

iblistener (master)
λ mv project\plugins.sbt ../
mv: cannot move `project\\plugins.sbt' to `../project\\plugins.sbt'

iblistener (master)
λ mv project\plugins.sbt ..\
mv: cannot move `project\\plugins.sbt' to `..\\/project\\plugins.sbt'

It works correctly if you use forward slashes.
cp ../ch07/karma.conf.js .
Pressing tab to autocomplete your path puts in backslashes, so it doesn't help much.

That's because the mv and cp commands (and also rm ones) from msysgit are too old.
I would suggest that you install Gow or GnuWin32, and make sure they are at the beginning of the path.
I'm using my own set of utils here: win32-utils as GoW replaced ssh with plink.

Seems fixed long ago when we updated something.


Cable conduit

Suggestion.
The cabke conduit which can transport ic2s eu between macines, thats all.
The crafting might require the 6 composites and some energy crystals or glass fibre cable.
I think its a good idea.

Thank you for your suggestion. It has been added to our list or possible enhancement.
This ticket will be closed because we want the list of open tickets to reflect known issues.


release: v0.2.0-beta.6

Description
Release to include the fix for monaco validation so that we can bubble up to dashboard
References
Review Checklist

[x] I have clicked on "allow edits by maintainers".
[ ] I have added documentation for new/changed functionality in this PR or in a PR to openfga.dev [Provide a link to any relevant PRs in the references section above]
[x] The correct base branch is being used, if not main
[ ] I have added tests to validate that the change in functionality is working as expected

Before we release this, can we check if any dependencies can be updated and get that in?

@rhamzeh, npm outdated was only reporting updates for @types/node so updated that and restructured the commits to make more sense (update before release)

re updating, I find running: rm -r package-lock.json node_modules; npx npm-upgrade@latest to find the most updates (it forces refreshing the lock file, and npm-upgrade allows you to read the changelogs of each item)


Use new Github Action to upload release assets

Use alexellis/upload-assets instead of actions/upload-release-asset, which is no longer maintained. One advantage is that we can list all assets with a glob expression, so the workflow file is much less verbose.
We also do a minor change to ./hack/generate-manifest-windows.sh, so that it can be run on macOS (one of the sed commands was GNU-specific, and there is no reason to use sed instead of kustomize).
Fixes #4514

/skip-all


Adds note to external issuer contributions to wait for approval

Signed-off-by: joshvanl<EMAIL_ADDRESS>/assign @wallrj

/retest


chore: Spectra DAO custom domain

Hi! What is your PR about?

[ ] Add or edit a skin
[x] Add a custom domain for your space
[ ] Add an alias to migrate your space

Please also complete steps 4 to 6 from the docs https://docs.snapshot.org/user-guides/spaces/add-custom-domain#2.-add-your-custom-domain-to-domains.json

Please also complete steps 4 to 6 from the docs https://docs.snapshot.org/user-guides/spaces/add-custom-domain#2.-add-your-custom-domain-to-domains.json

This PR looks like step 6. About step 4 - it's done as well.

Please also complete steps 4 to 6 from the docs https://docs.snapshot.org/user-guides/spaces/add-custom-domain#2.-add-your-custom-domain-to-domains.json

This PR looks like step 6. About step 4 - it's done as well.

The doc has just been updated, and steps order have changed.
Can you ensure you have completed all the steps ? The domain http://vote.spectra.finance/ is not redirecting to snapshot yet

Please also complete steps 4 to 6 from the docs https://docs.snapshot.org/user-guides/spaces/add-custom-domain#2.-add-your-custom-domain-to-domains.json

This PR looks like step 6. About step 4 - it's done as well.

The doc has just been updated, and steps order have changed.
Can you ensure you have completed all the steps ? The domain http://vote.spectra.finance/ is not redirecting to snapshot yet

I see. It should be fine now.

Can you update your space settings with the custom domain name ? https://snapshot.org/#/spectradao.eth/settings

Done


Issue 70 request to add more button variant and create a button reference example page

Change Summary
Readded the button component in component-showcase page.
Added all button component variant include:

Inactive
Small One (default and cutout)
Default
Finish
Cutout
Link

Change Form

[x] The pull request title has an issue number
[ ] The change works by "Smoke testing" or quick testing
[x] The change has tests
[ ] The change has documentation

Inactivated Button now has been set as disabled={true}.


Practical steps towards Shapely 2.0

TODO before final release:

[ ] update list of contributors again

TODO items for the Shapely / PyGEOS merge:

[x] Merge packages into a single shapely package:

[x] Merge the python source code of both packages into a single, minimal working shapely package -> https://github.com/Toblerity/Shapely/pull/1237
[x] Consolidate both strtree.py files -> https://github.com/Toblerity/Shapely/pull/1251

[x] Continuous Integration:

[x] Update and consolidate the github action workflow for testing -> https://github.com/Toblerity/Shapely/pull/1241
[x] Update the github action workflow for wheel building / releasing -> https://github.com/Toblerity/Shapely/pull/1253
[x] Ensure Travis CI is running (after moving to the shapely org?)

[x] Packaging:

[x] Consolidate the setup.py parameters -> https://github.com/shapely/shapely/pull/1376
[x] Consolidate pyproject.toml and setup.cfg
[x] Consolidate MANIFEST.in, ensure sdist/wheel creation is working -> https://github.com/Toblerity/Shapely/pull/1249
[x] Ensure versioneer is working and has a correct shapely 2.0.0.dev+.. version

[ ] Tests

[ ] Move /tests to /shapely/tests -> #1257, #1275, ...
[ ] Combine / deduplicate tests where useful

[ ] Documentation

[ ] Update docstrings
[x] Merge the sphinx documentation sources -> https://github.com/shapely/shapely/pull/1377, https://github.com/shapely/shapely/pull/1402

Opening an issue to discuss the more practical aspects of the work on Shapely 2.0 (https://github.com/shapely/shapely-rfc/pull/1/). Changes needed in Shapely 1.8 (deprecations, etc) related to this are tracked in https://github.com/Toblerity/Shapely/issues/932
The general route I am now trying out is to, iteratively, refactor the shapely code in-place. But @caspervdw mentioned at https://github.com/Toblerity/Shapely/issues/782/#issuecomment-592058242 also the option of starting "fresh" (for the code, not for the existing tests and things like that).
For both ways, the work can be done in a separate branch, and then using the normal PR workflow (with PRs targetting that branch). This branch has already been created: https://github.com/Toblerity/Shapely/tree/shapely-2.0 (but is already a bit behind master).
First question: how to keep this branch updated while master is still for 1.8? I would like to propose to initially rebase shapely-2.0 regularly on master. In an initial phase where there is still a lot of activity for 1.8 on master and only few people contribute to the shapely-2.0 branch, this seems easier / cleaner (there are eg also still some things to be merged in master on which we depend for shapely 2.0). Once the development focus shifts more to shapely-2.0, we can use the normal merging strategy already being used for the different branches right now. Does that sound good?
(I can volunteer to do the rebases / fix conflicts :-))
At some point we should probably move the source code of PyGEOS into Shapely (I would propose to do this in its entirety, and keeping its commit history (for proper attribution), and then clean-up / integrate in subsequent steps).
But initially, I am actually already testing some things (eg the Geometry subclasses) with using pygeos as an external package.
cc @sgillies @mwtoews @tomplex @caspervdw

Practical steps (to further fill in while we go, but to keep track of the items we already have/know):

[x] Remove the functionality deprecated in Shapely 1.8 (https://github.com/Toblerity/Shapely/issues/932)

[x] Mutability -> PR https://github.com/Toblerity/Shapely/pull/960
[x] Adapter/proxy classes -> PR https://github.com/Toblerity/Shapely/pull/961
[x] Ctypes / array interface

[x] Refactor the Geometry classes as subclasses of pygeos.Geometry -> https://github.com/Toblerity/Shapely/pull/983
[x] Remove shapely.geos.lgeos and its usage (use pygeos where needed instead) -> https://github.com/Toblerity/Shapely/pull/1163
[x] Move all above changes into the main branch (-> https://github.com/Toblerity/Shapely/pull/1211)
[x] Move the source code of PyGEOS into Shapely (-> https://github.com/Toblerity/Shapely/pull/1221)
[ ] ...

To give an update on this: the geometry classes already have been refactored to subclass pygeos.Geometry a while ago, and in the meantime I have been refactoring most of the other parts of shapely as well to remove any direct use of the ctypes based lgeos and impl.
The two main remaining places where it is used are:

shapely.ops -> I have a PR to refactor this (https://github.com/Toblerity/Shapely/pull/1065), but this still needs some additions to pygeos as well
STRtree -> this can eventually be replaced with the pygeos STRtree implementation, but we first need to decide on the exact API regarding the return values. I started a PR with a concrete proposal (for shapely 1.8, and once agreed can be applied to shapely-2.0 branch as well): https://github.com/Toblerity/Shapely/pull/1064

A few smaller other cases as well (like the validation module, pickling linearrings), will look into fixing those as well.
So in summary, I think we are close (once the above are done) to be able to remove full of shapely.geos.lgeos and all ctypes usage (at which point Shapely is basically a pure python package fully depending on pygeos for all GEOS interaction).

With that said, I would like to bring up the next step in the outline above: "Move the source code of PyGEOS into Shapely"
I think it would be a good time to start consolidating development (and discussions, interactions, etc) in a single repo (eg after a next release of pygeos).
Practically speaking, I was thinking about:

Move the full pygeos git repository into the shapely repository (so we can preserve history for the pygeos files, and commit author recognition, etc). I need to check a bit how this would exactly work, but I think with eg git-subtree this should be possible.
The first step would simply add the pygeos source, so both are side by side in the same repo. Then we can progressively move things to the correct place in the consolidated repo.

The exact file organization is something we should then still discuss. There are also some aspects where both repos use different "practices" (like pyproject.toml, versioneer, ..) that need to be discussed/consolidated

Regarding issues: it might be useful to migrate open issues from pygeos to Shapely, at some point. We can either do this manually, or try to find an automated way (github's issue migration is only possible for repo's in the same org).

Thoughts about this?

To give an update on this: the geometry classes already have been refactored to subclass pygeos.Geometry a while ago, and in the meantime I have been refactoring most of the other parts of shapely as well to remove any direct use of the ctypes based lgeos and impl.
The two main remaining places where it is used are:

shapely.ops -> I have a PR to refactor this (https://github.com/Toblerity/Shapely/pull/1065), but this still needs some additions to pygeos as well
STRtree -> this can eventually be replaced with the pygeos STRtree implementation, but we first need to decide on the exact API regarding the return values. I started a PR with a concrete proposal (for shapely 1.8, and once agreed can be applied to shapely-2.0 branch as well): https://github.com/Toblerity/Shapely/pull/1064

A few smaller other cases as well (like the validation module, pickling linearrings), will look into fixing those as well.
So in summary, I think we are close (once the above are done) to be able to remove full of shapely.geos.lgeos and all ctypes usage (at which point Shapely is basically a pure python package fully depending on pygeos for all GEOS interaction).

With that said, I would like to bring up the next step in the outline above: "Move the source code of PyGEOS into Shapely"
I think it would be a good time to start consolidating development (and discussions, interactions, etc) in a single repo (eg after a next release of pygeos).
Practically speaking, I was thinking about:

Move the full pygeos git repository into the shapely repository (so we can preserve history for the pygeos files, and commit author recognition, etc). I need to check a bit how this would exactly work, but I think with eg git-subtree this should be possible.
The first step would simply add the pygeos source, so both are side by side in the same repo. Then we can progressively move things to the correct place in the consolidated repo.

The exact file organization is something we should then still discuss. There are also some aspects where both repos use different "practices" (like pyproject.toml, versioneer, ..) that need to be discussed/consolidated

Regarding issues: it might be useful to migrate open issues from pygeos to Shapely, at some point. We can either do this manually, or try to find an automated way (github's issue migration is only possible for repo's in the same org).

Thoughts about this?

I had a chat with @caspervdw about this last week, and trying to summarize a few thoughts:

Move Shapely 1.8 forward (https://github.com/Toblerity/Shapely/issues/1066) so a beta/final version can be released and its development can be moved to a maint-1.8 branch
At that point, the master branch can become the current shapely-2.0 branch, and then we can move the pygeos source code and development into Shapely

Basically we were thinking that it's probably important to only move pygeos here when the development on it can happen in the master branch, to ease the development workflow.
(because there will still be quite some work needed to integrate both code bases, and while doing that we will also still further develop the pygeos C code, and this will all be easier to work on if it's on the master branch, I think)

I had a chat with @caspervdw about this last week, and trying to summarize a few thoughts:

Move Shapely 1.8 forward (https://github.com/Toblerity/Shapely/issues/1066) so a beta/final version can be released and its development can be moved to a maint-1.8 branch
At that point, the master branch can become the current shapely-2.0 branch, and then we can move the pygeos source code and development into Shapely

Basically we were thinking that it's probably important to only move pygeos here when the development on it can happen in the master branch, to ease the development workflow.
(because there will still be quite some work needed to integrate both code bases, and while doing that we will also still further develop the pygeos C code, and this will all be easier to work on if it's on the master branch, I think)

Now Shapely 1.8 has been released, and a maint-1.8 branch has been created, I would like to move forward with the next steps outlined in this issue.

At that point, the master branch can become the current shapely-2.0 branch, and then we can move the pygeos source code and development into Shapely

For the step of moving the pygeos source code into the Shapely repo, I would propose the following workflow:

Move the full pygeos git repository into the shapely repository as a /pygeos subdir using git-subtree

This way we can can preserve history for the pygeos files, and commit author recognition, etc
Initially adding this as a subdirectory should avoid file name clashes of top-level files in this first step (things like setup.py etc)

This first step simply add the pygeos source, so both are side by side in the same repo. Then we can progressively move things to the correct place in the consolidated repo, both for the actual package code as for development workflow related files (CI etc). Different aspects, and each of those will require some discussion:

Merge the actual python and C source files (to discuss: package layout, etc)
Merge the packaging and development setup (setup.py, versioning, CI, etc)
Merge the tests
Merge the docs

Those different items of step 2) will require some more discussion. I will open a separate issue for the package layout, and discuss some of the development workflow issues here (see comment below).
I would like to have done the minimal basics for 2.i and 2.ii as fast as possible, so we have the main branch in an installable status as fast as possile (and can start doing shapely 2.0.0-alpha releases as quick as possible to test things out).
Initially we also will still want to do some updates in pygeos or make new releases of it (since many people are already using it), but I would propose that once step 1 and 2.ii is done, all substantial changes are first committed to shapely, and then backported to pygeos when needed/useful. @caspervdw would that work for you?

Some further discussion points for step 2.ii regarding merging the packaging and development setup.
Consolidation packaging setup and development workflows

CI:

pygeos has moved Windows tests from Appveyor to github actions as well. I would propose to follow that lead (one CI service less to worry about)
pygeos actually still has some Travis CI setup for more exotic platforms (ppc64le, s390x)

Linting

in pygeos we use flake8, black and isort in a pre-commit config file. Are people OK with using those tools here as well?

Versioning:

Shapely currently uses a simple approach of a harcoded version number in __init__ that is updated manually on releases. In PyGEOS we use versioneeer (https://github.com/python-versioneer/python-versioneer) which uses the git tag to automatically determine the version number. Personally, I like the approach of using git tags (it's also being used in geopandas, pandas, etc): when doing a release you just add a tag (which you need to do anyway) and the versioning follows from that + you also get a development version (like pandas version 1.4.0.dev0+973.g82f5395e0c). Another alternative for this approach would be setuptools_scm (https://github.com/pypa/setuptools_scm)

Wheel building

cibuildwheel: we made some effort setting this up in PyGEOS (see https://github.com/pygeos/pygeos/blob/9dcb9969f028eea90e34238b2746272105a7ff5e/.github/workflows/release.yml#L39-L134). I would propose to keep using this in the merged repo instead of the separate shapely-wheels repo. Cibuildwheel has some advantages: well maintained, easier to use, can be included in the main repo (so you can more easily test a PR that might impact wheel building; no need to synchronize the shapely repo inside shapely-wheels), and some other packages I know also started or are starting to use it (eg scikit-learn, numpy).

Release / publishing:

In addition to building wheels, in pygeos we also automated the building of sdist / uploading to github release / to PyPI for releases (see https://github.com/pygeos/pygeos/blob/9dcb9969f028eea90e34238b2746272105a7ff5e/.github/workflows/release.yml#L136-L181). We have been using a similar approach in geopandas as well, and it makes releasing a very smooth experience.

Heads up: the first step (merging the pygeos source code and history into this repo) has been done!
This will require lots of follow-up to clean up and consolidate the merged repo (will make a more detailed checklist in the top post), but I started with a first step to get the package working again: https://github.com/Toblerity/Shapely/pull/1237

@sgillies I tagged the main branch with 2.0.0.dev (the commit that merged in pygeos, since there was no good commit directly after 1.8 to tag, shouldn't also really matter), so with the current versioneer setup, you get this version on the main branch now:
In [1]: import shapely

In [2]: shapely.__version__
Out[2]: '2.0.0.dev0+4.g0d3d811'

Now that the STRtree API changes are mostly settled for 2.0 (https://github.com/shapely/shapely/issues/1386), I think the main open issue/PR is https://github.com/shapely/shapely/pull/1414 (about the Geometry() class constructor).
Next to that we also listed the credits update and changelog as requirements for a first 2.0 alpha release. I have started https://github.com/shapely/shapely/pull/1442 for the changelog.
I would propose to do cut a first alpha 0 after merging https://github.com/shapely/shapely/pull/1414? Having a first alpha would allow to test the release / wheel building workflow, update the conda recipes (and make it easier to use it in CI for example in geopandas). And we can still only communicate about it once the changelog is in a better state.

@sgillies @caspervdw @brendan-ward @mwtoews as mentioned above (and discussed before), I am planning to tag a first alpha release after merging https://github.com/shapely/shapely/pull/1414 (which should be ready to be merged). Please speak up if there are any concerns about this!

I think it would be good to have #1451 and #1391 in first.  Do we also want to make sure that one of #1426 / #1430 is in so that setup.py and related are a bit more stable before the alpha?

Do we also want to make sure that one of #1426 / #1430 is in so that setup.py and related are a bit more stable before the alpha?

In theory that should only be moving the same information around to another file / config format. Of course in practice there might be small nuances. I think the main problem is that pyproject.toml (https://github.com/shapely/shapely/pull/1426) is blocked by dropping Python 3.6 support.
But personally I don't see those as critical for an alpha release.

I'm investigating the static project metadata PRs, with a preference with PEP 621 as a final place for the "boring parts".

All of https://github.com/shapely/shapely/pull/1451, https://github.com/shapely/shapely/pull/1391 and https://github.com/shapely/shapely/pull/1426 are merged (as well as the update to require Python >= 3.7), so I am planning to tag a first alpha.

The automated release / packaging seems to have worked for the github relaese: https://github.com/shapely/shapely/releases/tag/2.0a1
However:

The upload from github actions to PyPI failed(https://github.com/shapely/shapely/runs/7648698789?check_suite_focus=true#step:7:12), although the PYPI_API_TOKEN has been set up. There is a warning about a missing "pypi-" prefix. I might have missed that, will try to update it.
The upload to PyPI from travis (linux aarch64 wheels) is also failing simply because we forgot to add the encrypted password for this. I am looking creating an encrypted token, however I am running into an issue that seems to happen for old repos: https://travis-ci.community/t/travis-encrypt-data-too-large-for-pypi-tokens-with-older-repos/5792

Update: for github PyPI upload, it was just a small mistake: the secret was named differently than what we had in the workflow file .. I updated that, and re-ran the workflow, and now it is working: https://pypi.org/project/shapely/2.0a1/

@jorisvandenbossche have you announced on Twitter yet?

I first wanted to get the conda-forge packages done (but feel free to already announce, that's not critical)

To whom it might concern: having a dependency on geopyspark (or just installing it) might blindly drag in shapely 2.0 alpha/beta releases in your environment. See https://github.com/locationtech-labs/geopyspark/issues/712

So the conda packages are also ready. If you want to install shapely 2.0 alpha 1, you can do:
# using pip
pip install --pre shapely==2.0a1
# using conda /mamba
conda install -c conda-forge/label/shapely_dev shapely

Draft release notes can already be seen at https://github.com/shapely/shapely/pull/1442/files#diff-f271474562bb2f8c3bdcce3839a98b1ddf7d918b1a4711c6e04f1b572725f12b, although the existing migration guide for updating to 1.8 / 2.0 might be good to point to as well: https://shapely.readthedocs.io/en/stable/migration.html

@soxofaan thanks for pointing that out!

I would like to move forward with a next beta release.
I think most of the issues we have been discussing have been merged (a couple of renames (offset_curve/parallel_offset, quad_segs keyword, unary_union alias, max_segment_length keyword, documenting the changed behaviour of GEOS for offset_curve, etc). The remaining item is:

Behaviour of reducers like unary_union (union_all) for empty or all-None arrays: https://github.com/shapely/shapely/issues/1332.

There is a lot of discussion about this in #1501, and a fix in #1540.
Given this is a PR that might not be merged in the next few days, and given that for shapely users, it is mostly the unary_union behaviour that matters, I also opened https://github.com/shapely/shapely/pull/1553 targeted just at unary_union to potentially include in 2.0 beta1

In addition, I think those two following items would also benefit from getting a decision:

https://github.com/shapely/shapely/pull/1231 (do we want to normalize by default or not?)
https://github.com/shapely/shapely/pull/1522

Unless I hear something, I am planning to do a beta release shortly (with https://github.com/shapely/shapely/pull/1553 included)

One little undiscussed feature that I'm nearly done is to implement a geometry __format__ specification (e.g. f"{Point(1, 2):.2f}" to get POINT (1.00 2.00)). While not a crucial feature, it would be nice to put into 2.0. Hopefully I can complete it in another day for review. A draft for implementing https://github.com/shapely/shapely/discussions/1490 is still weeks away, however, so probably won't make it.

Practical note: personally I would say that it is still fine to add new features until a first RC release. Because I mostly want to get the beta release out to have more people test Shapely 2.0 to report compatibility / updating issues for code now runs on Shapely < 2, and in theory completely new features shouldn't impact that.
(so to say: I would be fine with still merging a __format__ PR after the beta)

Would #1443 be a part of the beta? Or would it be included after the beta? Part of my project extends shapely with C code and relies on casting _geom as a C pointer. So I need such a C API for migration.

@jjyyxx can you give a bit more details about what you are trying to do? (but maybe in #1443 to keep the discussion about a C API there) The _geom attribute is accessible, so you should still be able to access that in C and cast it to a C pointer, the same way as you could do with shapely <= 1.8.

I tagged and released a beta 1! -> https://pypi.org/project/shapely/2.0b1 (https://github.com/shapely/shapely/releases/tag/2.0b1)
This can be installed with pip or conda:
# using pip
pip install --pre shapely==2.0b1
# using conda /mamba
conda install -c conda-forge/label/shapely_dev shapely

For getting a release candidate and final release for Shapely 2.0, @caspervdw and I were thinking to just put out a target date we can follow (except if new issues come up).
So one proposal would be: 4 weeks for the beta + 2 weeks for a release candidate, and then a final release.
Given that the first beta was released on Monday October 17, the target dates could then be Monday November 14 for a first release candidate, and if all goes fine Monday November 28 for a final 2.0.0 release.
Thoughts on such a timeline?
We can still merge entirely new features until the first RC (eg https://github.com/shapely/shapely/pull/1556, https://github.com/shapely/shapely/pull/1548), and we can still do API changes (if needed) before the RC (and then ideally still release a next beta to include those in a release before the RC)

@jorisvandenbossche sounds great!

Released a beta 2 with some of the latest fixes: https://github.com/shapely/shapely/releases/tag/2.0b2

The date for a first RC passed, and while I am still planning to have that out this week, there are a few PRs that are currently milestoned for 2.0 (https://github.com/shapely/shapely/pulls?q=is%3Aopen+is%3Apr+milestone%3A2.0) that I would still like to include (or at least make some decision on whether to include it for 2.0 or not):

https://github.com/shapely/shapely/pull/1604
https://github.com/shapely/shapely/pull/1559
https://github.com/shapely/shapely/pull/1548

Hi all,
Thanks for making shapely even greater!
Did you consider adding any kind of a srs/crs attribute to shapely 2.0 objects?

may I propose a 2.0b3? People would love to see concave hulls in action.

@sgillies You can also see the concave hull in action with a 2.0rc1! ;)
Joking aside, the new concave_hull (is indeed awesome) is a slim wrapper around a GEOS function, just as we have many others. So testing this is mostly testing the new GEOS implementation, which is useful of course, but something that will typically require changes in GEOS, not Shapely. So I think in general, IMO we shouldn't expect to always do a cycle of test releases whenever we have a release that exposes something new from GEOS.
(there might be other reasons to still do a beta release at this point, though, I just don't think concave_hull is one)

Did you consider adding any kind of a srs/crs attribute to shapely 2.0 objects?

@idanmiara that is currently considered out of scope for Shapely, and in any case a bigger discussion that we are not going to have for the upcoming 2.0 release (since we are finalizing this). If you would like to bring this up and discuss further, let's do that in a separate issue (maybe first have a look through older issues if there is already something about, I would have to look myself as well)

@idanmiara shapely is (mostly) only a planar geometry library. Separation of concerns is good for software. Coordinate reference systems, features, layers, cartography, all that has been out of scope and I'm convinced that those concerns will always be better left to, for example, GeoPandas.

@sgillies @jorisvandenbossche
Thanks for you kind replies.
Before I open a separate issue to discuss this further, I just wanted to know if you see any technical difficulties (API/ABI compatibility for instance) with adding an immutable srs/crs attribute in shapely 2.1 geometry objects?

Sorry to be strict, but answering that is for that separate issue ;) (I really want to keep this focused on getting out 2.0).
And I would certainly encourage you to actually open a separate issue (or maybe discussion: https://github.com/shapely/shapely/discussions). Even if it is for us to just repeat that this is out of scope (but we can go a bit in more detail), it is a useful to have a reference for this question and answer (since you are not the only one wondering this).

As a heads up, pending no further comments or feedback, I am planning to cut a first RC tomorrow or on Saturday

@jorisvandenbossche do it!

RC1 is on PyPi, Thanks @jorisvandenbossche
https://pypi.org/project/shapely/2.0rc1/

Yes, and in the meantime everything is packaged as well. So you can install and test the rc1 with:
# using pip
pip install --pre shapely==2.0rc1
# using conda /mamba
conda install -c conda-forge/label/shapely_dev shapely

Did a quick RC2 to test the latest changes to packaging (the update to pyproject.toml, building aarch64 wheels on CircleCI).

RC2 seems to work fine in our project. 🥳

General note: the final 2.0.0 release is planned for tomorrow (2 weeks after the RC)
@felixdivo thanks a lot for testing!

Hi all,
I was wondering what is the estimated timeline for 2.0.1 and which opened PRs are considered for that version.
Thanks!

No concrete timeline, but I hope to do a push this weekend, and we should probably release 2.0.1 shortly with whatever we already have (I think only https://github.com/shapely/shapely/issues/1707 is a remaining reported regression that we should certainly ensure to include)

I think that https://github.com/shapely/shapely/issues/1711 is also a bug/regression that should be addressed in 2.0.1 (as only shapely 2 uses relative imports)

I am planning to do a first 2.0.1 release with the fixes we have merged at the moment (https://github.com/shapely/shapely/pull/1737). There are a few more fixes in the pipeline, but we can do a 2.0.2 not much after.

I think that #1711 is also a bug/regression that should be addressed in 2.0.1 (as only shapely 2 uses relative imports)

@idanmiara I think that's only an issue for contributors, not for end users? (so I wouldn't consider that as critical for 2.0.1)

Also going to close this, since 2.0.0 is released now. The remaining follow-up issues listed in the top post (tests, docs) have its own issue now. Will open a separate issue for coming bug-fix releases.

I think that #1711 is also a bug/regression that should be addressed in 2.0.1 (as only shapely 2 uses relative imports)

@idanmiara I think that's only an issue for contributors, not for end users? (so I wouldn't consider that as critical for 2.0.1)

As a user I would expect it to be easy to run/debug doctests to help me understand how a function works, thus I would prioritize it.


[$1000] Chat - Copy email option is missing chat settings with new user

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Issue found when executing PR https://github.com/Expensify/App/pull/21779
Action Performed:

Open app and login with User A
Click on new chat and enter an email of a User B (new user that doesn't have Expensify account)
Click on header of chat and copy the email of User B

Expected Result:
Copy email option should be available
Actual Result:
Copy email option is missing on Web in chat with new user
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[x] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number: <IP_ADDRESS>
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/78819774/1b10c61f-56e3-4f4c-ab1f-9698f78a5242
Expensify/Expensify Issue URL:
Issue reported by: Yes
Slack conversation: Yes
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~0198cc663a4ea8fbfd
Upwork Job ID:<PHONE_NUMBER>124038656
Last Price Increase: 2023-07-14

This should be fixed in the backend. When open report with new email, the backend now returns accountID, avatar, and displayName. This should include login as well.

Ideally we fix this by adding the Email to the profile even for new users? (We won't have the rest like pronouns etc.)
Looks like this:

But we want it to look like this:

Proposal:
I can work on this

Hello, has the problem been solved or are you still accepting proposals? Greetings!👍

This also happens when renaming an account after account exists.  See this issue for steps to create such an account: https://github.com/Expensify/App/issues/22293

Contributor details
Your Expensify account email<EMAIL_ADDRESS>Upwork Profile Link: https://www.upwork.com/freelancers/~017a45afbd5badccec

Not overdue, reviewing proposals

There isn't any proposals actually.
@uzproblue  Kindly use this proposal template to provide analysis and solution

Proposal
I can work on this issue.
I will fix copy email feature and make the component look like the example provided above.

Proposal
Please re-state the problem that we are trying to solve in this issue.
When we click on the header of a chat we can't copy the email when the user has no login
What is the root cause of that problem?
In ProfilePage and DetailsPage we only display the line with  copy Email or copy Sms if the user has a login.
For example for ProfilePage the condition is here:
https://github.com/Expensify/App/blob/9c65620c724410693e71786d2df5980769ea2f8a/src/pages/ProfilePage.js#L181-L195
What changes do you think we should make in order to solve the problem?
When the user has no login we can use the display name, I think the easiest way is to put displayName as a default value when we retrieve the login. So instead of this:
https://github.com/Expensify/App/blob/9c65620c724410693e71786d2df5980769ea2f8a/src/pages/ProfilePage.js#L113
We can do this:
const login = lodashGet(details, 'login', displayName);
We can do the same thing for DetailsPage
What alternative solutions did you explore? (Optional)
I don't see what regressions that could cause but just in case if we are afraid of regressions we can also replace the null here:
https://github.com/Expensify/App/blob/9c65620c724410693e71786d2df5980769ea2f8a/src/pages/ProfilePage.js#L195
by the same thing as above but with displayName, and maybe also test that displayName is a correct email or sms

@abdulrahuman5196 is now reviewing proposals

Reviewing now

@ShogunFire for proposal here https://github.com/Expensify/App/issues/22192#issuecomment-1635084689
I don't think using displayName will be a right option, since displayname can be something with isn't email.

I think this is due to the recent change of not sending login value as part of userdetails for privacy concerns. So I am not sure on the new expectation of this issue on the profile page. So tagging @luacmartins (Assuming he worked on this, if not kindly tag the person who be able to provide the expectation on this)

Thanks for the ping. I didn't work directly on this feature. @Beamanator can you weight in here

There are times where it's impossible to get the email if I understand correctly. In that case I think we should focus on the times where we can get the email/phone number
What do you think of doing the last sentence of my alternative proposal:

and maybe also test that displayName is a correct email or sms

The email NOT showing up in this case was by design - if you don't "know" the user, you won't get their login in the returned personal details
cc @puneetlath as we both worked on this project
I believe we should :donothing: here
@lanitochka17 when you created this issue, you mentioned Slack conversation: Yes but you didn't link a slack convo

@Beamanator so do we just need to close this issue then? What are we waiting on?

I agree this isn't a bug and can be closed.

I find it weird that userA doesn't know userB login when he has used this login to create the chat...


Asyncio not retrieving task exceptions

@callumforrester as requested.
When using epicsadapter, following an interrupt, the after_update iterates through records allocated interrupt_records, gets their current value from the device and sets it. The getter is user defined (in the device) the setter uses a pythonSoftIOC default. This can be found in softioc/device.py which defines the processing of epics devices.
On this setting call the following function is called to cast the type 'got' from the tickit device to the one appropriate to that record. Simply:
def _value_to_epics(self, value):
        return self._ctype_(value)

If the value passed to this function from the device is not castable, eg. string -> float, Then it appears to hang the simulation.
If you then attempt to raise another interrupt, the simulation will crash with the error ERROR:asyncio:Task exception was never retrieved.
The rest of the trace:
ERROR:asyncio:Task exception was never retrieved
future: <Task finished name='Task-10' coro=<TcpServer._generate_handle_function.<locals>.handle() done, defined at /workspace/tickit-devices/.venv/lib/python3.9/site-packages/tickit/adapters/servers/tcp.py:79> exception=AttributeError("'MasterScheduler' object has no attribute 'last_time'")>
Traceback (most recent call last):
  File "/workspace/tickit-devices/.venv/lib/python3.9/site-packages/tickit/adapters/servers/tcp.py", line 99, in handle
    tasks.append(asyncio.create_task(reply(await handler(data))))
  File "/workspace/tickit-devices/.venv/lib/python3.9/site-packages/tickit/adapters/composed.py", line 42, in handle_message
    await self.raise_interrupt()
  File "/workspace/tickit-devices/.venv/lib/python3.9/site-packages/tickit/core/components/component.py", line 114, in raise_interrupt
    await self.state_producer.produce(output_topic(self.name), Interrupt(self.name))
  File "/workspace/tickit-devices/.venv/lib/python3.9/site-packages/tickit/core/state_interfaces/internal.py", line 168, in produce
    await self.server.push(topic, Message(value=value))
  File "/workspace/tickit-devices/.venv/lib/python3.9/site-packages/tickit/core/state_interfaces/internal.py", line 64, in push
    await subscriber.add_message(message)
  File "/workspace/tickit-devices/.venv/lib/python3.9/site-packages/tickit/core/state_interfaces/internal.py", line 145, in add_message
    await self.callback(message.value)
  File "/workspace/tickit-devices/.venv/lib/python3.9/site-packages/tickit/core/management/schedulers/base.py", line 73, in handle_message
    await self.schedule_interrupt(message.source)
  File "/workspace/tickit-devices/.venv/lib/python3.9/site-packages/tickit/core/management/schedulers/master.py", line 116, in schedule_interrupt
    + int((time_ns() - self.last_time) * self.simulation_speed)
AttributeError: 'MasterScheduler' object has no attribute 'last_time'

I thought it was curious that the exception (which it does produce) gets lost somewhere down the stack so that asyncio doesn't receive it.

I have found that the same (not so helpful) error message can be produced when sending an interrupting command to a simulated device when there is a typo in the configuration yaml. For example, try misspelling one of the shutters in shutter.yaml and sending T=1 to the device when it's running.

Closed with PR #115


chore: Adding feedback request to contributors bot

I've seen good response rates asking contributors for feedback via G2.
However, this is tricky as it's manual and not all of them are in the Slack.
Solution: Add a simple request to the bot, which tags them when recognizing their work.
Added bonus: +1 to the number of repos I have touched at PostHog so far!

I feel "let us know what you think" is perfectly great, but "submit a review about us on trustpilot" (or any other website) to be kind of pushy by nature.

Agree - 'let us know what you think' is fine with me, but it feels like a bait-and-switch to ask that and then direct people to an external site that hoovers up their personal data (this is mainly why I ignore any feedback requests from products unless they go to the company directly).

OK, it's been consistent feedback that this feels too pushy, even with the softened wording. I'm going to close this, unmerged.


Multiple tab check, to prevent popup

Added a optional feature to check if the session is active in one tab, then do not open the confirmation popup in other inactive tabs. This is helpful if the user switches between tabs he will not be annoyed by the popup, as he was actively using the app in a tab.
Steps:

Open your app in 3 tab
t1, t2, t3
t1 is active , t2, t3 are inactive
now if the new setting 'checkTimeBeforePopup' is set then in the "t2" and "t3" before opening the pop-up timeleft is checked from server and the client side timer is reset

Hey @roshandevadiga it went completely under my radar! Anyways, I don't consider this plugin to be the way to go anymore.
Thanks for your contribution!


Feature/miduweb 475 veranstaltungskachel

As discussed: We need to use the MDX Variables for Distances/ Fonts etc.
Can be done once Access is guaranted


Java interop wasn't support for json only returns

Description:
If Java implementation only return json type then interop failed with below error during the createBirJar phase.
{ballerinax/java}METHOD_SIGNATURE_DOES_NOT_MATCH message=No such Java method

Steps to reproduce:
Affected Versions:
OS, DB, other environment details and versions:
Related Issues (optional):

Suggested Labels (optional):

Suggested Assignees (optional):

The same thing can be observed for XML as well.


Added a fix to overwatch when multiple characters are shooting to ret…

…urn the results correctly.
fixes #75

Pull Request Test Coverage Report for Build 911722121

7 of 7 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.0006%) to 99.459%

Totals

Change from base Build 910704599:
0.0006%

Covered Lines:
1315

Relevant Lines:
1322

💛  - Coveralls


[SKY30-367] adds N/A fallback and filter option for establishment stage column

Substitute this line for a meaningful title for your changes
Overview

adds N/A fallback for undefined values.
adds a N/A option to Establishment Stage filter to be able to filter by this new value.

Designs
Link to the related design prototypes (if applicable)
Testing instructions
Please explain how to test the PR: ID of a dataset, steps to reach the feature, etc.
Feature relevant tickets
https://vizzuality.atlassian.net/browse/SKY30-367

Checklist before submitting

[ ] Meaningful commits and code rebased on develop.

@SARodrigues I am putting this PR on hold as it might be addressed by the science team.


Add Makefile to init template

As mentioned in #6, I added a Makefile to the init template.
I also changed the filename of the test file so that pytest collects it automatically.

Thanks! Looks good, would you mind adding some Makefile documentation on the README?

I added a line to the readme.


i18n iapi

Issue
Closes  #5589: List of missing strings from internal repo
Although the "variable'd strings" issue remain unresolved, we can close the issue since solving that would require messing with the repo.
Notes
"Favorite Five 🖐" -- not sure if this will work well with Transifex.  Let's see how it goes.

If this goes in, we should make another Transifex push


Make ID non-optional in the Consignment domain model

Refactor the Consignment model so that the ID is compulsory. It's not clear why this was an Option in the first place, but removing it makes the code simpler because the deferred resolvers don't need to decide what to do if the value is None.

@techncl This is the refactoring we talked about the other day. I thought I'd try it out while I was waiting for something to build, and it was simpler than I expected!


Remove konflux pipelines, in order to re-install

Goal is to update to latest version

/lgtm
/approve


Higher resolution avatar on /peers.

Currently the avatar URL being returned is the low resolution one. Would it be possible to change this to the higher resolution URL?

Yeah, I believe there are three URLs returned from the steam API, avatar, avatarmedium, and avatarfull


PDF support

The last major feature lacking from vl-convert that is possible with altair_saver and the Vega CLI is PDF export support.  The primary motivating use case for PDF export is to support embedding charts in LaTeX in vector format (LaTeX doesn't support SVG as far as I understand).
Related work
altair_saver accomplishes this using a system web browser and selenium. This approach is not an option for vl-convert because it requires the external system dependency on a web browser, and we're working hard to keep vl-convert a standalone binary without dependencies on system applications or libraries. We also want to keep the core of vl-convert from depending on Python so that it's available as a standalone CLI binary and is easy to wrap in other languages.
The vl2pdf CLI accomplishes this using the node canvas createPDFStream method. Node canvas is not compatible with Deno, so this isn't an option for vl-convert either.
Background
vl-convert uses the Deno JavaScript runtime to export Vega/Vega-Lite charts to SVG images. The resulting SVG images are optionally converted to PNG using the resvg Rust library. resvg depends on an interesting library named usvg. usvg is an SVG simplifier. It converts all SVG constructs into a couple of primitives, the main one being SVG paths.  This simplified SVG is then processed by resvg to render it to a PNG image.
svg2pdf
There is a really compelling Rust library called svg2pdf for converting SVG images to PDF documents. svg2pdf happens to rely on the same usvg library for performing SVG simplification before applying it's own logic to convert the simplified SVG to PDF.  This works great, and the project has an impressive test suite that uses pdfium to convert the resulting PDFs to PNG images for comparison with baselines.
One notable feature of how this process works is that usvg is capable of converting text into geometric paths (and both resvg and svg2pdf take advantage of this). In the case of svg2pdf, this means that the exact geometry of the source font is preserved in the output document without the need to embed the font into the resulting PDF document. The downside of this is that the PDF viewer no longer recognizes text as text, so it's not possible to select and copy it. This also means that it's not possible for screen readers to locate the text.  This is why I've been hesitant to incorporate svg2pdf up to this point.
Way forward
I spent some time this weekend digging into svg2pdf to try to identify the best path forward for adding text selection support to the resulting PDF documents.
The most obvious approach might be to stop the conversion of text to geometric paths and instead use PDF text. I tried this in a branch of svg2pdf, and it wasn't too difficult, but the issue is that for all but the "base fonts" (more on those later) this approach requires embedding the font into the resulting PDF document. This is a really complex process that's not abstracted by the pdf-writer library that svg2pdf depends on. This approach can also significantly increases the PDF document size unless the even more complex process of font subsetting is performed (font subsetting is the process of pruning a font to only include the characters that are actually used in the document).
After groking the complexity of the above approach, I went for a walk, and came up with an alternative. The PDF format specifies that all PDF readers must include built-in support for 14 "base fonts" including Helvetica, Courier, and Times New Roman in the regular, italic, bold, bold italic variants. Suppose we render all text as paths the way svg2pdf currently does, and then overlay the paths with the same text using a base font with opacity 0. This is similar to what OCR software does, where it overlays a scanned image with invisible text that can be searched and selected.
By happy coincidence, Helvetica is the default font used by vl-convert (with fallbacks to Arial and Liberation Sans which have near identical sizing). So in the majority case the overlaid text will be Helvetica and will exactly match the text drawn as paths. When a chart uses a font that is not one of the PDF base fonts, we'll have the task of choosing the "best" base font (and font size) to overlay on top of the text with custom font. I have some ideas on how to do this, and I'm pretty confident that we'll be able to do a good enough job here. And even if the overlaid text doesn't line up exactly, it's still a lot better than nothing as it's still possible to select and copy and for screen readers to find.
This approach avoids the complexity and file size increase of font embedding. After some experimentation, I found that it's also possible to do this today without any changes needed in svg2pdf. (we will need to wait for svg2pdf to be updated to usvg 0.35.0, but that's in progress).
cc some folks who use Vega in LaTeX in case you have feedback on this approach: @domoritz @arvind @kanitw @jheer @joelostblom @nicolaskruchten

I don't have too much technical input on this, but I think your suggested approach sounds feasible and like an effective way to solve the issues you highlighted. I agree that PDF support would be a nice feature to simplify not only for latex users but also those unfamiliar with the svg format.
Is svg2pdf a heavy dependency? It seems to be 7MB when I checked the repo size and vl-convert is only 6MB (but I'm not sure how big a full installation of vl-convert is currently).

Is svg2pdf a heavy dependency?

In terms of the binary itself, vl-convert is ~55MB uncompressed and ~22MB compressed as a wheel. The release compiled svg2pdf lib looks like it's around 2MB uncompressed. And vl-convert already includes some of the dependencies of svg2pdf, so I think the increase will be a very large percentage.

Update
I ended up working out how to do proper font embedding by following the logic in the typst project, which also uses the pdf-writer crate that svg2pdf relies on.  PR is almost ready in https://github.com/vega/vl-convert/pull/97.


XSUAA service instance expected to be same for UI and backend [2]

Hi @nenaraab
Continuing, because the issue got closed
https://github.com/SAP/cloud-security-xsuaa-integration/issues/191
Consider a situation, where the particular backend is offered as Odata Service (Let's say deployed in different account) and people can add it as destination and consume in the UI.
In such scenario, how they can bind to the same service instance ?
How to deal with this scenario ?
Regards
Navin

Hi @navinkrishnan,
of course, in case you like to connect to a remote service this needs to be realized with so-called destination service. Find further information about that here:
https://blogs.sap.com/2018/10/08/using-the-destination-service-in-the-cloud-foundry-environment/
Furthermore, the Cloud SDK does support Client Credentials Authentication for connecting to a destination. Its implementation heavily relies on the platform Destination Service. The online documentation lists Client Certificate Authentication as one of its supported features. For a complete overview visit the SAP Cloud SDK Overview.
Best regards,
Nena


Fixes broken link in Snapshot Testing docs

Summary
Motivation for that change is to make the hyperlink correct.
Test plan
I copied the link to my browser and ensured it's accessible.

@Biki-das done

@Biki-das done

@robdy thanks LGTM!