I would be happy to give an example of how to transfer the coordinates of a real object, rather than enter them manually.
https://docs.blender.org/api/blender2.8/gpu.html#wireframe-cube-using-index-buffer

Thank you for providing an fix for that issue.

I have updated my Blender to yesterday's version and am unfortunately still having the same crashes.
I also updated my sample code in the first post, seems I deleted too much code when I was simplifying it. I am very sorry for that.
It should work (or rather crash) as intended now. I even added a small panel for convenience's sake.

I cannot reproduce this in the current build. Please check if the issue still exists.
If yes, then please start Blender from the terminal and post the output here.

Ok. Thanks for Your help, and sorry for posting it here.

thanx @Bastien Montagne (mont29) for clearing that up! (sorry for my uneducated fiddeling here...)

Thanks again!

First of all, this is not a bug report at all, and should not be handled here. We have a site for that kind of question: https://devtalk.blender.org/

I can only repeat myself: I am on shaky ground here, if the above file doesnt work for you, I am probably out of ideas...

Sorry, Your blend file was not empty, my mistake. But the error still occurs.

Not sure if this is the recommended way, but picking a region type for your spacetype that doesnt draw panels automatically seems fine, I guess...
So for space TEXT_EDITOR, you could use bl_region_type = 'HEADER', bl_region_type = 'WINDOW'?

This .blend file You attached is (as far as I know) default init blend file, so I can't check what You have changed. Please attach the changed .py file.
I followed Your directions:

• I removed enumerate (It was there for testing purposes anyway), but this did not solve the problem.
• I assume that Your step 2 was passing 'deepcopy(branch['sub_items'])' instead of ''branch['sub_items'] into the recursive function. It did not solve the problem for me (did it for You?). Please remember that (like I wrote in the comments of my py file) calling operator again does not replicate the error: "I have to restart blender to repeat the error". And after that changes error is still there. Also, the problem from Your link is little different from mine, because my problem is with 'current_item' variable (not with ''branch['sub_items']"). I am not passing 'current_item' to the recursive call, and as far as I know my current_tems variables from every scope point to a different object, coz I create it in the scope, not passing it as a parameter.

Regards.

Thanks! layout.popover() seems like exactly what I need.

Can confirm the crash (when accessing/printing the current_item after the recursive call)

?

Oki, closing then

I think this is just a limitation of the menu system. For more custom layouts, use a popover.

Menus are a bit limited in regards to layout.
I dont have an exact list of these limitations (I just remeber I had an issue in D4215 as well).

I think this isn't worth worrying about, we could use from __future__ import print_function all over for our utilities, but in practice we never had people adding back old style print statements.

The future import makes legacy print statements syntax errors even in Python 2 which prevents Python 2 developers from making changes which break Python 3 compatibility.

Committed rB7262ac6202eb9258293473f35a24f375f9d6f635, no need for __future__

That was probably a bit too quick on my side, need to look at that again (on Monday)...

I regret to write: it is not it :(.
I changed init to sub_init and I steel get TypeError: unsubscriptable object.

I couldn't check that the bake result is correct. Yesterday's daily build crashes upon clicking the image dropdown menu in Image editor or UV editor. That's an unrelated issue, and I'll wait a day or two before reporting it.

Cool, it seems to be fixed in current daily builds. I close my bug report as resolved.

RNA_def_property: runtime property identifier "TreeItems.items" - this keyword is reserved by python

@Campbell Barton (campbellbarton) Thank you :), just downloaded the latest 2.80 beta directly from blender.org and so far, all working well. Thanks again. Can't overstate how grateful we are.... and relieved too. :)

Committed basic undo system support in background mode: rB3d16a268ee688da25f72a1adb08fdaab454c344d

Is this still an issue if you use the latest intel drivers?

I'm getting the following assert when changing the properties:
BLI_assert failed: blender/source/blender/depsgraph/intern/depsgraph_query.cc:145, DEG_get_evaluated_scene(), at 'scene_cow != __null && DEG::deg_copy_on_write_is_expanded(&scene_cow->id)'

I also take copies of objects. I then, among other things:

@Jeducious (jameshcrowther), updated P563 although this should be documented.

I maintain an exporter add-on which messes extensively with the scene during export, then uses undo to clean everything up. Now that undo is unavailable in background mode junk objects are leaking out everywhere. I don't think that many users of my addon are running it in background mode...but *I* am for my unit tests, and those directly affect the quality of the addon.

In T60934#614228, @Campbell Barton (campbellbarton) wrote:

Hi @Bastian Neumann (bneu), this is mostly a question of priorities since there are enough high priority undo bugs open which need attention, see: T61045

2.79b also didn't properly initialize undo, eg: wm_files.c

	if (!G.background) {
		BKE_undo_reset();
		BKE_undo_write(C, "original");  /* save current state */
	}

While it didn't crash, it wasn't fully working either.

This is something to look into, if we should have basic memfile undo support in background mode, or add the ability to fully initialize undo.

Some context for how you're using this feature in 2.79 would be helpful.

---

I commented about this on the thread that explained how to use it, but no one ever replied to my comment that it wasn't working.

Could you link to this post?

@Jeducious (jameshcrowther), can you briefly explain what you need undo in background mode for? For memory usage on render nodes being able to save memory is quite important, and now might be a good time to make such a breaking change. However there may be solutions to handle both cases.

Note that there is a replacement for scene_update_post in the form of depsgraph_update_post and the new timer API.