gtigen panic about core

[ddkwork]

we need change InspectGenDecl func as:

			for i, field := range st.Fields.List {
				if field == nil {//---------------------------------------> add this 
					continue
				}
				// if we have no names, we are embed, so add to embeds and remove from fields
				if len(field.Names) == 0 {
					emblist.List = append(emblist.List, field)
					st.Fields.List = slices.Delete(st.Fields.List, i+delOff, i+1+delOff) // we need to add delOff to correctly handle situations where we delete multiple times and our indices become inaccurate
					delOff--                                                             // we have deleted so we need to update offset
				}
			}

[kkoreilly]

I can not reproduce this issue; are you doing anything other than just running go test in gtigen?

[kkoreilly]

The reason that the test is failing is that you are running it outside of the normal location of the code, which means that it can not load the correct files for the test, and thus it panics. I do not know why GoLand decides to put everything in bizarre temporary locations, as that is the cause of both this issue and the Vulkan panic. This will work if you run the test in the normal way by just running go test in gtigen, so this is not an issue. We will not support running tests in the wrong location, and the test works perfectly with both the standard command line workflow and VS Code. You can probably configure GoLand to place executables and tests in the current directory. Adding a pointless nil check does not fix this problem; you are conflating not panicking and working: just because something doesn't panic doesn't mean that it works. Most of the nil panic issues are caused by other problems, and adding a simple nil check almost never fixes the actual problem.

[ddkwork]

Ok

[ddkwork]

[ddkwork]

I have a different take on this issue.

[ddkwork]

			for i := 0; i < len(st.Fields.List); i++ {
				field := st.Fields.List[i]
				// if we have no names, we are embed, so add to embeds and remove from fields
				if len(field.Names) == 0 {
					emblist.List = append(emblist.List, field)
					st.Fields.List = slices.Delete(st.Fields.List, i+delOff, i+1+delOff) // we need to add delOff to correctly handle situations where we delete multiple times and our indices become inaccurate
					i++
					delOff-- // we have deleted so we need to update offset
				}
			}

[ddkwork]

As for vulkan, as long as you've successfully mocked the various events inside the unit tests, I'll patiently debug it and see if I can find the cause of the actual panic. But between the invisibility of cgo code to debugging, I'm not sure, unless there's an alternative way to intercept the cgo execution flow

[kkoreilly]

Please tell me whether the gtigen test still panics when you run it in Git Bash with go test.

[ddkwork]

I have tried, external run cmd, go test is also panic, another code inside the logic and execution process I have verified! 2762713521 ***@***.***  

…

------------------ 原始邮件 ------------------ 发件人: "cogentcore/core" ***@***.***>; 发送时间: 2024年3月6日(星期三) 晚上11:45 ***@***.***>; ***@***.******@***.***>; 主题: Re: [cogentcore/core] gtigen panic (Issue #926) Please tell me whether the gtigen test still panics when you run it in Git Bash with go test. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[kkoreilly]

Please send me a screenshot of you running go test in gtigen.

[ddkwork]

[kkoreilly]

It is really weird that it panics on your computer but not mine. I will work on debugging this now.

[ddkwork]

You write the code you should be very clear about the logic of its implementation, slice 5 members, deleted a, the remaining 4, range to the fourth time, 4 is index, starting from 0, in fact, he is 5, but has been deleted, so the empty pointer panic

[ddkwork]

			for i := 0; i < len(st.Fields.List); i++ {
				field := st.Fields.List[i]
				// if we have no names, we are embed, so add to embeds and remove from fields
				if len(field.Names) == 0 {
					emblist.List = append(emblist.List, field)
					st.Fields.List = slices.Delete(st.Fields.List, i+delOff, i+1+delOff) // we need to add delOff to correctly handle situations where we delete multiple times and our indices become inaccurate
					i++
					delOff-- // we have deleted so we need to update offset
				}
			}

This fix perfectly matches the execution logic of your code

[kkoreilly]

Sorry, I misunderstood the situation, and I will apply that fix now.

[ddkwork]

I would like to ask you a question, I'm trying to understand the execution of core by debugging, but I have not been able to find the place where the reflected structure is. For example:

func TestStructView(t *testing.T) {
	b := gi.NewBody()
	NewStructView(b).SetStruct(myStructValue)
	b.AssertRender(t, "structview/basic")
}

As I understand it, SetStruct is supposed to perform reflection, i.e.: reflect the struct to the ki n-forked tree structure, then various traversals to add events, styles, etc. to send to vulkan, and finally vulkan hands it off to glfw to interact with the graphics card hardware. But I didn't find any code related to the reflection structure.

[kkoreilly]

You are asking how the entire architecture of Cogent Core is structured, which is a hard question to easily answer. I will write architecture documentation that explains all of that soon, but until then, here is a simple answer: SetStruct results in StructView.ConfigWidget happening, in which the reflect.Value of the struct is used to construct a widget structure with labels and values for the fields of the struct. The struct view and the widgets add events and styles functions to the widgets, which are then called in later event loop and style application passes. All of the content is later rendered to an image on the Scene, which is then pushed to the screen with Vulkan.

[kkoreilly]

Can you try my new fix for this issue?

[ddkwork]

Sorry I just fell asleep for a while and it's 2:30 a.m. Thank you for the explanation of the reflection part. Also, I'm a little curious if you won't panic on your computer before this fix? Didn't you test? What's even stranger is that I didn't panic on my computer after running the core command for so long, perhaps for only one reason: except for this unit test scenario, all the core commands executed did not trigger names==0 to delete the slice member. It's just that when I execute the unit test, it crashes. In addition to this, the core command also has a warning under the giv package and exits, indicating that the field name is the same, which I guess is roughly the stake: the two fields of the struct have the same name. It should mean something similar.

[ddkwork]

It should be fine, wait a minute I'll test it. By the way, it feels like you're too busy to write code all day long

…

---Original--- From: ***@***.***> Date: Thu, Mar 7, 2024 02:13 AM To: ***@***.***>; Cc: ***@***.******@***.***>; Subject: Re: [cogentcore/core] gtigen panic (Issue #926) Can you try my new fix for this issue? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[ddkwork]

So where did the drawing take place? Set up the struct, reflect, send the event, set the style, and then goosi receives the event and gets it to vulkan. I haven't seen where to execute the drawing operation after looking at the code related to this process for a long time, such as drawing the rectangle of the button, setting the foreground color after the mouse gets focus, etc., and I haven't found where the button widget is drawn after looking at it for a long time

…

---Original--- From: ***@***.***> Date: Thu, Mar 7, 2024 01:51 AM To: ***@***.***>; Cc: ***@***.******@***.***>; Subject: Re: [cogentcore/core] gtigen panic (Issue #926) You are asking how the entire architecture of Cogent Core is structured, which is a hard question to easily answer. I will write architecture documentation that explains all of that soon, but until then, here is a simple answer: SetStruct results in StructView.ConfigWidget happening, in which the reflect.Value of the struct is used to construct a widget structure with labels and values for the fields of the struct. The struct view and the widgets add events and styles functions to the widgets, which are then called in later event loop and style application passes. All of the content is later rendered to an image on the Scene, which is then pushed to the screen with Vulkan. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[ddkwork]

Hello, I'm going to write an interface for ollama, but I don't know how to insert text into the text editing widget continuously without clearing the previous insertion, because the AI chat scene is the uninterrupted output of text, if the one-time output feels like the chat delay on a low-configuration device, so we need to support the stream feature, one input, streaming output. Is there a way to do this in the text editing widget?

ollama/ollama#2842

[kkoreilly]

The response from the AI should not be in a text editor; it should be in a Label. You can just call Label.SetTextUpdate with the newly streamed text whenever you want to.

[ddkwork]

Thanks, it's finally dawn and it's time to do code again

…

---Original--- From: ***@***.***> Date: Thu, Mar 7, 2024 08:08 AM To: ***@***.***>; Cc: ***@***.******@***.***>; Subject: Re: [cogentcore/core] gtigen panic (Issue #926) The response from the AI should not be in a text editor; it should be in a Label. You can just call Label.SetTextUpdate with the newly streamed text whenever you want to. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>