Sheet Metal workbench causes "__dict__ must be set to a dictionary" when loading

Post here for help on using FreeCAD's graphical user interface (GUI).
Forum rules
and Helpful information
IMPORTANT: Please click here and read this first, before asking for help

Also, be nice to others! Read the FreeCAD code of conduct!
Frotz
Posts: 105
Joined: Thu Jun 21, 2018 1:52 am

Sheet Metal workbench causes "__dict__ must be set to a dictionary" when loading

Post by Frotz »

Partially in reference to viewtopic.php?p=668506, I've found a cause of my trouble with errors like the following when loading a .FCStd file:

Code: Select all

<string>(1)<class 'TypeError'>: __dict__ must be set to a dictionary, not a 'NoneType'
I've nailed down a concrete and easy-to-demonstrate cause: Create a body within a part and make that body active. Then make a sketch within the body. Draw something that doesn't form a closed figure, ie a wavy line, then close it. Select the sketch and in the Sheet Metal workbench, click the "Make Base Wall" to make a wavy sheet. Save it. Close that file. Load it. This will provoke a single instance of the error I pasted above.

Attached is something that will provoke this error.

I've identified some other ways to provoke the error, but have yet to come up with a simple demonstration. These focus on making something with the Part workbench, cloning the thing, then putting the original and clones into a union.

Code: Select all

OS: Debian GNU/Linux bookworm/sid (MATE/mate)
Word size of FreeCAD: 64-bit
Version: 0.21.0.32391 (Git)
Build type: Unknown
Branch: master
Hash: a2fec5192343f862ff07702ed1cdf508a4612d0f
Python 3.11.2, Qt 5.15.8, Coin 4.0.0, Vtk 9.1.0, OCC 7.6.3
Locale: English/United States (en_US)
Installed mods: 
  * Pyramids-and-Polyhedrons
  * sheetmetal 0.2.61
  * freecad.gears 1.0.0
  * A2plus 0.4.60k
  * fasteners 0.4.55
  * Manipulator 1.5.0
Attachments
metal-test.FCStd
(25.37 KiB) Downloaded 15 times
Syres
Veteran
Posts: 2893
Joined: Thu Aug 09, 2018 11:14 am

Re: Sheet Metal workbench causes "__dict__ must be set to a dictionary" when loading

Post by Syres »

Frotz wrote: Mon Mar 20, 2023 6:47 am Partially in reference to viewtopic.php?p=668506, I've found a cause of my trouble with errors like the following when loading a .FCStd file:

Code: Select all

<string>(1)<class 'TypeError'>: __dict__ must be set to a dictionary, not a 'NoneType'
To stop the error appearing all you need to do is enter something in the Part>Id property value, in my case 12345:

Part_ID_Field.png
Part_ID_Field.png (29.1 KiB) Viewed 841 times

I'm sure the error handling can be improved to give the user a clue as to the origin of the error and a possible solution. I'll throw some time at it over the next couple of days and if I'm struggling I'll raise an Issue on Github.
Syres
Veteran
Posts: 2893
Joined: Thu Aug 09, 2018 11:14 am

Re: Sheet Metal workbench causes "__dict__ must be set to a dictionary" when loading

Post by Syres »

This took some tracking down but the new Log message rather than Error is:

Code: Select all

PropertyPythonObject::fromString(): repr is null for object <class 'SheetMetalBaseCmd.SMBaseBend'>
which would only be used by the developers if something actually did not work so a new user would not see it as Log messages are not enabled by default.

@openBrain do you think this https://github.com/FreeCAD/FreeCAD/comp ... D:patch-71 is acceptable?
openBrain
Veteran
Posts: 9034
Joined: Fri Nov 09, 2018 5:38 pm
Contact:

Re: Sheet Metal workbench causes "__dict__ must be set to a dictionary" when loading

Post by openBrain »

Syres wrote: Mon Mar 20, 2023 12:02 pm @openBrain do you think this https://github.com/FreeCAD/FreeCAD/comp ... D:patch-71 is acceptable?
From my point of view it's not ideal. :)
I would have kept this part of the code as is, and place this block

Code: Select all

            if (repr == "null") {
                Py::String typestr(this->object.type().str());
                Base::Console().Log("PropertyPythonObject::fromString(): repr is null for object %s\n", typestr.as_string().c_str());
                return;
            }
a bit above in the function, just after :

Code: Select all

        if (repr.empty())
            return;
So it's clearer that we handle a special case, and we don't proceed to further computation in this case.

Then other cases where 'res == None' may appear, but we will have the opportunity to get a report and analyze it. ;)
Syres
Veteran
Posts: 2893
Joined: Thu Aug 09, 2018 11:14 am

Re: Sheet Metal workbench causes "__dict__ must be set to a dictionary" when loading

Post by Syres »

@openBrain OK thanks, that's what I did initially but then changed my mind!!
Frotz
Posts: 105
Joined: Thu Jun 21, 2018 1:52 am

Re: Sheet Metal workbench causes "__dict__ must be set to a dictionary" when loading

Post by Frotz »

Syres wrote: Mon Mar 20, 2023 10:24 am
Frotz wrote: Mon Mar 20, 2023 6:47 am Partially in reference to viewtopic.php?p=668506, I've found a cause of my trouble with errors like the following when loading a .FCStd file:

Code: Select all

<string>(1)<class 'TypeError'>: __dict__ must be set to a dictionary, not a 'NoneType'
To stop the error appearing all you need to do is enter something in the Part>Id property value, in my case 12345:


Part_ID_Field.png


I'm sure the error handling can be improved to give the user a clue as to the origin of the error and a possible solution. I'll throw some time at it over the next couple of days and if I'm struggling I'll raise an Issue on Github.
What's the hash for the build of FreeCAD you're using? I tried that and the error message still appears.
Syres
Veteran
Posts: 2893
Joined: Thu Aug 09, 2018 11:14 am

Re: Sheet Metal workbench causes "__dict__ must be set to a dictionary" when loading

Post by Syres »

Frotz wrote: Mon Mar 20, 2023 8:42 pm What's the hash for the build of FreeCAD you're using? I tried that and the error message still appears.

Code: Select all

OS: Linux Mint 20.3 (X-Cinnamon/cinnamon)
Word size of FreeCAD: 64-bit
Version: 0.21.0.32394 (Git)
Build type: Release
Branch: master
Hash: 431fafc5337976c43bf50aae7bc75b46ee8037c7
Python 3.8.10, Qt 5.12.8, Coin 4.0.0, Vtk 7.1.1, OCC 7.7.0
Locale: English/United Kingdom (en_GB)
Installed mods: 
  * Silk 1.0.0
  * CurvedShapes 1.0.4
  * freecad.gears 1.0.0
  * Curves 0.6.8
  * PieMenu 1.2.4
  * Plot 2022.4.17
  * AirPlaneDesign 0.4.0
  * fasteners 0.4.54
  * sheetmetal 0.2.59
As a side note, I see your Build Type is Unknown, it's best practice to have the Cmake switch when self compiling to

Code: Select all

-DCMAKE_BUILD_TYPE=Release
especially with regard to some libraries' performance or

Code: Select all

-DCMAKE_BUILD_TYPE=Debug
if you're debugging. https://wiki.freecad.org/Compile_on_Linux#Configuration


Hopefully the proper error handling PR will get merged later this week and all this will no longer be relevant.
Syres
Veteran
Posts: 2893
Joined: Thu Aug 09, 2018 11:14 am

Re: Sheet Metal workbench causes "__dict__ must be set to a dictionary" when loading

Post by Syres »

Syres
Veteran
Posts: 2893
Joined: Thu Aug 09, 2018 11:14 am

Re: Sheet Metal workbench causes "__dict__ must be set to a dictionary" when loading

Post by Syres »

openBrain wrote: Mon Mar 20, 2023 1:36 pm a bit above in the function, just after :

Code: Select all

        if (repr.empty())
            return;
So it's clearer that we handle a special case, and we don't proceed to further computation in this case.

Then other cases where 'res == None' may appear, but we will have the opportunity to get a report and analyze it. ;)
I'm going to confirm once my compiling finishes but looks like this has caused a major regression in Path Wb, see viewtopic.php?t=77032

Just before the actual errors freman reported, this is shown:

Code: Select all

14:41:56  PropertyPythonObject::fromString(): repr is null for object <class 'Path.Main.Gui.Job.ViewProvider'>
14:41:56  PropertyPythonObject::fromString(): repr is null for object <class 'Path.Base.Gui.SetupSheet.ViewProvider'>
14:41:56  PropertyPythonObject::fromString(): repr is null for object <class 'Path.Tool.Gui.Bit.ViewProvider'>
Which makes me think those three viewprovider objects would normally carry on through the code rather than now returning 'early'.
Post Reply