text:
Problem with creating C# project with latest custom mono and godot build

Godot version:
Godot latest build from Github ( 3.1 Alpha 3 / custombuild )
OS/device including version:
Ubuntu 18.04 and Mono 5.23.0 latest build from github.
OpenGL ES 3.0 Renderer: AMD Radeon (TM) RX 480 Graphics
Editing project: /home/sourceskyboxer/TestCS_Alpha3_1 (::home::sourceskyboxer::TestCS_Alpha3_1)
OpenGL ES 3.0 Renderer: AMD Radeon (TM) RX 480 Graphics
Issue description:
"Failed to create C# project" If I use copy_mono_runtime=yes
It looks can't resolve
Steps to reproduce:
Create new project and mono -> create C# solution than it throws alert "Failed to create C# project!"
Minimal reproduction project:
Same Step to reproduce
History of compilation and testing
I download mono from github
./autogen.sh --prefix=/usr --enable-big-arrays --enable-large-heap=yes
make -j32
sudo make install
and download godot from github
scons p=x11 tools=yes module_mono_enabled=yes mono_glue=no copy_mono_root=yes -j 32
bin/godot.x11.tools.64.mono --generate-mono-glue modules/mono/glue
Here is my output:
https://gist.github.com/SourceSkyBoxer/64222696be7b0af0b9ea932d2f003786
And I build it:
scons p=x11 target=release_debug tools=yes module_mono_enabled=yes copy_mono_root=yes -j 32
And open it than I create new project and select mono -> create C# solution
It throws

// EDIT - I add for open with existing project
Open with existing projects than godot crashed
https://gist.github.com/SourceSkyBoxer/1c5f8223056dcf1bece7fd85676d5d73
//
That is proof - why do I not get solution. I can't believe that. Is it buggy or I should roll back with Mono runtime version?
But I have installed MonoDevelop here and my own C# development works fine with latest version of Mono runtime.

do you have a working msbuild?

Also can you try running with TERM=linux godot.x11 ... ?

Hello @hpvb  Thanks funny monkey,
Yes I am using msbuild from Mono 5.18.0 ( Mono custom build was critical because it has problem like runtime is not stable. but mkbundle works fine.)
I have compiled mkbundle from custom mono and copy into Mono 5.18
Godot 3.0.6 + Mono 5.18 = no problem and no any issues = COMPLETED SUCCESSFULLY
Godot 3.1 Alpha 3 / custom version + Mono 5.18 = If I create C# solution = It happens it looks crazy :(
Bonus Fix: Godot 3.0.6 and Mono 5.18 with custom mkbundle version from mono latest build = It sis successfully.
So sad for latest version sometime not works....

Are you using the same project? Can you test by creating a completely new empty project if you haven't.

Yeah I have create new project from Godot 3.06 + Mono 5.18 = No problem
Godot latest + 5.18 = no work for creating project and opening exited project = No success and it throws errors
That is why existing project or new creating project looks like don't work yet. Please check Godot -> #csharp from Discord Server My name is Jens Eckervogt.

copy_mono_root doesn't do anything on 3.0.6 it is a new feature. I'm still really not clear on what you're trying to do or what the problem is.
Can you give us the console output of when you get the 'cannot create C# project' error?

Oh @hpvb Oh sorry my bad English. I explain easy Godot 3.0.6 with Mono 5.18.0 and it works fine.
I will show you video like this.
https://www.youtube.com/watch?v=Y-YdmT9_NzM
I show you with latest Godot + Mono 5.18.0 = Error and criticality
https://www.youtube.com/watch?v=KE8DJmlbQy0
That is proof because 2 different ways stable Godot and latest Godot. And thanks! Please fix critical issue for latest Godot build

The C# build system and solution architecture has changed significantly since 3.1alpha3. These issues are likely no longer present in 3.3 (or in a different form), closing. To avoid opening a duplicate, please search for other related topic:mono
issues before opening a new issue.

authors: Calinou SourceSkyBoxer exts ghost hpvb


text:
File.READ_WRITE only reads OR writes

Godot 3.1 alpha 3
Windows 10 x64
In the documentation for the File.READ_WRITE mode, it says "Opens the file for read and write operations." However, it only appears to work for read or write, depending on which operation happens first.
For example, consider the following read operation::
#read operation
var testString = file.get_line()

and write operation:
#write operation
file.store_string("this is fun text")

Only one of those lines will work, specifically the one that happens first. If you reverse the order, then the other one will work.
I'm not sure if this is intended behavior, but it makes me wonder what's the point of having a File.READ_WRITE, if it is not much different than just opening the file with File.READ and File.WRITE separately.

Can't reproduce. Both lines worked.

Might be Windows-specific, does it allow read+write file handles?

godot_file_READ_WRITE_issue.zip
I attached a minimal project showcasing the issue.
To be more verbose, consider two snippets of code:
In this snippet, the get_line operation works, but not the get_line
var file = File.new()
file.open("res://testfile.txt", File.READ_WRITE)

var testString = file.get_line()
print(testString)

file.store_string("this is fun text")

However, if you reverse the order, as shown below, the store_string operation works, but not the get_line operation.
var file = File.new()
file.open("res://testfile.txt", File.READ_WRITE)

file.store_string("this is fun text")

var testString = file.get_line()
print(testString)

Can reproduce with the given project. On Linux it works as expected (the second line is overwritten):
This is text
this is fun textxt is fun or something

On Windows, the write operation fails silently. (unless seek is called before writitng)

source: gharchive/issue

authors: Naryosha Oranjoose akien-mga

repo: godotengine/godot

license: MIT

license_type: permissive

license_source: github-api


text:
iOS error spam "500" [GLES3]

Godot version:
Commit 3b2e854f4bbcac2f5ed752c95a7d2dbcd5f5f915
OS/device including version:
iOS, tested on iPhone 7 - Apple A10 GPU
Issue description:
Error log fills up with 500 error
Traced this down to the _copy_screen function here:
https://github.com/godotengine/godot/blob/master/drivers/gles3/rasterizer_scene_gles3.cpp#L4058
This call tries to invalidate the depth stencil buffer but iOS doesn't like it. Remove that or change it to the depth buffer and it's happy.
Steps to reproduce:
Run any project under iOS that does something with 3D. Even just rendering a cube is fine.

This did not get fixed by the framebuffer fix, this is a separate issue.

I think it was a different one, but I am confident it should be fixed now, so closing.

authors: BastiaanOlij reduz


text:
Linux android build error: can't find libz.so.1

I am tryn to build for android and i came to a few problems but managed to fix them. Now though i get an that a libz shared file is missing form godot.
Buildfile: /home/carlos/Documents/godot-source/platform/android/java/build.xml
-set-mode-check:
-set-debug-files:
-check-env:
[checkenv] Android SDK Tools Revision 24.4.1
[checkenv] Installed at /opt/android-sdk-linux
-setup:
[echo] Project Name: Godot
[gettype] Project Type: Application
-set-debug-mode:
-debug-obfuscation-check:
-pre-build:
-build-setup:
[getbuildtools] Using latest Build Tools: 23.0.2
[echo] Resolving Build Target for Godot...
[gettarget] Project Target:   Android 4.4.2
[gettarget] API level:        19
[echo] ----------
[echo] Creating output directories if needed...
[echo] ----------
[echo] Resolving Dependencies for Godot...
[dependency] Library dependencies:
[dependency]
[dependency] ------------------
[dependency] Ordered libraries:
[dependency]
[dependency] ------------------
[echo] ----------
[echo] Building Libraries with 'debug'...
nodeps:
-set-mode-check:
-set-debug-files:
-check-env:
[checkenv] Android SDK Tools Revision 24.4.1
[checkenv] Installed at /opt/android-sdk-linux
-setup:
[echo] Project Name: play_licensing
[gettype] Project Type: Android Library
-set-debug-mode:
-debug-obfuscation-check:
-pre-build:
-build-setup:
[getbuildtools] Using latest Build Tools: 23.0.2
[echo] Resolving Build Target for play_licensing...
[gettarget] Project Target:   Android 4.0.3
[gettarget] API level:        15
[echo] ----------
[echo] Creating output directories if needed...
[mkdir] Created dir: /home/carlos/Documents/godot-source/platform/android/libs/play_licensing/res
[mkdir] Created dir: /home/carlos/Documents/godot-source/platform/android/libs/play_licensing/libs
[mkdir] Created dir: /home/carlos/Documents/godot-source/platform/android/libs/play_licensing/bin
[mkdir] Created dir: /home/carlos/Documents/godot-source/platform/android/libs/play_licensing/bin/res
[mkdir] Created dir: /home/carlos/Documents/godot-source/platform/android/libs/play_licensing/bin/rsObj
[mkdir] Created dir: /home/carlos/Documents/godot-source/platform/android/libs/play_licensing/bin/rsLibs
[mkdir] Created dir: /home/carlos/Documents/godot-source/platform/android/libs/play_licensing/gen
[mkdir] Created dir: /home/carlos/Documents/godot-source/platform/android/libs/play_licensing/bin/classes
[mkdir] Created dir: /home/carlos/Documents/godot-source/platform/android/libs/play_licensing/bin/dexedLibs
[echo] ----------
[echo] Resolving Dependencies for play_licensing...
[dependency] Library dependencies:
[dependency] No Libraries
[dependency]
[dependency] ------------------
[dependency] API<=15: Adding annotations.jar to the classpath.
-code-gen:
[mergemanifest] Merging AndroidManifest files into one.
[mergemanifest] Manifest merger disabled. Using project manifest only.
[echo] Handling aidl files...
[aidl] No AIDL files to compile.
[echo] ----------
[echo] Handling RenderScript files...
[echo] ----------
[echo] Handling Resources...
[aapt] Generating resource IDs...
[aapt] /opt/android-sdk-linux/build-tools/23.0.2/aapt: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory
BUILD FAILED
/opt/android-sdk-linux/tools/ant/build.xml:597: The following error occurred while executing this line:
/opt/android-sdk-linux/tools/ant/build.xml:649: The following error occurred while executing this line:
/opt/android-sdk-linux/tools/ant/build.xml:694: null returned: 127

I don't have much experience with building for android so I might be missing something, but why aren't you using the scons buildsystem to build for android?

I did use the scons build system to create the .so file that ends up in the bin. I am on the last step of building for android and that requires ant to make the apk file i need.

Thanks for the clarification. Did you initialize the build with builtin_zlib=no?

No i did not, i only did this (ant debug) so i should try it like this (ant debug builtin_zlib=no)

I don't know if ant knows this option, it comes from the scons buildsystem. But by default it uses builtin_zlib=yes, which is why I'd expect it not too complain about missing libz.so.1.

I did change something in the java folder. It is the name of a .zip folder called libs. I changed the name to lib because in the steps from the android compile documentation it says to copy the .so file into java/libs/armeabi and because the .zip folder was named libs it was not letting me create the libs folder so i changed it to lib. I don't know if that has anything to do with it or not.

Found the problem this was my stupidity. I needed to install a package i didn't have just in case someone else is having this problem installing the package lib32z1 on ubuntu will solve this issue.

authors: akien-mga carlosmarti


text:
Gridmap warning

Godot version:
3.1 Stable
OS/device including version:
Ubuntu Linux. XFce
Issue description:
Warning  GridMap.theme/get_theme() is deprecated and will be removed in a future version. Use GridMap.mesh_library/get_mesh_library() instead shows up in Output tab. I'm not using it anywhere, must be inside engine. It actually does not have visible effect on game. It is rather case of annoying thing.
Steps to reproduce:
I have no idea. It sometimes shows, sometimes not. Seems random to me but I'm indeet using grid map to build level. There seems to be no other requestment to trigger warning than having active grid map.

Probably some of the levels you have are still using the old GridMap.theme inside the scene file, instead of the newer GridMap.mesh_library. Just resave those levels or replace the property name manually.
Something like s/theme =/mesh_library =/ should work.

Probably some of the levels you have are still using the old GridMap.theme inside the scene file, instead of the newer GridMap.mesh_library. Just resave those levels or replace the property name manually.
Something like s/theme =/mesh_library =/ should work.

Nope, I started developing in 3.1 Stable. Plus, it pops up sometimes which means it pops only when it is called.As I mentioned, I'm not using it anywhere, it must be inside engine. Everything was made in 3.1 stable. I suspect it is leftover from older versions of editor.

To show this warning only need to create and save empty gridmap

The problem is caused when the node saving code actually iterates over every property in the GridMap class to get values.
Since theme is still a part of the properties (although deprecated) the get_theme() method is called.
Solutions I can think of:

ignore the warning
Remove the theme from the properties - which kinda breaks compatibility (unsure)
Workaround to skip deprecated attributes from being called. (A lot of extra effort and modifications that don't feel worth it)

authors: Garrom KidRigger bojidar-bg qarmin


text:
Socket Error 54

Godot version:

3.1.stable.mono.official
OS/device including version:

MacOS Mojave
Issue description:

I downloaded the procedural planet generation project from:
https://github.com/Bauxitedev/stylized-planet-generator
But when I try to run it, I get the following error:
** Debug Process Started **
drivers/unix/net_socket_posix.cpp:199 - Socket error: 54
** Debug Process Stopped **
Steps to reproduce:
Download this github project and try to run.
Minimal reproduction project:

See the github project.

Can't reproduce on non mono Godot

drivers/unix/net_socket_posix.cpp:199 - Socket error: 54

It's just a crash of the debugger, it happens when the game process is crashed
It's not clear how to fix it, without MacOS of course, at least it does not happen on Windows, it also can be a driver-related bug

It happens to me too.

MacBook Pro mid 2015 - Intel Iris Pro 1536 MB
OpenGL ES 3.0 Renderer: Intel Iris Pro OpenGL Engine

It seems to happen when I have too many Particles2D with different materials. I've tried with 2 and works fine, but with 3, it crashes.
I can have 3 or more Particles2D with the same material though.

Can you provide minimal project?

Yes, I'll try to post it when I can :)
I was following this tutorial, if it helps for the moment https://www.youtube.com/watch?v=RZiLFdUXI2c

Try closing the project and re-opening. When I got this error it was because it couldn't find the location of some images after I moved things around.

I was hitting this as well, and I can confirm that closing then reopening resulted in it working as expected.

Disabling "Wait for debugger" in the "Project > Debugger" settings fixes the issue for me. Of course, since I'm using an external debugger, I would really prefer I did not have to disable this.
In my case, this happened when I cloned the project to a new computer. So I'm not sure whether it's the version of Godot or the version of Mono that's causing the problem. It was working before I moved computers.

The issue appears for me when deleting scene dependencies such as materials or other resource files

Can anyone still reproduce this bug in Godot 3.2.3 or any later release?

authors: Chaosus G3bE KoBeWi hiulit joshbenner qarmin robgraeber shianiawhite trumanellis


text:
Review and cleanup GlobalScope constants for 4.0

Godot version:
Master (e2bbf2cba)
Issue description:
The @GlobalScope documentation lists a number of constants which are no longer used, especially among property hints, usage flags and method flags.
The list should be reviewed for 4.0 to drop obsolete stuff, including their duplicate entries in the GDNative API.
See also #16863.

If anyone wants to do this review and propose potential changes, feel free to. I'm not finding time to do it myself and if it's not done soon, it's best to drop the idea for now.

Quite a few things have been updated over the years there. We did another pass over PropertyHint / PropertyUsage stuff with @reduz and @YuriSizov, seems like it's in a good enough state now.


text:
Mono/Android - DateTime.Now crashes the game on Android

Godot version:
3.2 Beta 2 (Mono)
OS/device including version:
Android 10, Build QP1A.191105.003
Google Pixel 3a
Issue description:
Using System.DateTime.Now will instantly crash the game
Log from adb logcat
11-23 18:46:23.164 29219 29271 E mono    :
11-23 18:46:23.164 29219 29271 E mono    : Unhandled Exception:
11-23 18:46:23.164 29219 29271 E mono    : System.DllNotFoundException: __Internal assembly:<unknown assembly> type:<unknown type> member:(null)
11-23 18:46:23.164 29219 29271 E mono    :   at (wrapper managed-to-native) System.TimeZoneInfo+AndroidTimeZones.monodroid_get_system_property(string,intptr&)
11-23 18:46:23.164 29219 29271 E mono    :   at System.TimeZoneInfo+AndroidTimeZones.GetDefaultTimeZoneName () [0x00029] in <3b08f2249ec641d8b691b85bde6bce48>:0
11-23 18:46:23.164 29219 29271 E mono    :   at System.TimeZoneInfo+AndroidTimeZones.get_Local () [0x00000] in <3b08f2249ec641d8b691b85bde6bce48>:0
11-23 18:46:23.164 29219 29271 E mono    :   at System.TimeZoneInfo.CreateLocal () [0x00000] in <3b08f2249ec641d8b691b85bde6bce48>:0
11-23 18:46:23.164 29219 29271 E mono    :   at System.TimeZoneInfo.get_Local () [0x00009] in <3b08f2249ec641d8b691b85bde6bce48>:0
11-23 18:46:23.164 29219 29271 E mono    :   at System.TimeZoneInfo.GetDateTimeNowUtcOffsetFromUtc (System.DateTime time, System.Boolean& isAmbiguousLocalDst) [0x00000] in <3b08f2249ec641d8b691b85bde6bce48>:0
11-23 18:46:23.164 29219 29271 E mono    :   at System.DateTime.get_Now () [0x00008] in <3b08f2249ec641d8b691b85bde6bce48>:0
11-23 18:46:23.164 29219 29271 E mono    :   at Nodey._Ready () [0x00001] in <47566f4059054cfabb0b52642f33fb86>:0

Steps to reproduce:

Create a C# Script, and Print out System.DateTime.Now.ToString() (for example)
Build to an Android device

Minimal reproduction project:
Test.zip

Not a permissions issue, checked all of them


text:
crash report

Godot version:
3.2
OS/device including version:
Mac OS X 10.15.3 (19D76)
Issue description:
The scene editor has no response when switch scene tab, then it quit.
It happens very frequently.
Steps to reproduce:
It happens randomly without any particular steps.
Minimal reproduction project:
crash.txt

Please fill out the template. We need more info to help you!

Godot version:
3.2.1.rc1.official
OS/device including version:
Windows 7 SP1 x64
Steps to reproduce:

Create new project
Add Node2D (for example)
Save Scene and closed tab - tab1
Reopened closed scene
Add new tab - tab2
Go to previous tab (tab1) and delete node
Go to tab2 and back to tab1
Crash

authors: alexzheng clayjohn kant1989


text:
Errors in the Editor from core classes?

I'm getting two odd errors reported in the debugger when working with the release candidate, these errors don't appear to be related to anything in my project, the errors are always present when I'm working in this release candidate, if this error isn't present for others I'm not sure how to recreate the issue. System is Windows 10, graphics card is Geforce 780. Here are the specific errors being reported:
Type: Error
Description:
Time: 0:00:00:0340
C Error: Condition '!elem' is true. returned: __null
C Source: core/rid.h:146
C Function: get
Type: Error
Description:
Time 0:00:00:0342
C Error: Condition '!texture' is true
C Source drivers/gles2/rasterizer_gles2.cpp:1268
C Function: texture_set_flags

What is the status on current master? (I don't think its fixed, but still)

Assumed fixed in master, I haven't seen similar reports recently.

authors: Faustabov akien-mga bojidar-bg


text:
Incorrect operator property for visual script nodes.

Godot version
4.0 Dev (92f75046378a63b46946e8acbd7c224f027ebfa5)
System information
Windows 10, OpenGL ES 3.0 Renderer: AMD Radeon(TM) Vega 10 Graphics
Issue description
Name of the operator property in the inspector does not match with the type of Visual Script node. This is happening for bitwise and logical operator nodes.
The issue is not observed in 3.3.x stable builds. I believe this is side effect of new implementation of variant operators added in https://github.com/godotengine/godot/pull/43323.
Please check the screenshot animation below for exact issue.

I have made required changes to fix this issue, will submit the PR as well for review.
Steps to reproduce

Add visual script to any node
Inside visual script editor add a node "Bitwise Shift Left".
Observe that operator property in inspector shows "concatenate"
Add another node "Logical AND", observe the operator property in the inspector shows "Bit Negate"

Minimal reproduction project
I will submit if can't be re-produced with steps given.

Note: related PR merged recently #49831 (fixes a similar issue but for captions).

authors: MisoMosiSpy akien-mga


text:
Godot randomly crashes with radeon that fails to dealloccate virtual address for buffer

Godot version
3.3.3
System information
Linux kernel: 5.10.63-1-MANJARO
GPU model: AMD Radeon R7 M270
GPU Driver: xf86-video-amdgpu 21.0.0-1
Rendering backend: GLES3
Godot first lines log:
Godot Engine v3.3.3.stable.arch_linux - https://godotengine.org
Found discrete GPU, setting DRI_PRIME=1 to use it.
Note: Set DRI_PRIME=0 in the environment to disable Godot from using the discrete GPU.
OpenGL ES 3.0 Renderer: AMD OLAND (DRM 2.50.0, 5.10.63-1-MANJARO, LLVM 12.0.1)

Issue description
radeon: Failed to deallocate virtual address for buffer:
radeon:    size      : 65536 bytes
radeon:    va        : 0x1492f0000
radeon: Failed to deallocate virtual address for buffer:
radeon:    size      : 65536 bytes
radeon:    va        : 0x149780000
radeon: Failed to deallocate virtual address for buffer:
radeon:    size      : 65536 bytes
radeon:    va        : 0x149250000
radeon: Failed to deallocate virtual address for buffer:
radeon:    size      : 131072 bytes
radeon:    va        : 0x1493f0000
radeon: Failed to deallocate virtual address for buffer:
radeon:    size      : 131072 bytes
radeon:    va        : 0x149920000
radeon: Failed to deallocate virtual address for buffer:
radeon:    size      : 131072 bytes
radeon:    va        : 0x149940000
radeon: Failed to deallocate virtual address for buffer:
radeon:    size      : 131072 bytes
radeon:    va        : 0x149960000
radeon: Failed to deallocate virtual address for buffer:
radeon:    size      : 262144 bytes
radeon:    va        : 0xa40000
handle_crash: Program crashed with signal 11
Dumping the backtrace. Please include this when reporting the bug on https://github.com/godotengine/godot/issues
[1] /usr/lib/libc.so.6(+0x3cda0) [0x7f11df65eda0] (??:0)
[2] /usr/lib/libc.so.6(+0x1636f9) [0x7f11df7856f9] (??:0)
[3] /usr/lib/dri/radeonsi_dri.so(+0x2580fd) [0x7f11dc39c0fd] (??:0)
[4] /usr/lib/dri/radeonsi_dri.so(+0x2532af) [0x7f11dc3972af] (??:0)
[5] /usr/lib/dri/radeonsi_dri.so(+0x22e2ea) [0x7f11dc3722ea] (??:0)
[6] /usr/lib/dri/radeonsi_dri.so(+0x300715) [0x7f11dc444715] (??:0)
[7] /usr/lib/dri/radeonsi_dri.so(+0x30f413) [0x7f11dc453413] (??:0)
[8] godot(+0xeec1be) [0x560d7345d1be] (??:0)
[9] godot(+0xef1b75) [0x560d73462b75] (??:0)
[10] godot(+0x26f0c3a) [0x560d74c61c3a] (??:0)
[11] godot(+0x2701380) [0x560d74c72380] (??:0)
[12] godot(+0x2723807) [0x560d74c94807] (??:0)
[13] godot(+0x27245e6) [0x560d74c955e6] (??:0)
[14] godot(+0x27258cd) [0x560d74c968cd] (??:0)
[15] godot(+0x26eb432) [0x560d74c5c432] (??:0)
[16] godot(+0x6981aa) [0x560d72c091aa] (??:0)
[17] godot(+0x67af24) [0x560d72bebf24] (??:0)
[18] godot(+0x665e2f) [0x560d72bd6e2f] (??:0)
[19] /usr/lib/libc.so.6(__libc_start_main+0xd5) [0x7f11df649b25] (??:0)
[20] godot(+0x66a03e) [0x560d72bdb03e] (??:0)
-- END OF BACKTRACE --

Steps to reproduce
There is not steps to reproduce, it just randomly happens.
Minimal reproduction project
None

Also after the Godot crash my OS crashes as well

For me this is almost 100% driver bug.
Can you upgrade Mesa to the latest available version(21.2 or even 21.3 GIT)?
Did you tried to follow this instructions - https://askubuntu.com/questions/1157235/amd-radeon-r5m430-gpu-error-while-attempting-to-use-dri-prime-1-failed-to-all?

For me this is almost 100% driver bug. Can you upgrade Mesa to the latest available version(21.2 or even 21.3 GIT)?
Did you tried to follow this instructions - https://askubuntu.com/questions/1157235/amd-radeon-r5m430-gpu-error-while-attempting-to-use-dri-prime-1-failed-to-all?

Mesa is already at version 21.2.1-1
Also the issue on the link you provided seems to be when using the DRI_PRIME=1 while mine has no issue with that,
my issue it that the engine crashes randomly while using it, not on startup.

Also i think it important to point out that when the engine crashes the editor window still remains open frozen and the process becomes godot <defunc>

A theory would be that available dedicated video memory of your graphics card has been exceeded, so your graphics card proceeds to deallocate memory without Godot acknowledging, thus when the deallocation should happen it is just unable to do so.
Although, there's an older issue regarding the same problem: #26606

A theory would be that available dedicated video memory of your graphics card has been exceeded, so your graphics card proceeds to deallocate memory without Godot acknowledging, thus when the deallocation should happen it is just unable to do so.
Although, there's an older issue regarding the same problem: #26606

Yeah it looks like we have (maybe exactly) the same issue as the one you referenced, this was opened 3 years ago and the issue didn't get much attention, don't know if this is a Godot issue or a dedicated graphics card driver issue. At least I hope that there is a solution to it and I will not be forced to run Godot with the integrated GPU as it has worse performance.

authors: PanTrakX qarmin simple0x47


text:
Exporting to Android aab is missing assets

Godot version
3.x
System information
Windows 10
Issue description
It seems the custom android export to aab no longer includes the assets of the project, could this have anything
to do with commit 35a98d305bf4133fdfc33c18d269226bff5aa416 "Add support for Play Asset Delivery."
Exporting an apk works fine. Is is possible to disable this assetPacks feature?
Steps to reproduce
Install Android build template, Use custom build, Select Export AAB, close the export dialog. Run the project on an android device/emulator, it will crash on start.
Minimal reproduction project
No response

bundlefail.zip
A small example project. I had to remove the android/build/libs/debug/godot-lib.debug.aar from zip, else the upload file is too large.
I was compiled using the current head of 3.x

@daansystems can you specify the commands you're using to run the project, and which version of Android you're running the project on.
Can you also provide the crash stack trace.

@m4gr3d , I'm just clicking the run on android device icon in godot's main window.
here's the build config:
ext.versions = [
    androidGradlePlugin: '4.2.1',
    compileSdk         : 29,
    minSdk             : 18,
    targetSdk          : 29,
    buildTools         : '30.0.3',
    supportCoreUtils   : '1.0.0',
    kotlinVersion      : '1.5.10',
    v4Support          : '1.0.0',
    javaVersion        : 1.8,
    ndkVersion         : '21.4.7075529' // Also update 'platform/android/detect.py#get_project_ndk_version()' when this is updated.
]

The stacktrace of the crash:
10-02 17:31:16.734 12222 12222 W System.err: java.io.FileNotFoundException: _cl_
10-02 17:31:16.735 12222 12222 W System.err:    at android.content.res.AssetManager.nativeOpenAsset(Native Method)
10-02 17:31:16.735 12222 12222 W System.err:    at android.content.res.AssetManager.open(AssetManager.java:874)
10-02 17:31:16.735 12222 12222 W System.err:    at android.content.res.AssetManager.open(AssetManager.java:851)
10-02 17:31:16.735 12222 12222 W System.err:    at org.godotengine.godot.Godot.parseCommandLine(Godot.java:497)
10-02 17:31:16.736 12222 12222 W System.err:    at org.godotengine.godot.Godot.getCommandLine(Godot.java:480)
10-02 17:31:16.736 12222 12222 W System.err:    at org.godotengine.godot.Godot.onCreate(Godot.java:614)
10-02 17:31:16.736 12222 12222 W System.err:    at androidx.fragment.app.Fragment.performCreate(Fragment.java:2414)
10-02 17:31:16.736 12222 12222 W System.err:    at androidx.fragment.app.FragmentManagerImpl.moveToState(FragmentManager.java:1418)
10-02 17:31:16.737 12222 12222 W System.err:    at androidx.fragment.app.FragmentTransition.addToFirstInLastOut(FragmentTransition.java:1195)
10-02 17:31:16.737 12222 12222 W System.err:    at androidx.fragment.app.FragmentTransition.calculateFragments(FragmentTransition.java:1078)
10-02 17:31:16.737 12222 12222 W System.err:    at androidx.fragment.app.FragmentTransition.startTransitions(FragmentTransition.java:117)
10-02 17:31:16.737 12222 12222 W System.err:    at androidx.fragment.app.FragmentManagerImpl.executeOpsTogether(FragmentManager.java:2408)
10-02 17:31:16.737 12222 12222 W System.err:    at androidx.fragment.app.FragmentManagerImpl.removeRedundantOperationsAndExecute(FragmentManager.java:2366)
10-02 17:31:16.737 12222 12222 W System.err:    at androidx.fragment.app.FragmentManagerImpl.execSingleAction(FragmentManager.java:2243)
10-02 17:31:16.737 12222 12222 W System.err:    at androidx.fragment.app.BackStackRecord.commitNowAllowingStateLoss(BackStackRecord.java:654)
10-02 17:31:16.737 12222 12222 W System.err:    at org.godotengine.godot.FullScreenGodotApp.onCreate(FullScreenGodotApp.java:61)
10-02 17:31:16.737 12222 12222 W System.err:    at com.godot.game.GodotApp.onCreate(GodotApp.java:45)
10-02 17:31:16.737 12222 12222 W System.err:    at android.app.Activity.performCreate(Activity.java:8000)
10-02 17:31:16.737 12222 12222 W System.err:    at android.app.Activity.performCreate(Activity.java:7984)
10-02 17:31:16.738 12222 12222 W System.err:    at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1309)
10-02 17:31:16.738 12222 12222 W System.err:    at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3422)
10-02 17:31:16.738 12222 12222 W System.err:    at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3601)
10-02 17:31:16.738 12222 12222 W System.err:    at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:85)
10-02 17:31:16.739 12222 12222 W System.err:    at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:135)
10-02 17:31:16.739 12222 12222 W System.err:    at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:95)
10-02 17:31:16.739 12222 12222 W System.err:    at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2066)
10-02 17:31:16.739 12222 12222 W System.err:    at android.os.Handler.dispatchMessage(Handler.java:106)
10-02 17:31:16.739 12222 12222 W System.err:    at android.os.Looper.loop(Looper.java:223)
10-02 17:31:16.739 12222 12222 W System.err:    at android.app.ActivityThread.main(ActivityThread.java:7656)
10-02 17:31:16.739 12222 12222 W System.err:    at java.lang.reflect.Method.invoke(Native Method)
10-02 17:31:16.739 12222 12222 W System.err:    at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
10-02 17:31:16.739 12222 12222 W System.err:    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:947)

10-02 17:31:17.069 12222 12275 E godot   : ERROR: Couldn't load file 'res://project.binary', error code 19.
10-02 17:31:17.071 12222 12275 E godot   :    at: _load_settings_text_or_binary (core\project_settings.cpp:600) - Couldn't load file 'res://project.binary', error code 19.

This is probably caused by the missing of the assets directory in the apk/bundle.

It could also be a version mismatch. Did you generate and install the custom build template from the exact same commit that you use for the editor? Alternativel, do you have this issue with official 3.4 beta 5 builds (also making sure to reinstall the source template with that version).

@jimbofoo This looks like a version mismatch. Your compileSdk version is 29 while the version with play asset delivery support should be 30.
Make sure you delete you're android directory in the project and recreate it using the Install Android Build Template... option.

I can reproduce the issue with the build from:
https://downloads.tuxfamily.org/godotengine/3.4/beta5/
I've reinstalled the android build template from the export templates.
I have uploaded the full project with the android custom build here:
https://www.daansystems.com/tmp/godot_issue_53328.zip
I've also create a little movie displaying the issue
https://user-images.githubusercontent.com/4447520/135727577-9e75a1a6-830e-4707-bc22-f1d56bf751db.mp4

I can reproduce the issue with 3.4 beta 6 and the test project in https://github.com/godotengine/godot/issues/53328#issuecomment-932713732.
The AAB doesn't seem to include any assets aside from the icons indeed.

authors: akien-mga daansystems jimbofoo m4gr3d


text:
Prevent Godot from crashing when making a loop in scene system

This bug might be possible to do on every version of Godot
Description:
A scene has another scene as a child.
If you put to this child a child that is his parent, it will crash
e.g : "game.tscn" has" settings.tscn" as a child, "settings.tscn" has "game.tscn" as a child
If a scene is connected to one of the two scenes, it will not be playable or editable.
The game will simply crash and the editor will too (excepted if it's the first scene loaded,it will then just show an error message).
Also, if you put this scene or one of the two that are creating the loop in the script editor
e.g : preload("node_not_working.tscn")
it will fail to check the existence of the scene and crash.
There are only two ways of fixing this :

having made backups
not using a binary format to save files, for you can edit the xml by yourslef

I know this is a very dumb case, but it can happen while not watching when using the auto-fix of depencies, and then totally break a project.

Circular scene reference is impossible since 2.1.
In 3.1, you can't create a circular scene preload (it simply says "can't preload resource"), but load will work and crash the game without any message.

Is this still possible to do?

I can't seem to reproduce load() crash anymore. You can make a circular reference resulting in stack overflow when two scenes instance each other, but this is expected. The editor crash is covered by more detailed #28100
I will close this for now, if someone manages to reproduce in 3.2.3+, please comment with a reproduction project.

authors: KoBeWi ObaniGemini justchen1369


text:
Default C# script names do not match case, which prevents [Export] variables from appearing in the inspector

Godot version
v4.2.dev5.mono.official
System information
Godot v4.2.dev5.mono - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3080 Laptop GPU (NVIDIA; 31.0.15.2756) - 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz (16 Threads)
Issue description
When you use "attach script" to a node, it auto-fills a lower-case version of the node name with the .cs suffix.  For instance, when following the tutorial here [https://docs.godotengine.org/en/stable/getting_started/first_2d_game/03.coding_the_player.html)], you create a "Player" node but the default name for the c# script is "player.cs".  The c# script needs to be named "Player.cs", otherwise you can't edit/see the [Export] fields.
This is a minor issue, but is very disruptive as an initial experience.
The auto-filled script name should use the correct case.
Steps to reproduce
Create a node.  Click attach script.  Not the case of the auto-filled script name.  Observe that the [Export] variables do not work if the case is incorrect.
Minimal reproduction project
N/A

Related:

https://github.com/godotengine/godot-proposals/issues/1211
https://github.com/godotengine/godot/issues/39441

Could probably be closed as duplicate of those other issues, there's also a PR that fixes them and it should make C# default to PascalCase for script file names.

https://github.com/godotengine/godot/pull/78119

Duplicate issue, with an existing PR to fix it.  Thanks @raulsntos for the response.

authors: Rehrok raulsntos


text:
clip children doesn't work in CanvasGroup

Godot version
v4.1.3.stable.official [f06b6836a]
System information
Godot v4.1.3.stable - Windows 10.0.22621 - Vulkan (Compatibility) - Intel(R) Iris(R) Plus Graphics (Intel Corporation; 27.20.100.9664) - Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz (8 Threads)
Issue description
If a CanvasItem is a child of a CanvasGroup, all "clip children" options for the canvas item has no effect on its children besides changing the order in which they're drawn
Steps to reproduce
Create a canvas group, add 2 ColorRect nodes to it as children, make one ColorRect a child of the other, try clip-children settings of the upper ColorRect. Effects visible in editor. (Also affects sprites etc.)
Minimal reproduction project
N/A

Quoting from the CanvasGroup Documentation

Note: Since CanvasGroup and CanvasItem.clip_children both utilize the backbuffer, children of a CanvasGroup who have their CanvasItem.clip_children set to anything other than CanvasItem.CLIP_CHILDREN_DISABLED will not function correctly.

This is a design constraint of CanvasGroup and clip_children.
I agree that it is a bit annoying and there is discussion on changing how CanvasGroup's work to remove this limitation.


text:
Can't easily drag mutiple node into property shared by multiple node

Tested versions
409c71bdfd8e0a08fd726225ebdce16bc60a4570
System information
macOS 13.3.0 - Vulkan (Forward+) - integrated Apple M1 Pro - Apple M1 Pro (8 Threads)
Issue description
Since #90378 you can now easily drag and drop a batch of node inside a property of a node. Unfortunately this doesn't work for putting it in properties in multiple nodes. This is a small usability issue which is not urgent especially since improving this will most likely be hard. Maybe here the good solution would be to be able to pin the Inspector.
Steps to reproduce
N/A
Minimal reproduction project (MRP)
N/A

This sounds like a proposal, not a bug

Yeah you might be right I thought of it has a bug as the workaround would allow it if I remember correctly.

authors: AThousandShips ajreckof


text:
optimized color conversion for svg generation

After this pr:
+ SVG_GENERATION TIME: 0.680435  (with conversion)
- SVG_GENERATION TIME: 0.690145  (without conversion)
+ SVG_GENERATION TIME: 0.677619  (with conversion)
- SVG_GENERATION TIME: 0.719461  (without conversion)
+ SVG_GENERATION TIME: 0.694041  (with conversion)
- SVG_GENERATION TIME: 0.669586  (without conversion)
+ SVG_GENERATION TIME: 0.685164  (with conversion)

(0.680435 + 0.677619 + 0.694041 +  0.685164) / 4 -> 0.6843147 (with conversion)
(0.690145 + 0.719461 + 0.669586) / 3 -> 0.693064 (without)
-> so basically the same (in this test it was even faster with the conversion... but I only tested 7 times ...)
before the change:
- SVG_GENERATION TIME: 0.677409 (without conversion)
+ SVG_GENERATION TIME: 0.800365 (with conversion)
- SVG_GENERATION TIME: 0.669492 (without conversion)
+ SVG_GENERATION TIME: 0.791202 (with conversion)
- SVG_GENERATION TIME: 0.669209 (without conversion)
+ SVG_GENERATION TIME: 0.778514 (with conversion)
- SVG_GENERATION TIME: 0.6814 (without conversion)
+ SVG_GENERATION TIME: 0.789975 (with conversion)

(0.800365 + 0.791202 + 0.778514 + 0.789975) / 4 -> 0.790014 (with conversion)
(0.677409 + 0.669492 +  0.669209 + 0.6814) / 4 -> 0.6743775 (without)
-> definitely a difference. (more than 10%)

I realize that this change uses Color.to_ABGR32() and it might have conflicts with #11028

Yeah, conflicts now. Would you mind rebasing and resolving them?

source: gharchive/pull-request

authors: hpvb mrawlingst toger5


text:
Pr-allow-to-disabled-tooltip

Allow to disabled tool-tips(tool-tip not used under mobile platform like android/ios/etc)

i think this should be customizable with something in Globals.. remember that some platforms such as Android can also be used with a mouse

Thanks @reduz, people frequently forget this about mouse usage on "mobile" OS.

I agree with @reduz that this should preferably be made via a Globals setting and not a compile time option. Archiving it as it probably won't be merged as is.

authors: akien-mga reduz sanikoyes silverkorn


text:
Deselect recents when selecting favorites and vice versa in Create Node window.

Deselect recents when selecting favorites and vice versa in Create Node window.

Thanks!

authors: DualMatrix akien-mga


text:
support New TileSet Editor zooming use CTRL/CMD + MouseWheel

issue #22976 , i have implement the zooming action use CTRL/CMD + MouseWheel

Why is CTRL required? The viewport and texture region editor lets you zoom in/out with just mouse wheel.

Why is CTRL required? The viewport and texture region editor lets you zoom in/out with just mouse wheel.

In my opinion , some operations such as drawing a polygon sometime need to scroll the view, the default mousewheel handle is to scroll the view, so add CTRL when zoom in/out

Please squash the commits together, see PR workflow.

thanks , i have squashed the commits

Thanks!

authors: Liangdi Zylann akien-mga


text:
Fix inherited icons for script classes

This should close #24657. I added a loop that goes through the base classes in the script class and checks if any of them have icons, all the way up until there aren't any more scripts.

Updated

Thanks!

Cherry-picked for 3.1.1.

authors: akien-mga willnationsdev


text:
Fix "Make Scene Root" deleting previous root whenever focusing another scene

Hopefully fixes #24484 and fixes #27222.

Thanks!

Cherry-picked for 3.1.2.

authors: akien-mga bojidar-bg


text:
Translations update from Weblate

Translations update from Weblate for Godot Engine/Godot Class Reference.

Welp, looks like I forgot to turn this off.

authors: akien-mga weblate


text:
Tooltips: Improve code clarity and docs

The return type for _make_custom_tooltip is clarified as Control, and users
should make sure to return a visible node for proper size calculations.
Moreover in the current master branch, a PopupPanel will be added as parent
to the provided tooltip to make it a sub-window.
Clarifies documentation for Control._make_custom_tooltip, and shows how to
use the (until now undocumented) "TooltipPanel" and "TooltipLabel" theme types
to style tooltips.
Fixes #39677.

Supersedes #43273.
My aim initially was to re-add flexibility to Control._make_custom_tooltip in what kind of tooltip popup will be created. In 3.2 you can pass any Control to be used as is, while in master popups derive Window, and thus the custom tooltip Control created by the user is wrapped in a TooltipPanel of type PopupPanel.
I thought some users might want more flexibility here, so I tried to make TooltipPanel part of the public API, and make it so it's no longer used by default in Viewport but should be returned by users in _make_custom_tooltip, if they want it (otherwise they could use another Window-derived control for a popup window, or even another type of Control for some in-game tooltip hints). But since Popup/PopupPanel now inherit Window, they're no longer Control so we have a type mismatch. In the end, I'm not sure the flexibility I was pursuing really corresponds to actual use cases that users have (it came from my own use case in https://github.com/akien-mga/godot-debug-watermark, but I think I can work with styling TooltipPanel as documented in this PR), so I prefer to wait for user feedback before exploring a potentially more flexible API.

CC @rxlecky as this is partly based on our discussion on #39677.

Changes look good to me all in all. The docs are definitely clearer now and the extra section on theming tooltips is great, I didn't know that.
Also, I'd like to bring up my argument from https://github.com/godotengine/godot/issues/39677#issuecomment-720492032 and say that if user returns a custom tooltip Control with visible = false and there is an edge case that causes unexpected behaviour under that conditions, we should just show empty TooltipPanel. That is more of an expected behaviour than showing a tooltip which is half-cropped by window edge. I, as a user, would consider that behaviour an engine bug, rather than user error. Even though the docs are now explicitly flagging this, there will be many people who won't read it and will instead report issues about supposedly bugged tooltips.
I feel like there are three main ways we can communicate with the user, in order of accessibility:

Behaviour
Output console
Documentation

If we make the first point of contact, behaviour, confusing by showing unexpected, half-cropped tooltip, we haven't communicated the cause of the problem to the user very well. If we instead show empty tooltip panel, the user might either get a hint that their tooltip is not set to visible or it will prompt them to read the documentation where they will find answer to why tooltip is empty.

Also, I'd like to bring up my argument from #39677 (comment) and say that if user returns a custom tooltip Control with visible = false and there is an edge case that causes unexpected behaviour under that conditions, we should just show empty TooltipPanel. That is more of an expected behaviour than showing a tooltip which is half-cropped by window edge. I, as a user, would consider that behaviour an engine bug, rather than user error. Even though the docs are now explicitly flagging this, there will be many people who won't read it and will instead report issues about supposedly bugged tooltips.

In the master branch, this is actually what happens. It's only the TooltipPanel created by the engine that gets show()-ed, the Control you pass from make_custom_tooltip() is not impacted. So if it's not visible, you will indeed see an empty panel (contrarily to 3.2 where show() is called on the custom Control).

Oh, sorry, didn't realize that. That's good then. Perhaps we should replicate that behaviour in 3.2 when backporting this change.

Cherry-picked for 3.2.4.

Perhaps we should replicate that behaviour in 3.2 when backporting this change.

I chose not to as this could be considered a breaking change. IMO the fact that I was the one to report this issue even though I don't work on any serious Godot project apart from the engine itself shows that there are probably not too many users affected by this, so the documentation change should be enough for those.

authors: akien-mga rxlecky


text:
Tweak the editor CheckButton "presed" appearance to be more recognizable

The blue accent color is now used, which matches the default editor accent color. The dot contained within the slider is also now white to be visible on any background.
It doesn't change to match the currently configured accent color automatically, but doing so would require modifying the CheckButton class a lot for little benefit.
This closes https://github.com/godotengine/godot-proposals/issues/2002.
Preview
Dark

Light

Thanks!

Cherry-picked for 3.2.4.

authors: Calinou akien-mga


text:
Add ability to restore RandomNumberGenerator state

3.2 version of #44089.
get_seed() still returns the previous state and not the initial seed, because users may rely on this behavior for resetting the state in 3.2. Documented this is going to be fixed in 4.0.
func _ready():
	var rng = RandomNumberGenerator.new()
	var initial_state = rng.state
	print("Initial ", rng.state)
	print(rng.randf())
	print(rng.randf())
	print(rng.randf())
	print("Current ", rng.state)
	print("Reset to initial state...")
	rng.state = initial_state
	print(rng.randf())
	print(rng.randf())
	print(rng.randf())
	print("Current ", rng.state)

Initial -6332740101472756719
0.621225
0.978975
0.367289
Current -6028506256414837201
Reset to initial state...
0.621225
0.978975
0.367289
Current -6028506256414837201

Thanks!

Thanks!

authors: Xrayez akien-mga


text:
Fix gridmap free octans

Fix GridMap problem issue

Looks great! This fixes #33648, #43712 and #49995 which are all the same bug.
The only thing is a PR should be opened on master instead of 3.3 branch. It's the usual process for fixes that can be applied to the latest version of Godot (it will still be cherry-picked for 3.3 and 3.4).
I would suggest to close this PR and open the same one on master (switching branches causes issues with github, it's interpreted as trying to merge the whole branch).

I would suggest to close this PR and open the same one on master (switching branches causes issues with github, it's interpreted as trying to merge the whole branch).

Sorry)
This error stopped my development progress)

No worries at all, your fix is very welcome!
Let me know in case it's too much extra work for you to set things up on master. Instead another contributor can open the new PR on master and credit you for your work.

Pull PR : #50052


text:
Fix visible background line in intersections in screen-space reflections

master version of https://github.com/godotengine/godot/pull/56843.
Adjusting the step grading by one resolves the issue without affecting performance or introducing adverse artifacts.
Note: The above note about artifacts is currently not true due to a bug in the master SSR implementation that causes visible artifacts with the first step. This does not happen in 3.x and can be reproduced by setting Fade In to the Zero preset (right-click the value in the inspector).
This closes https://github.com/godotengine/godot/issues/50916.
Preview
Before

After

I don't think that https://github.com/godotengine/godot/issues/56845 is related. I would be fine merging this without addressing https://github.com/godotengine/godot/issues/56845 first

I don't think that #56845 is related. I would be fine merging this without addressing #56845 first

It's indeed not related, but this fix will make the artifacts more noticeable.

Thanks!

authors: Calinou akien-mga clayjohn


text:
fix boolean conditional

Conditional logical is probably better.  It also allows "short circuiting".

What is the problem being solved here?

What is the problem being solved here?

bitwise & changed to logical &&, more idiomatic and can be faster in some cases

That's probably just a typo. The commit message needs to be more explicit though, e.g. mention that your fix is in TextServer.

Apologies, I've adjusted the commit to be more clear.

Thanks!

authors: YuriSizov akien-mga fire firefly2442 pooroligarch


text:
Add a few missing entries in Project Converter

A few renaming PRs were merged too eagerly, and I didn't know they also had to be included in the Project Converter. So this PR includes these:

https://github.com/godotengine/godot/pull/64157
https://github.com/godotengine/godot/pull/64354
https://github.com/godotengine/godot/pull/64355

Thanks!

authors: Mickeon akien-mga


text:
Update property keying state without a full Inspector rebuild

Fixes https://github.com/godotengine/godot/issues/74275. There is a race condition that leads to crash, because we are doing two updates at the same time. First, we resetting the dictionary which changes the property editor for that property. But we are also losing the only animation, so the keying status is also reset.
Currently, changing keying state leads to update_tree and a full rebuild. This doesn't seem necessary, so I added some code to directly refresh the keying status of each property editor. In the words of the wise KoBeWi, "It can't be this simple?" So please test for regressions. But I don't see why this would be problematic in principle.
In general we should aim to reduce the need for a complete tree rebuild for 4.1. We have a few cases (my favorite is theme updates) where we could just do targeted changes. This is one of them.

There seems to be an issue with the animation editor related to the reported use case. If you hide the Animation tab, crash does not occur, which is good. But when you bring the tab back, the old animation is still displayed in the OptionButton at the top. It doesn't immediately err, but trying to add new animations throws 3 identical error messages, telling you that old_animation_name does not exist. It doesn't break anything, but it should be fixed.
But I'll leave it for the animation team to sort out, as it's not critical at the moment 🙃

This PR is basically the same as #70696, which was reverted.
I tested all the issues it previously caused and they don't seem to be happening, so I guess the code changed enough to allow this now.

Ah yes, that whole thing. Well, the approach was different, maybe that affected things (like, propagating a call through everything may be causing unnecessary race conditions).

Now that you've reminded me about the last time related issues were worked on, I think it's safer not to include it into 4.0.1 for now. We can give it a bit of time in the master branch, and if it's all good now, we can pick it for 4.0.2. Crash is not great, but the uncertainty is worse.

authors: KoBeWi YuriSizov


text:
CI: Use gh-cli for changed files, and workaround codespell skip list bug

For PRs, this should give a more accurate list, as the previous method would
diff to the tip of the master branch, which could include new commits (and
thus changed files) not present in the PR branch.
Also works around this upstream codespell bug: https://github.com/codespell-project/codespell/issues/1915
Instead of relying on the skip list for folders, we exclude them manually. .git and bin should never be part of the list of files changed in Git so we don't bother with them.
And works around another misfeature of https://github.com/codespell-project/actions-codespell - the check_hidden optional parameter is considered true if defined, even if set to false... the only way not to enable it is not to mention it.

Cherry-picked for 4.0.3.


text:
Suppress surface upgrade warnings when showing SurfaceUpgradeTool warning

This fixes the warning spam reported here: https://github.com/godotengine/godot/pull/85222#issuecomment-1823451782
The problem comes from the fact that the SurfaceUpgradeTool callback was called for each out of date surface and the old surface-specific warning was still shown to the user.
This PR ensures that, if the surface update callback is handled, the only warning shown to the user is the own pointing them at the SurfaceUpgradeTool. We don't need the old per-surface warning in this case as the user can fix all meshes by running the tool.
The RenderingServer still has the warning for cases where the scene is run outside the editor.

This also updates the EditorProgress dialogue that runs after the upgrade tool is run. Previously it would start at 100%, then run through re-saving all the files (locked at 100%), then would appear to freeze while deleting the .import files. Now it properly progresses through re-saving all the files, and shows progress while deleting files.

Thanks!

authors: akien-mga clayjohn


text:
Improve error message in text resource format parser

Related to my debugging of #77007 and should help users identify potential recursion points in order to circumvent or fix these issues with a work around while we continue to find a fix on an engine level.
This improves the error message in our text resource parsing code to help the user potentially fix parsing issues in case of failure. It also helps with the debugging process of finding out which sub_resource is causing the parser to fail with line messages and resource paths.
Old error message:
ERROR: res://scenes/objects/some_entity.tscn:203 - Parse Error:
   at: _parse_node_tag (scene/resources/resource_format_text.cpp:284)

New error message:
ERROR: Parse Error: Busy. [Resource file res://Character.tscn:10]
   at: _parse_node_tag (scene/resources/resource_format_text.cpp:285)

This notably:
1 - Gives us the error code, which can help identify which conditional down the code path is flagging an error. It can also potentially help us determine whether or not the error is valid (In this example, the error code is Busy).
2 - Tells the user which file is problematic and which line the parser failed on. The line of failure is important as it empowers the user to find a work around in the worst case scenario, but also helps them find potential mistakes that they may have made during a git conflict resolution.
I'll continue to look into causes for the bug but I think we should consider making our error message here more verbose to help with the debugging process of future tscn parsing bugs. :)

Thanks!

authors: Eoin-ONeill-Yokai akien-mga


text:
Shorten the bug report template in order to maximize attention

Had a discussion with Nat from the comms team. She underlined how verbose is the current bug report template.
This PR aims to correct verbosity by removing explanations on why we need files or some info. We need it because contributors need that to fix the issues.
This PR removes too the idea to ask C# users to create a project in GDScript, as C# is fully supported.

[x] Add link on how to report system information for versions 4.0 and prior
[x] Validate the new content with her

@akien-mga I added "Sharing system information" to CONTRIBUTING.md in order to explain to Godot 4.0 and prior users what to share.
It will look like this:


text:
[Core] Fix property access on read-only Dictionary

Read-only dictionaries can be modified with property access, like so:
var my_dict := { "a": 0 }
my_dict.make_read_only()
my_dict.a = 1

This seems to be an oversight (and can't find any reports on it), but this makes it aligned with how it works for const

I'm not familiar with VariantInternal, but shouldn't the [] operator check for readonly? I think that the check should work not only in GDScript (variant_setget.cpp), but also in the core.
https://github.com/godotengine/godot/blob/fe01776f05b1787b28b4a270d53037a3c25f4ca2/core/variant/dictionary.cpp#L82-L83

As explained above, it uses the temporary, it doesn't throw any errors for the operator version (only the set method)

What we might want to do is add a check to get_or_add as it does mutate like that, will see about that separately

Thanks!

Thank you!

authors: AThousandShips akien-mga dalexeev


text:
Fix some strings not caught by editor pseudolocalization

Currently, editor pseudolocalization is activated after the creation of EditorNode / ProjectManager. Thus strings translated via TTR() in the constructor are not affected by pseudolocalization.
This PR moves the activation of editor pseudolocalization before the creation of those two objects.

Thanks!

authors: Repiteo timothyqiu


text:
[3.x] [JavaScript] Don't cache emsdk

3.x version of:

https://github.com/godotengine/godot/pull/98965

See there for more details

Thanks!

Thank you!

authors: AThousandShips lawnjelly


text:
Fix orphan strings in shader preprocessor

Fixes small regression after https://github.com/godotengine/godot/pull/98549

Thanks!

authors: Chaosus akien-mga


text:
Survey bug fix

There's still more I want to do here, but given that survey logic is straight-up broken in current version, I'd like to fix to merge this and deploy to pypi soon. Also adds a method "show_flow" to survey that helps visualize the skip-logic cc: @rbyh

Sorry about black formatting issues - my main laptop crapped out this weekend and I haven't properly configured VS code in new one.

repo: goemeritus/edsl


text:
kotti faucet http://kotti.little-dripper.com/ is down

Is listed on README.
cc @zcstarr is this permanent downage?

permanent downage :D
On Fri, Dec 13, 2019 at 7:10 AM meowsbits notifications@github.com wrote:

Is listed on README.
cc @zcstarr https://github.com/zcstarr is this permanent downage?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/goerli/testnet/issues/66?email_source=notifications&email_token=AABKJA4F3Z6SVWWBSXAW6ITQYOQVFA5CNFSM4J2OI5T2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IALEOZA,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABKJAYCEGMN43BPPJUEKPLQYOQVFANCNFSM4J2OI5TQ
.

authors: meowsbits zcstarr

repo: goerli/testnet

license: WTFPL


text:
Client-side service Rust SDK

The idea is that client-side services should be written in systems languages and compiled to wasm for execution in the browser, rather than written in pure javascript. It should be the responsibility of the backend service developer to write the security-conscious code that interfaces directly with the service, rather than a front-end developer who is not used to dealing with security-critical infrastructure.
SDKs can be provided such that it becomes trivial for back-end developers to write "actions" that are executed on the client-side, are given client-side context details (url information, client-side state, etc.) and which can themselves call actions on their own services, or call other client-side actions defined in other applications.
Also as part of this SDK there must be a js library which can provide imports for front-ends to call into the client-side services to execute the operations.
For example, imagine that a service action requires a user to first credit 10 tokens to the service, then call an action on it. The service developer should define a simple client-side action that calls tokensys::credit with the appropriate amounts, followed by calling their application service action. If done correctly, front-end application developers should be able to easily import a javascript library function and simply call one client-side action that facilitates sending the sequence of actions (tokensys::credit + service:action) from the currently logged-in-user automatically.

Subsumed by plugin infra

repo: gofractally/psibase


text:
请教如何自定义数据校验中的:attribute值

Go Version:  go1.16.3
GF Version:  v1.16.0
比如规则是 same:pssword
就会提示“PasswordConfirmed 字段值必须和password相同”，
如何把i18n多语言字段提示改为“确认密码 字段值必须和密码相同"
简单说，如何自定义字段提示别名。期待回复，感激不尽，谢谢

@ygcool 你看下文档呢，有介绍 https://goframe.org/pages/viewpage.action?pageId=1114384

抱歉，可能是我描述有问题，我的意思是，在使用默认的“gf.gvalid.rule.required”规则或其他默认规则时，其中的:attribute能自定义文案吗？当前默认是直接取字段名，类似laravel表单验证中的public function attributes()

@ygcool 不行，你可以自定义错误，不使用其中的:attribute属性。

好的了解了，谢谢

authors: gqcn ygcool

repo: gogf/gf


text:
Slow repository browsing response times

Configuring Gogs, browsing the commit log, searching, pushing/pulling, etc. is all fairly snappy, but browsing the files of a repository is (comparatively) very, very slow.
For example, I have a repository with 30 entries in the root, and 147 folders in a nested folder. The total page time (as seen at the bottom of the page) is ~700ms for the root, and ~4000ms for the larger nested folder. I realize that's still only 23-27ms per item, but the sum total lag is significant, and makes it difficult to browse between folders. The template rendering time itself is negligible (~10ms).
Below are the top results of an strace -cfp pidof gogs`` for a refresh of the 147-item folder. Note this only shows the time spent in syscalls, which is only about a quarter of the total time (it takes twice as long when strace is running):
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 30.50    0.749541         603      1242           futex
 17.68    0.434417      217209         2         1 restart_syscall
 17.55    0.431308         936       461           epoll_wait
 14.96    0.367632        1585       232           wait4
 13.43    0.329996        2750       120           sched_yield
  2.48    0.061040          90       676           select
  1.07    0.026240           5      5618           read
  0.46    0.011213           2      5789           mmap

Gogs version: Gogs version 0.6.3.0802 Beta
Git version: git version 2.5.0
System: Fresh install of CentOS 7 in a single-core VM on a Windows 8 host (Hyper-V). No anti-virus.
Any idea of what might be causing this?

Thanks your detailed feedback!

Any idea of what might be causing this?

In my opinion, I think it's not a topic about what causes this, instead, it is because Gogs hasn't had a cache system for repository Git data(it reloads everything every time you visit a page).
The speed should be improved at some point in the future release.
Hope my explanation help you understand. :smile:

Ah OK, so this is normal?

At least it is expected for me when:

I have a repository with 30 entries in the root, and 147 folders in a nested folder.

Got it :-) It's really a pretty small repository, it's just spread over a lot of files.

Yeah, so parse file header info takes time, cache(when implemented) would definitely help!

Hmm, I wonder -- would it help much if the calls to git were batched by changeset? Often many files were changed at the same time.
The calls to git log -1 for each sha1 could have multiple paths appended instead of just one at a time.

Hmm, turns out git log -1 path1 path2 doesn't work that way -- it yields the top commit among the set of commits for both files together (one output), instead of the top commit per file (two outputs).
This is related to #684.

this is currently a show-stopper for something like this repo: https://github.com/gentoo/gentoo

Performance is enhanced.

This is still a thing: https://try.gogs.io/Rukenshia/loonix
It is impossible to browse this repository properly. Loading the "Documentation" folder takes over 45 seconds for me. I dont know how gogs handles viewing the tree, but maybe an idea would be some kind of loading the file info delayed (last commit on that file/directory). I think GitLab does this too.
@Unknwon can you tell me whether gogs loads the complete tree of the repository when viewing the repo?

Yeah, I too think that caching is not the only answer. The answer is to just show a loading icon for the git commit info, have the information being gathered in the background and just show it when it's available, while still allowing other operations that don't need that information.

Gogs finds only the information necessary for the immediate files in the folder being displayed, not the whole tree. But internally, git itself goes through its entire history looking for each child file/folder to get the most recent commit. Git's data structures are really not made for that kind of query.

Gogs finds only the information necessary for the immediate files in the folder being displayed,

I don't think you need commit hash, commit message and modification date to just browse the repository, do you? So these information can be loaded while the tree itself is already shown.

Sorry, I wasn't clear. I meant as opposed to loading the information for the whole tree, as Rukenshia was wondering.
I agree that if the information cannot be obtained instantly, preventing the UI from blocking by fetching it in the background is a good idea.

I might use https://github.com/src-d/go-git to test see if we can get performance gain.

I tried at one point to implement the same functionality using the git C API directly (from C code), taking in the whole list of files as input instead of a single one at a time. No matter what I tried, it was still slower than invoking the git process one file at a time, which of course is already too slow.
Fundamentally, whatever client is used, git's data structures don't allow this sort of query to be done quickly.

@cameron314 One git process execution is under 100ms on my dev machine, and I can speed up with unlimited processes running at the same time, but this cause many problems on machines with small memory, so right now it is hard limited to 10 at maximum.
Therefore, I think cache layer is the ultimate solution, and cache ahead browsing, is another way to improve view experience.

I have the same problem with a big repo. I uploaded it to try.gogs.io, so you can see the performance in a known machine/config. The same repo works pretty well with cgit (with the cache enabled).
Probably the slowest directory in the repo is this: https://try.gogs.io/juanfra684/openbsd-ports/src/master/devel (Gogs Version: 0.9.14.0321 Page: 118641ms Template: 214ms)

An alternative strategy for very large directories, instead of calling git log for every file, would be to walk the git commit history and check for each commit whether or not a file in the directory was modified in this commit. Using the git command, this would be something like:
git log --name-only --format="%cd" <dirname>

This should be much more efficient than calling git log for each file, because internally git log has to walk the commit history until it finds a commit at which the file was modified. Instead of walking the git commit history n times where n is the number of files, this would only walk it once and collect information about all files in one pass.
Furthermore, using a git library instead of making calls to the git command could make this solution reasonably efficient.
Another advantage of this approach is that it allows trading-off running time for accuracy: there could be a limit on the number of commits to visit. After that, the files for which the date of last modification could not be determined could simply render as "more than x months ago", where x is determined based on the commit date of the last commit visited.
As mentioned above, the git data model was not designed for this kind of queries, so it seems that eventually some caching will be necessary for both efficient and exact answers for large directories/commit history.

@Thibauth: I tried pretty much this. Using libgit in C. It was slower than invoking git for each file (which doesn't pass through libgit if I understand correctly, but uses even lower level code).
But I like the idea of limiting the search to give a reasonable worst case instead of degenerating.

@cameron314 thanks for your answer. It is interesting that you tried and didn't find any performance gain by using libgit. Do you still have the code you experimented with (maybe you can put it on gist or something)? I think there are several ways to go about this and I agree with you that making it efficient will require doing it at a pretty low level, similar to how it is done in git.
Also, following the discussion in #2592, to implement this kind of approach in Go, we will have to use either git2go (go bindings to the C library libgit2) or the more recent pure go go-git. @Unknwon seems to prefer a pure go solution for portability reasons. I don't have much time right now, but I am also considering experimenting with all this a couple of weeks from now. I also have a few thoughts about how the caching could be done.

@Thibauth Unfortunately I lost the source code. It was just a crude test so I was a little careless with it. I remember basing most of the code on the log example, with the key being git_pathspec_match_tree (I tried a few other ways too, can't quite remember now). But even if the path matching could be made very fast, walking the commit log is fundamentally too slow in the worst case. Precomputing the desired per-file/directory information and updating it as commits are pushed is probably a better solution, though obviously there is a non-negligible space (and complexity) cost to that.

Thanks, I will keep that in mind when experimenting. Regarding the caching, I think the space cost should really be close to negligible: storing the hash of the last commit for each entry in the tree should take the same amount of space as storing a single tree associated with a single commit, so this is basically the size of single commit.

Ok so I did a very preliminary experiment usling libgit2 and the approach described above. The code is very ugly and not fully functional, but it already gives an idea of the gain which could be obtained.
Testing it on the root directory of the Gentoo repository I am able to cut the running time by a factor two when using the above approach rather than calling git log on each file. A couple of comments about this:

I ran into some limitations of libgit2 and, profiling the code, I believe that using a customized pure go implementation of git, we could cut another factor 2
the gain would be even larger for larger directories: calling git log for each file grows linearly with the  number of file, while the above approach grows sublinearly with the number of files

The gain is not mind-blowing, and it is a design choice to decide to pay in terms of code complexity for it. Ultimately, caching is probably the way to go, and the more I think about it the more I think it wouldn't be too hard to implement.

A bit late, but I found the source code of my test, if you want to compare implementations. Here you go: https://gist.github.com/cameron314/c9d55a82cc91e45496ab0c38a31e69cb

Maybe taking a look into how GitLab implements the repository browsing might be worth a try. I just gave it a shot on a Virtual Machine here on my tower PC. GitLab displays the "Files" tab of the Git repository in very little time (~1s) while Gogs needs ~23s to display the (semantically equivalent) "Code" tab. :(

I don't know for gitlab but i thinks that github take the approach of displaying the file list directly and retreiving after the hash from api. This will also permit to divide the problem and focus on optimizing (maybe by caching) the hash retreiving separatly.

Related? #3022

@tycho kind of, but not the exact same problem.

I think it is related in that if we go for a caching solution for this issue, we might as well cache the commit count at the same time and fix both problems at the same time.

Loading Django repository (~23k commits) with gogs takes about ~5 seconds.

What do you think about this ? Can be a nice feature for large directories like https://github.com/DefinitelyTyped/DefinitelyTyped

I have made a mirror of github.com/torvalds/linux and pageloads are between 6 and 40 seconds for this repository on my machine. This process runs with 100%  git rev-list --count <SOME_HASH> while the page is loading. Maybe we can cache the the output of git rev-list --count ...?

Is someone working on this? This issue is tagged with "dont send pull request" so I'm not going to send one, but through simple caching I was able to speedup a repositories home (overview) site by 300% on subsequent requests (the first one still takes its time), it's kind of a pain to work with a repository which takes three seconds to load :/

My biggest problem with this issue is that in the underlying gogits/git-module, there's an artifical .2s delay for every non-commit object. By commenting that Sleep out, a 20s page rendering goes down to 1.6s, without caching!

I should mention, that on my server browsing linux kernel repo clone is slow, but possible, but loading tags (release page) takes very long time.

my problem is if i have plenty files on a folder  ( 1500 ) to be precise it take allot to process almost 13 minutes to open the folder on gogs :(

I transferred to gitea, as this issue is still unresolved here...
simoesp notifications@github.com ezt írta (időpont: 2017. ápr. 10., H
12:11):

my problem is if i have plenty files on a folder ( 1500 ) to be precise it
take allot to process almost 13 minutes to open the folder on gogs :(
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/gogits/gogs/issues/1518#issuecomment-292907195, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAPoSuyRJB_4gJGuH59pe024mzqvr5qGks5rugBAgaJpZM4FvG8D
.

Do we have any progress on this?

authors: BurakDev NiklasRosenstein Rukenshia Thibauth Unknwon agherzan cameron314 gerasiov hasufell juanfra684 klingtnet sapk simoesp socketubs tgulacsi tkausl tycho

repo: gogits/gogs


text:
Being able to filter in pull requests using a small filter input field

Gogs version (or commit ref):
Version: 0.11.10.0517

Git version:
git version 1.7.1

Operating system:
Centos 6.4

Database (use [x]):

[ ] PostgreSQL
[x] MySQL
[ ] MSSQL
[ ] SQLite

Can you reproduce the bug at https://try.gogs.io:

[ ] Yes (provide example URL)
[ ] No
[x] Not relevant

Log gist (usually found in log/gogs.log):

Description
We've got a bunch of pull request. It would be great if we could somehow filter these pull requests by title or description. A small filter input such as with the branch dropdown would help us a big deal.

I think this thread can be part of https://github.com/gogits/gogs/issues/4239, closing.

authors: Unknwon peterurk


text:
Empty
 tags gets created when  is wrapped by
 in render-image.html

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

$ hugo version
hugo v0.113.0+extended darwin/amd64 BuildDate=unknown

Does this issue reproduce with the latest release?
Yes
Description
I have a very simple post that only contains the following:
---
title: "My First Post"
date: 2023-06-17T06:09:29+08:00
draft: true
---

[![CC BY-NC 4.0 License](https://licensebuttons.net/l/by-nc/4.0/88x31.png)](https://creativecommons.org/licenses/by-nc/4.0/)

Say I have a render-image.html:

which yield:

If I changed the render-image.html by adding a
 that wraps :

The output now adds additional
 tags before and after the
 tag:

Since the image is wrapped by an  tag, the first
 tag also contains the anchor.
You can find the source of this example at https://github.com/tomy0000000/hugo-render-image-demo
To add a little observability, I add a short custom CSS that will add a small icon at the end of every  tag. So this is what I expected:

And this is the actual result:

Notice the top left icon is attached to the empty  tag inside
 tag

You are viewing the rendered HTML in your browser's dev tools. The browser adjusts the HTML because what you are actually rendering is invalid HTML. If you view source (typically Ctrl +U) you will see the actual HTML rendered by Hugo.
This is not a bug. It's a configuration issue. Let's move this discussion to the forum (https://discourse.gohugo.io/). We prefer to use GitHub for verified bugs and vetted enhancements. Thanks.

repo: gohugoio/hugo


text:
Create a simple way to list pages with a default language edition if not found

See https://discourse.gohugo.io/t/is-there-a-good-example-for-overlay-localization-with-hugo/10788
So, if this is rendering the Chinese site, I should be able to do something similar to:
{{ $pages := .Site.RegularPages | languages.Merge "en" }}
{{ range  $pages }}
{{ . }}
{{ end }}

The above should create a page list its default sort which:

includes all English pages not translated to Chinese
includes all Chinese pages

I would obviously have to work on the API/naming in the above, but the above is hard to do in the templates, but should be fairly trivial to do in Go.

Related only because it's the same "multilingual" topic, and I can make another issue if it's indeed an issue-worthy thing, but I'd like to know if I can:

list all items of a taxonomy regardless of the language of the pages they are attached to, for something like a generic 404 page.
create taxo nav href's with something like {{ .URL | absLangURL }} that switches skillfully to what is appropriate for the language, say /tags/whatever or /en/tags/whatever. In other words, a cleaner way than href="{{ if eq $thislang "en" }}/en/{{ else }}/{{ end }}tags">.

https://discourse.gohugo.io/t/multilingual-site-tag-lists-bug-feature/10688

@RickCogley you need to take that in another issue.

OK, naming/computer science experts out there:
{{ $pages := .Site.RegularPage | languages.Merge $enSite.RegularPages  }}

Or is:
{{ $pages := .Site.RegularPage | languages.Union $enSite.RegularPages  }}

Better?
The semantics are:

includes all pages in the right collection not translated in the left
includes all pages in the left collection

/cc @digitalcraftsman @moorereason @kaushalmodi

Thanks for the ping. I don't have a strong opinion between Merge and Union, but Merge somehow feels a bit better over here.

Thinking about it, this is a left join, so ´languages.LeftJoin` would be better ...

Technically, yes, it appears to be a left join. "Union" has variations,
some of which are like what you stated. "Merge" seems more generic /
humanistic.
A thought occurred to me: Does this type of function exist elsewhere in
Hugo and, should the naming be the same or similar?

--
This email message and any attachments are confidential, and are meant to
be read by the intended recipient only. If you are not the intended
recipient, we would request you delete this message or any attachments
without reading or distributing, and kindly advise eSolia Inc. (contacts:
esolia.com/about http://esolia.com/about). Thank you in advance.

Thinking about it, this is a left join

TIL about LEFT JOIN. But even after reading that:

The LEFT JOIN keyword returns all records from the left table (table1), and the matched records from the right table (table2). The result is NULL from the right side, if there is no match.

If I understand correctly, what we are trying to do here is (changes for our application in bold):

The LEFT JOIN keyword returns all records from the left table (table1), and the unmatched records from the right table (table2). The result is ALL from the right side, if there is no match.

So it doesn't technically seem to be LEFT JOIN for folks who might be familiar with that.. or may be I am just wrong :)

So it doesn't technically seem to be LEFT JOIN for folks who might be familiar with that.. or may be I am just wrong :)

You are absolutely right. I'm thinking slowly today.

I will add .MergeByLanguage to the Pages to start with. I will see if I add a languages.Merge template func -- it may make sense to make this pipe friendly. Not sure.

authors: RickCogley bep kaushalmodi


text:
Hugo puts square brackets around keywords

i have the following front matter in a hugo markdown file
title: Telegram Bot on Netlify Functions
keywords: golang telegram bot, telegram bot go
date: 2018-03-27T11:59:49+03:00
categories:
  - "tutorials"
tags:
  - "function"
  - "bot"
  - "go"
---

the issue is when the following template is rendered
<!doctype html>

    {{ partial "includes.html" . }}
    <meta name="keywords" content="{{ .Page.Keywords }}">
    <title>{{ .Page.Title }} | WebDona</title>

    {{ partial "header.html" . }}

{{ .Page.Title }}

            {{ .Date.Format "January 2, 2006" }}

                {{ range .Params.tags }}

{{ . }}

                {{ end }}

        {{ .Content }}

    {{ partial "footer.html" . }}

the keywords meta tag has the following content [golang telegram bot, telegram bot go]
i am using hugo version 0.37.1

Thanks for getting in touch, but it feels like this is a question  that would be better suited to the Hugo Discussion Forum.  We prefer to use GitHub issues only for bugs and enhancements. Feel free to update this issue with a link to the re-posted question (so that other people can find it) or add some more details if you feel this is a genuine bug. You may also find the answers you search for in Hugo Documentation.

authors: bep webdona


text:
Support bool type params in shortcode

This a 4-param shortcode used in a post:
{{< vidur 9KvBeKu false true false>}}
	gambrill
{{< /vidur >}}

If boolean can be passed through params, we would have a better code:

	<video
		{{- cond (.Get 1) "autoplay" "" -}}
		{{- cond (.Get 2) "controls" "" -}}
		{{- cond (.Get 3) "loop" "" -}}
	>
		<source src='https://i.imgur.com/{{- .Get 0 -}}.mp4'/>
	</video>
	{{ with .Inner }}
{{.}}
{{ end }}

I agree. We should probably also support numbers, so you can do:
{{< vidur 9KvBeKu false true 32 3.14 >}}

This will be a slightly breaking change, but should be very limiting. If people want strings, they should do:
{{< vidur 9KvBeKu "false" "true" "32" "3.14" >}}

authors: bep dtvn


text:
Broken Homepage

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

$ hugo version

Does this issue reproduce with the latest release?
Yes
The issue is with the homepage and older templates there is no guide (and please do not link to the previous issue) on how to migrate older templates to new templates.  This is very very very bad form to put breaking changes like this in non major versions, I am sorry but it is.

Please use https://discourse.gohugo.io/ for questions/troubleshooting. Also see  Hugo Documentation.

authors: bep craigmpeters


text:
releaser: Fix some issue regexps

Re. -- skip releaser prefix.
releaser: Add "note" to Note regexp 3473e31 @bep
releaser: Rework and simplify to use GitHub only for release notes 24a893c @bep
releaser: Add release notes to /docs for release of 0.89.4 ab01ba6 @bep
releaser: Add release notes for 0.89.4 [ci skip] f97da9e @bep
releaser: Add release notes to /docs for release of 0.89.3 c88cdb5 @bep
releaser: Add release notes for 0.89.3 [ci skip] bf489b9 @bep
releaser: Add release notes to /docs for release of 0.89.2 63e3a5e @bep
releaser: Add release notes for 0.89.2 [ci skip] cf3eb58 @bep
releaser: Add release notes to /docs for release of 0.89.1 b6a4ae4 @bep
releaser: Add release notes for 0.89.1 [ci skip] a074102 @bep
releaser: Prepare repository for 0.90.0-DEV 41e9e9fe [@bep](https://github.com/bep)

Fixed with https://github.com/gohugoio/hugo/commit/dffca57883ba779121d63a59e0e74f37bf28d651.

authors: bep jmooring


text:
new loggers

new loggers for debugging KAfka.

👍

repo: goibibo/woof

license_source: bigquery


text:
Log middleware with whole pattern

I want to be able to log the entire pattern that was matched in a middleware but this doesn't seem easily doable if I am using submuxes.
If I put the middleware on the root mux then I only get the pattern up to the wildcard. If I put the middleware on the submux then I get the pattern after the wildcard.
Ideally I would like to be able to put it on the root mux and get the whole pattern, but I would settle for doing it on each submux as well.
Do you have advice for how to do this? Thanks.

Sorry—this issue seems to have fallen through the cracks.
I haven't found a great way to do this besides adding a middleware to every mux and submux "along the chain" that grabs patterns out of the local context and appends them to a list. I'll be the first to admit this is ugly—it's just one of those things that turned out to be less easy than I thought it would be when I first designed the APIs.
Other solutions include creating custom Pattern types (perhaps a vendored copy of pat) that opt-in to cooperative "whole pattern"-building.

Yeah your solution is basically what we ended up implementing. Mostly wanted to make sure there wasn't an obviously easy way that I was missing. Appreciate the response, thanks.

authors: troylelandshields zenazn

repo: goji/goji

license: mit


text:
Not working with redroid

ENV:

ecapture: 0.7.0
devices: redroid 13 (docker container)

Error:
2023/12/16 17:30:14 Failed to read kernel configuration., error:open /proc/config.gz: no such file or directory
Redroid didn't include /proc/config.gz, maybe can add some argument like --force to force execute ecapture?

Good suggestion, I will evaluate it.

Can confirm /sys/kernel/btf/vmlinux is existed in redroid

Not all androids will have /sys/kernel/btf/vmlinux present. I intend to be compatible with both cases.

Not all androids will have /sys/kernel/btf/vmlinux present. I intend to be compatible with both cases.

Sweet, I'm looking forward to using it with redroid👍

Can you check where the '/proc/config.gz' file has been changed on your Redroid device?

Can you check where the '/proc/config.gz' file has been changed on your Redroid device?

I have tried many times with the Redroid (from android 12-13), it looks like /proc/config.gz has removed and I can't find where is it.

Okay, I know what happens now, so the IsContainer function in bpf_androidgki.go is not done yet
Force return true in IsContainer function to make it work

The 'IsContainer' function does not return 'true' directly, and some features need to be detected. What are the characteristics of Redroid that are different from Android? Like a file? A configuration?

The IsContainer function does not return true directly, and some features need to be detected. What are the characteristics of Redroid that are different from Android? Like a file? A configuration?

TBH, I also don't know what the difference between them XD.
The reason why I use Redroid is it just a docker container and it is easy to deploy it.

Well, it looks like a niche need. I'm not going to fix it to the project, what do you think?

Well, it looks like a niche need. I'm not going to fix it to the project, what do you think?

Well, maybe need a --force arg and don't need to fix the IsContainer function

@hongyang51 在你的开发板设备上， config的路径是什么呢？

@hongyang51 在你的开发板设备上， config的路径是什么呢？

/boot/config* , 但是我只是修改了检索的路径，修改为/data/local/config.gz 可以手动push上去。
校验与否对我来说实际不太重要

repo: gojue/ecapture


text:
Column labels don't align with their data fields in font editing window

Have seen this in fileview as well. Resizing window fixes the alignment.

yeah, this is a tricky issue as the header is a separate widget, and if it aligns with cols when screen is too small, it gets its own scrollbar, which is not good...   then I just remembered the "overflow" property -- setting it to "hidden" works great!

authors: rcoreilly rohrlich thazy

repo: goki/gi


text:
Memory Utilization is running high

I keep getting this annoying email notification. Database for such a simple purpose should not consume that much amount of memory. Please considering fix this, say at least drop the memory usage of MySQL instance down to 100M (currently 300M+). Thanks.
cc @yangwenmai

OK. I resolved the issue via:
performance_schema = 0

in my.conf

repo: golang-design/redir


text:
Pruning should also delete broken symlinks

using dep v0.4.0, after doing a dep ensure with unused-packages = true, in some cases some broken symlinks are still there.
What seem the case is that.
I am vendoring GitHub.com/a/project which has subpackage sub1, sub2, sub3.
I am only using sub3
sub2 contains a symlink to a go file in sub1
After dep ensure is executed, sub1 has successfully been pruned out, but sub2 is still there with a broken symlink to some file in sub1.
(as a workaround, I added a script that removes broken links from my vendor dir)

We'll get to this indirectly soon enough, as we soon won't be writing out symlinks at all.

@simonferquel  : Can you please share the script to prune symlink files/directories?

We used something like find vendor -type l ! -exec test -e {} \; -print | xargs rm -v

Dep was officially deprecated earlier this year, and the proposal to archive this repository was accepted. As such, I'm closing outstanding issues before archiving the repository. For any further comments, please use the proposal thread on the Go issue tracker. Thanks!

authors: balaji39mit mvdan sdboyer simonferquel

repo: golang/dep


text:
Missing quotes added

Hey there!
In the quote, which is given to explain the meaning of the dep ensure, a quotation mark is omitted in a figurative reference to the dep.

I signed it!

Hmm, why @googlebot duplicates its messages

guys?(

This has been merged!

authors: gabolaev kevinburke


text:
os: Stat() fails on NTFS volumes with Deduplication enabled

Go Version: go1.4.2 windows/amd64
OS and Arch: Windows 8.1 Pro 64-bit.
Action: os.Stat("Path\to\deduped.file")
Expected Result: successfully returns (FileInfo, nil)
Actual Result: err := "readlink Path\to\deduped.file: The system cannot find the file specified."

From a bit of digging, the issue is caused by NTFS Dedupe using reparse points for deduplicated files. The Windows implementation of fileStat.Mode() treats all reparse points as symlinks, however there are several other cases to consider, including Deduplication and Mount Points, neither of which are symlinks.
The Windows implementation of os.Readlink() already performs a sanity check to ensure that it is handling a symlink. Ideally a similar inspection could be performed in Mode(), checking for IO_REPARSE_TAG_DEDUP == 0x80000013 and stripping the Symlink flag, allowing the file to be treated as Regular.

@NTmatter would you like to send a fix for this? You seems to know all about these file types. See http://golang.org/doc/contribute.html for details. If not, I will fix it myself.
Alex

I can take a stab at it if you don't have enough bandwidth. It'll probably be a few days before I can get a proper dev and test environment together, depending on my workload.

Please try to fix this. I don't know much about any of this and don't really want to learn. But happy to review your code. I can test your code if you don't have appropriate environment setup. Good new test will make our task much easier, considering I know little about the subject. Test that breaks with current tip, but PASSes once your changes are applied.
No pressure. I will do it myself, if you cannot do it. Thank you.
Alex

I've got a basic dev environment running now. Should be possible to start looking at it in the next day or two :)

Took a bit longer than expected, but a small change set is up for review at https://go-review.googlesource.com/11330/

authors: NTmatter alexbrainman

repo: golang/go


text:
runtime: fatal error: MSpanList_Remove

Please answer these questions before submitting your issue. Thanks!

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

What operating system and processor architecture are you using (go env)?
Linux xxxx 3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 21:16:20 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

What did you do?
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.

Our program is a long TCP connection server, which receiving data from a TCP and forwarding it to other. When it upgrade to 1.6, it run a long time (around 4 days) then panic with same error. Log attached below:
failed MSpanList_Remove 0x7f27485cf7f0 0x7f27481d3aa8 0xb6f170 0xb6f180
fatal error: MSpanList_Remove

runtime stack:
runtime.throw(0x947fd0, 0x10)
        /opt/go1.6/src/runtime/panic.go:530 +0x90
runtime.(*mSpanList).remove(0xb6f180, 0x7f27485cf7f0)
        /opt/go1.6/src/runtime/mheap.go:911 +0x1ad
runtime.(*mcentral).freeSpan(0xb6f160, 0x7f27485cf7f0, 0x16, 0xc8cbdc4080, 0xc8cbdc5b80, 0xc847e62100, 0x100000001)
        /opt/go1.6/src/runtime/mcentral.go:178 +0x131
runtime.(*mspan).sweep(0x7f27485cf7f0, 0x3efd50003ef00, 0xc800021b01)
        /opt/go1.6/src/runtime/mgcsweep.go:319 +0x613
runtime.sweepone(0x4)
        /opt/go1.6/src/runtime/mgcsweep.go:112 +0x23e
runtime.gosweepone.func1()
        /opt/go1.6/src/runtime/mgcsweep.go:124 +0x21
runtime.systemstack(0x7f272ab15db8)
        /opt/go1.6/src/runtime/asm_amd64.s:307 +0xab
runtime.gosweepone(0xb6eb08)
        /opt/go1.6/src/runtime/mgcsweep.go:125 +0x3d
runtime.deductSweepCredit(0x8000, 0x0)
        /opt/go1.6/src/runtime/mgcsweep.go:384 +0xc6
runtime.(*mcentral).cacheSpan(0xb70a50, 0x7f27703fd000)
        /opt/go1.6/src/runtime/mcentral.go:36 +0x56
runtime.(*mcache).refill(0x7f278da73000, 0xc900000042, 0xc867dc1380)
        /opt/go1.6/src/runtime/mcache.go:119 +0xcc
runtime.mallocgc.func2()
        /opt/go1.6/src/runtime/malloc.go:642 +0x2b
runtime.systemstack(0xc82002b500)
        /opt/go1.6/src/runtime/asm_amd64.s:291 +0x79
runtime.mstart()
        /opt/go1.6/src/runtime/proc.go:1048

What did you expect to see?
No crash

What did you see instead?
Crash

There is a old issue with same panic backtrace: #14831

@googollee #14831 was due to a bug in some code called from cgo, does your code use cgo ?
Is your code available ? Can you provide a sample which reproduces the problem ?

@davecheney to be correct, #14831 did not involve cgo at all, it was just a syscall (ioctl) and there was a bug in a proprietary kernel driver that in some edge case went past the provided buffer by 4 bytes, resulting in memory corruption.
@googollee if you are dealing with memory corruptions, they can happen with syscalls, or use of the unsafe package (pointers) if there's a bug in the pointer math or type conversions via unsafe.Pointer

There is no cgo or syscall or unsafe in my code. I will try to make a sample to reproduce it, but the code is really complex and mess ,and panic after a long run. I'm not sure which part cause this issue now.

The first thing I think your should do is build a race enabled version of your application, go build -race and deploy that.

On 28 Mar 2016, at 19:41, Googol Lee notifications@github.com wrote:
There is no cgo or syscall or unsafe in my code. I will try to make a sample to reproduce it, but the code is really complex and mess ,and panic after a long run. I'm not sure which part cause this issue now.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

OK. I will try.

CC @aclements @RLH

failed MSpanList_Remove 0x7f27485cf7f0 0x7f27481d3aa8 0xb6f170 0xb6f180

Looks like the span was on nonempty, but was being removed from empty because its freelist was nil. Unfortunately, I don't think there's enough information in the traceback to glean which of these conditions was wrong.

@googollee it may be worth looking at the dependencies/3rd party libs you may be using and they may be using in turn. Your code may not be doing anything with the unsafe package/syscall/cgo directly but some dependency may.

I try go build -race and hope to get some log to check now.
@bits01 I have checked all 3rd party libs and all of them are not using cgo/unsafe/sysctl.

I find some race code and try to fix them. After that I will check if the program will panic again.
Thanks.

I'm going to close this until there's something actionable for us to do. Feel free to reopen if you have more details to suggest it's a bug in Go.

authors: aclements bits01 bradfitz davecheney googollee ianlancetaylor