text:
Godot 4.0.2 locks up when ConfirmationDialog is visible in editor and you change it's parent type

Godot version
4.0.2
System information
Windows 11
Issue description
Godot 4.0.2 locks up when ConfirmationDialog is visible in editor and you change it's parent type.
Forced to end task and lose changes.
Steps to reproduce

New standard/default project
Add Control node
Add ConfirmationDialog as child of Control node
Make the ConfirmationDialog visible
Change the Control type to Node2D
Try to do anything in godot including clicking the X button.

Expected:

Should not lock up godot

Actual:

Godot completely locked up but still responsive.

Assuming it's some sort of modal dialog oopsy.
Minimal reproduction project
confirmation-dialog-freeze.zip

The father AcceptDialog  the same, the deadlock also happens on Linux + GitHub tip:
ctrl+c

Process 137980 stopped
* thread #1, name = 'godot.linuxbsd.', stop reason = signal SIGSTOP
    frame #0: 0x00007ffff7d1523f libc.so.6`__GI___clock_nanosleep(clock_id=0, flags=0, req=0x00007fffffffd6c0, rem=0x00007fffffffd6d0) at clock_nanosleep.c:78:7
(lldb) bl all
error: 'bl' is not a valid command.
(lldb) bt all
* thread #1, name = 'godot.linuxbsd.', stop reason = signal SIGSTOP
  * frame #0: 0x00007ffff7d1523f libc.so.6`__GI___clock_nanosleep(clock_id=0, flags=0, req=0x00007fffffffd6c0, rem=0x00007fffffffd6d0) at clock_nanosleep.c:78:7
    frame #1: 0x00007ffff7d1aec7 libc.so.6`__GI___nanosleep(requested_time=0x00007fffffffd6c0, remaining=0x00007fffffffd6d0) at nanosleep.c:27:13
    frame #2: 0x00005555577a5cea godot.linuxbsd.editor.dev.x86_64`OS_Unix::delay_usec(this=<unavailable>, p_usec=<unavailable>) const at os_unix.cpp:273:9
    frame #3: 0x000055555a122909 godot.linuxbsd.editor.dev.x86_64`OS::add_frame_delay(this=0x00007fffffffd858, p_can_draw=<unavailable>) at os.cpp:564:4
    frame #4: 0x0000555556ade195 godot.linuxbsd.editor.dev.x86_64`Main::iteration() at main.cpp:3322:23
    frame #5: 0x0000555556a32e4d godot.linuxbsd.editor.dev.x86_64`OS_LinuxBSD::run(this=0x00007fffffffd858) at os_linuxbsd.cpp:889:7
    frame #6: 0x0000555556a2972b godot.linuxbsd.editor.dev.x86_64`main(argc=<unavailable>, argv=<unavailable>) at godot_linuxbsd.cpp:73:6
    frame #7: 0x00007ffff7c5c083 libc.so.6`__libc_start_main(main=(godot.linuxbsd.editor.dev.x86_64`main at godot_linuxbsd.cpp:43), argc=2, argv=0x00007fffffffdd88, init=<unavailable>, fini=<unavailable>, rtld_fini=<unavailable>, stack_end=0x00007fffffffdd78) at libc-start.c:308:16
    frame #8: 0x0000555556a2959e godot.linuxbsd.editor.dev.x86_64`_start + 46
  thread #2, name = 'godot.linuxbsd.'
    frame #0: 0x00007ffff7f8e376 libpthread.so.0`__pthread_cond_wait at futex-internal.h:183:13
    frame #1: 0x00007ffff7f8e359 libpthread.so.0`__pthread_cond_wait at pthread_cond_wait.c:508:14
    frame #2: 0x00007ffff7f8e290 libpthread.so.0`__pthread_cond_wait(cond=0x000055555d73c1e0, mutex=0x000055555d73c1b8) at pthread_cond_wait.c:647:10
    frame #3: 0x000055555a8fec00 godot.linuxbsd.editor.dev.x86_64`std::condition_variable::wait(std::unique_lock<std::mutex>&) + 16
    frame #4: 0x000055555a22c435 godot.linuxbsd.editor.dev.x86_64`_IP_ResolverPrivate::_thread_function(void*) [inlined] Semaphore::wait(this=0x000055555d73c1b8) const at semaphore.h:56:14
    frame #5: 0x000055555a22c3f8 godot.linuxbsd.editor.dev.x86_64`_IP_ResolverPrivate::_thread_function(self=0x000055555d73a190) at ip.cpp:115:13
    frame #6: 0x000055555a122de1 godot.linuxbsd.editor.dev.x86_64`Thread::callback(p_caller_id=<unavailable>, p_settings=<unavailable>, p_callback=(godot.linuxbsd.editor.dev.x86_64`_IP_ResolverPrivate::_thread_function(void*) [inlined] std::__atomic_base<bool>::load(std::memory_order) const at ip.cpp:111
godot.linuxbsd.editor.dev.x86_64`_IP_ResolverPrivate::_thread_function(void*) [inlined] std::atomic<bool>::load(std::memory_order) const at atomic:113:22
godot.linuxbsd.editor.dev.x86_64`_IP_ResolverPrivate::_thread_function(void*) [inlined] SafeFlag::is_set() const at safe_refcount.h:147:15
godot.linuxbsd.editor.dev.x86_64`_IP_ResolverPrivate::_thread_function(void*) at ip.cpp:114:29), p_userdata=0x000055555d73a190)(void*), void*) at thread.cpp:61:3
    frame #7: 0x000055555a974d74 godot.linuxbsd.editor.dev.x86_64`execute_native_thread_routine + 20
    frame #8: 0x00007ffff7f87609 libpthread.so.0`start_thread(arg=<unavailable>) at pthread_create.c:477:8
    frame #9: 0x00007ffff7d57133 libc.so.6`__clone at clone.S:95
  thread #3, name = 'godot.linuxbsd.'
    frame #0: 0x00007ffff7f8e376 libpthread.so.0`__pthread_cond_wait at futex-internal.h:183:13
    frame #1: 0x00007ffff7f8e359 libpthread.so.0`__pthread_cond_wait at pthread_cond_wait.c:508:14
    frame #2: 0x00007ffff7f8e290 libpthread.so.0`__pthread_cond_wait(cond=0x000055555d58df48, mutex=0x000055555d58df20) at pthread_cond_wait.c:647:10
    frame #3: 0x000055555a8fec00 godot.linuxbsd.editor.dev.x86_64`std::condition_variable::wait(std::unique_lock<std::mutex>&) + 16
    frame #4: 0x000055555a6299fb godot.linuxbsd.editor.dev.x86_64`WorkerThreadPool::_thread_function(void*) [inlined] Semaphore::wait(this=<unavailable>) const at semaphore.h:56:14
    frame #5: 0x000055555a6299af godot.linuxbsd.editor.dev.x86_64`WorkerThreadPool::_thread_function(p_user=<unavailable>) at worker_thread_pool.cpp:154:39
    frame #6: 0x000055555a122de1 godot.linuxbsd.editor.dev.x86_64`Thread::callback(p_caller_id=<unavailable>, p_settings=<unavailable>, p_callback=(godot.linuxbsd.editor.dev.x86_64`WorkerThreadPool::_thread_function(void*) at worker_thread_pool.cpp:152), p_userdata=0x000055555d7ada50)(void*), void*) at thread.cpp:61:3
    frame #7: 0x000055555a974d74 godot.linuxbsd.editor.dev.x86_64`execute_native_thread_routine + 20
    frame #8: 0x00007ffff7f87609 libpthread.so.0`start_thread(arg=<unavailable>) at pthread_create.c:477:8
    frame #9: 0x00007ffff7d57133 libc.so.6`__clone at clone.S:95
  thread #4, name = 'godot.linuxbsd.'
    frame #0: 0x00007ffff7f8e376 libpthread.so.0`__pthread_cond_wait at futex-internal.h:183:13
    frame #1: 0x00007ffff7f8e359 libpthread.so.0`__pthread_cond_wait at pthread_cond_wait.c:508:14
    frame #2: 0x00007ffff7f8e290 libpthread.so.0`__pthread_cond_wait(cond=0x000055555d58df48, mutex=0x000055555d58df20) at pthread_cond_wait.c:647:10
    frame #3: 0x000055555a8fec00 godot.linuxbsd.editor.dev.x86_64`std::condition_variable::wait(std::unique_lock<std::mutex>&) + 16
    frame #4: 0x000055555a6299fb godot.linuxbsd.editor.dev.x86_64`WorkerThreadPool::_thread_function(void*) [inlined] Semaphore::wait(this=<unavailable>) const at semaphore.h:56:14
    frame #5: 0x000055555a6299af godot.linuxbsd.editor.dev.x86_64`WorkerThreadPool::_thread_function(p_user=<unavailable>) at worker_thread_pool.cpp:154:39
    frame #6: 0x000055555a122de1 godot.linuxbsd.editor.dev.x86_64`Thread::callback(p_caller_id=<unavailable>, p_settings=<unavailable>, p_callback=(godot.linuxbsd.editor.dev.x86_64`WorkerThreadPool::_thread_function(void*) at worker_thread_pool.cpp:152), p_userdata=0x000055555d7ada68)(void*), void*) at thread.cpp:61:3
    frame #7: 0x000055555a974d74 godot.linuxbsd.editor.dev.x86_64`execute_native_thread_routine + 20
    frame #8: 0x00007ffff7f87609 libpthread.so.0`start_thread(arg=<unavailable>) at pthread_create.c:477:8
    frame #9: 0x00007ffff7d57133 libc.so.6`__clone at clone.S:95
  thread #5, name = 'godot.l:disk$0'
    frame #0: 0x00007ffff7f8e376 libpthread.so.0`__pthread_cond_wait at futex-internal.h:183:13
    frame #1: 0x00007ffff7f8e359 libpthread.so.0`__pthread_cond_wait at pthread_cond_wait.c:508:14
    frame #2: 0x00007ffff7f8e290 libpthread.so.0`__pthread_cond_wait(cond=0x000055555dc94e30, mutex=0x000055555dc94e08) at pthread_cond_wait.c:647:10
    frame #3: 0x00007ffff426e81d libvulkan_radeon.so`___lldb_unnamed_symbol8708 + 13
    frame #4: 0x00007ffff42418bb libvulkan_radeon.so`___lldb_unnamed_symbol7982 + 139
    frame #5: 0x00007ffff426e73b libvulkan_radeon.so`___lldb_unnamed_symbol8701 + 27
    frame #6: 0x00007ffff7f87609 libpthread.so.0`start_thread(arg=<unavailable>) at pthread_create.c:477:8
    frame #7: 0x00007ffff7d57133 libc.so.6`__clone at clone.S:95
  thread #7, name = 'godot.linuxbsd.'
    frame #0: 0x00007ffff7d4cfcb libc.so.6`__GI___select(nfds=4, readfds=0x00007fffe318cd38, writefds=0x0000000000000000, exceptfds=0x0000000000000000, timeout=0x00007fffe318cd28) at select.c:41:10
    frame #1: 0x0000555556a3ea07 godot.linuxbsd.editor.dev.x86_64`DisplayServerX11::_wait_for_events(this=0x000055555dc0d850) const at display_server_x11.cpp:3641:22
    frame #2: 0x0000555556a4f503 godot.linuxbsd.editor.dev.x86_64`DisplayServerX11::_poll_events(this=0x000055555dc0d850) at display_server_x11.cpp:3657:3
    frame #3: 0x0000555556a4f4b5 godot.linuxbsd.editor.dev.x86_64`DisplayServerX11::_poll_events_thread(ud=<unavailable>) at display_server_x11.cpp:3619:18 [artificial]
    frame #4: 0x000055555a122de1 godot.linuxbsd.editor.dev.x86_64`Thread::callback(p_caller_id=<unavailable>, p_settings=<unavailable>, p_callback=(godot.linuxbsd.editor.dev.x86_64`DisplayServerX11::_poll_events_thread(void*) at display_server_x11.cpp:3619:18), p_userdata=0x000055555dc0d850)(void*), void*) at thread.cpp:61:3
    frame #5: 0x000055555a974d74 godot.linuxbsd.editor.dev.x86_64`execute_native_thread_routine + 20
    frame #6: 0x00007ffff7f87609 libpthread.so.0`start_thread(arg=<unavailable>) at pthread_create.c:477:8
    frame #7: 0x00007ffff7d57133 libc.so.6`__clone at clone.S:95
  thread #8, name = 'godot.linuxbsd.'
    frame #0: 0x00007ffff7d1523f libc.so.6`__GI___clock_nanosleep(clock_id=0, flags=0, req=0x00007fffdbffecb0, rem=0x0000000000000000) at clock_nanosleep.c:78:7
    frame #1: 0x00007ffff7d1aec7 libc.so.6`__GI___nanosleep(requested_time=0x00007fffdbffecb0, remaining=0x0000000000000000) at nanosleep.c:27:13
    frame #2: 0x00007ffff7d4d85f libc.so.6`usleep(useconds=50000) at usleep.c:32:10
    frame #3: 0x0000555556a37a6a godot.linuxbsd.editor.dev.x86_64`JoypadLinux::monitor_joypads(this=0x000055555f3e9370, p_udev=0x00007fffd4000b60) at joypad_linux.cpp:208:3
    frame #4: 0x0000555556a376b3 godot.linuxbsd.editor.dev.x86_64`JoypadLinux::monitor_joypads_thread_run(this=0x000055555f3e9370) at joypad_linux.cpp:129:4
    frame #5: 0x0000555556a3742a godot.linuxbsd.editor.dev.x86_64`JoypadLinux::monitor_joypads_thread_func(p_user=<unavailable>) at joypad_linux.cpp:115:8 [artificial]
    frame #6: 0x000055555a122de1 godot.linuxbsd.editor.dev.x86_64`Thread::callback(p_caller_id=<unavailable>, p_settings=<unavailable>, p_callback=(godot.linuxbsd.editor.dev.x86_64`JoypadLinux::monitor_joypads_thread_func(void*) at joypad_linux.cpp:113:6), p_userdata=0x000055555f3e9370)(void*), void*) at thread.cpp:61:3
    frame #7: 0x000055555a974d74 godot.linuxbsd.editor.dev.x86_64`execute_native_thread_routine + 20
    frame #8: 0x00007ffff7f87609 libpthread.so.0`start_thread(arg=<unavailable>) at pthread_create.c:477:8
    frame #9: 0x00007ffff7d57133 libc.so.6`__clone at clone.S:95
  thread #9, name = 'godot.linuxbsd.'
    frame #0: 0x00007ffff7d1523f libc.so.6`__GI___clock_nanosleep(clock_id=0, flags=0, req=0x00007fffdb7fdd70, rem=0x0000000000000000) at clock_nanosleep.c:78:7
    frame #1: 0x00007ffff7d1aec7 libc.so.6`__GI___nanosleep(requested_time=0x00007fffdb7fdd70, remaining=0x0000000000000000) at nanosleep.c:27:13
    frame #2: 0x00007ffff7d4d85f libc.so.6`usleep(useconds=10000) at usleep.c:32:10
    frame #3: 0x0000555556a38db0 godot.linuxbsd.editor.dev.x86_64`JoypadLinux::joypad_events_thread_run(this=0x000055555f3e9370) at joypad_linux.cpp:470:4
    frame #4: 0x0000555556a3743a godot.linuxbsd.editor.dev.x86_64`JoypadLinux::joypad_events_thread_func(p_user=<unavailable>) at joypad_linux.cpp:443:8 [artificial]
    frame #5: 0x000055555a122de1 godot.linuxbsd.editor.dev.x86_64`Thread::callback(p_caller_id=<unavailable>, p_settings=<unavailable>, p_callback=(godot.linuxbsd.editor.dev.x86_64`JoypadLinux::joypad_events_thread_func(void*) at joypad_linux.cpp:441:6), p_userdata=0x000055555f3e9370)(void*), void*) at thread.cpp:61:3
    frame #6: 0x000055555a974d74 godot.linuxbsd.editor.dev.x86_64`execute_native_thread_routine + 20
    frame #7: 0x00007ffff7f87609 libpthread.so.0`start_thread(arg=<unavailable>) at pthread_create.c:477:8
    frame #8: 0x00007ffff7d57133 libc.so.6`__clone at clone.S:95
  thread #10, name = 'godot.linuxbsd.'
    frame #0: 0x00007ffff7d1523f libc.so.6`__GI___clock_nanosleep(clock_id=0, flags=0, req=0x00007fffdadf6d20, rem=0x00007fffdadf6d30) at clock_nanosleep.c:78:7
    frame #1: 0x00007ffff7d1aec7 libc.so.6`__GI___nanosleep(requested_time=0x00007fffdadf6d20, remaining=0x00007fffdadf6d30) at nanosleep.c:27:13
    frame #2: 0x00005555577a5cea godot.linuxbsd.editor.dev.x86_64`OS_Unix::delay_usec(this=<unavailable>, p_usec=<unavailable>) const at os_unix.cpp:273:9
    frame #3: 0x00005555577b6679 godot.linuxbsd.editor.dev.x86_64`AudioDriverPulseAudio::thread_func(p_udata=0x00007fffffffda28) at audio_driver_pulseaudio.cpp:587:25
    frame #4: 0x000055555a122de1 godot.linuxbsd.editor.dev.x86_64`Thread::callback(p_caller_id=<unavailable>, p_settings=<unavailable>, p_callback=(godot.linuxbsd.editor.dev.x86_64`AudioDriverPulseAudio::thread_func(void*) at audio_driver_pulseaudio.cpp:397), p_userdata=0x00007fffffffda28)(void*), void*) at thread.cpp:61:3
    frame #5: 0x000055555a974d74 godot.linuxbsd.editor.dev.x86_64`execute_native_thread_routine + 20
    frame #6: 0x00007ffff7f87609 libpthread.so.0`start_thread(arg=<unavailable>) at pthread_create.c:477:8
    frame #7: 0x00007ffff7d57133 libc.so.6`__clone at clone.S:95
  thread #11, name = 'godot.linuxbsd.'
    frame #0: 0x00007ffff7f8e376 libpthread.so.0`__pthread_cond_wait at futex-internal.h:183:13
    frame #1: 0x00007ffff7f8e359 libpthread.so.0`__pthread_cond_wait at pthread_cond_wait.c:508:14
    frame #2: 0x00007ffff7f8e290 libpthread.so.0`__pthread_cond_wait(cond=0x000055555f09bab8, mutex=0x000055555f09ba90) at pthread_cond_wait.c:647:10
    frame #3: 0x000055555a8fec00 godot.linuxbsd.editor.dev.x86_64`std::condition_variable::wait(std::unique_lock<std::mutex>&) + 16
    frame #4: 0x00005555575d3f4b godot.linuxbsd.editor.dev.x86_64`tvg::TaskQueue::pop(this=0x000055555f09ba40, task=0x00007fffda5f5dd0) at tvgTaskScheduler.cpp:79:19
    frame #5: 0x00005555575d3da3 godot.linuxbsd.editor.dev.x86_64`tvg::TaskSchedulerImpl::run(this=0x000055555fe51cd0, i=0) at tvgTaskScheduler.cpp:137:44
    frame #6: 0x000055555a974d74 godot.linuxbsd.editor.dev.x86_64`execute_native_thread_routine + 20
    frame #7: 0x00007ffff7f87609 libpthread.so.0`start_thread(arg=<unavailable>) at pthread_create.c:477:8
    frame #8: 0x00007ffff7d57133 libc.so.6`__clone at clone.S:95
  thread #12, name = 'godot.linuxbsd.'
    frame #0: 0x00007ffff7d1523f libc.so.6`__GI___clock_nanosleep(clock_id=0, flags=0, req=0x00007fffb3ffebf0, rem=0x00007fffb3ffec00) at clock_nanosleep.c:78:7
    frame #1: 0x00007ffff7d1aec7 libc.so.6`__GI___nanosleep(requested_time=0x00007fffb3ffebf0, remaining=0x00007fffb3ffec00) at nanosleep.c:27:13
    frame #2: 0x00005555577a5cea godot.linuxbsd.editor.dev.x86_64`OS_Unix::delay_usec(this=<unavailable>, p_usec=<unavailable>) const at os_unix.cpp:273:9
    frame #3: 0x00005555583dfb72 godot.linuxbsd.editor.dev.x86_64`EditorExportPlatformAndroid::_check_for_changes_poll_thread(ud=0x00007fffb4038160) at export_plugin.cpp:404:25
    frame #4: 0x000055555a122de1 godot.linuxbsd.editor.dev.x86_64`Thread::callback(p_caller_id=<unavailable>, p_settings=<unavailable>, p_callback=(godot.linuxbsd.editor.dev.x86_64`EditorExportPlatformAndroid::_check_for_changes_poll_thread(void*) [inlined] std::__atomic_base<bool>::load(std::memory_order) const at export_plugin.cpp:259
godot.linuxbsd.editor.dev.x86_64`EditorExportPlatformAndroid::_check_for_changes_poll_thread(void*) [inlined] std::atomic<bool>::load(std::memory_order) const at atomic:113:22
godot.linuxbsd.editor.dev.x86_64`EditorExportPlatformAndroid::_check_for_changes_poll_thread(void*) [inlined] SafeFlag::is_set() const at safe_refcount.h:147:15
godot.linuxbsd.editor.dev.x86_64`EditorExportPlatformAndroid::_check_for_changes_poll_thread(void*) at export_plugin.cpp:262:27), p_userdata=0x00007fffb4038160)(void*), void*) at thread.cpp:61:3
    frame #5: 0x000055555a974d74 godot.linuxbsd.editor.dev.x86_64`execute_native_thread_routine + 20
    frame #6: 0x00007ffff7f87609 libpthread.so.0`start_thread(arg=<unavailable>) at pthread_create.c:477:8
    frame #7: 0x00007ffff7d57133 libc.so.6`__clone at clone.S:95
  thread #13, name = 'godot.linuxbsd.'
    frame #0: 0x00007ffff7d1523f libc.so.6`__GI___clock_nanosleep(clock_id=0, flags=0, req=0x00007fffb37fdd70, rem=0x00007fffb37fdd80) at clock_nanosleep.c:78:7
    frame #1: 0x00007ffff7d1aec7 libc.so.6`__GI___nanosleep(requested_time=0x00007fffb37fdd70, remaining=0x00007fffb37fdd80) at nanosleep.c:27:13
    frame #2: 0x00005555577a5cea godot.linuxbsd.editor.dev.x86_64`OS_Unix::delay_usec(this=<unavailable>, p_usec=<unavailable>) const at os_unix.cpp:273:9
    frame #3: 0x000055555843b2c6 godot.linuxbsd.editor.dev.x86_64`EditorExportPlatformIOS::_check_for_changes_poll_thread(ud=0x0000555560e8ba90) at export_plugin.h:169:26
    frame #4: 0x000055555a122de1 godot.linuxbsd.editor.dev.x86_64`Thread::callback(p_caller_id=<unavailable>, p_settings=<unavailable>, p_callback=(godot.linuxbsd.editor.dev.x86_64`EditorExportPlatformIOS::_check_for_changes_poll_thread(void*) [inlined] std::__atomic_base<bool>::load(std::memory_order) const at export_plugin.h:144
godot.linuxbsd.editor.dev.x86_64`EditorExportPlatformIOS::_check_for_changes_poll_thread(void*) [inlined] std::atomic<bool>::load(std::memory_order) const at atomic:113:22
godot.linuxbsd.editor.dev.x86_64`EditorExportPlatformIOS::_check_for_changes_poll_thread(void*) [inlined] SafeFlag::is_set() const at safe_refcount.h:147:15
godot.linuxbsd.editor.dev.x86_64`EditorExportPlatformIOS::_check_for_changes_poll_thread(void*) at export_plugin.h:147:28), p_userdata=0x0000555560e8ba90)(void*), void*) at thread.cpp:61:3
    frame #5: 0x000055555a974d74 godot.linuxbsd.editor.dev.x86_64`execute_native_thread_routine + 20
    frame #6: 0x00007ffff7f87609 libpthread.so.0`start_thread(arg=<unavailable>) at pthread_create.c:477:8
    frame #7: 0x00007ffff7d57133 libc.so.6`__clone at clone.S:95
  thread #14, name = 'godot.linuxbsd.'
    frame #0: 0x00007ffff7d1523f libc.so.6`__GI___clock_nanosleep(clock_id=0, flags=0, req=0x00007fffb2ffcda0, rem=0x00007fffb2ffcdb0) at clock_nanosleep.c:78:7
    frame #1: 0x00007ffff7d1aec7 libc.so.6`__GI___nanosleep(requested_time=0x00007fffb2ffcda0, remaining=0x00007fffb2ffcdb0) at nanosleep.c:27:13
    frame #2: 0x00005555577a5cea godot.linuxbsd.editor.dev.x86_64`OS_Unix::delay_usec(this=<unavailable>, p_usec=<unavailable>) const at os_unix.cpp:273:9
    frame #3: 0x00005555584a422f godot.linuxbsd.editor.dev.x86_64`EditorExportPlatformWeb::_server_thread_poll(data=0x00005555606f1c70) at export_plugin.cpp:651:24
    frame #4: 0x000055555a122de1 godot.linuxbsd.editor.dev.x86_64`Thread::callback(p_caller_id=<unavailable>, p_settings=<unavailable>, p_callback=(godot.linuxbsd.editor.dev.x86_64`EditorExportPlatformWeb::_server_thread_poll(void*) at export_plugin.cpp:648), p_userdata=0x00005555606f1c70)(void*), void*) at thread.cpp:61:3
    frame #5: 0x000055555a974d74 godot.linuxbsd.editor.dev.x86_64`execute_native_thread_routine + 20
    frame #6: 0x00007ffff7f87609 libpthread.so.0`start_thread(arg=<unavailable>) at pthread_create.c:477:8
    frame #7: 0x00007ffff7d57133 libc.so.6`__clone at clone.S:95
  thread #15, name = 'godot.linuxbsd.'
    frame #0: 0x00007ffff7d1523f libc.so.6`__GI___clock_nanosleep(clock_id=0, flags=0, req=0x00007fffd9df4d60, rem=0x00007fffd9df4d70) at clock_nanosleep.c:78:7
    frame #1: 0x00007ffff7d1aec7 libc.so.6`__GI___nanosleep(requested_time=0x00007fffd9df4d60, remaining=0x00007fffd9df4d70) at nanosleep.c:27:13
    frame #2: 0x00005555577a5cea godot.linuxbsd.editor.dev.x86_64`OS_Unix::delay_usec(this=<unavailable>, p_usec=<unavailable>) const at os_unix.cpp:273:9
    frame #3: 0x00005555586b54c6 godot.linuxbsd.editor.dev.x86_64`EditorFileServer::_thread_start(s=0x000055556011a3f0) at editor_file_server.cpp:293:24
    frame #4: 0x000055555a122de1 godot.linuxbsd.editor.dev.x86_64`Thread::callback(p_caller_id=<unavailable>, p_settings=<unavailable>, p_callback=(godot.linuxbsd.editor.dev.x86_64`EditorFileServer::_thread_start(void*) at editor_file_server.cpp:259), p_userdata=0x000055556011a3f0)(void*), void*) at thread.cpp:61:3
    frame #5: 0x000055555a974d74 godot.linuxbsd.editor.dev.x86_64`execute_native_thread_routine + 20
    frame #6: 0x00007ffff7f87609 libpthread.so.0`start_thread(arg=<unavailable>) at pthread_create.c:477:8
    frame #7: 0x00007ffff7d57133 libc.so.6`__clone at clone.S:95
  thread #16, name = 'godot.linuxbsd.'
    frame #0: 0x00007ffff7f8e376 libpthread.so.0`__pthread_cond_wait at futex-internal.h:183:13
    frame #1: 0x00007ffff7f8e359 libpthread.so.0`__pthread_cond_wait at pthread_cond_wait.c:508:14
    frame #2: 0x00007ffff7f8e290 libpthread.so.0`__pthread_cond_wait(cond=0x000055556df8c0b0, mutex=0x000055556df8c088) at pthread_cond_wait.c:647:10
    frame #3: 0x000055555a8fec00 godot.linuxbsd.editor.dev.x86_64`std::condition_variable::wait(std::unique_lock<std::mutex>&) + 16
    frame #4: 0x00005555583d75e8 godot.linuxbsd.editor.dev.x86_64`TilesEditorPlugin::_thread() [inlined] Semaphore::wait(this=0x000055556df8c088) const at semaphore.h:56:14
    frame #5: 0x00005555583d7593 godot.linuxbsd.editor.dev.x86_64`TilesEditorPlugin::_thread(this=0x000055556df8b9f0) at tiles_editor_plugin.cpp:68:23
    frame #6: 0x00005555583d74a5 godot.linuxbsd.editor.dev.x86_64`TilesEditorPlugin::_thread_func(ud=<unavailable>) at tiles_editor_plugin.cpp:62:6 [artificial]
    frame #7: 0x000055555a122de1 godot.linuxbsd.editor.dev.x86_64`Thread::callback(p_caller_id=<unavailable>, p_settings=<unavailable>, p_callback=(godot.linuxbsd.editor.dev.x86_64`TilesEditorPlugin::_thread_func(void*) at tiles_editor_plugin.cpp:62:6), p_userdata=0x000055556df8b9f0)(void*), void*) at thread.cpp:61:3
    frame #8: 0x000055555a974d74 godot.linuxbsd.editor.dev.x86_64`execute_native_thread_routine + 20
    frame #9: 0x00007ffff7f87609 libpthread.so.0`start_thread(arg=<unavailable>) at pthread_create.c:477:8
    frame #10: 0x00007ffff7d57133 libc.so.6`__clone at clone.S:95
  thread #17, name = 'godot.linuxbsd.'
    frame #0: 0x00007ffff7f8e376 libpthread.so.0`__pthread_cond_wait at futex-internal.h:183:13
    frame #1: 0x00007ffff7f8e359 libpthread.so.0`__pthread_cond_wait at pthread_cond_wait.c:508:14
    frame #2: 0x00007ffff7f8e290 libpthread.so.0`__pthread_cond_wait(cond=0x0000555560ecfd10, mutex=0x0000555560ecfce8) at pthread_cond_wait.c:647:10
    frame #3: 0x000055555a8fec00 godot.linuxbsd.editor.dev.x86_64`std::condition_variable::wait(std::unique_lock<std::mutex>&) + 16
    frame #4: 0x0000555557b311f5 godot.linuxbsd.editor.dev.x86_64`EditorResourcePreview::_thread() [inlined] Semaphore::wait(this=0x0000555560ecfce8) const at semaphore.h:56:14
    frame #5: 0x0000555557b311b8 godot.linuxbsd.editor.dev.x86_64`EditorResourcePreview::_thread(this=0x0000555560ecf8e0) at editor_resource_preview.cpp:326:15
    frame #6: 0x0000555557b31155 godot.linuxbsd.editor.dev.x86_64`EditorResourcePreview::_thread_func(ud=<unavailable>) at editor_resource_preview.cpp:99:7 [artificial]
    frame #7: 0x000055555a122de1 godot.linuxbsd.editor.dev.x86_64`Thread::callback(p_caller_id=<unavailable>, p_settings=<unavailable>, p_callback=(godot.linuxbsd.editor.dev.x86_64`EditorResourcePreview::_thread_func(void*) at editor_resource_preview.cpp:99:7), p_userdata=0x0000555560ecf8e0)(void*), void*) at thread.cpp:61:3
    frame #8: 0x000055555a974d74 godot.linuxbsd.editor.dev.x86_64`execute_native_thread_routine + 20
    frame #9: 0x00007ffff7f87609 libpthread.so.0`start_thread(arg=<unavailable>) at pthread_create.c:477:8
    frame #10: 0x00007ffff7d57133 libc.so.6`__clone at clone.S:95
  thread #18, name = 'WSI swapchain q'
    frame #0: 0x00007ffff7f8e7d1 libpthread.so.0`__pthread_cond_timedwait at futex-internal.h:320:13
    frame #1: 0x00007ffff7f8e7aa libpthread.so.0`__pthread_cond_timedwait at pthread_cond_wait.c:520:11
    frame #2: 0x00007ffff7f8e6d0 libpthread.so.0`__pthread_cond_timedwait(cond=0x0000555577181c68, mutex=0x0000555577181c40, abstime=0x00007fffe398dde0) at pthread_cond_wait.c:665:10
    frame #3: 0x00007ffff41cbb81 libvulkan_radeon.so`___lldb_unnamed_symbol6530 + 257
    frame #4: 0x00007ffff7f87609 libpthread.so.0`start_thread(arg=<unavailable>) at pthread_create.c:477:8
    frame #5: 0x00007ffff7d57133 libc.so.6`__clone at clone.S:95

Seems to be a duplicate of #68575.

...and your PR fixes it :-)

Duplicate of https://github.com/godotengine/godot/issues/68575.

authors: Calinou Rindbee capnm graydwarf


text:
simple 2D (pong) game guide docs suggestion

IMHO, I don't think that the step-by-step intro to godot docs should assume the reader has any experience with Python. Whilst this page:
http://docs.godotengine.org/en/stable/tutorials/step_by_step/simple_2d_game.html
Does a good job of explaining each step of building up the script, it doesn't include a complete script code listing and nor does it explain that every line of code printed after
func _process(delta):
Should be indented so as to be part of the _process function. Whilst this may be obvious to those who have experience with python, it likely won't be so obvious to those who don't.

Could you open this issue on the docs repository instead? https://github.com/godotengine/godot-docs

I didn't know it had a separate repo. Will do.

source: gharchive/issue

authors: akien-mga danboid

repo: godotengine/godot

license: MIT

license_type: permissive

license_source: github-api


text:
"W" Key Acting VERY Strange with Input Actions While Holding CTRL

Tested versions

Reproduceable In: v4.2.2.stable.official [15073afe3]

System information
Godot v4.2.2.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1070 (NVIDIA; 31.0.15.4629) - AMD Ryzen 9 5900X 12-Core Processor (24 Threads)
Issue description
Before I go on: This is only SOMETIMES happening to me and for the moment it seems entirely random each time I boot up the Godot Engine development environment as to if it will or won't happen. If the problem does occur it will ALWAYS occur until I close the Godot Engine entirely, then it seems to be another roll of the dice when I start it back up.
Basically, when this issue occurs, if you're holding down either CTRL key on the keyboard and attempt to push the W key to trigger an Input Action, it will not occur, though the problem is actually a little more involved depending on which keys you press/release in what order:
Press W: Input action occurs as intended.
Hold CTRL -> Press W: Nothing happens.
Hold CTRL -> Hold W -> Release CTRL: Nothing happens for about half a second, then the input action occurs.
Hold CTRL -> Hold W -> Quickly Release CTRL, Hold CTRL, Release CTRL: Nothing happens even though you're now holding W and not CTRL.
This problem seems to ONLY affect the W key. I haven't tested all 100+ keys on the keyboard but I can confirm the other 25 letters do not have this issue.
Steps to reproduce
At present it seems entirely random if this problem will occur or not upon starting the Godot Engine. There's almost certainly a reason but I can't even remotely figure out what it is. The problem WILL persist until completely shutting down the Godot Engine; even going back to the project list doesn't resolve it.
Minimal reproduction project (MRP)

Start a new project.
Make a 2D scene and add a Sprite2D object using the default icon.svg included in the project.
Open your Input Map and add in a new action which uses the W key on the keyboard. For the code below I named this action "W Key".
Attach a script to the Node2D for the scene and give it the following:

extends Node2D

func _process(delta):
	if Input.is_action_pressed("W Key"):
		$Sprite2D.set_visible(true)
	else:
		$Sprite2D.set_visible(false)

Now just run the project. Pressing W should theoretically always make the sprite appear but if this problem is occurring, holding either CTRL will prevent the W key from doing anything, releasing CTRL while holding W will make the sprite appear half a second later, and holding CTRL, then holding W, then releasing and quickly tapping and releasing CTRL again should prevent the sprite from appearing at all until you release W and try pressing it again.

Do you have languages installed that use Input Method Editor?

To add to @huwpascoe's comment, also check if you have sticky keys or slow keys enabled in Windows' accessibility settings.

I do have the Japanese language installed which uses IME, but I rarely ever turn it on. I looked through my Windows settings just now to see if there's any hotkeys associated with the languages options but they're all blank, so I don't understand why that would have an effect on the W key specifically?
Also, ALL accessibility keys are turned off because you really can't have a gaming computer with those enabled unless you never touch the keyboard! That said, I do not have an option anywhere for "Slow Keys". If I try to search for it Windows brings me to the rest of the accessibility key settings and it's not in there.

OK nevermind, I finally found another game this occurs in which is NOT a Godot Engine game, meaning it's not a Godot Engine problem and thus something I need to figure out on my own. It's weird that it's so random though. :/

authors: Calinou Pixelmusement huwpascoe


text:
one property string in TileSet editor, "Physics Layer %d", is not got translated

Tested versions

since 4.0
available in 4.4.dev4
tested only for windows

System information
Windows
Issue description
https://github.com/godotengine/godot/blob/master/editor/plugins/tiles/tile_set_atlas_source_editor.cpp#L742
For some reason, the string "Physics Layer %d" is not translated when the Editor is compiled. I tested in both Turkish and Spanish languages, both having a translation for it older than a year.

Steps to reproduce

open the editor in a language other than English, start a new empty project
add a new TileMap or TileMapLayer
set a new TileSet
add a new Physics Layer
under TileSet editor, add a tile sheet, let it auto make an atlas
click on "select", select a tile
expand physics property to see this string not translated

Minimal reproduction project (MRP)
same as above

As an addendum, none of the layers in that specific section of the TileSet editor are localized.

As an addendum, none of the layers in that specific section of the TileSet editor are localized. I'm not sure if they easily can be, at the moment.

At least, "Navigation Layer %d"  and "Occlusion Layer %d"  are other strings.
I am translating documentation, and done with parts other than tutorials section (makes about 30%). now I went ahead with 2D tutorial, and this is the first one I noticed so far. Maybe a problem with parametrized strings?

authors: Mickeon yilmazdurmaz


text:
Add autocomplete support for change_scene()

Closes #20635
Not sure if it's the correct way, but well, works. As a side-effect, any method named change_scene() will complete scene names. I didn't know how to do it only for SceneTree, but that actually might be a feature if someone wants a custom change_scene().
Also I had to implement a function that returns file list with extension filter. It's general-purpose, so it might be useful for filtering specific resources based on context (e.g. supported formats for Textures etc.)

you can add this directly in SceneTree using Node::get_argument_options function

you can add this directly in SceneTree using Node::get_argument_options function

Bump.

Ok, changed.

Apart from a couple comments, should be good to merge.

Added requested changes and rebased.

Thanks!

source: gharchive/pull-request

authors: KoBeWi akien-mga reduz


text:
Add ability to set oneshot connection from Editor

Closes #1987

Works great.

authors: TheHX akien-mga


text:
Toggle CPUParticles2D visibility when redrawing

Addresses: https://github.com/godotengine/godot/issues/30672 (not sure if fully fixes)
Code graciously donated by Gamblify
This PR sets the number of visible particles based on the value of redraw. This matches the behaviour of CPUParticles introduced in 24b7f08.
This PR should also regain the performance lost in 24b7f08

Thanks!

Cherry-picked for 3.1.2.

authors: akien-mga clayjohn


text:
Added more details for set_drag_preview()

While coding some functionnality which needs drag and drop on a control, I struggled to understand that set_drag_preview() needed a node that is not in the scene tree.
I modified to the doc to include a sample from one of the demo project.

I think this is similar case as with _make_custom_tooltip. You might want to check its description.

I think this is similar case as with _make_custom_tooltip. You might want to check its description.

Bump. That method indeed has a better explanation of what happens (the control is freed, so it should be a new instance).

Ping.

Rebased to address feedback and also add definition of the used color.

Thanks!

how to center the preview to the mouse - currently mouse is shown on top-left of the preview

authors: KoBeWi ReyAnthony akien-mga wamiqurrehman093


text:
Load overrides if getting style from current class

This PR changes these conditions in Control
p_type == StringName() || p_type == ""

into
p_type == StringName() || p_type == get_class_name()

p_type is a StringName, so comparing it with both empty name and empty string makes no sense.
As for the get_class_name, some controls provide the p_name in get_some_style methods, while others don't. Example from Label
https://github.com/godotengine/godot/blob/2add51d0823fe2ef7cb439a6f3fae17e8dd4717f/scene/gui/label.cpp#L91
and from WindowDialog
https://github.com/godotengine/godot/blob/2add51d0823fe2ef7cb439a6f3fae17e8dd4717f/scene/gui/dialogs.cpp#L205
The reason is that some classes inherit from WindowDialog and they take constants etc. from WindowDialog class. Removing class name from get_some_style calls breaks inheriting dialogs, and keeping them causes value overrides set in the inspector to be ignored and only use Theme values. With this PR, the overrides are loaded if fetching value for the same class (so WindowDialog works correctly), while inheriting classes will still get correct values too.
tl;dr fixes #32211

Thanks!

authors: KoBeWi akien-mga


text:
Document the formats supported by Image.load()

This partially addresses #32166.

Thanks!

Cherry-picked for 3.2.2.

authors: Calinou akien-mga


text:
Add a Pause button to the 2D and 3D editor

Salvaged from https://github.com/godotengine/godot/pull/31070. Thanks @Chaosus :slightly_smiling_face:
This can be used to decrease CPU/GPU usage if particles or shaders are being displayed in the editor.
Note: Since low-processor usage mode hasn't been reimplemented yet in master, this won't decrease CPU/GPU usage significantly in the master branch, only in 3.2 if it's backported there.
Don't merge yet as pausing will break freelook in the 3D editor and scrolling in the script editor if smooth scrolling is enabled (related to https://github.com/godotengine/godot/issues/28385, partially addressed by https://github.com/godotengine/godot/pull/42704).
I can make a 3.2 version of this PR once it's ready.
This closes https://github.com/godotengine/godot-proposals/issues/942.
Preview
Freeze icon is at the bottom.

Salvaged from #31070.

Yeah, as I remember the pretensions for that PR in IRC was: "it was not customizable enough and better to be placed in the menu" and "it takes a valuable place". Perhaps the views are changed from that time...

Perhaps the views are changed from that time...

I think the current problem at hand is more important than saving a bit of space in the menu. It's making people not use Godot when they could.

Yeah, as I remember the pretensions for that PR in IRC was: "it was not customizable enough and better to be placed in the menu" and "it takes a valuable space". Perhaps the views are changed from that time...

At this point I'd take that pause button over most others, haha. To maybe prevent confusion with the pause scene button on the top right, I'd suggest changing the tool name to "Freeze." I've made a 14x14 icon here: ToolFreeze.zip

@molevision I amended my PR to use the icon you provided, thanks :slightly_smiling_face:

Just a note that I think although pausing might be useful for timelines, a more suitable fix for the problem of constant editor updates might be to have a slight modification to the system for requesting updates.
At the moment it is very broad, you request an update in the editor no matter whether this is caused by an animating texture, or something that really needs updating (like an update to the UI). Most of the time speaking for myself on a fanless PC, I don't want these constant updates the moment I use TIME in a shader or somesuch.
I'm wondering whether we can change the request_update function to have an argument such as a bool (perhaps with a default) to indicate whether the update is an essential update or not. Then we could have a switch in the UI to turn the non essential updating on and off.
I've been meaning to have a look at this but it might be something you might be interested in @Calinou.

Is this likely to make it to 3.2.4?

Is this likely to make it to 3.2.4?

Probably not, since 3.2.4 is nearing release.

Probably not, since 3.2.4 is nearing release. You can still cherry-pick this pull request and build it locally if you need it.

I haven't ever been able to get Vulkan Godot to work properly on my machine, the viewport is always completely black. Is there some way to build this PR with 3.3?

Is there some way to build this PR with 3.3?

You can cherry-pick the PR's commit to the 3.3 branch, but you'll have to resolve merge conflicts in the way.
You can also apply the .patch file using git am, but I don't know how to resolve conflicts in an interactive manner with git am.

Rebased and tested again, it works successfully.

Congratulations on the 3.3 release! Can this please make it in to 3.3.1? 😅
This PR was intended as a stopgap awaiting specific fixes to a lot of people's technical problems with the viewport updating. I can't add animations to my characters or use post-processing without it, the editor load is just too high. I have not been able to use Godot for about a year because of this. It would make a big difference to everyone in #39758 to have this merged.
(Plus, Vulkan in 4.0 using the MoltenVK backend to access Metal might just make the problem go away, for Mac users at least.)

This can be closed, functionality implemented by #53463.

authors: Calinou Chaosus lawnjelly molevision


text:
[3.2] Fix SPACING_SPACE not used for drawing characters.

Fixes #38630

Thanks!

authors: akien-mga bruvzg


text:
Cleanup a bunch of debug messages in OpenXR

Just cleaning up a bunch of debug messages in OpenXR and changing the ones we want to keep to print_verbose. There was an immense amount of spam in the logs when OpenXR starts. Most of these are handy when debugging specific issues as we dump out the capabilities OpenXR reports, but in normal conditions we don't need to see these so changed most to print_verbose.

Thanks!

authors: BastiaanOlij akien-mga


text:
[TextServer] Fix build with disabled graphite.

Fixes https://github.com/godotengine/godot/issues/67584

Thanks!


text:
C#: Do not use DocCache when generating glue code

Fixes #76250
See also https://github.com/godotengine/godot/pull/72855#issuecomment-1515491486

Just a workaround really, but I am not sure what the problem is and the in-editor documentation for these classes seems to work just fine.

This commit seems to have caused a regression, the editor help no longer works (video by @KoBeWi on Windows, and I could confirm it on Linux too):
https://user-images.githubusercontent.com/4701338/233503506-75e459b4-7c20-41d0-aafa-468fac3e9b02.mp4

authors: RedworkDE akien-mga


text:
Enabled processing for TexturePreview on AnimatedTexture

Fixes #77415
Problem
The issue was, that the TexturePreview would only get redrawn when the redraw was issued from another place (like the viewport calling queue_redraw().
My solution
In the contructor of TexturePreview, I check if the "previewed" Texture is an AnimatedTexture, and if so, I set_process(true) and then handle the NOTIFICATION_PROCESS by queuing a redraw there.
Here are two videos showing the end result (second one is to show, that the preview updates even when the mouse isnt moving).
https://github.com/godotengine/godot/assets/75789249/a006bcda-5bd7-4c6e-99a9-7df28730fcd7
https://github.com/godotengine/godot/assets/75789249/84197618-f184-4025-a5d4-a8c6119d6e0e

Closing because this seems to be a deeper issue. Not only the TexturePreview is not redrawing, but also a normal Sprite2D with an AnimatedTexture in the Viewport.


text:
Disconnect EditorNode from file dialogs on destruction

Fixes https://github.com/godotengine/godot/issues/84000.
The fact that EditorNode is freed before parts of the editor UI created by plugins is a curiosity that may warrant further investigation. But this fixes a crash and is generally a good thing to do on exit.

Thanks!

authors: YuriSizov akien-mga


text:
Only apply LOD when camera is outside the AABB of mesh in mobile renderer.

Fixes: https://github.com/godotengine/godot/issues/89028
This copies the same logic from https://github.com/godotengine/godot/pull/79590 for the Forward+ renderer and applies it to the Mobile renderer.
Note: this is a stopgap PR to get 4.3 out the door. I note the comments in https://github.com/godotengine/godot/issues/81995 and recognize that this PR won't fix the problems identified there.

Thanks!


text:
GA4

Is there any way to use this with GA4? It seems really bizzare that this method just does not work anymore and its not possible to switch to UA without making a new account

This seems promising
https://developers.google.com/tag-platform/devguides/consent#passing_ad_click_client_id_and_session_id_information_in_urls

I was able to disable some unwanted cookies and session storage by adjusting the code in _document.js:
<script
            dangerouslySetInnerHTML={{
              __html: `
                window.dataLayer = window.dataLayer || [];
                function gtag(){dataLayer.push(arguments);}
                gtag('consent', 'default', {
                  'ad_storage': 'denied',
                  'analytics_storage': 'denied'
                });
              `
            }}
          />

and also in the  _app.js:
const pageView = () => {
  if (!window.gtag) {
    return
  }
  gtag('consent', 'default', {
    ad_storage: 'denied',
    analytics_storage: 'denied',
  })
  gtag('config', 'G-CQKB7LXRKM', {
    page_path: location.pathname,
    client_storage: 'none',
    anonymize_ip: true,
    client_id: window.user_id
  })
}

Though sometimes there is an empty item created in the session storage. I did not yet figure out why and when this event occurs, but by switching pages, this issue occurs seemingly randomly.

repo: goenning/cookieless-ga


text:
2.0目前可以用于线上环境吗

2.0目前可以用于线上环境吗

可以

authors: houseme junsonw

repo: gogf/gf


text:
golang  Topics 排行里面没有排名呢

1. What version of Go and system type/arch are you using?

2. What version of GoFrame are you using?

3. Can this issue be re-produced with the latest release?
4. What did you do?

5. What did you expect to see?
6. What did you see instead?

什么玩意？

https://github.com/topics/golang
项目在这个排名里面没有。

@gqcn 加上了


text:
Webhook and sha256 hmac

Hello!
Instead of sending the Webhook secret in cleartext (it's cleartext even if the transports is protected by https) we should do as github does and create a hmac of the payload.
There are at least two benefits of this:

The webhook secret is protected when in transfer
The payload hasn't been tampered with

The most important thing is number 2 (but if the webhook secret is picked up on the wire, the number 2 is almost a fact), webhooks are often used for continue (integrations|deployments).
A theoretical attack could be to trigger a build+deploy of an older version of a software that contains security-related bugs.
I can try to create a pull request, but I can not guarantee that the code will look good and elegant (I'm a novice in Go).
Do you think this is a feature to add (and want to do it yourself) or has it been rejected in the past, and why in that case?
This is the python version of the code:
import hmac
mac = hmac.new(webhook_secret, msg=payload, digestmod=hashlib.sha1)
//Robert

So as far as I understand you want to change how the verification of the webhook secret works (the way that the other party proves the fact that it knows the secret).
It sounds like a good idea to not send the secret over the wire directly because it is not necessary to do so.
Let me explain my understanding:

Take the payload of the webhook request.
Create a message authentication code (MAC, doesn't have to be HMAC) with the Webhook secret as it's key. (this is done by the sender and receiver (once the receiver got the message))
Send the message payload and MAC.
If the MAC is identical on both sides, both sides have the same webhook secrect  and the same message payload.

Even though HMAC is quite resistent to collisions in the underlying hash function, maybe it is a good idea not to use SHA1 in which more and more flaws are discovered..

Hi!
You got me right, that workflow is how I imagine the things should be done.
And yes, we should maybe use sha256 or 512 instead of sha1.
I think I have some learning to do before I contribute with code ;)

GitHubs Webhooks (which Gogs tries to be compatable with) says this:

secret: An optional string that's passed with the HTTP requests as an X-Hub-Signature header. The value of this header is computed as the HMAC hex digest of the body, using the secret as the key.

So I agree that Gogs should be changed to reflect this :+1:
Source: https://developer.github.com/v3/repos/hooks/#example

Note: https://play.golang.org/p/wteqLNcnTV

Patch has pushed to fix this issue, please test on release/0.11 branch or https://try.gogs.io.

authors: FSMaxB Unknwon bkcsoft rjes

repo: gogits/gogs


text:
Use very strong ciphers

This sets strong ciphers/curves for when TLS is used.

Thanks for the PR, but CI is failing on Go 1.5:
cmd/web.go:674: undefined: tls.TLS_RSA_WITH_AES_256_GCM_SHA384

You're welcome. Production binaries are currently built with 1.5? Is there any reason not to move to the latest version? I know that the latest release has some big performance gains due to use of SSA in their backend. More information about their use of SSA here https://blog.golang.org/go1.7
You can also support HTTP/2 (which I think is important these days) if you're on anything greater than or equal to 1.6.
If you're not open to moving to the latest release I can adjust the ciphers for 1.5, they just won't be as strong :)

Builtin HTTPS functionality is convenient  but use proxy (e.g. NGINX, Caddy) to handle HTTPS is more general solution. So it is not worth dropping support of Go 1.5.

Sure, I can understand having people use a reverse-proxy instead. It's what I do on my servers too. I've removed that cipher to be compatible with 1.5.

Thanks!

authors: Unknwon aaronjwood


text:
first commit + react frontend

Adição de Pasta frontend que contém o App React + Componentes do react

Alterações realizadas

repo: gogixweb/bahea-cal


text:
Error: Error building site: "": [BUG] goldmark: runtime error: index out of range [0] with length 0

What version of Hugo are you using (hugo version)?

$ hugo version
Hugo Static Site Generator v0.60.1-96066756 openbsd/amd64 BuildDate: 2019-11-29T14:58:39Z

Does this issue reproduce with the latest release?
Normally, I use the actual package version on OpenBSD:
Hugo Static Site Generator v0.53 openbsd/amd64 BuildDate: unknown

To night, I search to use your pre-built Hugo binary for OpenBSD amd64 on OpenBSD 6.6 (actual stable).
When I execute it, I have this error:
$ hugo server -D
Building sites … WARN 2019/12/08 23:49:42 Page.URL is deprecated and will be removed in a future release. Use .Permalink or .RelPermalink. If what you want is the front matter URL value, use .Params.url
goroutine 125 [running]:
runtime/debug.Stack(0x1e876a0, 0x2b32360, 0xc001582500)
	/usr/local/go/src/runtime/debug/stack.go:24 +0x9d
github.com/gohugoio/hugo/markup/goldmark.(*goldmarkConverter).Convert.func1(0xc000678780, 0xc001a73000, 0x27cd, 0x3000, 0xc001f69b01, 0xc001f69bd8)
	/root/project/hugo/markup/goldmark/convert.go:162 +0x203
panic(0x197e140, 0xc000a3c0e0)
	/usr/local/go/src/runtime/panic.go:679 +0x1b2
github.com/yuin/goldmark/parser.parseAttribute(0x1e96bc0, 0xc001a4afc0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1867d00)
	/go/pkg/mod/github.com/yuin/goldmark@v1.1.8/parser/attribute.go:100 +0x5f7
github.com/yuin/goldmark/parser.ParseAttributes(0x1e96bc0, 0xc001a4afc0, 0x1f, 0x20, 0x0, 0x20)
	/go/pkg/mod/github.com/yuin/goldmark@v1.1.8/parser/attribute.go:59 +0x153
github.com/yuin/goldmark/parser.parseLastLineAttributes(0x1eace60, 0xc001a5b4d0, 0x1e96bc0, 0xc001a4aa10, 0x1e97100, 0xc001a4a9a0)
	/go/pkg/mod/github.com/yuin/goldmark@v1.1.8/parser/atx_heading.go:229 +0x2b4
github.com/yuin/goldmark/parser.(*atxHeadingParser).Close(0xc00076491a, 0x1eace60, 0xc001a5b4d0, 0x1e96bc0, 0xc001a4aa10, 0x1e97100, 0xc001a4a9a0)
	/go/pkg/mod/github.com/yuin/goldmark@v1.1.8/parser/atx_heading.go:169 +0x139
github.com/yuin/goldmark/parser.(*parser).closeBlocks(0xc00077e000, 0x0, 0x0, 0x1e96bc0, 0xc001a4aa10, 0x1e97100, 0xc001a4a9a0)
	/go/pkg/mod/github.com/yuin/goldmark@v1.1.8/parser/parser.go:845 +0x162
github.com/yuin/goldmark/parser.(*parser).parseBlocks(0xc00077e000, 0x1eac9e0, 0xc001a3d180, 0x1e96bc0, 0xc001a4aa10, 0x1e97100, 0xc001a4a9a0)
	/go/pkg/mod/github.com/yuin/goldmark@v1.1.8/parser/parser.go:1058 +0x753
github.com/yuin/goldmark/parser.(*parser).Parse(0xc00077e000, 0x1e96bc0, 0xc001a4aa10, 0xc001f01c10, 0x1, 0x1, 0x46d, 0x0)
	/go/pkg/mod/github.com/yuin/goldmark@v1.1.8/parser/parser.go:818 +0x148
github.com/gohugoio/hugo/markup/goldmark.(*goldmarkConverter).Convert(0xc000678780, 0xc001a73000, 0x27cd, 0x3000, 0x1, 0x1e40060, 0xc001c6d770, 0x0, 0x0)
	/root/project/hugo/markup/goldmark/convert.go:174 +0x393
github.com/gohugoio/hugo/hugolib.(*pageContentOutput).renderContent(0xc00103a700, 0xc001a73000, 0x27cd, 0x3000, 0xc000a959a0, 0xc000f6cf80, 0x0, 0x1e50b60)
	/root/project/hugo/hugolib/page__per_output.go:335 +0x74
github.com/gohugoio/hugo/hugolib.newPageContentOutput.func1.1(0x0, 0x0)
	/root/project/hugo/hugolib/page__per_output.go:102 +0xa7e
github.com/gohugoio/hugo/hugolib.newPageContentOutput.func1.2(0x1e66d20, 0xc001a02cc0, 0x0, 0x0, 0x0, 0x1a97eb5)
	/root/project/hugo/hugolib/page__per_output.go:184 +0x26
github.com/gohugoio/hugo/lazy.(*Init).withTimeout.func1(0xc0002133b0, 0x1e66d20, 0xc001a02cc0, 0xc001a02d20)
	/root/project/hugo/lazy/init.go:177 +0x47
created by github.com/gohugoio/hugo/lazy.(*Init).withTimeout
	/root/project/hugo/lazy/init.go:176 +0x10e
Built in 1529 ms
Error: Error building site: "~/Projets/hugo-sites/blog/content/fr/sys/openbsd/munin-server.md:1:1": [BUG] goldmark: runtime error: index out of range [0] with length 0: create an issue on GitHub attaching the file in: /tmp/hugo_bugs/goldmark_3b85aa30346eda091ffbeb5de2a55c91.txt

And the file '/tmp/hugo_bugs/goldmark_3b85aa30346eda091ffbeb5de2a55c91.txt' contains:

## Description

**Munin** est un outil de surveillance des ordinateurs. Il présente ces informations par le biais d'une interface web, qui visualise des graphiques statiques, générés toutes les 5 minutes, par défaut. Un certain nombre de plugins de monitoring divers sont utilisables sans gros effort.

**Munin** permet de monitorer facilement la performance de tout matériel informatique (ordinateurs, réseaux, applications, mesures diverses, etc.). Il permet de discerner les problèmes de performance des ressources.

* Site web : http://munin-monitoring.org/
* Version : 2.0.49
* OpenBSD : 6.6
* Services : httpd + munin_node + munin_asyncd

## Documentation

Il est toujours utile de lire les documentations `pkg-readmes` fournies ; celles disponibles sont dans `/usr/local/share/doc/pkg-readmes/`, à-propos de :

* munin-node
* munin-server
* la documentation officielle :
    * http://munin-monitoring.org/wiki/Documentation
    * http://munin.readthedocs.org/
* la FAQ officielle : http://munin-monitoring.org/wiki/faq

## Installation

Code : sh

# pkg_add munin-node munin-server

Un utilisateur `_munin` a été créé et le répertoire web, par défaut, est dans `/var/www/htdocs/munin/`.  Ce répertoire reçoit les droits de l'utilisateur `_munin` et du groupe web `www`.

Pour information, cela installe en dépendance quelques paquets de plus, dont `p5-Net-CIDR` - *ce paquet est utile pour la configuration de l'option `cidr_allow` dans le
fichier de configuration du nœud de munin
 ; s'il n'est pas installé, faites-le !*

Si vous désirez le support des moniteurs SNMP
, il faut installer le paquet `p5-Net-SNMP`.

## Configuration

Deux fichiers de configuration principaux sont dans `/etc/munin` :

* `munin.conf` relatif au serveur lui-même
* `munin-node.conf` relatif au nœud de surveillance local.

Une fois, ces fichiers configurés, il est possible de démarrer les deux services de munin.

### munin.conf

Généralement, il y a peu de choses à changer, néanmoins, pour informations, certaines variables peuvent être configurées.

* `dbdir` : répertoire de la base de donnée de munin
* `htmldir` : répertoire de destination des données graphiques générées.
* `logdir` : répertoire des journaux de munin
* `rundir` : répertoire où s'exécute le processus munin.

Si vous préférez une exécution du processus par cron plus que par script CGI, vous pouvez modifier les deux variables `graph_strategy` et `html_strategy`.

Par défaut sera configurée une arborescence basique basée sur localhost, tel que :

Code :

[localhost]
    address 127.0.0.1
    user_node_name yes

Si vous préférez une arborescence par nom de domaine, modifiez/commentez/ajoutez `localhost` par le nom de domaine désiré, tel `huc.fr.eu.org`. Bien sûr, il est possible de surveiller autant d'hôtes que désiré.

Il est possible de gérer les différents nœuds par groupe ; cela permet de regrouper les informations. Je vous renvoie aux documentations officielles et autres manpages.

Les noms de nœuds, de groupe de nœuds ainsi que les adresses IPv6 doivent être encadrés de `[ ]`.

#### Ajouter un nœud

Exemple :

Code :

# server name
[srvr.huc.fr.eu.org]
# address IP
    address 192.168.1.1
    use_node_name yes

# first pc
[pc1.huc.fr.eu.org]
    address 192.168.1.10
    use_node_name yes

#### Recevoir les alertes par mail

Pour recevoir les alertes par mail, il est nécessaire de renseigner une ou plusieurs adresses de contact, tel que :

Code :

contact.root.command mail -s "Munin notification" email
contact.other-user.command mail -s "Munin notification" email-user

Ceci étant un exemple, remplacez par les informations nécessaires à votre situation.

### munin-node.conf

La partie de la [configuration du fichier de nœud](/fr/sys/openbsd/munin-node/) étant expliquée sur sa propre page, il suffit de suivre les informations et de les adapter au nœud du serveur lui-même

### crontab

Après avoir configuré les deux fichiers de configuration ci-dessus, il est important de paramétrer une tâche cron, tel que :

Code :

# crontab for munin-server
*/5     *       *       *       *       su  -s /bin/sh _munin /usr/local/bin/munin-cron

### newsyslog.conf

Il est nécessaire de modifier le fichier de configuration du journal `/etc/newsyslog.conf` pour créer une rotation des journaux générés par munin.

Ajoutez-y :

Code :

# munin-server
/var/www/logs/munin/munin-cgi-graph.log  www:_munin  644  7     250  *     Z
/var/www/logs/munin/munin-cgi-html.log   www:_munin  644  7     250  *     Z
/var/www/logs/munin/munin-graph.log  _munin:_munin   644  7     250  *     Z
/var/www/logs/munin/munin-html.log   _munin:_munin   644  7     250  *     Z
/var/www/logs/munin/munin-limits.log _munin:_munin   644  7     250  *     Z
/var/www/logs/munin/munin-update.log _munin:_munin   644  7     250  *     Z
# munin-node
/var/log/munin/munin-node.log   root:wheel      644  7     250  *     Z

Ce sont tous les journaux gérés et nécessaires à minima pour munin.

### httpd

Ici, je vous renvoie à mon article de découverte du serveur **httpd**, et tout particulièrement aux informations d'[utilisations](/web/httpd/httpd/#utilisation).

Modification du fichier de configuration `/etc/httpd.conf` pour y ajouter :

Code :

include "/etc/httpd.d/munin.conf"

Création du fichier de config du serveur pour nagios `/etc/httpd.d/munin.conf` :

Code :

server "192.168.1.3" {

    listen on * port 80
    root "/htdocs/munin"

#    location "/cgi-bin/munin-cgi*" {
#        fastcgi socket "/run/slowcgi.sock"
#        root "/"
#    }

    location "/" {
        directory index index.html
    }

}

Les fichiers dans le répertoire web de munin doivent avoir les droits de l'utilisateur `_munin` et du groupe web `www`, par défaut.

#### Chroot web

Du fait du chroot web, il est nécessaire de faire les modifications systèmes suivantes :

Code : sh

# mkdir -p /var/www/{logs,var/run}/munin
# chown _munin: /var/www/{logs,var/run}/munin

mais en plus de modifier la
configuration du fichier du serveur
 :

Code :

htmldir /var/www/htdocs/munin
logdir /var/www/logs/munin
rundir  /var/www/var/run/munin

### Packet-Filter

Concernant les règles pour PF
, il faut ouvrir en entrée et sortie, vers et depuis les nœuds :

* pour Munin lui-même : `4949/tcp`
* pour SNMP : `161`, `162` en `udp` et `tcp` - cela dépend de votre configuration SNMP
, bien sûr.

## Démarrage des services

Pensez à activer et démarrer les services nécessaires, si ce n'est pas fait !

Code : sh

# rcctl enable munin_node munin_asyncd slowcgi httpd
# rcctl start munin_node munin_asyncd slowcgi
# httpd -n && rcctl start httpd

## Dépannage

### Erreur : Failed to create rundir (/var/run/munin): Permission denied

Citation :

Failed to create rundir (/var/run/munin): Permission denied at /usr/local/libexec/munin/munin-update line 39.

* Avez-vous réellement fait lu le chapitre **
chroot
** ?

### Erreur : [FATAL] There is nothing to do here, since there are no nodes with any plugins

Citation :

[FATAL] There is nothing to do here, since there are no nodes with any plugins.  Please refer to http://munin-monitoring.org/wiki/FAQ_no_graphs at /usr/local/libexec/munin/munin-html line 40.

* Avez-vous démarré vos services munin ?
* Avez-vous activé/désactivé des plugins ? Si oui, avez vous redémarré le service `munin-node` ?

----

## Remerciements

Une spéciale dédicace à [Solene Rapenne](http://solene.perso.pw) qui fait partie de l'équipe d'OpenBSD, et qui m'a bien aider pour démarrer ce projet.

----

Have you one idea?

I close this, because I forgot to set file config!

repo: gohugoio/hugo


text:
WIP: tpl: Make Hugo work with Go 1.11 (and Go 1.10)

Thanks to @rjoleary for the investigation.
Fixes #4784

Good news: Yay!  It compiled!
Bad news: go test ./... fails at TestShortcodePreserveOrder?
Compare:

Job #9196.5 (master): https://travis-ci.org/gohugoio/hugo/jobs/391685137
Job #9199.5 (this PR): https://travis-ci.org/gohugoio/hugo/jobs/391820859

v1: 0 sgo: <nil>|v2: 1 sgo: 0|v3: 2 sgo: 1|v4: 3 sgo: 2|v5: 4 sgo: 3|

So, in the above it seems that Go 11 prints nil as ... "nil", which is a pretty breaking change. I will try to look into this and create an issue on their tracker.
If this is the only breaking test, you can just remove "v1: 0 sgo: " from the assert -- it is not important for this particular test.

So, in the above it seems that Go 11 prints nil as ... "nil", which is a pretty breaking change. I will try to look into this and create an issue on their tracker.

Thank you so much for looking into this and filing golang/go#25875!  You are amazing as always!

If this is the only breaking test, you can just remove "v1: 0 sgo: " from the assert -- it is not important for this particular test.

Yes, it is indeed the only breaking test, as the following one-time experiment shows:

https://travis-ci.org/gohugoio/hugo/builds/392039772

Sidenote: The first build on Linux with go1.9.5 on Travis CI actually produced a race condition!  Unfortunately, I pressed "Rebuild" for that job, which now passes, but it seems to be no way to get at the old build log.
Anyhow, seeing how golang/go#25875 is labelled "NeedsFix" and "release-blocker" for go1.11, and how the two issues (API change vs <nil>) are not directly related, I think I'd better keep hugolib/shortcode_test.go as-is, and not remove "v1: 0 sgo: ".

authors: anthonyfok bep


text:
Move source types into their own package and discover them using java.util.ServiceLoader

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
The ingestion sources are currently mingled in with all the other ingestion code in the transforms package. This makes it hard to distinguish what all the sources are and makes it trickier for people to see how they might extend feast to support new sources.
Describe the solution you'd like
I'd like to create a source package in the ingestion module, and create common factory type class that can create FeatureIO.Read instances and have a function for returning their type string. New source implementations need only implement this interface and use an @AutoService annotation to make it available.
The import job can then load all available source factories from the class path and find the one with the matching type string against the import spec.
This follows the same pattern we use for storage types and allows us a path for including new source types as external dependencies, or moving existing ones into their own module. And then making them available simply by adding their jars on the class path.

This issue isn't relevant any more due to changes in Feast 0.3.0.

authors: tims woop

repo: gojek/feast


text:
Splits sometimes don't work.

Sometimes when you click and drag a split, nothing happens except a new split dragger is created.

this is much more reliable now..

repo: goki/gi


text:
Asset provisioning strategy for things like icons, cursors, fonts, etc

There was some discussion of this on go-nuts and likely some good accepted solutions..

implemented a good basic standard version for icons.  should work for cursors.  not dealing with fonts.


text:
go get-like CLI API

Proposal:
The dep CLI commands and flags to be much more similar to go get.
dep get github.com/pkg/errors@^0.8.0
dep get -u github.com/pkg/errors (latest)

We (the committee) went back and forth over the naming of the verbs and flags quite a lot, and settled intentionally on ensure. It's not even that it does more than go get does - it's that their behavior really only has partial overlap:

dep has nothing to do with go install-ing code; it will never generate a binary. As such, the -d flag has no analogue.
go get's -fand-fixflags have no possible analogue indep. -t`, if we even make an analogue, would likely be done as part of a wider system of os/arch/build/release tags, and would be a permanent choice recorded in the manifest.
Once we add support for doing individual dep updates, the equivalent of dep ensure -u github.com/pkg/errors would get you the latest version of pkg/errors that's allowed by the constraint in manifest.json. That may or may not be the same as the "latest" from upstream

...assuming that the solver can find a workable solution, at all.
It also might find a version that's not the very latest, because the very latest didn't satisfy all other constraints in the depgraph.
It would also NOT update the transitive dependencies of pkg/errors, unlike go get -u ....

go get has no concept of an override, but that's a crucial control option in dep.
Similarly, there's no analogue in go get to ignores or requires - we've not dropped those in yet, but they're planned and described in the spec doc, and you can hand-write them into the manifest today (#108 actually has preliminary code for require)
dep ensure, no args, covers an entire project. go get operates just from the current package.

Basically, go get has us all in the mentality of directly mutating state on disk. In dep, that's almost more of a side effect - instead, you're focused on setting up constraints, and dep then works out the solution. This is the standard tradeoff between direct, imperative control and safety - the very same class of tradeoff Go makes for its memory safety.
Making the dep commands and flags similar to go get would just reinforce the expectation that they behave the same way. While I do believe it's important to make transitioning to dep as easy as possible, I think that setting up false expectations is a poor way to do it. Plus, the command set that we're trying to provide with dep is complicated in its own right. I think it's preferable to focus on internal consistency of the design, rather than saddling it with the additional requirement of being like go get.
Finally, I'm hoping for a future in which go get still exists, but as a tool solely for the consumers/installers of go code. I think that's an important distinction (I give basic reasons for this in the introduction to my pkg mgmt article - PDM vs LPM), and it's worth trying to avoid blurring that line.
To be clear, I'm not saying the verbs or flags are final - not at all. I'm just rejecting "be like go get as a design goal.

I'm closing this, as the design goal is a non-starter. Please feel free to open specific issues about particular verbs or flags, though!

Closing after 4h doesn't look like very nice approach to the community.

The issue's not locked, just closed. I'm not preventing you from discussing it. I'm just trying to clearly signal that we believe this is a settled question; leaving the issue open indicates that the maintainers consider something unresolved here.
To reiterate, there are lots of rough edges and things needing improvement with the current verbs and flags. And I, really truly seriously, invite you to open specific issues about them with specific arguments.

authors: VojtechVitek sdboyer

repo: golang/dep

license_source: bigquery


text:
Update gps to v0.16.0

This updates us to gps v0.16.0. The most noteworthy changes are not API-visible; it exerts more careful control over running subprocesses, which could be sufficient for us to do #301. Also, sdboyer/gps#196 is in, which should put an end to the race conditions. That should help out #378, and probably fix a number of others.
This MAY cause a performance regression, owing to when we hit the network for source version information. If it does, though, it'll be a fleeting problem - the refactored sourceMgr gives us lots of performance headroom now!

Putting this one in. Huzzah!


text:
godoc.org unable to display docs for a go-gettable package.

The Go package with a vanity import path "src.sourcegraph.com/vfs" can be acquired with go get:
$ go get -u src.sourcegraph.com/vfs
$

It also works on gotools.org:
http://gotools.org/src.sourcegraph.com/vfs
However, it results in a "Not Found" page on godoc.org:
https://godoc.org/src.sourcegraph.com/vfs

Cause
I've identified the cause for this issue. It happens because of a slightly incorrect logic for resolving vanity import paths for git repositories in github.com/golang/gddo/gosrc package. I will create a PR that explains the details and fixes it shortly.
It happens with Go packages on src.sourcegraph.com because it's currently strict about its git clone URL. It will work if you do git clone https://src.sourcegraph.com/vfs, but it will not work if you add a ".git" suffix like git clone src.sourcegraph.com/vfs.git (nor any other suffix; it only supports the canonical clone URL at this time). Most other hosts support both and that's why they were not affected.

Here are some more details from my debugging session for those interested.
See https://github.com/golang/gddo/pull/353#issue-118173779 for a detailed description of what the valid behavior for resolving vanity import paths to a git clone URL should be.
Doing curl 'https://src.sourcegraph.com/vfs?go-get=1' results in:
<meta name="go-import" content="src.sourcegraph.com/vfs git https://src.sourcegraph.com/vfs">go get src.sourcegraph.com/vfs

The repo-root value is "https://src.sourcegraph.com/vfs" and that's what should be used for git clone/ls-remote. However, it was appending a .git suffix and trying to ls-remote that, which produced an error:
gddo-server $ go build -o /tmp/o && /tmp/o
2015/11/20 20:39:56 Starting server, os.Args=/tmp/o
importPath = (string)("src.sourcegraph.com/vfs")
2015/11/20 20:40:03 git ls-remote --heads --tags https://src.sourcegraph.com/vfs.git
2015/11/20 20:40:04 web   fetch: 1713 notfound: VCS not found src.sourcegraph.com/vfs
^C

The fix in #353 makes it so that gddo uses the correct clone URL as specified in the go-import meta tag:
git ls-remote --heads --tags https://src.sourcegraph.com/vfs

Which allows gddo to dispaly docs for this Go package successfully:

repo: golang/gddo


text:
Proposal: Add highlight for golang code, golang doc/blog or other document web page

Proposal: Add highlight for golang code for golang doc/blog or other document web page.
The current document, blog and other document, even online source code browser doese not have code highlight.
See following page, do you feel it ?
Example none highlight page
Blog page: https://blog.golang.org/context
Packge page: https://golang.org/pkg/bufio/#example_Scanner_custom
Source code page: https://golang.org/src/bufio/scan.go
Ok,let's testing the highlight result.
Testing highlight result

Install google chrome browser
Open one of the url address previous section
Press F12 open chrome develop tools
find <pre> tags, change it to <pre class="prettyprint">
switch to chrome console, type following code

var script = document.createElement('script');script.type='text/javascript';
script.src="https://cdn.rawgit.com/google/code-prettify/master/loader/run_prettify.js";
document.head.appendChild(script);

you will see the rendered result

How to do this?
The highlight is powered by google's dog food:
https://github.com/google/code-prettify
To use it very simple

Add class="prettyprint" to the <pre> tag
Load js at the button of each page

<script type="text/javascript">
var script = document.createElement('script');script.type='text/javascript';
script.src="https://cdn.rawgit.com/google/code-prettify/master/loader/run_prettify.js";
document.head.appendChild(script);
</script>

Please no.

I don't understand the logic of the highlighting in the screenshot you provided. Some identifiers are black and some are purple. Why? It doesn't follow any logic that I can discern. Overall, that screenshot is less legible than the status quo in my opinion.
The current docs highlight comments. The code/comment distinction is objective, and so is therefore an uncontroversial stance. The rest is a matter of opinion. Historically the project does not encourage syntax highlighting.

The code highlight style is powered by google's implement https://github.com/google/code-prettify
Code highlight in IDE were good for reading code.
Emacs,VIM or other IDE both have code highlight .
Not just plain text.
Why not support code highlight?
What Text Editor you guys using? No any color ? just black and white text?

Code highlight can make code more easily to read and understand. will save our time to read and understand the code. why you think that was nonsense and useless?

Emacs,VIM or other IDE both have code highlight

They also easily allow changing the color scheme. Not everybody likes the colours that you, or some service, pick.
They even allow modifying the patterns used for highlighting.

What Text Editor you guys using? No any color ? just black and white text?

There is a large enough group of programmers that prefer no syntax highlighting whatsoever, among them a large portion of the Go team.
Personally I recommend that you use something like greasemonkey, or the equivalent for your browser, and add syntax highlighting to any page you wish. That way, you get to control all aspects of the syntax highlighting.

Code highlight can make code more easily to read and understand

That is subjective. Also, it is more relevant for languages with too complex syntax. Go is a very simple language syntactically. One shouldn't require colours to tell a few syntactic elements apart.

Thanks @dominikh , I made a script , https://github.com/netroby/golang-org-code-highlight-userscript
By using it under chrome browser, you need install tampermonkey extension to load userscript

why you think that was nonsense and useless?

That's not what I said.

Code highlight can make code more easily to read and understand.

Not at all times. I use the lack of syntax highlighting as a readability test. I find standard library godoc and examples quite readable without syntax highlighting. It is a sign that the language and the standard library APIs are simple enough. Maybe we should always keep godoc this way to have a reality check with the verbosity.

Thanks for you time, i choose to die.

i choose to die, too

authors: adg cznic dominikh netroby rakyll richox

repo: golang/go


text:
go http concurrency request to outside

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?
go version go1.4.2 linux/amd64

What operating system and processor architecture are you using (go env)?
CentOS 7.2 Minimal Desktop
(Linux Development 3.10.0-327.el7.x86_64 #1 SMP Thu Nov 19 22:10:57 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux)

GOARCH="amd64"
GOBIN=""
GOCHAR="6"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/xxxxxxx/Desktop/maas"
GORACE=""
GOROOT="/usr/lib/golang"
GOTOOLDIR="/usr/lib/golang/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
CXX="g++"
CGO_ENABLED="1"

What did you do?
go http concurrency request to outside

What did you expect to see?
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x20 pc=0x401a28]

What did you see instead?
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x20 pc=0x401a28]

Please provide a runnable piece of sample code that demonstrates the
problem.
On Thu, 28 Apr 2016, 19:41 John Kou, notifications@github.com wrote:

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?
go version go1.4.2 linux/amd64
2.
What operating system and processor architecture are you using (go env
)?
CentOS 7.2 Minimal Desktop
(Linux Development 3.10.0-327.el7.x86_64 #1
https://github.com/golang/go/issues/1 SMP Thu Nov 19 22:10:57 UTC
2015 x86_64 x86_64 x86_64 GNU/Linux)
GOARCH="amd64"
GOBIN=""
GOCHAR="6"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/johnkou/Desktop/maas"
GORACE=""
GOROOT="/usr/lib/golang"
GOTOOLDIR="/usr/lib/golang/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
CXX="g++"
CGO_ENABLED="1"

What did you do?
go http concurrency request to outside
2.
What did you expect to see?
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x20 pc=0x401a28]
3.
What did you see instead?
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x20 pc=0x401a28]
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/golang/go/issues/15479

var job_temp HTTP json.NewDecoder(req.Body).Decode(&job_temp) go func(job_temp *HTTP) { 	for { 		var method string 		switch job_temp.RequestMethod { 		case 0: method = "GET" 		case 1: method = "POST" 		case 2: method = "PUT" 		case 3: method = "DELETE" 		case 4: method = "PATCH" 		case 5: method = "HEAD" 		} 		client := &http.Client{Timeout: time.Duration(int64(time.Second) * int64(job_temp.RequestTimeout))} 		request, _ := http.NewRequest(method, "http://" + job_temp.RequestAddress + ":" + strconv.FormatInt(int64(job_temp.RequestPort), 10), nil) 		response, _ := client.Do(request) 		response.Close = true 		fmt.Println("This is a HTTP job for " + job_temp.RequestAddress + " Result is: " + strconv.FormatInt(int64(response.StatusCode), 10)) 		time.Sleep(time.Second * time.Duration(job_temp.JobInterval)) 	} }(&job_temp)
The job will run every specific interval, it seems that some bugs when concurrency by client.Do(request)

type HTTP struct {
JobID           string
JobUserID       string
JobName         string
JobInterval		uint8
RequestAddress  string
RequestMethod   uint8
RequestVersion  uint8
RequestPort     uint32
RequestHeader   []HTTPHeader
RequestBody		string
RequestUsername string
RequestPassword string
RequestTimeout  uint8
ResponseBody    string
ResponseContain bool
}

Thank you for providing a code sample, in future, please provide it in a runnable form. What you have provided is not runnable.
With that said, you are ignoring the error from json decode, which if it fails will probably leave job_temp undefined. I'm guessing your program crashes at the switch on job_temp.RequestMethod.
The rest of your program is also ignoring any error checking. You must check each and every error if you want to want to use the result from an operation that can possibly return an error.
I am going to close this error as there is no bug to be fixed. We do not use the issue tracker for general discussion, I recommend you ask your question in another forum, see https://golang.org/wiki/Questions.


text:
Type information missing for argument of three function in package regexp

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
go1.7.1 - Not relevant
What operating system and processor architecture are you using (go env)?
darwin/amd64 macOS Sierra 10.12.0 - Not relevant.
What did you do?
Documentation on package regexp ( https://golang.org/pkg/regexp/ )
func (re *Regexp) ReplaceAll(src, repl []byte) []byte
func (re *Regexp) ReplaceAllLiteral(src, repl []byte) []byte
func (re *Regexp) ReplaceAllLiteralString(src, repl string) string
func (re *Regexp) ReplaceAllString(src, repl string) string
What did you expect to see?
The type for src, is it a string or an []byte?
What did you see instead?
Argument type is missing.

For functions, you are permitted to have a list of identifiers, followed by the type. So the identifiers src and repl are followed by the type []byte, which applies both preceding identifiers. This is a language feature specified in Function types section.
Working as intended.

@RWPearson in case you need to, here are some resources you can use https://github.com/golang/go/wiki/Questions to ask some questions, since we use the issue tracker to track bugs.

authors: RWPearson dsnet odeke-em


text:
builtin: print and println do not accept multiple-value expressions like fmt.Println and others

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
go version go1.8.3 linux/amd64
What did you do?
package main

import "fmt"

func f1() ([]int, int, int) {
	return nil, 1, 2
}

func f2() (int, int) {
	return 1, 2
}

func main() {
	// function call nesting is ok.
	fmt.Println(f2())

	var s []int
	// function call nesting is ok.
	s = append(f1())
	_ = s

	// function call nestings are not ok.
	println(f2()) // multiple-value f() in single-value context
	print(f2()) // multiple-value f() in single-value context
}

What did you expect to see?
compile okay.
What did you see instead?
compile failed.

Smaller reproducer on play.golang.org: https://play.golang.org/p/0MMwjZ50XU

go/types accepts it.
Similar: #15992

In general it seems like you're right and this is an unexpected inconsistency - append takes ...Type just like print and println.
Then again, the print funcs are not guaranteed to stay in the language, so perhaps this was somehow done on purpose or not fixed on purpose.

This is an implementation restriction: https://golang.org/ref/spec#Bootstrapping:
print and println need not accept arbitrary argument types, but printing of boolean, numeric, and string types must be supported.

print and println are for bootstrapping - the language never guaranteed that they be first-class built-ins. Closing.

authors: ALTree go101 griesemer mvdan


text:
runtime: cherry-pick CL 56670

CL 56670 fixes an issue causing false-positive race detector reports in Google-internal tests. I'm not sure if the same failure can be triggered by regular users of the runtime/pprof package.

Fixed by 42046e8


text:
x/vgo: Second vgo build execution gives an error

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
go version go1.10 linux/amd64
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOBIN="/home/francisco/go/bin"
GOCACHE="/home/francisco/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/francisco/go"
GORACE=""
GOROOT="/usr/lib/go"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build916224046=/tmp/go-build -gno-record-gcc-switches"
What did you do?
I'm trying vgo in a project that already uses dep. It's a library (still not open source but will be soon).
I run CC=gcc vgo build (See https://github.com/golang/go/issues/23965#issuecomment-368005415) and the process runs successfully.
If I run CC=gcc vgo build again I get the error
vgo: errors parsing go.mod:
/$HOME/go/src/github.com/dr-go/go-healthcheck/go.mod:11: invalid module: github.com/ralekseenkov/govaluate should be v1, not v3 (v3.0.0)

I put go.mod, Gopkg.lock and Gopkg.toml in this gist.
What did you expect to see?
A successful build.
What did you see instead?
A failed build.

I have the same issue in a more simple scenario, just pure vgo
mkm@nemo $ git clone https://github.com/mmikulicic/vgo-issue-24069
mkm@nemo $ cd vgo-issue-24069
mkm@nemo $ vgo build
vgo: resolving import "github.com/go-sql-driver/mysql"
vgo: finding github.com/go-sql-driver/mysql (latest)
vgo: adding github.com/go-sql-driver/mysql v1.3

I ran a recent vgo (go get -u golang.org/x/vgo just now)
and now it records v1.3:
mkm@nemo $ git diff
diff --git a/go.mod b/go.mod
index 75216a6..c2dfb2e 100644
--- a/go.mod
+++ b/go.mod
@@ -1 +1,3 @@
 module "github.com/mmikulicic/vgo-issue-24069"
+
+require "github.com/go-sql-driver/mysql" v1.3

but it still breaks next time we run vgo build:
mkm@nemo $ vgo build
vgo: finding github.com/go-sql-driver/mysql v1.3.0
vgo: github.com/go-sql-driver/mysql v1.3.0: unexpected status (https://api.github.com/repos/go-sql-driver/mysql/git/refs/tags/v1.3.0): 404 Not Found
vgo: finding github.com/go-sql-driver/mysql v1.3.0
vgo: github.com/go-sql-driver/mysql v1.3.0: unexpected status (https://api.github.com/repos/go-sql-driver/mysql/git/refs/tags/v1.3.0): 404 Not Found
vgo: unexpected status (https://api.github.com/repos/go-sql-driver/mysql/git/refs/tags/v1.3.0): 404 Not Found

The version gets rewritten as a side effect of the second vgo build:
mkm@nemo $ git diff
diff --git a/go.mod b/go.mod
index 75216a6..c2dfb2e 100644
--- a/go.mod
+++ b/go.mod
@@ -1 +1,3 @@
 module "github.com/mmikulicic/vgo-issue-24069"
+
+require "github.com/go-sql-driver/mysql" v1.3.0

@mmikulicic As you already pointed out go-sql-driver has a v1.3 tag, but no v1.3.0 tag, thus resulting in 404 for vgo
I can echo that this issue also occurs for me. A minimal example to reproduce the issue has been uploaded to https://github.com/mewspring/pixel-vgo-example
vgo build completes successfully the first time and produces a go.mod file.
u@x220 ~/D/g/s/g/m/pixel-vgo-example> vgo build
vgo: resolving import "github.com/faiface/pixel"
vgo: finding github.com/faiface/pixel (latest)
vgo: adding github.com/faiface/pixel v0.7
vgo: resolving import "golang.org/x/image/colornames"
vgo: finding golang.org/x/image (latest)
vgo: adding golang.org/x/image v0.0.0-20180314180248-f3a9b89b59de
vgo: finding golang.org/x/image v0.0.0-20180314180248-f3a9b89b59de
vgo: finding github.com/faiface/pixel v0.7
vgo: downloading github.com/faiface/pixel v0.7
vgo: downloading golang.org/x/image v0.0.0-20180314180248-f3a9b89b59de
vgo: resolving import "github.com/faiface/glhf"
vgo: finding github.com/faiface/glhf (latest)
vgo: adding github.com/faiface/glhf v0.0.0-20170610131041-98c0391c0fd3
vgo: resolving import "github.com/faiface/mainthread"
vgo: finding github.com/faiface/mainthread (latest)
vgo: adding github.com/faiface/mainthread v0.0.0-20171120011319-8b78f0a41ae3
vgo: resolving import "github.com/go-gl/glfw/v3.2/glfw"
vgo: finding github.com/go-gl/glfw (latest)
vgo: adding github.com/go-gl/glfw v0.0.0-20170814180746-513e4f2bf85c
vgo: resolving import "github.com/go-gl/mathgl/mgl32"
vgo: finding github.com/go-gl/mathgl (latest)
vgo: adding github.com/go-gl/mathgl v0.0.0-20180319210751-5ab0e04e1f55
vgo: resolving import "github.com/pkg/errors"
vgo: finding github.com/pkg/errors (latest)
vgo: adding github.com/pkg/errors v0.8.0
vgo: finding github.com/pkg/errors v0.8.0
vgo: finding github.com/go-gl/mathgl v0.0.0-20180319210751-5ab0e04e1f55
vgo: finding github.com/go-gl/glfw v0.0.0-20170814180746-513e4f2bf85c
vgo: finding github.com/faiface/mainthread v0.0.0-20171120011319-8b78f0a41ae3
vgo: finding github.com/faiface/glhf v0.0.0-20170610131041-98c0391c0fd3
vgo: downloading github.com/faiface/glhf v0.0.0-20170610131041-98c0391c0fd3
vgo: downloading github.com/faiface/mainthread v0.0.0-20171120011319-8b78f0a41ae3
vgo: downloading github.com/go-gl/mathgl v0.0.0-20180319210751-5ab0e04e1f55
vgo: downloading github.com/pkg/errors v0.8.0
vgo: downloading github.com/go-gl/glfw v0.0.0-20170814180746-513e4f2bf85c
vgo: resolving import "github.com/go-gl/gl/v3.3-core/gl"
vgo: finding github.com/go-gl/gl (latest)
vgo: adding github.com/go-gl/gl v0.0.0-20180319200113-f8cee0ff968a
vgo: finding github.com/go-gl/gl v0.0.0-20180319200113-f8cee0ff968a
vgo: downloading github.com/go-gl/gl v0.0.0-20180319200113-f8cee0ff968a

Contents of go.mod:
module "github.com/mewspring/pixel-vgo-example"

require (
	"github.com/faiface/glhf" v0.0.0-20170610131041-98c0391c0fd3
	"github.com/faiface/mainthread" v0.0.0-20171120011319-8b78f0a41ae3
	"github.com/faiface/pixel" v0.7.0
	"github.com/go-gl/gl" v0.0.0-20180319200113-f8cee0ff968a
	"github.com/go-gl/glfw" v0.0.0-20170814180746-513e4f2bf85c
	"github.com/go-gl/mathgl" v0.0.0-20180319210751-5ab0e04e1f55
	"github.com/pkg/errors" v0.8.0
	"golang.org/x/image" v0.0.0-20180314180248-f3a9b89b59de
)

However, running vgo build again does not work as the version of Pixel is v0.7, and vgo rewrites it to v0.7.0 which results in 404.
u@x220 ~/D/g/s/g/m/pixel-vgo-example> vgo build
vgo: finding github.com/faiface/pixel v0.7.0
vgo: github.com/faiface/pixel v0.7.0: unexpected status (https://api.github.com/repos/faiface/pixel/git/refs/tags/v0.7.0): 404 Not Found
vgo: finding github.com/faiface/pixel v0.7.0
vgo: github.com/faiface/pixel v0.7.0: unexpected status (https://api.github.com/repos/faiface/pixel/git/refs/tags/v0.7.0): 404 Not Found
vgo: unexpected status (https://api.github.com/repos/faiface/pixel/git/refs/tags/v0.7.0): 404 Not Found

authors: franciscocpg mewmew mmikulicic


text:
cmd/link: don't assume all sections but __PKGDEF are object files

I'm currently implementing support for modular static analysis in Google's build system. Unlike "go vet", which saves analysis facts in a .vetx file known to the build system, I'm taking the approach of storing the facts in an extra section in the .a files produced by cmd/pack, as this requires no changes to the build system. Analysis facts are thus, fittingly, treated much like type checker facts, which are recorded in the __PKGDEF section. Unfortunately, cmd/link blindly assumes that all sections not named __PKGDEF are object files, and tries to link them.
cmd/link should use a better heuristic for deciding what sections to link than section.Name != "__PKGDEF"; I propose strings.HasSuffix(section.Name, ".o").  Do we ever care about object files not called *.o?

Answering my own question: the name field is only 16 bytes so we can't rely on the file name suffix being untruncated, and thus the heuristic will have to rely on the prefix. So, how about !strings.HasPrefix(section.Name, "__")? Only a fool* would choose to name their file that way.
*hold my beer


text:
proposal: cmd/gofmt: deprecate 'gofmt' in favor of 'go fmt'

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

$ go version
go version go1.12.7 linux/amd64

Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (go env)?
go env Output
$ go env

What did you do?

What did you expect to see?
Currently is gofmt and go fmt are both used in the community for formatting. go fmt runs gofmt -l -w on packages. The args for gofmt are system paths, for go fmt - packages.
Can't we just use go fmt with the full set of gofmt args and depricate gofmt?
At least for a newbies it's a little bit confusing gofmt vs go fmt - why there are 2 things that does appr. the same thing?
What did you see instead?

/cc @bcmills

gofmt can be used as a Unix-style filter, which reads source code from stdin and prints the formatted source to stdout. go fmt currently cannot - invoking it without arguments formats the package in the current working directory - although I think that could be changed without breaking the latter use case.
At least in the abstract, I like the idea of merging the two or explicitly recommending one. It would, to some extent, parallel how go vet became the recommended way to invoke vet, rather than using go tool vet directly.

CC @ianthehat @jayconrod

I don't think this is a good idea; see @rsc's comment in a related issue.
I guess we could teach go fmt to behave like gofmt given some flag or knob, but there are still lots of programs and scripts out there that require gofmt.
It's also worth noting that gofmt is a relatively small and simple binary, while go fmt is part of cmd/go, which is a comparatively massive suite of tools, often including a compiler and linker.

Duplicate of #35258.

authors: bcmills dpinela ialidzhikov julieqiu mvdan rsc


text:
how to atomic.load/store a pointer

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

go version go1.13 linux/amd64

Does this issue reproduce with the latest release?
YES
What operating system and processor architecture are you using (go env)?
go env Output
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/zylthinking/.cache/go-build"
GOENV="/home/zylthinking/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY="*.qianxin-inc.cn"
GONOSUMDB="*.qianxin-inc.cn"
GOOS="linux"
GOPATH="/home/zylthinking/go"
GOPRIVATE="*.qianxin-inc.cn"
GOPROXY="https://goproxy.io"
GOROOT="/opt/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/opt/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build825018572=/tmp/go-build -gno-record-gcc-switches"

What did you do?
package main

import (
    "fmt"
    "sync/atomic"
    "unsafe"
)

func main() {
    n := 0;
    n1 := 0;
    intp := &n;
    fmt.Println(&n, &n1);
    a := (unsafe.Pointer(&intp));
    fmt.Println(a, intp)
    atomic.StorePointer(&a, unsafe.Pointer(&n1));
    fmt.Println(a, intp)
}

What did you expect to see?
0xc00009e010 0xc00009e018
0xc0000a2018 0xc00009e010
0xc0000a2018 0xc00009e018
What did you see instead?
0xc0000a0000 0xc0000a0008
0xc000096018 0xc0000a0000
0xc0000a0008 0xc0000a0000
words
I do know how to generate the desired result, just
    a := (*unsafe.Pointer) (unsafe.Pointer(&intp));
    atomic.StorePointer(a, unsafe.Pointer(&n1));

however,  &intp is Integer pointer, but it is not a *unsafe.Pointer
it is not like (*reflect.SliceHeader) and  (*reflect.StringHeader) confirmed by std library to be compatible.

Hello @zylthinking, unlike other projects, we do not use the issue tracker for questions such as these. It is only used for bugs and feature proposals. I will close this issue, but please feel free to ask it in any of these forums below:

Stack Overflow with questions tagged "go"

The Go Forum, a web-based forum

Gophers Slack, use the invite app for access. The #general channel is a good starting point.

Go Community on Hashnode with questions and posts tagged with "go"

The golang-nuts mailing list

IRC channel #go-nuts on Freenode

Thanks

authors: agnivade zylthinking


text:
How can this be improved?

`func UploadClientFile(upload string) error { //UPLOADS CLIENT FILE TO SERVERS
var content []byte
content, err = ioutil.ReadFile(upload)
if err != nil {
	return err
}

data := []byte(content)
str := base64.StdEncoding.EncodeToString(data)

res1 := strings.ReplaceAll(upload, "\\", "_")

Base64 := UploadFile{
	Type:   "ClientFile",
	Token:  DeviceToken,
	UID:    UID(),
	UpFile: str,
	File:   res1,
}

RequestBody, err := json.Marshal(Base64)
if err != nil {
	return err
}
resp, err := http.Post(GateCNC, "application/json", bytes.NewBuffer(RequestBody))
if err != nil {
	fmt.Println("Could not connect to website to send dir file ", err)
}
defer resp.Body.Close()

fmt.Println(string(RequestBody))
CommandComplete("3") //COMPLETED

return err

}`
the issue I have with this code is if it reads a big file (5mb and etc and up) memory usage of the program goes up and never comes back down, how can this code over all be improved? I am loading in a whole file using ReadAll in to a string canthis be improved? if so can someone post how? or modify the code, I tried many things. also can the post request be improved too?

Unlike some projects, we don't use the issue tracker for questions.  You will get better and faster answers if you use a forum, as described at https://golang.org/wiki/Questions.  Thanks.
When asking the question in a forum, please explain exactly how you are measuring the memory usage of the program.  Go is a garbage collected language, so if the heap gets big for a while it will say big for several minutes even if most of the heap is no longer in use.

authors: Dontmindmes ianlancetaylor


text:
x/tools/internal/jsonrpc2_v2: test failures with "connection reset by peer"

2021-05-20T18:25:17-2275bb5/darwin-amd64-10_12
--- FAIL: TestServe (0.29s)
    --- FAIL: TestServe/tcp (0.28s)
        serve_test.go:104: dial tcp 127.0.0.1:49317: connect: connection reset by peer
FAIL
FAIL	golang.org/x/tools/internal/jsonrpc2_v2	0.515s

2021-04-12T17:45:26-2140cce/openbsd-amd64-68
--- FAIL: TestIdleTimeout (0.20s)
    serve_test.go:50: conn2.Close failed with error: failed reading header line: read tcp 127.0.0.1:25126->127.0.0.1:44239: read: connection reset by peer
FAIL
FAIL	golang.org/x/tools/internal/jsonrpc2_v2	0.532s

CC @ianthehat @findleyr

greplogs --dashboard -md -l -e '(?ms)connection reset by peer.*FAIL\s+golang\.org/x/tools/internal/jsonrpc2_v2' --since=2021-06-03
2021-10-04T20:57:50-db89b5a-e8a85e9/freebsd-amd64-race
2021-09-22T03:45:00-b98090b-051df0d/freebsd-386-11_4
2021-09-15T17:32:52-76d4494-6196979/freebsd-amd64-11_4
2021-09-11T04:35:30-915f620-170a72e/freebsd-amd64-11_2
2021-09-09T21:49:46-295a39b-21a4e67/openbsd-amd64-68
2021-08-03T20:45:05-2f64839-16ab7e4/illumos-amd64
2021-07-15T20:16:41-6e9046b-69728ea/openbsd-386-64

I don't think we're going to make progress on root causing these, but we can perhaps add a retry.

https://build.golang.org/log/68b65c83e87999b56d037bc57391e95c266a2bdc

authors: bcmills findleyr toothrot


text:
cmd/compile: cannot use .this ( type *T[interface{}]) as type T[go.shape.interface {}_0] in  T[go.shape.interface {}_0].Method

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

$ go version
go version devel go1.18-07525e1 Fri Jan 7 00:15:59 2022 +0000 darwin/amd64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
The gotip playground
What did you do?
https://gotipplay.golang.org/p/vuF7acfKTIv
What did you expect to see?
No Error.
What did you see instead?
# goerror
<autogenerated>:1: cannot use .this (type *fp.Seq[interface {}]) as type fp.Seq[go.shape.interface {}_0] in argument to fp.Seq[go.shape.interface {}_0].Append
<autogenerated>:1: cannot use .this (type *fp.Seq[interface {}]) as type fp.Seq[go.shape.interface {}_0] in argument to fp.Seq[go.shape.interface {}_0].Iterator
<autogenerated>:1: cannot use .this (type *fp.Seq[interface {}]) as type fp.Seq[go.shape.interface {}_0] in argument to fp.Seq[go.shape.interface {}_0].Size

If I remove  ToSeq or Map method of Iterator, the error goes away.

Maybe related https://github.com/golang/go/issues/50419 cc @danscales

Even though the gotip playground example is still failing, I can't seem to reproduce this locally.  I create the module directory with main.go, go.mod, and fp/fp.go, and when I do 'go run main.go, everything runs fine.  Everything runs fine locally at both 07525e1 and current tip 11b28e7e98 (and also the beta1 release becaeea119).  I also tried building with GOARCH=386 (since I thought the playground is sometimes a 32-bit machine), but that also worked fine.  Is there something different about the gotip playground that I need to account for?
Can anyone else reproduce locally?  I'm missing something.
@randall77 @cuonglm @ianlancetaylor

Oops, sorry about that, there was something mixed up in my local setup.  Now I can reproduce it fine.  Will take a look.

OK, I understand the issue and have a fix.  (Not related to #50419, since that relates to the use of blanks for typeparams.)

authors: csgura cuonglm danscales