text:
Can't get method on CallableCustom "Delegate::Invoke" error when building/debugging .NET project

Godot version
4.0beta
System information
windows10,NVIDIA GeForce GTX 1660,Vulkan API 1.2.0
Issue description
GODOT BETA 7.0 C # version, when debugging for many times, suddenly stuck, the debugging progress bar did not respond, and then if the program was not forced to close in time, the entire operating system would crash.
But there is no error prompt,
After I restart the computer, a lot of errors will occur when I open the project:
  modules/mono/managed_callable.cpp:92 - Condition "delegate_handle.value == nullptr" is true.
  Can't get method on CallableCustom "Delegate::Invoke".
  core/object/object.cpp:1058 - Error calling from signal 'timeout' to callable: 'Node::': Method not found.
  modules/mono/managed_callable.cpp:92 - Condition "delegate_handle.value == nullptr" is true.
  Can't get method on CallableCustom "Delegate::Invoke".
  core/object/object.cpp:1058 - Error calling from signal 'timeout' to callable: 'Node::': Method not found.
  modules/mono/managed_callable.cpp:92 - Condition "delegate_handle.value == nullptr" is true.
  Can't get method on CallableCustom "Delegate::Invoke".
  core/object/object.cpp:1058 - Error calling from signal 'timeout' to callable: 'Node::': Method not found.
  modules/mono/managed_callable.cpp:92 - Condition "delegate_handle.value == nullptr" is true.
  Can't get method on CallableCustom "Delegate::Invoke".
  core/object/object.cpp:1058 - Error calling from signal 'timeout' to callable: 'Node::': Method not found.
  modules/mono/managed_callable.cpp:92 - Condition "delegate_handle.value == nullptr" is true.
  Can't get method on CallableCustom "Delegate::Invoke".
  core/object/object.cpp:1058 - Error calling from signal 'timeout' to callable: 'Node::': Method not found.
  modules/mono/managed_callable.cpp:92 - Condition "delegate_handle.value == nullptr" is true.
  Can't get method on CallableCustom "Delegate::Invoke".
  core/object/object.cpp:1058 - Error calling from signal 'timeout' to callable: 'Node::': Method not found.
  modules/mono/managed_callable.cpp:92 - Condition "delegate_handle.value == nullptr" is true.

Deleting the godot folder can solve the problem, but it will seriously affect my computer health and my spirit.
I'm going crazy.
Please solve this problem, otherwise it will become difficult to use, thank you.
Steps to reproduce
N/A
Minimal reproduction project
N/A

Just wanted to chime in and say that I am also facing this issue and it's blocking. Not complaining or anything, I know it's beta :).
Is this related to, but not fixed by  #69194? If so, do we know how to work around it for the time being?

Just wanted to provide some more context:
This issue occurs for me only when a C# script marked as [Tool] is attached to a node, and the script loads 1 or more resources.
Here is the code that causes the error, in my case:
[Tool]
public partial class LevelManager : Node3D
{
	public override void _Ready()
	{
	    LoadBlocks();

	    if(_levelNode == null){
		_levelNode = new Node3D() {Name = "Level"};
		AddChild(_levelNode);
		if(Engine.IsEditorHint()){
			_levelNode.Owner = this;
		}
	    }
	    LoadLevel();
	}

        private void LoadBlocks(string path = "Prefabs/Blocks"){
	    _blockList.Clear();

	    var files = Directory.GetFiles(path, "*.tscn", SearchOption.AllDirectories);

	    foreach(String file in files){
		var filename = Path.GetFileNameWithoutExtension(file);
		_blockList[filename] = GD.Load<PackedScene>($"res://{path}/{filename}.tscn");
	    }
	}
}

If either the [Tool] attribute is removed or the LoadBlocks method is commented out, the issue does not occur. I hope this helps.

I was running into this. In my case it seems to have been caused by using a .NET 7 SDK instead of .NET 6. dotnet defaults to using the latest installed SDK and I have both installed. Adding the following global.json file to the root of the project fixed the issue.
{
  "sdk": {
    "version": "6.0.404"
  }
}

{
  "sdk": {
    "version": "6.0.404"
  }
}

This unfortunately hasn't fixed it in my case. On the next build after launching I get the same error as above.
The messages from the terminal are:
Copying Godot Offline Packages...
Unloading assembly load context...
Assembly unloading is taking longer than expected...
Failed to unload assemblies. Possible causes: Strong GC handles, running threads, etc.
ERROR: .NET: Failed to unload assemblies.
   at: (modules/mono/mono_gd/gd_mono.cpp:504)
ERROR: Condition "delegate_handle.value == nullptr" is true.
   at: call (modules/mono/managed_callable.cpp:92)
ERROR: Can't get method on CallableCustom "Delegate::Invoke".
   at: (core/variant/callable.cpp:333)
ERROR: Error calling from signal 'timeout' to callable: 'Node::': Method not found.

I'm running:
4.0.beta10.mono (As far as I can tell this has affected every build since the .net 6 merge.)
Windows 10 pro x64
dotnet --info shows:
.NET SDKs installed:
2.1.202 [C:\Program Files\dotnet\sdk]
2.1.401 [C:\Program Files\dotnet\sdk]
2.1.402 [C:\Program Files\dotnet\sdk]
2.1.526 [C:\Program Files\dotnet\sdk]
3.1.120 [C:\Program Files\dotnet\sdk]
3.1.201 [C:\Program Files\dotnet\sdk]
3.1.426 [C:\Program Files\dotnet\sdk]
5.0.104 [C:\Program Files\dotnet\sdk]
5.0.408 [C:\Program Files\dotnet\sdk]
6.0.112 [C:\Program Files\dotnet\sdk]
6.0.307 [C:\Program Files\dotnet\sdk]
6.0.400 [C:\Program Files\dotnet\sdk]
6.0.404 [C:\Program Files\dotnet\sdk]

@gallsy can you confirm that you are running a [Tool]  script and it loads a resource from disk?

@matthew798 yes that's right.
The problem seems to be caused by my C# plugin using [Tool] and has multiple references to scenes via ResourceLoader.Load<PackedScene>("uid://whatever") and json files via
var fileStream = FileAccess.Open(filePath, FileAccess.ModeFlags.Read);
var fileText = fileStream.GetAsText();
fileStream.Dispose();

The only external dependency I'm using is Newtonsoft.Json.

Been hit by this myself in beta 9.0
I had some [Tool] scripts, but removing [Tool] did not fix the issue.
It appears to be being caused by assemblies not getting unloaded properly. From the godot console:
`Unloading assembly load context...
Vulkan API 1.3.205 - Using Vulkan Device #0: NVIDIA - NVIDIA GeForce GTX 1050 Ti

Assembly unloading is taking longer than expected...
Failed to unload assemblies. Possible causes: Strong GC handles, running threads, etc.`
The deluge of errors starts immediately thereafter.
In my case, I can cause this to happen by:

Starting up the editor
You can build/run the project as much as you like without issue here
Make a change to the code that forces script recompilation
Something somewhere will kick up an exception in ScriptManagerBridge.TryReloadRegisteredScriptWithClass to do with adding a type to a dictionary that already contains that given key, always a generic class:
  modules/mono/glue/runtime_interop.cpp:1223 - System.ArgumentException: An item with the same key has already been added. Key: DisplayControlCollection2[PawnSystem.Pawn,ClientControllerSystem.PawnUIControl]
at System.Collections.Generic.Dictionary2.TryInsert(TKey key, TValue value, InsertionBehavior behavior)   at System.Collections.Generic.Dictionary2.Add(TKey key, TValue value)
at Godot.Bridge.ScriptManagerBridge.ScriptTypeBiMap.Add(IntPtr scriptPtr, Type scriptType) in /root/godot/modules/mono/glue/GodotSharp/GodotSharp/Core/Bridge/ScriptManagerBridge.types.cs:line 23
at Godot.Bridge.ScriptManagerBridge.TryReloadRegisteredScriptWithClass(IntPtr scriptPtr) in /root/godot/modules/mono/glue/GodotSharp/GodotSharp/Core/Bridge/ScriptManagerBridge.cs:line 545`
Project can still run etc as many times as you like
At the next script recompilation, the assembly fails to unload as described above and it all goes to hell

Curiously, only building from visual studio code (as opposed to the godot editor) sees the issue with TryReloadRegisteredScriptWithClass and generic classes kick off immediately. The second time you build from VSCode, either the deluge begins in the godot editor or it just outright freezes, but so long as you don't need to edit scenes you can still work and run the project just fine from visual studio code.

Quick update, I've had some luck tracking this down!
The cause - in my case - appeared to be, as the 'failed to unload assemblies' message mentioned, strong GC handles. Specifically, static variables that would persist between reloads and potentially have handles to things that should have been deleted.
The quick tl;dr, manage your static variables responsibly. I had a few things static that really didn't need to be, and after refactoring I can no longer reproduce the error as I mentioned previously.

@guessy42 Interesting. I'd be curious to see what the before and after of your refactoring look like. I don't see how a static variable would cause an issue here. Also, I don't have any static variables in my script.

@guessy42 Interesting. I'd be curious to see what the before and after of your refactoring look like. I don't see how a static variable would cause an issue here. Also, I don't have any static variables in my script.

It could also be static events, or really anything that creates a strong handle that stops the assembly from being unloaded. To be honest, I'm not 100% sure what all the possible causes for stopping assemblies unloading even are.
This is the original, problematic script: https://pastebin.com/Ey7XQtGH
This is the fixed one: https://pastebin.com/PjG67QEr
It's pretty much moving static variables to singleton instance variables and adding more cleanup / safeguards. Awaiters is an autoload.
In hindsight the use of static variables in that script was honestly bound to cause problems but, well, that's hindsight.

I don't know if my circumstances match everyone elses, but I am also seeing this issue in beta 16 as well.
I have found that if I hit "Build" manually before hitting the play button I do not seem to get the errors. Also, I noticed that if I do not hit "Build" before hitting play, even if I have mistakes in my code that should prevent compile it still runs the app. I do not need to hit "Build" every time before I hit play if I have not made code changes. I suspect there is an issue causing the build to either not happen or not complete in time when you just press play.

@TomNCatz I was having the same problem with a project that worked in beta 15 but not 16, I was able to fix it (in beta 17) by deleting the "temp" folder at "Project Dir"/.godot/mono/

@TomNCatz I was having the same problem with a project that worked in beta 15 but not 16, I was able to fix it (in beta 17) by deleting the "temp" folder at "Project Dir"/.godot/mono/

Running 4.0 beta 17 mono edition, ran into the same issue, this solution also worked for me.

I am now on version rc.3, after deleting the temp folder, the issue would still occur after some code changes and rebuilding.

This still happens in stable.
It happens almost every single time I make a change to a C# script, no matter how simple the project is.
Just rotating a cube is enough to cause this.

I found a temporary solution.
Modify GodotPlugins\Main.cs
Change the return false to return true in line 270.
Rework "--generate-mono-glue".
Do not use += and Callable.Form() for signal connections to the EditorPlugin.
Using the
.Connect(EditorSelection.SignalName.SelectionChanged, new Callable (this, DevHelper.MethodName.XXX))

Unloading assembly load context...
Assembly unloading is taking longer than expected...
Failed to unload assemblies. Possible causes: Strong GC handles, running threads, etc.
ERROR: Condition "delegate_handle.value == nullptr" is true.
   at: ManagedCallable::call (modules\mono\managed_callable.cpp:92)
ERROR: Can't get method on CallableCustom "Delegate::Invoke".
   at: (core\variant\callable.cpp:377)

I found a temporary solution.
Modify GodotPlugins\Main.cs
Change the return false to return true in line 270.
Rework "--generate-mono-glue".
Do not use += and Callable.Form() for signal connections to the EditorPlugin.
Using the
.Connect(EditorSelection.SignalName.SelectionChanged, new Callable (this, DevHelper.MethodName.XXX))

I am also facing this problem in 4.0 Stable. The MRP is simply setting and using any static fields in a Godot-based class's static constructor.
My temporary solution is to make sure all static fields and properties are not be set in ModuleInitializer and static constructors of any classes that extends Godot classes, such as Node, Control, etc..

@RedworkDE It happens pretty much in any project for me once I make a single change to a C# script, but here's a really simple project:
GodotTimeoutIssue.zip
Here's a short video on how I can trigger it:
https://user-images.githubusercontent.com/975131/229175342-72aa6714-35c6-4d4e-a71b-88b1b811788e.mp4

Can't reproduce with that project, but the issue seems to limited to just the error spam, so that probably gets fixed by https://github.com/godotengine/godot/pull/75533 already.

It's not just log spam for me unfortunately.
If I run the project one more time without restarting once the errors come up all script export variables will be reset to 0  in the editor which is a massive pain to resolve on larger projects.

You can try building from source with that PR and test if it fixes the issue problems for you, because the error spam is really just a symptom of the editor breaking beyond recovery and that is what the PR fixes.
If it does not (I never tried to figure out what exactly the consequences of continuing are) a lot more system information is need to even begin diagnosing these issues.

@RedworkDE Just tried the PR and it seems like it does indeed resolve the issue.
I get this error now after every change in the C# project but it doesn't seem to affect anything:
Another resource is loaded from path 'res://Cube.cs' (possible cyclic resource inclusion).

JZGLtest.zip
After loading the plugin, click the arrow position on the screenshot.
Then add or remove [Export] in the cs file (the method attribute should also trigger), and finally rebuild the solution with VS.
Godot reported an error.

Then using #75533 will cause other problems.

I updated to the 4.1 beta 1 and I'm still getting this issue. It's really preventing me from making progress. It happens very reliably for me. Basically I have the game running and then reload the scene twice and I'm locked out basically.
Essentially this comment
However I have to delete the projects .godot folder in the project before reopening the editor to fix the issue.
I'm on Fedora Silverblue 38, with VS Code. I haven't got any [Tool]s.
After the first reload (Step 4):

Details

  modules/mono/glue/runtime_interop.cpp:1325 - System.ArgumentException: An item with the same key has already been added. Key: Presenter`2[FundsModel,FundsView]
     at System.Collections.Generic.Dictionary`2.TryInsert(TKey key, TValue value, InsertionBehavior behavior)
     at System.Collections.Generic.Dictionary`2.Add(TKey key, TValue value)
     at Godot.Bridge.ScriptManagerBridge.ScriptTypeBiMap.Add(IntPtr scriptPtr, Type scriptType) in /root/godot/modules/mono/glue/GodotSharp/GodotSharp/Core/Bridge/ScriptManagerBridge.types.cs:line 23
     at Godot.Bridge.ScriptManagerBridge.TryReloadRegisteredScriptWithClass(IntPtr scriptPtr) in /root/godot/modules/mono/glue/GodotSharp/GodotSharp/Core/Bridge/ScriptManagerBridge.cs:line 579
  modules/mono/glue/runtime_interop.cpp:1325 - System.ArgumentException: An item with the same key has already been added. Key: Presenter`2[UptimeModel,UptimeView]
     at System.Collections.Generic.Dictionary`2.TryInsert(TKey key, TValue value, InsertionBehavior behavior)
     at System.Collections.Generic.Dictionary`2.Add(TKey key, TValue value)
     at Godot.Bridge.ScriptManagerBridge.ScriptTypeBiMap.Add(IntPtr scriptPtr, Type scriptType) in /root/godot/modules/mono/glue/GodotSharp/GodotSharp/Core/Bridge/ScriptManagerBridge.types.cs:line 23
     at Godot.Bridge.ScriptManagerBridge.TryReloadRegisteredScriptWithClass(IntPtr scriptPtr) in /root/godot/modules/mono/glue/GodotSharp/GodotSharp/Core/Bridge/ScriptManagerBridge.cs:line 579
  modules/mono/glue/runtime_interop.cpp:1325 - System.ArgumentException: An item with the same key has already been added. Key: ArrayPresenter`2[AppListModel,AppModel]
     at System.Collections.Generic.Dictionary`2.TryInsert(TKey key, TValue value, InsertionBehavior behavior)
     at System.Collections.Generic.Dictionary`2.Add(TKey key, TValue value)
     at Godot.Bridge.ScriptManagerBridge.ScriptTypeBiMap.Add(IntPtr scriptPtr, Type scriptType) in /root/godot/modules/mono/glue/GodotSharp/GodotSharp/Core/Bridge/ScriptManagerBridge.types.cs:line 23
     at Godot.Bridge.ScriptManagerBridge.TryReloadRegisteredScriptWithClass(IntPtr scriptPtr) in /root/godot/modules/mono/glue/GodotSharp/GodotSharp/Core/Bridge/ScriptManagerBridge.cs:line 579
  modules/mono/glue/runtime_interop.cpp:1325 - System.ArgumentException: An item with the same key has already been added. Key: Presenter`2[AppListModel,IGridView]
     at System.Collections.Generic.Dictionary`2.TryInsert(TKey key, TValue value, InsertionBehavior behavior)
     at System.Collections.Generic.Dictionary`2.Add(TKey key, TValue value)
     at Godot.Bridge.ScriptManagerBridge.ScriptTypeBiMap.Add(IntPtr scriptPtr, Type scriptType) in /root/godot/modules/mono/glue/GodotSharp/GodotSharp/Core/Bridge/ScriptManagerBridge.types.cs:line 23
     at Godot.Bridge.ScriptManagerBridge.TryReloadRegisteredScriptWithClass(IntPtr scriptPtr) in /root/godot/modules/mono/glue/GodotSharp/GodotSharp/Core/Bridge/ScriptManagerBridge.cs:line 579
  modules/mono/glue/runtime_interop.cpp:1325 - System.ArgumentException: An item with the same key has already been added. Key: ArrayPresenter`2[IdeaListModel,IdeaModel]
     at System.Collections.Generic.Dictionary`2.TryInsert(TKey key, TValue value, InsertionBehavior behavior)
     at System.Collections.Generic.Dictionary`2.Add(TKey key, TValue value)
     at Godot.Bridge.ScriptManagerBridge.ScriptTypeBiMap.Add(IntPtr scriptPtr, Type scriptType) in /root/godot/modules/mono/glue/GodotSharp/GodotSharp/Core/Bridge/ScriptManagerBridge.types.cs:line 23
     at Godot.Bridge.ScriptManagerBridge.TryReloadRegisteredScriptWithClass(IntPtr scriptPtr) in /root/godot/modules/mono/glue/GodotSharp/GodotSharp/Core/Bridge/ScriptManagerBridge.cs:line 579
  modules/mono/glue/runtime_interop.cpp:1325 - System.ArgumentException: An item with the same key has already been added. Key: Presenter`2[IdeaListModel,IGridView]
     at System.Collections.Generic.Dictionary`2.TryInsert(TKey key, TValue value, InsertionBehavior behavior)
     at System.Collections.Generic.Dictionary`2.Add(TKey key, TValue value)
     at Godot.Bridge.ScriptManagerBridge.ScriptTypeBiMap.Add(IntPtr scriptPtr, Type scriptType) in /root/godot/modules/mono/glue/GodotSharp/GodotSharp/Core/Bridge/ScriptManagerBridge.types.cs:line 23
     at Godot.Bridge.ScriptManagerBridge.TryReloadRegisteredScriptWithClass(IntPtr scriptPtr) in /root/godot/modules/mono/glue/GodotSharp/GodotSharp/Core/Bridge/ScriptManagerBridge.cs:line 579

The error seems to reference a parent class I have made:
public abstract partial class Presenter<M, V> : MarginContainer where M : Resource where V : class {}
public partial class FundsPresenter : Presenter<FundsModel, FundsView> {}

Then I get this error on repeat on the second reload (Step 6):

.NET: Failed to unload assemblies. // This line doesn't repeat
modules/mono/managed_callable.cpp:92 - Condition "delegate_handle.value == nullptr" is true.
Can't get method on CallableCustom "Delegate::Invoke".
core/object/object.cpp:1080 - Error calling from signal 'timeout' to callable: 'Node::': Method not found.

I don't mind providing my entire project if it helps diagnose the problem, though it's quite messy. It just takes commenting and uncommenting a line to cause the issue. I'll do some more research and see if I can simplify the reproduction.

@dannymate In my case the issue in your reproduction appears in 4.1 beta 1, but running in 4.0 stable or 4.0.3 stable doesn't cause the issue for some reason. I guess 4.1 beta changes something? I also having this issue in my own project that appears in 4.0 stable and in 4.1 beta 1.

Well from what I gather it seems the first error, with the dictionary entries, is related to ScriptManagerBridge.cs line 579 in which it tries to add the Type which is loaded from an assembly to a ScriptTypeBiMap object.
Inside the ScriptTypeBiMap it tries to add the Type as a key but it seems duplicated. I'm not sure why it's Presenter<FundsModel, FundsView> instead of FundsPresenter for example but  it seems how it figures out the Type may be part of the problem.
Another thing that could help is adding checking for duplicated keys in ScriptTypeBiMap before adding to dictionary or using TryAdd.

I'm experiencing the same problem in 4.0.3 stable and I have had this problem in previous versions (of Godot 4) as well. It even happens if I have an empty scene set as the main scene with nothing else (no scripts whatsoever) attached to it. Sometimes it happens when I start a new project. And sometimes I make a change to my C# class (just anything, really) and suddenly I'm getting that same repeating error and I have to restart Godot to make it disappear (only for it to come back when I hit play).

this problem is present in version 4.0.3 of c#. problem is stable.

Tested my project and MRP in 4.1 and still getting this issue.
There are some slight differences and improvements however.

The console doesn't get spammed anymore.
The first error, "An item with the same key...", actually appears when first running the game even before any changes are made. And the ".Net failed to load assemblies" shows after one change.
I no longer have to delete the .godot folder if this error occurs to reopen a project with this error.
Any changes I make to a games code after this error occurs does get reflected now.

Overall still an issue but it's not going to prevent me from developing my game anymore.

I have this problem too with my C# game+plugin project since 4.0 (but it got worser in 4.1). Before i just ignored it and it worked. But now in 4.1, when i build my project in Visual Studio, Godot start to drop ".NET failed to unload assemblies" and Delegate::Invoke errors, until i restart the engine. As a mitigation workaround for now i add the plugin instance child to GetEditorMainScreen(), so the errors start to drop only when i used the plugin, but its very annoying.

Do you guys have readonly variables? I removed the readonly modifier and the Condition "managed_callable... went away. The other thing that could be causing it is a dropped signal between an "EmitChanged" and a node being dropped as a new build clears all the nodes.

I want to add, as annoying as this error is, in Godot 1.4.4 stable. I'm finding that it also often resets exported variables (e.g. default int/float values are set to 0). It would be fine if it was just this issue, but the fact that it's also making me check every single script with an exported variable to see if it's been changed is really, really annoying.
I've looked at all the potential solutions on this issue, but none of them work for me. I'm getting so tired of this.


text:
Changing AspectRatioContainer to anything other than 'fit' crashes Godot Editor 4.0 RC1

Godot version
4.0 RC1
System information
Intel Mac OS
Issue description
When using an aspect ratio container, with a texture rect as a child. Setting the aspect ratio container to anything other than 'fit' is crashing the editor
Steps to reproduce

change the aspect ratio container mode from 'fit' to 'cover'
crashes editor

Minimal reproduction project
aspectratiobug.zip

GDB Backtrace
Thread 1 "godot.linuxbsd." received signal SIGSEGV, Segmentation fault.
0x0000555569bb727d in Callable::get_object (this=0x7fffed958810) at core/variant/callable.cpp:132
132                     return ObjectDB::get_instance(custom->get_object());
(gdb) bt
#0  0x0000555569bb727d in Callable::get_object (this=0x7fffed958810) at core/variant/callable.cpp:132
#1  0x000055556a3bde92 in MessageQueue::statistics (this=0x6070000f47e0) at core/object/message_queue.cpp:154
#2  0x000055556a3bd5f7 in MessageQueue::push_callablep (this=0x6070000f47e0, p_callable=..., p_args=0x0, p_argcount=0, p_show_error=false) at core/object/message_queue.cpp:121
#3  0x0000555562d0a0d7 in MessageQueue::push_callable<>(Callable const&) (this=0x6070000f47e0, p_callable=...) at ./core/object/message_queue.h:101
#4  0x0000555564fb08d3 in CanvasItem::queue_redraw (this=0x61f00055b290) at scene/main/canvas_item.cpp:358
#5  0x0000555565357cd3 in Button::set_text (this=0x61f00055b290, p_text=...) at scene/gui/button.cpp:451
#6  0x0000555562ed5c58 in EditorLog::LogFilter::set_message_count (this=0x604005f7ff60, p_count=2) at editor/editor_log.h:112
#7  0x0000555562ecd591 in EditorLog::_process_message (this=0x61e000d47090, p_msg=..., p_type=EditorLog::MSG_TYPE_STD) at editor/editor_log.cpp:223
#8  0x0000555562ecd7d4 in EditorLog::add_message (this=0x61e000d47090, p_msg=..., p_type=EditorLog::MSG_TYPE_STD) at editor/editor_log.cpp:235
#9  0x0000555562f7e18d in EditorNode::_print_handler (p_this=0x61f000064a90, p_string=..., p_error=false, p_rich=false) at editor/editor_node.cpp:6503
#10 0x000055556a49d45e in __print_line (p_string=...) at core/string/print_string.cpp:81
#11 0x000055555d8497a4 in print_line (v=...) at ./core/string/print_string.h:65
#12 0x000055556a3bd585 in MessageQueue::push_callablep (this=0x6070000f47e0, p_callable=..., p_args=0x0, p_argcount=0, p_show_error=false) at core/object/message_queue.cpp:120
#13 0x0000555562d0a0d7 in MessageQueue::push_callable<>(Callable const&) (this=0x6070000f47e0, p_callable=...) at ./core/object/message_queue.h:101
#14 0x0000555564fb08d3 in CanvasItem::queue_redraw (this=0x61f000556c90) at scene/main/canvas_item.cpp:358
#15 0x0000555565812266 in RichTextLabel::_add_item (this=0x61f000556c90, p_item=0x607001f7e040, p_enter=false, p_ensure_newline=false) at scene/gui/rich_text_label.cpp:2979
#16 0x0000555565811658 in RichTextLabel::add_text (this=0x61f000556c90, p_text=...) at scene/gui/rich_text_label.cpp:2924
#17 0x0000555562ece827 in EditorLog::_add_log_line (this=0x61e000d47090, p_message=..., p_replace_previous=false) at editor/editor_log.cpp:327
#18 0x0000555562ecd476 in EditorLog::_process_message (this=0x61e000d47090, p_msg=..., p_type=EditorLog::MSG_TYPE_STD) at editor/editor_log.cpp:219
#19 0x0000555562ecd7d4 in EditorLog::add_message (this=0x61e000d47090, p_msg=..., p_type=EditorLog::MSG_TYPE_STD) at editor/editor_log.cpp:235
#20 0x0000555562f7e18d in EditorNode::_print_handler (p_this=0x61f000064a90, p_string=..., p_error=false, p_rich=false) at editor/editor_node.cpp:6503
#21 0x000055556a49d45e in __print_line (p_string=...) at core/string/print_string.cpp:81
#22 0x000055555d8497a4 in print_line (v=...) at ./core/string/print_string.h:65
#23 0x000055556a3bd585 in MessageQueue::push_callablep (this=0x6070000f47e0, p_callable=..., p_args=0x0, p_argcount=0, p_show_error=false) at core/object/message_queue.cpp:120
#24 0x0000555562d0a0d7 in MessageQueue::push_callable<>(Callable const&) (this=0x6070000f47e0, p_callable=...) at ./core/object/message_queue.h:101
#25 0x000055556545c14a in Container::queue_sort (this=0x61e0002eb090) at scene/gui/container.cpp:143
#26 0x000055556545a586 in Container::_child_minsize_changed (this=0x61e0002eb090) at scene/gui/container.cpp:40
#27 0x00005555654633ec in call_with_variant_args_helper<Container>(Container*, void (Container::*)(), Variant const**, Callable::CallError&, IndexSequence<>) (p_instance=0x61e0002eb090, p_method=NULL, p_args=0x0, r_error=...)
    at ./core/variant/binder_common.h:293
#28 0x0000555565462b29 in call_with_variant_args<Container> (p_instance=0x61e0002eb090, p_method=(void (Container::*)(Container * const)) 0x55556545a562 <Container::_child_minsize_changed()>, p_args=0x0, p_argcount=0, r_error=...)
    at ./core/variant/binder_common.h:407
#29 0x0000555565461dfa in CallableCustomMethodPointer<Container>::call (this=0x608001864bb0, p_arguments=0x0, p_argcount=0, r_return_value=..., r_call_error=...) at ./core/object/callable_method_pointer.h:104
#30 0x0000555569bb5cd0 in Callable::callp (this=0x60d003e9d968, p_arguments=0x0, p_argcount=0, r_return_value=..., r_call_error=...) at core/variant/callable.cpp:50
#31 0x000055556a3d4e2f in Object::emit_signalp (this=0x61e0002ebc90, p_name=..., p_args=0x0, p_argcount=0) at core/object/object.cpp:1046
#32 0x000055555e92a5fb in Object::emit_signal<>(StringName const&) (this=0x61e0002ebc90, p_name=...) at ./core/object/object.h:869
#33 0x000055556547868b in Control::_update_minimum_size (this=0x61e0002ebc90) at scene/gui/control.cpp:1539
#34 0x000055555ea65bdc in call_with_variant_args_helper<__UnexistingClass>(__UnexistingClass*, void (__UnexistingClass::*)(), Variant const**, Callable::CallError&, IndexSequence<>) (p_instance=0x61e0002ebc90, p_method=NULL,
    p_args=0x7fffffffd0f0, r_error=...) at ./core/variant/binder_common.h:293
#35 0x000055555ea61adb in call_with_variant_args_dv<__UnexistingClass> (p_instance=0x61e0002ebc90, p_method=(void (__UnexistingClass::*)(__UnexistingClass * const)) 0x555565478414 <Control::_update_minimum_size()>, p_args=0x0,
    p_argcount=0, r_error=..., default_values=...) at ./core/variant/binder_common.h:440
--Type <RET> for more, q to quit, c to continue without paging--
#36 0x000055555ea584c4 in MethodBindT<>::call(Object*, Variant const**, int, Callable::CallError&) const (this=0x60c0000d69d0, p_object=0x61e0002ebc90, p_args=0x0, p_arg_count=0, r_error=...) at ./core/object/method_bind.h:320
#37 0x000055556a3d000c in Object::callp (this=0x61e0002ebc90, p_method=..., p_args=0x0, p_argcount=0, r_error=...) at core/object/object.cpp:733
#38 0x0000555569bb635f in Callable::callp (this=0x7fffedd587a0, p_arguments=0x0, p_argcount=0, r_return_value=..., r_call_error=...) at core/variant/callable.cpp:62
#39 0x000055556a3c0054 in MessageQueue::_call_function (this=0x6070000f47e0, p_callable=..., p_args=0x7fffedd587b8, p_argcount=0, p_show_error=false) at core/object/message_queue.cpp:229
#40 0x000055556a3c08be in MessageQueue::flush (this=0x6070000f47e0) at core/object/message_queue.cpp:275
#41 0x000055556514b8da in SceneTree::process (this=0x619000301190, p_time=0.0069444444444444449) at scene/main/scene_tree.cpp:461
#42 0x000055555d9911eb in Main::iteration () at main/main.cpp:3131
#43 0x000055555d8432ea in OS_LinuxBSD::run (this=0x7fffffffdf30) at platform/linuxbsd/os_linuxbsd.cpp:880
#44 0x000055555d82ebd2 in main (argc=4, argv=0x7fffffffe538) at platform/linuxbsd/godot_linuxbsd.cpp:73

To add: this only happens if the TextureRect's expand mode is "Fit Width Proportional"

I spent some time researching this bug, and it appears to be caused in part due to container sorting logic (specifically the AspectRatioContainer, but I haven't investigated other containers yet). Essentially, after changing the mode to Cover, the children are sorted / resized. This causes the container's minimum size to change, which causes the sorting to happen again, except this time the children are sized larger than before, which affects the container's minimum size (infinite loop), and this continues until the MessageQueue buffer is full, explaining the stack trace above. This leads me to believe the issue is with a signal/notification, because the message queue doesn't appear to be fully processing messages (and freeing up queue space).
There may be a separate bug with the message queue causing an access violation, which may only manifest when the queue is full. I am investigating that too.

The MessageQueue crash is likely https://github.com/godotengine/godot/issues/63298
But the infinite loop in container logic should be fixed independently of that one.

Printing the child_size gives interesting results 🙃
https://user-images.githubusercontent.com/2223172/219110360-c16395b8-4d76-43c7-ac2f-f54e614a702d.mp4

If the issue is caused by the TextureRect, then from the discussion on RC it seems that TextureRect is wrongly using its current size to compute its min size. This shouldn't be done.

Then what should it use? The whole point of expand modes was to have the TextureRect fit the texture properly based on size.

@KoBeWi It should use the current size to compute the size of the texture. But it should not use it to compute the min size of the control, otherwise it can lead to infinite growth and recalculation, as is observed. The texture size should be used for the min size.

Okay, so after looking into the feature, I think that the original problem should've been solved differently. This implementation tries to trick the container into keeping a ratio by manipulating the min size, but that leads to other issues, as min size has to be deterministic and it isn't. This feature doesn't work with all containers because of that, and it also glitches when the control is used standalone, with anchors.
The solution to the problem should've been to introduce a new sizing flags for containers, or a probably modifier, like Expand, so that we tell the container the desired behavior instead of trying to trick it with what is in essence a hack. That new flag would tell the container to take the min size of the child and use it as a ratio when filling the space, so if the container needs to make the height bigger, it also has to make the width bigger. Then on the TextureRect's side you need to give it a min size with a correct ratio matching your texture, which is a bit of a setup, but will work reliably.
That's the proper solution, IMO. As for the current one, I'm not sure how to salvage it, because it relies on an unstable logic. The safest option would probably be to remove the newly added expand options and only keep the first two, keep size and ignore size. Then we can work on a better solution, in 4.1 I guess.

Anyway, something needs to be done fast because a crash/infinite loop isn't a good thing to have in 4.0 stable :/

he safest option would probably be to remove the newly added expand options and only keep the first two, keep size and ignore size.

If we are going for a temporary fix for the crash, I have a better solution: #73396
No reason to remove a functionality if it works fine in every case except one.

No reason to remove a functionality if it works fine in every case except one.

It's not just one case, and the fact that it works at all is incidental. The implementation is simply incorrect, and we will not be able to remove it after 4.0.

I don't have a permanent solution for now. We could even go with your sizing flag solution (but it can't require setting minimum size), in worst case we will end up with a few legacy enum values for expand_mode and some compatibility code.
Expand flags are too important for TextureRect to remove them after they finally got implemented and made the class usable in containers.

but it can't require setting minimum size

Why is that a limitations? Setting up min sizes is a normal practice for containers. You would need to supply the ratio somehow, without relying on the current size to avoid cascading issues.

Expand flags are too important for TextureRect to remove them after they finally got implemented and made the class usable in containers.

A size flag would be easy to implement. I don't think committing to a problematic implementation just to preserve our current status quo is valid. I understand that you need this, but we should make it waterproof. I'm sorry that the PR hasn't been reviewed properly in the first place, so we could avoid it.

Why is that a limitations?

Because it makes the TextureRect too rigid. If I use any expand mode other than "Keep Size", I don't care about texture size and just want the TextureRect to fit in whatever I put it into. Before Expand Modes I had to resort to all sorts of hacks to make it stretch properly in BoxContainers.
Implementing a ratio that depends on custom minimum size is totally pointless, because that's exactly how TextureRect was before - you had to use custom minimum size. And the container may change size or the size can sometimes be arbitrary, which makes it very cumbersome to work with.
As an example, you might want to have a HBoxContainer with text and icon. The icon is bigger than font, so you enable the "Expand" (as it was in 3.x) and set a minimum size, so the icon fits. But then you decide to change the font size, or whatever detail that affects the icon size. Suddenly it doesn't fit anymore and you have to manually set a new minimum size that will make the icon stretch properly. After doing it 10+ times, it becomes kind of annoying. It's even worse if the icon isn't square, because you need to calculate the minimum size that will make the icon keep aspect ratio.

But what I propose doesn't require you to do any of that. You give it a small minimum size and leave the rest to the container. If you really want to remove this step, we could add a flag to TextureRect to have a min size be a small ratio based on the texture size (say, values between 0 and 1). That would still be deterministic and work with any container.

I am interested in implementing the approach from @YuriSizov, including any compatibility shims / fixups. I'm a new contributor, but I think I can manage this implementation (including docs, compatibility/migration tooling, etc.). I think I will give it a try. :)

@chutchinson Hey, thanks for offering! It depends on the timeline right now. If we only remove the current options right now, and work on the solution later, I'd be happy to help you with this. But if we want to have the implementation replaced in the next few days (or even today), it's probably better if one of the maintainers (well, me, I guess) works on it. I'll let you know the plan.

The crash is fixed by #73396, so repurposing this issue for the underlying bug (feel free to edit the title if I didn't infer it correctly).

@chutchinson If you want to work on a PR for the updated implementation, feel free. If you drop by the contributors chat, I can help you to figure out the necessary steps.

In the end it might be impossible to implement proportional sizing for controls without the min size hackery, similar to how it's done in TextureRect. The main problem is that there is no mechanism to enforce any size restrictions aside from through the min size. So if we need to somehow tell the owning container that hey, if I grow horizontally I also must grow vertically, we just can't do that.
The container sizing option that I proposed here only moves the hack from the child node, like TextureRect, to the parent container. But then, if that container is also a child of another container, then we can only communicate this new limit via the min size. So we end up in the same place we are currently, with unstable logic that just kind of works.
Say we have a BoxContainer. It uses children min sizes to allocate itself a min size. If it's anchored and you resize it to be bigger, or if it's a child of another container that resizes it to be bigger, then it can use the remaining size to expand the children that want that. So in HBox we are free to expand horizontally to take as much space as there is. But if these children are configured to resize proportionally, then they will demand more vertical space as well. Something that our HBox doesn't necessarily have.
Which is not a problem in an anchored control, we can just grow in any direction. But if our HBox is a child of another container, say VBox, it needs to request more space from that VBox, and the only mechanism that Godot has for that is min size. (And then VBox might need to request space from its parent, and so on.)

Long story short, I'm putting a pin in this one. Feel free to come up with alternative ideas.
So far I can imagine some path with introducing an extra concept, besides the min size, that containers can use for their sizing logic. That could allow us to divorce the container logic and general min size limitations a node might have. So a control node can have some "requested size" which the container will use for allocating some space (all the way up the chain), and min size would be only used to actually limit the minimal size.

The crash is fixed by #73396, so repurposing this issue for the underlying bug (feel free to edit the title if I didn't infer it correctly).

The crash doesn't seem to be fully fixed, it still crashes if there are other container nodes (e.g. BoxContainer) between the AspectRatioContainer and the TextureRect.
These two functions are in conflict with each other.

The container tries to rely on the minimum size of the child control to determine the display space of the child control;
And the size of the child control depends on the size of the display space, which affects its own minimum size.

The condition of the infinite loop is met. Similar to #75713 at this point.

source: gharchive/issue

authors: KoBeWi Rindbee YuriSizov Zireael07 akien-mga chutchinson phil-hudson robertomorrison0 timothyqiu

repo: godotengine/godot

license: MIT

license_type: permissive

license_source: github-api


text:
Perfect music loop clips in Godot 4.

Godot version
4.0.2
System information
Windows 10
Issue description
I have a song that loops to an offset. This looping works perfectly in Godot 3 and Audacity, but Godot 4 introduces an ugly audio clip.
I will post a video so you can see what I mean.
Sorry if this is a duplicate, I tried looking for audio loop issues but didn't find anything that could be similar to mine. Except maybe issue #26931 but that one seems to go back to Godot 3, so I don't know if it applies.
I'm not sure what could be going on, maybe there's a small delay when looping? Or maybe the loop position is not being set correctly?
https://user-images.githubusercontent.com/113683950/233506996-b28cc420-a0d6-43bc-9d9a-559a4fe20718.mp4
Steps to reproduce
N/A
Minimal reproduction project
N/A

@strellydev Please upload a minimal reproduction project to make this easier to troubleshoot.

Doesn't matter if it's ogg, mp3 or wav, the three of them make the clip sound, although I must say the mp3 clip is way less noticeable.
In Godot 3, only wav introduces the audio clip, and again, way less noticeable.
I searched again for similar issues using "pop" instead of "clip" and this one came about: #64775
But there it says the mp3 version of the song doesn't pop, so I'll still upload my sample project in case it's useful on detecting a similar issue with mp3 files.
You'll find the projects in the main issue post.

Edit 3: Okay this is very weird in Godot 3. Like I said, in Godot 3, wav introduces de "pop" sound, but it's kinda random, I sat there repeating the loop and some times it doesn't introduce it and others it does. So yeah, no clue what's going on with that.

See https://github.com/godotengine/godot/issues/22016.

I will take a look at that, thanks, I'll close this issue too, seeing that it's covered by 64775.
Thanks for you support!

authors: Calinou strellydev


text:
Control get_focus_neighbor works only with manually assigned neighbours

Godot version
4.0.3
System information
Windows 10, all renderers, Nvidia GTX2070
Issue description
I'm trying to add a common game feature - continuous button traverse (focusing on the following UI in the direction). Every way possible I hit a brick wall to realize it.
With a keyboard, it "works" by default, thanks to an event echo. It is too fast and not usable. For a gamepad, it doesn't happen.
The last solution was to use the get_viewport().gui_focus_changed.connect(gui_focus_changed) signal to receive the focused Control node and change focus to its neighbor. Except it doesn't work automatically as it would with built-in UI actions, because there is no way to get a neighbor of a side without manually going over EVERY control to assign neighbors.
Control.get_focus_neighbour(side: Side) should give the same neighbor that would be focused automatically using UI actions.
Or at least give Control a method to focus on a neighbor to the side if there is any.
Steps to reproduce
The first solution was to remove "ui_right", "ui_left", "ui_down" and "ui_up" events from the input map to trigger actions from a code. Everything would be fine if Input.action_press("ui_right") worked in full extension instead of just Input.is_action_pressed() and Input.is_action_just_pressed.
Workaround to that would be to add arbitrary events to UI actions and trigger them with Input.parse_input_event(). But then I have to pray that a player won't trigger them.
Minimal reproduction project
.

Duplicate of https://github.com/godotengine/godot-proposals/issues/6690.

authors: Calinou nezvers


text:
Exits the editor

Tested versions
In the 4.3 stable
System information
Xiaomi mi 8 lite snapdragon 660
Issue description
I'm in the 3D tab either adding the player script when suddenly it exits godot
Steps to reproduce
The problem is not in the code but in the editor
Minimal reproduction project (MRP)
I just don't understand what you're referring to.

Can you please provide more information?
Also, please write responses in English (a machine translation is fine). This is an English speaking community, so we ask that everyone use English to interact.

Thank you for your report, but there isn't enough information here to do anything with this report, so I am closing this issue
If you provide more information this can be reopened

authors: AThousandShips Samuel-serna clayjohn


text:
Mention how to handle cancel in ConfirmationDialog

Resolves #17460
Although not sure what about the modal_closed mentioned in the issue. The get_cancel() is the proper way to use cancel, but you can do also do
connect("modal_closed", self, "cancelled") #This is emitted when user clicks outside dialog.
get_close_button().connect("pressed", self, "cancelled") #This is emitted when user clicks X.

which are more like "neutral actions" and aren't immanent to ConfirmationDialog.

Thanks!

source: gharchive/pull-request

authors: KoBeWi akien-mga


text:
Add editor freelook navigation scheme settings

Depending on what one is trying to achieve, a different freelook mode may be more desirable.

Video comparison (normal, then partly axis-locked, then fully axis-locked)
Feel free to suggest better names for settings; it's difficult to convey the differences in a single, short line.
Setting descriptions

Default (like it currently is).
Partially Axis-Locked

Vertical movement won't take camera pitch into account, but forward/backward movement will. This is similar to id Tech games' noclip mode, among many others.

Fully Axis-Locked

Same as Partially Axis-Locked, but forward/backward movement also won't take camera pitch into account. This is similar to Minecraft.

This closes #34034.

I think the settings descriptions you typed out are fine, I wonder if it's possible to put them in the docs somehow

Thanks!

Cherry-picked for 3.2.2.

authors: Calinou akien-mga asheraryam


text:
WebSocketServer: Expose the resource name the client used

This adds a method to WebSocketServer to retrieve the resource name (the part after the domain name, including any queries) that the client connected with.
I did not expose it to clients both due to reduced code-complexity and the fact that the clients (at least non-html5 ones) should already have access to it implicitly.
My use-cases for this are

Process a client immediately upon connection rather than wait for them to send a followup.
Related to the above, possibly authentication of a client so that connections can be dropped immediately rather than possibly hanging open waiting for a bad client to authenticate itself in a followup.

Very open to comments/feedback.

websocketserver.get_resource_name(1)

(and also for non-existent ids) returns the empty string, as well as errors in the debugger:
E 0:00:02.849   get_peer_resource_name: Condition "!has_peer(p_peer_id)" is true. Returned: String()
  <C++ Source>  modules/websocket/wsl_server.cpp:288 @ get_peer_resource_name()
  <Stack Trace> CmdServerSetup.gd:45 @ _connected()
                CmdServerSetup.gd:77 @ _process()

I am not sure if it is desirable to handle this a different way. I am also not sure what happens if websockets are used in conjunction with high level multiplayer.

Does this need a proposal to be considered?

Does this need a proposal to be considered?

No, I think this is nice, I don't like too much that we keep the resource name for the whole life cycle.
I'd also drop get_peer_resource_name and just leave get_peer(ID).get_resource_name() in case.

Does this need a proposal to be considered?

No, I think this is nice, I don't like too much that we keep the resource name for the whole life cycle.

The lifecycle of the peer? Or have I mistakenly stored it outside the peer/outside something that gets cleared when a peer is cleared?

I'd also drop get_peer_resource_name and just leave get_peer(ID).get_resource_name() in case.

What distinguishes get_peer_resource_name from the other two server-methods get_peer_port or get_peer_address? That it is a higher-layer concept than address/port?
I think another part of the reason I put the method on the server rather than exposing the method on the peer itself is to avoid having clients also need to store the resource name when they connect (which increases the code-complexity a bit from what I could see), though I might be overlooking something silly or overestimating the extra complexity. I did not really like having to pass the extra reference argument through two calls on the server though.
I can see it being beneficial to more explicitly put it on the peer/connection itself though.

I guess the client would be able to call it on a peer object (the server), but that it would not be useful (and that the server is the only peer the client is able to get with get_peer currently?).

I am not sure if I understand what changes the review is requesting (or if I have misunderstood the increased complexity from the changes).

I am not sure if I understand what changes the review is requesting (or if I have misunderstood the increased complexity from the changes).

CC @Faless

The lifecycle of the peer?

Yeah, that information is only relevant during connection, i.e. during the HTTP handshake, it's meaningless after that (from the protocol point of view), so it should not be stored anywhere after the handshake has completed. It might make sense to add it to the client_connected signal, but why should we keep it after that?

This makes sense, thanks. I did not think of signals when I thought of how to only temporarily expose a value.
Is it unproblematic to change the API by modifying existing signals (like client_connected) though? It would be added after the peer_id and protocol parameters from what I see.

Yeah, you are right, it's the other way around, the method should not stay on the peer at all.
Not WebSocketPeer::get_resource_name should exist in peer.

On the bright side, if adjusting existing signals by adding another parameter is fine, then this will simplify the changes a lot since the client_connected-signal is emitted through a call to _on_connect in the very same function where the resourcename is obtained:
https://github.com/godotengine/godot/blob/77803c10c18299cd531e1649159a521fab418c97/modules/websocket/wsl_server.cpp#L200-L226

Is it unproblematic to change the API by modifying existing signals (like client_connected) though?

Yes, this breaks compatibility but it's fine to do in 4.0.

So more or less like this?
I am having trouble testing them because I only applied them to my 4.0 branch where the editor runs pretty bad for me.

aaa forgot to update ADD_SIGNAL

Still good to go, I think.

Fixed a merge conflict in modules/websocket/emws_client.cpp since another commit also removed the superfluous semicolons there (there should now no changes to that file in this commit (though the previous changes there were just style-changes)).
Maybe it is better to squash and rebase instead of being lazy with the github web-ui though.

should be good now
although I have not been able to test it manually due to vulkan issues (the godot editor is detecting the wrong gpu/vulkan device and failing to start).

Thanks!

authors: Faless Meriipu akien-mga


text:
Add 'Export App Bundle' to Android Export Options

The final step in moving towards a gradle-based build system that can export Android App Bundles is to add the user interface element. For the 3.x release, and following the contribution guidelines, I think the simplest way to do this is to add a drop down menu to be able to Export as AAB. This option will not work unless Use Custom Build is also selected. For more details on the final scope of this project, read this comment.
The default value for this drop down menu is Export APK. If Use Custom Build is not selected, then Export APK follows the legacy build system. If Use Custom Build is selected and Export APK is selected, then it follows the normal Use Custom Build system.
The PR for the 4.0 branch might look different depending on how much of the legacy build system we want to retain.
We are working on this PR with @m4gr3d, as explained here
This PR builds on top of many previous PRs I've submitted. There are a lot of changes that need to be made to move towards a Gradle-based build system, so I have broken these changes into smaller, more understandable steps.

@akien-mga For the UI, another option is to replace Use Custom Build  and Export App Bundle (added by this PR) options with a drop-down that would list the various options for exporting the app.
For example, the options could be:

Export apk using legacy build
Export apk using gradle build
Export aab

The issue with this approach of course if that it would be slightly breaking compatibility as opposed to the current which, while not the best UX, does the job and doesn't break compatibility.
If we want to avoid breaking compatibility for the 3.2.x branch, we can also use the drop-down idea for the PR against master.

@amanj120 Don't forget to squash the commits.

I am so looking forward to this btw.

Thanks!

Does this support Play Asset Delivery and/or Play Feature Delivery. I'm interested in separating parts of my game which are In app purchase access only.

@fuzzypurplepixel This PR doesn't and it won't be available in Godot 3.2.4, but we're working on making it available in a future release.


text:
Fix Render Info

Fixed and redone the process to obtain render information from a Viewport
Some stats, such as material changes are too difficult to guess on Vulkan, were removed.
Separated visible and shadow stats, which causes confusion.
Texture, buffer and general video memory can be queried now.
Fixed the performance metrics too.

Feedback welcome on how to display the above info better ^

On the screenshot, the number of vertices drawn in shadow is greater than the general vertex count. If this actually is the case, I suggest displaying it as "(+15956446 in shadow)" instead.

The in shadow I read as counts within that other count which makes it weird they are higher numbers. I think this should be in shadowpass.

I would like to request that the current vertex count be renamed to "index count" (if index is confusing, it could be divided by 3 and named "triangle count"):
This disparity is evidenced in the code, where it assigns indices to the "vertices in frame" render info.
p_render_data->render_info->info[RS::VIEWPORT_RENDER_INFO_TYPE_VISIBLE][RS::VIEWPORT_RENDER_INFO_VERTICES_IN_FRAME] += indices;

I would also like to request that, if know, the true vertex count be measured by summing up the vertices of each object rendered. The true vertex count can be helpful for optimizing vertex shader invocation, skinning passes or other per-vertex overhead.

Also wish to support @lyuma 's suggestion (beyond an uptick). This has caused misunderstandings many times.

LOD generation is good
https://user-images.githubusercontent.com/17591539/124349236-d5c7a200-dbf6-11eb-9585-72579f20304f.mp4
shadows are too very expensive draw calls 93 bad optimization need optimization in LightmapGI
https://user-images.githubusercontent.com/17591539/124349272-f2fc7080-dbf6-11eb-9824-f8eb91775c44.mp4
configure global illumination Baked / Dynamic

the result is nothing diminishing the shadow in the draw calls
https://user-images.githubusercontent.com/17591539/124349457-be3ce900-dbf7-11eb-96a3-4e46b6fbbfd3.mp4

GI has nothing to do with shadows @Mobs1024

@reduz OmniLight3D and SpotLight3D shadow are zero if movement shows in shadows
https://user-images.githubusercontent.com/17591539/124351600-fba77380-dc03-11eb-9057-7c3ebfecf5c9.mp4

"Indices" is probably confusing, so maybe I should change the counter to be "primitives"?

@reduz OmniLight3D and SpotLight3D shadow are zero if movement shows in shadows

@Mobs1024 This is a feature, not a bug, if the shadow does not change it's not redrawn hence you see 0.
I have the feeling this information may be too confusing to users, who may think this ia bug, so maybe showing stuff in shadows should be avoided.

I have the feeling this information may be too confusing to users, who may think this ia bug, so maybe showing stuff in shadows should be avoided.

You mean not show shadow statistics at all? If we lump them all together, users will be more confused, and if we don't include shadow statistics, the information becomes much more limited in value as we are only telling half the story. Another option is a beginner / advanced selector in the editor options which controls such options (as we have for the project settings), if the concern is overwhelming beginners.

@lawnjelly to be honest I don't think shadow information is that useful. If you really want to see it, maybe an add-on could show it (I did not remove the API to obtain it). You can already see in the new GPU profiler how much it takes to render shadows anyway so if you have a bottleneck there it will be obvious.

I changed it to look like this:

Thanks!

authors: BastiaanOlij Calinou Mobs1024 Zireael07 akien-mga lawnjelly lyuma reduz


text:
[3.x] Compile TSCN files into binary .scn on export

Fixes https://github.com/godotengine/godot-docs/issues/5131 (.tscn scenes are compiled by default into .scn on export as expected)
Possible fix for https://github.com/godotengine/godot/issues/42115

The setting still needs to be respected. The only change here should be the introduction of compression, possibly to all types of resources, not just scenes. Well, I guess the extension can also be changed for scenes, if you are really pedantic about it, but it’s not necessary.

The plugin name EditorExportTextSceneToBinaryPlugin is misleading by itself as it doesn't mention text resources (in general) but only the scenes so maybe that should be changed as well?

Also, all PRs must be made against master first and foremost, unless there is a very special need to fix something in a 3.x branch. Changes can then be backported to 3.x anyway, either via a cherrypick (if compatible) or a dedicated PR (like this one).

I will prepare separate PR for master, but I'm working on a huge project on 3.x where I can check this better and mentioned bugs related to 3.x, that's why I reveresed the priority. I don't see prepared test project for 4.0.

The plugin name EditorExportTextSceneToBinaryPlugin is misleading by itself as it doesn't mention text resources (in general) but only the scenes so maybe that should be changed as well?

If all kinds of resources are piped through it, possibly.l it can be renamed. Though this can be left for a master PR for compatibility reasons.

If all kinds of resources are piped through it, possibly.l it can be renamed. Though this can be left for a master PR for compatibility reasons.

Maybe I will leave it here and change in separate PR, but it looks like they are. At least this is the only place (*two places in one plugin) where GLOBAL_GET("editor/export/convert_text_resources_to_binary") is respected.

A brief look at the design on export tscns to final project. Here are the trade-offs, and comments on the choices we can make when exporting.

text should not be default because it's big
binary (un-compressed) should be the default because steam or itch will also do compression
binary (zstd compressed) should be an option because sometimes the game is not shipped on a store
.pck vs zip is unrelated

Compressed binary should be the default. Even if the transfer is compressed by Steam etc, there's no reason the game should take up more space on disk (even after extracting a zip for instance). Especially with zstd reading compressed data (and decompressing it) is faster than reading not compressed data.
Also, it would be really interesting if someone looked into using the zstd training mode to create a dictionary during export - that should significantly improve compression of these types of files.

Regarding compression - now it's respecting filesystem/on_save/compress_binary_resources.
I agree that binary should be the default (as it is in most engines, I think that in major ones you don't have any choice), so I changed the default value of editor/convert_text_resources_to_binary_on_export to true.

@Listwon

so I changed the default value of editor/convert_text_resources_to_binary_on_export to true.

Maybe you should add this note to the top comment. It is a backport of #33228.
What else does this PR need to make it into 3.x? Compression is great, but I'm especially interested in binary everything on export by default.
Thanks for the effort.

authors: Listwon fire pycbouh tinmanjuggernaut xix-xeaon


text:
Optimize AABB calculation in software skinning

Using min/max instead of regular AABB for optimal processing.
Based on @lawnjelly's suggestion (see https://github.com/godotengine/godot/pull/53144#issuecomment-928946058).
This is 3.x only since software skinning is not implemented on master for now.

It does remind me, at some point we should add a REAL_MAX, that changes to represent the MAX depending on whether real_t is 32 or 64 bit, this would be more correct (although until 64 bit becomes common in Godot 4.x I doubt it matters in practice). Then change all the suitable FLT_MAXs in the same PR.

Thanks!

authors: akien-mga lawnjelly pouleyKetchoupp


text:
[3.x] Add drag and drop to TextEdit, LineEdit, RichTextLabel

Add drag and drop operation for TextEdit, LineEdit and RichTextLabel (only drag).
This is a backport of 55294 54339 55207 from master to 3.x branch.

Thanks!

authors: ConteZero akien-mga


text:
Exposes the BulletSpace internals.

Exposes the BulletSpace internals.
This change is really useful to use internal bullet physics features not supported by godot.

I'm not so fond of just making internals public without any kind of documented use case or usage instructions. Feels like a big "HERE BE DRAGONS" comment is needed then.
Some of this stuff like gravityDirection/gravityMagnitude require a call to update_gravity for the changes to make sense for example. Just exposing this as public doesn't guarantee that users will do this like set_param/get_param does.

Definitely will not change much for users, especially if they use GDScript or the PhysicsServer.
What this PR allows is that it's now possible to use the bullet physics internal parts directly:
The first step is cast the PhysicsServer to BulletPhysicsServer https://github.com/AndreaCatania/godot-kinematic-body/blob/3.x/kinematic_object_3d.cpp#L302-L305
Then it's possible to use bullet physics query directly: https://github.com/AndreaCatania/godot-kinematic-body/blob/3.x/kinematic_object_3d.cpp#L186-L191
In this way it's possible to use some not exposed bullet physics features, using C++.
This will not cause any issue, as it's not exposing anything new to the uses who normally deal with just the PhysicsServer.

I think if we expose things, we have a responsibility to make it usable, so at the very least some documentation should be added in the header so that users know what to do with these exposed internals.
I understand that it's for power users and that it's "here be dragons" material, so it doesn't have to be very detailed, but some docs like what you commented above can be useful (both to clarify why these internals are public in the first place, and how to use them for the few power users - most likely only you ;) - that will try to use them).

@akien-mga Doc added!

Thanks!

authors: AndreaCatania akien-mga


text:
Add ability to flag classes as experimental or deprecated

Draft WIP PR. Only supports is_experimental and is_deprecated flags for whole classes at the moment, but hoping to add support for methods, properties, and signals soon.
Implementing the proposal described here #5279

Thanks for the feedback!

Latest update:

Implemented Calinou's recommendations for deprecation.
Added support to class members too.
Removed deprecation and experimental flags from ClassDB since I think it can be implemented well enough purely as a doc feature.

I think this is at a point it can be considered merging now, though it might be worth asking what things, if any, might be appropriate candidates for this flag. Given 4.0 is a clean slate of sorts, deprecation isn't concern, but there are certain things which might be worth considering for 'experimental' status given the uncertainity surrounding their implementation.

Rebased now with changes recommended by @akien-mga.

Though, actually, I'm not sure if I'm specifically being asked to remove the deprecation/experimental markings for members/methods/signals. I personally don't see harm in having the markings avalible for the sake of consistency and the likelyhood that we may be more inclined deprecate individual functions as opposed to whole classes, but I guess can strip this part if you'd like.

Thanks!

authors: SaracenOne akien-mga


text:
Update list of known breaking changes compared to 4.0-stable (3)

Also moves the error annotation from README.md to the 4.0-stable.expected file.

Thanks!

authors: RedworkDE akien-mga


text:
Update tilemap physics' world2D on reparenting

Supersedes https://github.com/godotengine/godot/pull/84757
Fixes https://github.com/godotengine/godot/issues/83291
This is the same fix as in #84757, with the changes I requested. Made this superseding PR to have this included in RC1

Thanks @NewDefectus and @groud!

authors: akien-mga groud


text:
Add 1 second sleep after starting blender RPC

Ran into a bug where blender rpc server would not start fast enough and cause Godot editor to think that it was not running, more details here: in #85446
This simply adds a 1 second delay between starting the rpc server and initiating the connection via HTTP.
I thought about checking the STDOUT of the rpc command, but OS::create_process does not have a way to read the STDOUT that I can see in the codebase.
Production edit: Closes https://github.com/godotengine/godot/issues/85446

Alternative approach which might be less hacky: in the switch case that checks for the connection status, add a new case for STATUS_CANT_CONNECT (which is equivalent to the 4 that got printed in the issue you linked), delay for ~100ms in there and count a local "retry" counter up by 1. If it hits 10, error as before. This can make the delay shorter, as it'll poll for the RPC status more frequently while starting.

Alternative approach which might be less hacky: in the switch case that checks for the connection status, add a new case for STATUS_CANT_CONNECT (which is equivalent to the 4 that got printed in the issue you linked), delay for ~100ms in there and count a local "retry" counter up by 1. If it hits 10, error as before. This can make the delay shorter, as it'll poll for the RPC status more frequently while starting.

I thought about this as well, but got a little side tracked looking for a sleep function 🤣
I can update the PR to apply that kind of logic, the STATUS_CANT_CONNECT branch in the switch statement will have to rerun the client->connect_to_host("127.0.0.1", rpc_port); code a presume.

the STATUS_CANT_CONNECT branch in the switch statement will have to rerun the client->connect_to_host("127.0.0.1", rpc_port); code I presume.

Yeah I believe so as well.

the STATUS_CANT_CONNECT branch in the switch statement will have to rerun the client->connect_to_host("127.0.0.1", rpc_port); code I presume.

Yeah I believe so as well.

Since it will be waiting for max ~100ms if the RPC server start immediately, might make sense to increase the max wait time to like ~5s or ~10 seconds incase it's super slow on older machines?
It should still be faster on newer machines since it will break out of the loop when connected, but allow for slower devices to wait longer for the RPC server to spool up?

Sometimes other implementation use exponential backoff. Do you think that's required here?

Like the wikipedia page https://en.wikipedia.org/wiki/Exponential_backoff Truncated exponential backoff

Like the wikipedia page https://en.wikipedia.org/wiki/Exponential_backoff Truncated exponential backoff

I've pushed a change that allows this to return as early as 1000us instead of waiting for a full 1 second.
Latest push should also be rebased on master branch

Got busy with other stuff, sorry took me a while to get this done 🤣

Thanks @AThousandShips, I missed those :)

Nice, build passed finally! :)

Anything else that I need to add to this PR? Happy holidays btw! 😄

This PR has been open for a while now, not sure what the next step is.

Looks good to me overall.
Could you squash the commits? See PR workflow for instructions.

Sure, I'll squash the commits

I've pushed the squashed commit

Sorry, I missed the commit for the const changes, pushing now.

Changed to &p_client

I can't see the failure on the test.

Thanks!

Cherry-picked for 4.2.2.

authors: RedMser akien-mga fire mxaddict


text:
Fix infinite loop when calculating zoom level if tile_size * max_zoom < default

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

I made some modifications to the code as I noticed some potential issues, especially regarding zoom limits. Below, I describe the main ones:
Points of Divergence:

Consideration of Zoom Limits:

Changes in this PR: It does not explicitly consider the maximum and minimum zoom limits during the zoom adjustment loops.
My changes: Implement precise checks for the maximum and minimum zoom limits, avoiding infinite loops and ensuring that the zoom does not exceed these limits.

Zoom Adjustment Logic:

Changes in this PR: It uses loops to increase or decrease the zoom until reaching the desired tile size, without explicitly considering the zoom limits.
My changes: Considers whether the tile size multiplied by the maximum zoom is smaller than the desired size. It uses loops only when necessary, with checks for the zoom limits.

Handling Extreme Conditions:

Changes in this PR: It does not explicitly address scenarios where the original tile size multiplied by the maximum zoom is smaller than the desired size.
My changes: Specifically handles these extreme conditions, ensuring proper zoom adjustment even in situations where the initial tile size multiplied by the maximum zoom is smaller than the desired size.

My Code - I tested it locally and it worked without any apparent errors:
// Set the default zoom value.
int default_control_y_size = 200 * EDSCALE;

float target_tile_size = default_control_y_size / editor_zoom_widget->get_zoom();
Vector2 original_tile_size = tile_set->get_tile_size();
Vector2 current_tile_size = original_tile_size * editor_zoom_widget->get_zoom();

// Checks if the multiplication of the tile size by the maximum zoom is less than the default size
if (original_tile_size.y * editor_zoom_widget->get_max_zoom() < default_control_y_size) {
  // Adjusts the zoom to the maximum possible without exceeding the desired standard size
  float new_zoom = editor_zoom_widget->get_zoom() * (default_control_y_size / (original_tile_size.y * editor_zoom_widget->get_max_zoom()));
  if (new_zoom >= editor_zoom_widget->get_max_zoom()) {
  	editor_zoom_widget->set_zoom(editor_zoom_widget->get_max_zoom());
  } else {
  	editor_zoom_widget->set_zoom(new_zoom);
  }
} else {
  // Checks if the current tile size is smaller or larger than the desired size
  if (current_tile_size.y < target_tile_size) {
  	while (current_tile_size.y < target_tile_size && editor_zoom_widget->get_zoom() < editor_zoom_widget->get_max_zoom()) {
  		editor_zoom_widget->set_zoom(editor_zoom_widget->get_zoom() * 1.1);
  		current_tile_size = original_tile_size * editor_zoom_widget->get_zoom();
  	}
  } else if (current_tile_size.y > target_tile_size) {
  	while (current_tile_size.y > target_tile_size && editor_zoom_widget->get_zoom() > editor_zoom_widget->get_min_zoom()) {
  		editor_zoom_widget->set_zoom(editor_zoom_widget->get_zoom() * 0.9);
  		current_tile_size = original_tile_size * editor_zoom_widget->get_zoom();
  	}
  }
}

_zoom_changed();

I'm not sure if the issues I've highlighted are really important to emphasize, but I made that comment just in case and to check for problems.
This is my first time commenting on an open-source project, so I hope I haven't done anything strange or wrong. Have a great day!

@VetusScientia Thank you very much for your suggestion, invaluable.
I guess we can ask for some advice from @groud since he is the author of this code.
Also, feel free to take my pr and work based on it.

Alright, sorry for the late review, and thanks for the contribution.
While @VetusScientia's one is, like, more "correct", it would add a lot of LoC for limited gains IMO. I think the approach by @jsjtxietian is the simplest one. I think the current state of the PR is acceptable.

You did perfectly fine ! :)

Thank you very much, @ground! I'm still studying Godot's source code, meaning I'm still a noob :smile:

While @VetusScientia's one is, like, more "correct", it would add a lot of LoC for limited gains IMO.

But the current state of the PR is indeed simpler and works well. I hope to be able to contribute better in the future!
Have a great day!

Thanks!

Cherry-picked for 4.2.2.

authors: VetusScientia akien-mga groud jsjtxietian


text:
feat(tabs): exposes new values in brn-tabs-trigger

PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows our
guidelines: https://github.com/goetzrobin/spartan/blob/main/CONTRIBUTING.md#-commit-message-guidelines
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

Which package are you modifying?

[ ] accordion
[ ] alert
[ ] alert-dialog
[ ] aspect-ratio
[ ] avatar
[ ] badge
[ ] button
[ ] calendar
[ ] card
[ ] checkbox
[ ] collapsible
[ ] combobox
[ ] command
[ ] context-menu
[ ] data-table
[ ] date-picker
[ ] dialog
[ ] dropdown-menu
[ ] hover-card
[ ] input
[ ] label
[ ] menubar
[ ] navigation-menu
[ ] popover
[ ] progress
[ ] radio-group
[ ] scroll-area
[ ] select
[ ] separator
[ ] sheet
[ ] skeleton
[ ] slider
[ ] switch
[ ] table
[x] tabs
[ ] textarea
[ ] toast
[ ] toggle
[ ] tooltip
[ ] typography

What is the current behavior?

Brn Trigger currently does not expose the underlying elementRef as well as some other key values that could be useful in customizing the tabs component.
See this as an example of code used to create below tabs example
https://github.com/thatsamsonkid/portfolio-analog/blob/main/src/app/content/experience.component.ts#L199
Closes #
What is the new behavior?
PR update Brn trigger directive to expose underlying elementRef as well getters for key and if the tab is currently active.
Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information
https://github.com/goetzrobin/spartan/assets/22568206/c8bdaa91-9af5-49fe-acea-c98510c329ef

Also, @thatsamsonkid  can you add the exposedAs for this issue: https://github.com/goetzrobin/spartan/issues/105? Thanks already!

Also, @thatsamsonkid  can you add the exposedAs for this issue: https://github.com/goetzrobin/spartan/issues/105? Thanks already!

All sounds like good ideas to me, I'll make the changes later today

authors: goetzrobin thatsamsonkid

repo: goetzrobin/spartan


text:
incomplete import detection for tests

So I think I finally cracked automation of Go BuildRequires in Fedora rpms (at least the technical POC works, it just needs cleaning up, macrofication and lots of testing)
The big difference between Requires and BuildRequires is that BuildRequires also needs to include the dependencies used by the project unit tests.
Unfortunaly, the first experiments show golist is not detecting those properly (I rebuilt the current snapshot with Go 1.11 just to be sure).
For example,
golist --imported --package-path github.com/sirupsen/logrus --skip-self --tests
only outputs
github.com/stretchr/testify/assert
for sirupsen logrus, when the terminal_check_notappengine.go test imports
golang.org/x/crypto/ssh/terminal
(I had other failures in other packages, this is the simplest case I found)
I hope that can be fixed quickly, otherwise buildrequire automation won't save a lot of packager time

migrated to
https://pagure.io/golist/issue/9

repo: gofed/symbols-extractor


text:
add basic action scripts

增加GitHub Action CI脚本 单元测试未调试完成

代码覆盖率测试已经增加，增加了多版本测试

repo: gogf/gf


text:
service restart packager.io

HI,
Is it possible to do an automatic service restart at the end of the update on packager.io?
Have a nice day

Thanks your feedback!
cc @crohr can you help on this?

@Unknwon Sure, the easiest way is to add service gogs restart || true at the end of this file: https://github.com/gogits/gogs/blob/master/packager/debian/postinst

Thanks @crohr !

Closed by #1686

authors: Unknwon crohr preovaleo

repo: gogits/gogs


text:
Concurrent map read and map write (Dashboard)

Describe the bug
My hornet node crashed after I opened the dashboard. The node was already online for ~16h where the error does not occur.
The error log says: "fatal error: concurrent map read and map write"
This happened around the same time where the coordinator was offline. Maybe there is a connection between the events.
As you can see in the log the restart & recovery worked without problems.
To Reproduce
Steps to reproduce the behavior:

not deterministic

Expected behavior
Hornet shouldn't crash under any circumstances ;)
Environment information:

OS: Arch Linux
RAM: 12GB
Cores: 4 Cores
Type: Contabo VPS
Browser: Chrome (Linux)
HORNET Version: 0.5.0

hornet-crash.log

The same bug with my Node.
Hetzner CPX31 Ubuntu 20.04.1 LTS
hornet_log_mn.log

Fixed in #637

authors: Travetown muXxer schnico

repo: gohornet/hornet


text:
hugo new only accepts the .md extension in Hugo v0.24

This starts to fail in 0.24 and used to work in 0.23 and earlier versions of Hugo:
$ hugo new test.Rmd -v
INFO 2017/06/23 23:59:21 Using config file:
INFO 2017/06/23 23:59:21 attempting to create "test.Rmd" of "" of ext ".Rmd"
Error: open : no such file or directory

I don't know what this error message means. Only hugo new test.md is permitted now.

Duplicates #3626 -- it seems to be a pain for many, so I will push v0.24.1 today.

Very nice. Thanks!

authors: bep yihui

repo: gohugoio/hugo


text:
Add HTTPS to hugo server

Via https://github.com/FiloSottile/mkcert
Only OSX and Linux for now, Windows promised ...

I think the support for Windows has been added

As far as I can see, it is now available on Windows as well!

What is the status on this? This would be really useful for a current project, where we need to access a remote API that only allows TLS connections...

I'm not sure what benefit this would add over simply running hugo -w and using a dedicated static web server to serve files in the public/ directory. A rudimentary HTTP server via the serve command makes sense for quick testing, but more sophisticated web server features like HTTPS probably belong in a dedicated program. I think Hugo should stick to being an SSG.

@Seirdy @bep Thanks for looking into this!
As a (we were hoping temporary) workaround, we are now using Caddy to get TLS, and reverse-proxying Hugo. It works, but it is a relatively complex set-up (we had to do some trickery to get LiveReload working again). Having said that, i do understand that local TLS is maybe not something one can expect from an SSG.

Closing as duplicate of https://github.com/gohugoio/hugo/issues/11064.

authors: Fale Seirdy akshaybabloo bep jmooring wouter-muller


text:
Code blocks not rendered well in post summaries

What version of Hugo are you using (hugo version)?
$ hugo version
hugo v0.82.0-9D960784 linux/amd64 BuildDate=2021-03-21T17:28:04Z VendorInfo=gohugoio

Does this issue reproduce with the latest release?
Yes, this is the latest release, downloaded yesterday.
The Problem
Hi, I just started using Hugo yesterday. Looks great so far, but one problem I ran into right away is that when code blocks appear near the beginning of a post they are included in the summaries on the front page under Recent Posts, but they're not rendered as code blocks. This obviously doesn't look great. See the attached image. The source for that post is here.
I'm sure I can find a work-around, such as adding more content before the code block or if there's a configuration option to change how much shows up in the summaries, or just leave it the way it is, but I wanted to let you know about it.

Thanks!

the same with you

like this

Please close this bug report and open a post on https://discourse.gohugo.io. You started yesterday with Hugo and this is not a bug, but a misunderstanding about how these things work. A quick fix is to add a description="whatever the postpreview should read" to the frontmatter of that post. A better fix is to check the layout file that creates this preview and evaluate if HTML tags are stripped, Markdown is parsed or whatever happens there.
All that are support questions and when you opened this issue you should have seen a link to the support forum and the reminder to please ask support questions in the forum.

ok, thanks. Yes, I missed the very clear note to use Discourse. Sorry.

authors: cgay davidsneighbour nicky-chen


text:
Fix Print Method in Feast CLI

Expected Behavior
Unit test in feast cli should pass every time
Current Behavior
Example failure:
http://prow.feast.ai/view/gcs/feast-templocation-kf-feast/pr-logs/pull/gojek_feast/208/unit-test-cli/1138606091794386947
Unit test will fail occasionally. This is due to mismatched expectation between the actual functionality in the cli and the unit test. Test expects the printed output of the spec to be ordered but the cli data structure to store some values in spec data (i.e. map data structure) does not ensure order.
Possible Solution
Either it's okay for the printed output of CLI to not be in order (in this case, the test case need to be updated) or modify the data structure used in CLI to store spec to support ordered iteration.
Steps to reproduce
git clone https://github.com/gojek/feast
cd feast
# Need to run this command many times (e.g. 50 times) to observe the error
go test -v ./cli/feast/...

Specifications

Version: 0.1.1 (https://github.com/gojek/feast/tree/d5000015f7313b8778d091138899cd6ddf9fd222)
Platform: all

This issue isn't relevant any more due to changes in Feast 0.3.0. The Feast CLI is being rewritten in Python.

authors: davidheryanto woop

repo: gojek/feast


text:
Application unresponsive to key/mouse input when scrolling through long completion popup

open a file like findview.go and in some function type fv. and wait for completion so you get a really long list.
start scrolling down list using scroller or keys and shortly you will get the freeze.

Started from dlv debug but at this point there is no response typing into terminal
Mac menubar is responsive

Perhaps when the completion list is ridiculously long we should fill the popup with a single item that says, "too many possibilities!"

Good one! Thanks!

repo: goki/gi


text:
Not doing type inference on NrnV function in axon

e.g., in axon/act.go
		var gknaMed, gknaSlow float32 // note: gosl can't infer types from NrnV function
		gknaMed = NrnV(ctx, ni, di, GknaMed)
		gknaSlow = NrnV(ctx, ni, di, GknaSlow)

should be easy enough to fix.  reports an invalid type.

also failing here:
		geCtxt := ly.CT.GeGain * nrnCtxtGe

Now that I'm seeing more of this, it is clear that it all used to work fine -- not just the NrnV methods. The problem is that the Go source package is no longer parsable to get type info.
The solution is to add a //gosl: nohlsl directive that includes in go type parse but then cuts out of final hlsl

repo: goki/gosl


text:
Unable to connect to go.googlesource.com - connection refused and network is unreachable

What version of dep are you using (dep version)?

$ dep version
dep:
 version     : v0.5.4
 build date  : 2019-07-01
 git hash    : 1f7c19e
 go version  : go1.12.6
 go compiler : gc
 platform    : linux/amd64
 features    : ImportDuringSolve=false

What dep command did you run?

dep ensure -v -vendor-only
What did you expect to see?
dep ensure process finished normally
What did you see instead?
dep ensure -v -vendor-only Output
$ dep ensure -v -vendor-only
(1/61) Wrote github.com/gorilla/mux@v1.6.1
(2/61) Wrote github.com/tdewolff/parse@v2.3.2
.
.
.
(53/61) Failed to write golang.org/x/net@master
(54/61) Failed to write github.com/jmespath/go-jmespath@0b12d6b5
(55/61) Failed to write google.golang.org/genproto@master
(56/61) Failed to write golang.org/x/text@v0.3.2
(57/61) Failed to write google.golang.org/appengine@v1.6.5
(58/61) Failed to write golang.org/x/sys@master
(59/61) Failed to write golang.org/x/crypto@master
(60/61) Failed to write google.golang.org/grpc@v1.22.0
(61/61) Failed to write github.com/aws/aws-sdk-go@v1.12.65
grouped write of manifest, lock and vendor: error while writing out vendor tree: failed to write dep tree: failed to export golang.org/x/net:
(1) failed to list versions for https://go.googlesource.com/net: fatal: unable to connect to go.googlesource.com:
go.googlesource.com[0: 74.125.24.82]: errno=Connection refused
go.googlesource.com[1: 2404:6800:4003:c03::52]: errno=Network is unreachable
: exit status 128

Appendix
I also try getting the manually like this
go get -v golang.org/x/net Output
go get -v golang.org/x/net
get "golang.org/x/net": found meta tag get.metaImport{Prefix:"golang.org/x/net", VCS:"git", RepoRoot:"https://go.googlesource.com/net"} at //golang.org/x/net?go-get=1
golang.org/x/net (download)
cd .; git clone -- https://go.googlesource.com/net /home/nakama/.gvm/pkgsets/go1.13/global/src/golang.org/x/net
Cloning into '/home/nakama/.gvm/pkgsets/go1.13/global/src/golang.org/x/net'...
fatal: unable to connect to go.googlesource.com:
go.googlesource.com[0: 74.125.24.82]: errno=Connection refused
go.googlesource.com[1: 2404:6800:4003:c03::52]: errno=Network is unreachable
package golang.org/x/net: exit status 128

Here's my go's informations
go env Output
$ go env
GO111MODULE="auto"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/nakama/.cache/go-build"
GOENV="/home/nakama/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/nakama/.gvm/pkgsets/go1.13/global"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/nakama/.gvm/gos/go1.13"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/nakama/.gvm/gos/go1.13/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build274251549=/tmp/go-build -gno-record-gcc-switches"

Here's my Gopkg.lock (only shown some)
Gopkg.lock Content
[[projects]]
branch = "master"
digest = "1:da4b52e542eac65f91f8278b619d24402901c17ed21624b3444a6cf76c2082d7"
name = "golang.org/x/crypto"
packages = [
"pkcs12",
"pkcs12/internal/rc2",
]
pruneopts = ""
revision = "e1110fd1c708ef015366ea01799a23c459593c47"
[[projects]]
branch = "master"
digest = "1:31cd6e3c114e17c5f0c9e8b0bcaa3025ab3c221ce36323c7ce1acaa753d0d0aa"
name = "golang.org/x/net"
packages = [
"context",
"http/httpguts",
"http2",
"http2/hpack",
"idna",
"internal/timeseries",
"trace",
]
pruneopts = ""
revision = "da137c7871d730100384dbcf36e6f8fa493aef5b"

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: leguminosa mvdan

repo: golang/dep

license_source: bigquery


text:
update Best Practices FAQ for usage in CI

What does this do / why do we need it?
Updates the FAQ section on 'Best Practices' for usage in a CI environment.
Preview link - sudo-suhas/dep:docs/FAQ.md@b92d0e7#how-do-i-use-dep-in-ci
What should your reviewer look out for in this PR?
Not 100% sure about the usage of env in travis config. Would it be better to inline the X.X.X in the curl command itself?
Do you need help or clarification on anything?
Should there be an example for appveyor as well? I am not quite sure how we would do this in appveyor though.
Which issue(s) does this PR fix?
fixes #1275
P.S I also made some formatting change for the Docker section to leverage the syntax highlighting in github/editors like vscode.

I have used the setup here - https://github.com/sudo-suhas/symcrypto.

Thank you for documenting how to do this with Travis. If someone else wants to do the same for AppVeyor that's would be great.  This is good for now and I'd like to get it in our FAQ toot sweet. ❤

@carolynvs Do you think we should also enable caching on travis config?
Can be done like so:
# ...
cache:
  directories:
    - $GOPATH/pkg/dep

@sudo-suhas I don't think that enabling dep caching should be a blanket recommendation. 🤔  Until recently, we have had intermittent cache corruption that would have been super annoying if it was breaking Travis build too.
Also according to https://docs.travis-ci.com/user/caching/#Things-not-to-cache they don't recommend it for larger caches.
https://docs.travis-ci.com/user/caching/#How-does-the-caching-work%3F

Note that this makes our cache not network-local, it’s still bound to network bandwidth and DNS resolutions for S3. That impacts what you can and should store in the cache. If you store archives larger than a few hundred megabytes in the cache, it’s unlikely that you’ll see a big speed improvement.

Would you mind making a pull request (or issue) so that we can talk it through with a wider audience? I'm not saying we shouldn't do it, but that we probably want to point people to the caveats and pitch it as "if you want to turn it on, here is the magic shotgun to point at your foot". 😄

@carolynvs Thanks for the awesome and through reply. I have created a PR #1359. Please take a look.

authors: carolynvs sudo-suhas


text:
image/draw: linux/arm64 segfault

The builder has little to say:
signal: segmentation fault (core dumped)
FAIL	image/draw	0.367s

Appears to be independent of other failures, will investigate tomorrow.

@4ad are you planning on looking at this? If so, I'll avoid duplicating your work. :-)

I can take a look, but only on Saturday, so if you want to look into it sooner, go ahead.

This is the simplest reproduction I could come up with without digging into compiler diagnostics. It prints signal: segmentation fault on linux/arm64, running from tip.
package main

var ch  = make(chan bool)

func main() {
	f()
	go g()
	<-ch
}

func g() {
	defer func() {
		r := recover()
		if r != nil {
			panic(r)
		}
		close(ch)
	}()
	f()
}

func f() {
	i1 := 8
	srcb := make([]byte, i1)
	dstb := make([]byte, i1)
	d0 := 0
	s0 := 0
	ddelta := 1
	sdelta := 1
	idelta := 1
	i0 := 0
	for dy := 1; dy > 0; dy-- {
		dpix := dstb[d0:]
		spix := srcb[s0:]
		for i := i0; i != i1; i += idelta {
			var sr, sg, sb, sa byte

			var dr, dg, db, da byte

			_ = spix[i]
			_ = dpix[i]
			_ = sa
			_ = dr
			_ = sr
			_ = dg
			_ = sg
			_ = db
			_ = sb
			_ = da
			_ = sa
		}
	}

	_ = ddelta
	_ = sdelta
}

repo: golang/go


text:
runtime/pprof: TestCPUProfileMultithreaded has too few samples on Windows

Random test failure:
windows-amd64-gce at 5c7f94421ef5eca55b37f778b427abd5ea174c26
http://build.golang.org/log/135576b3d6ecdc234707e6e75b2829b9c6ea5bef
--- FAIL: TestCPUProfileMultithreaded (0.44s)
	pprof_test.go:164: total 4 CPU profile samples collected
	pprof_test.go:173: runtime/pprof_test.cpuHog1: 2
	pprof_test.go:173: runtime/pprof_test.cpuHog2: 0
	pprof_test.go:187: runtime/pprof_test.cpuHog2 has 0 samples out of 2, want at least 1, ideally 1
FAIL
FAIL	runtime/pprof	8.433s

No flaky tests are tolerated. Let's deflake or delete.
/cc @alexbrainman @dvyukov @minux

The bigger problem here is that there were only 4 CPU samples collected in 0.44 seconds. That sounds like the sampling is doing 10 Hz instead of 100 Hz.

... That sounds like the sampling is doing 10 Hz instead of 100 Hz.

I suspect it is all what schedule does. Ours together with Windows scheduler. It varies between different environments - how many CPUs you have, whether you're running in VM or not.
My windows xp 386 2*CPU:
C:\>go test -v -run=TestCPUProfileMultithreaded runtime/pprof
=== RUN   TestCPUProfileMultithreaded
--- PASS: TestCPUProfileMultithreaded (0.27s)
        pprof_test.go:165: total 48 CPU profile samples collected
        pprof_test.go:174: runtime/pprof_test.cpuHog1: 24
        pprof_test.go:174: runtime/pprof_test.cpuHog2: 24
PASS
ok      runtime/pprof   0.453s

Another vm windows 7 amd64 1*CPU:
c:\>go test -v -run=TestCPUProfileMultithreaded runtime/pprof
=== RUN   TestCPUProfileMultithreaded
--- PASS: TestCPUProfileMultithreaded (0.35s)
        pprof_test.go:165: total 27 CPU profile samples collected
        pprof_test.go:174: runtime/pprof_test.cpuHog1: 16
        pprof_test.go:174: runtime/pprof_test.cpuHog2: 10
PASS
ok      runtime/pprof   0.395s

As far as I remember, I have seen numbers vary if your PC is busy doing other staff.
It has been a while since I have seen this issue on our builders.
Alex

Maybe timeBeginPeriod call failed in os1_windows.go? That would give 15ms timer precision instead of 1ms.

Maybe timeBeginPeriod call failed in os1_windows.go?

No, it didn't - https://go-review.googlesource.com/#/c/12546/
Alex

authors: alexbrainman bradfitz dvyukov rsc


text:
tour: clarify that "export" means "public"

Context: https://tour.golang.org/basics/3
Change the title above to describe your issue and add your feedback here, including code if necessary
hI
I did not understand the description export.Please provide more clear explanation
regards,ppp

@getpradeep9 it basically says that the language doesn't have something like:
public someMethod() {
  // ...
}

private someOtherMethod {
  // ...
}

In order to make something visible outside, you'll have to use a capital letter, as in:
SomeMethod() {
 // ...
 // SomeMethod can be seen from outside
}

someOtherMethod {
 // this one can't, it doesn't begin with a capital letter
}

Be careful. Export does not mean the same thing as public. Export is a module concept, while public is (usually) a class concept.

Sure. I changed the bug summary again... "clarify what "export" means"

This is a duplicate of #12005

authors: bradfitz ericmdantas getpradeep9 kytrinyx robpike


text:
release: PGP-sign source and binary releases

We should sign the official releases.

We provide the downloads' checksums over https. We can do better than SHA-1 in future releases, but signing the binaries adds little extra benefit over providing the hashes securely. We do at least already sign the OS X and Windows releases, but that's to make the operating systems happy

It's much easier to verify a hash than a PGP signature. Plus we already have an HTTPS certificate for golang.org. What's the additional value in also having a PGP key?

Issue #12057 is about switching to SHA256.

Switching to SHA256 seems much better, and less work. Closing as dup of #12057.

authors: 4ad adg bradfitz rsc


text:
encoding/asn1: ASN1 UTC Time support should accept Time in "YYMMDDhhmmsshhmm" format

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?
go version go1.6.2 darwin/amd64

What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/sthorne/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GO15VENDOREXPERIMENT="1"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fno-common"
CXX="clang++"
CGO_ENABLED="1"

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.

encoding/asn1 does not support both known ASN1 UtcTime formats as described here: http://www.obj-sys.com/asn1tutorial/node15.html.
asn1.parseUTCTime
Currently, only "YYMMDDhhmm[ss]Z" is supported.

What did you expect to see?
Support for "YYMMDDhhmm[ss]Z" or "YYMMDDhhmmsshhmm"

What did you see instead?
When using a server with the second format this is the error.

Error : Get https://ovirt.example.com/: tls: failed to parse certificate from server: asn1: time did not serialize back to the original value and may be invalid: given "141020123326+0000", but serialized as "141020123326Z"response Status:

CC @agl

UTCTime values MUST be expressed in Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are YYMMDDHHMMSSZ)

(From RFC 5280.)
If the certificate is issued by a public CA please include it and I'll complain to the CA.

authors: agl ianlancetaylor sthorne