@Mike - It sounds like the issue was that you might have only been reloading the main script, as opposed to "deep reloading". First all of the dependencies have to be reloaded, and then the dependants have to be reloaded. Also I think it also makes a difference how you are importing things. It might require that you are importing the module, as opposed to doing a "from" import to bring in the class. Because once you have the class reference, I don't think reloading will work.
@Marcus First off I will say that I agree with the mess that can come from trying to reload() tools in a production situation, as opposed to doing it for debugging purposes. My view on the matter is that leaking memory is leaking memory. Will it every become a problem in a long-running Maya session? Well that depends on what kind of Qt applications/tools are being written. I doubt you would see an impact in any reasonable amount of time if you were leaking a simple dialog that has some buttons that do calls to Maya and whatnot. But that is one particular application. If an application consumes noticeable resources as part of its function, then leaking those could have a big impact on how long you can run that Maya session, rerunning that tool, before you encounter issues and have to restart it. So my opinion is that it should be considered an impacting situation. If you can figure out ways to avoid leaking, even with the small harmless stuff, you would end up thinking the same way when you are doing something that will have an impact. The parent-child relationship in Qt means that if you loose a reference to some parent QObject/QWidget, without deleting it, then none of the child objects will get cleaned up either. It is not just the top level object that you lose. Pythons garbage collection might clean up the python objects, but Qt isn't doing anything to clean up yet. I threw together a super-duper contrived example of how this could potentially be a problem. Lets say you have some app that loads in and displays tons of images for review (or video if you prefer). You may have a ton of QLabel objects that have a pixmap set on each one, or basically any possible situation where you are loading up data into QWidgets/QObjects. Then you show it as a dialog to your user. They use it for a bit, and then close it, but the dialog doesn't get deleted. So that dialog still continues to live, along with all of the QLabel's with the QPixmap that each one owns: https://gist.github.com/justinfx/811902fc2aadce31f631 This particular example is just a mock up to make it easier to show. It creates a temporary 10MB file to pretend it is an image, and then reads it 10 times into a buffer (or QPixmap being then set into a QLabel). If you run that dialog and click the button, you should notice your RSS increase by about 100MB each time. Not only is the memory increasing, but it is leaking file descriptors as well ( lsof -p <pid> | wc -l ). When you close the dialog, the resources are not freed. And then you can rerun that dialog and do it some more. At some point you would either run out of memory, or have too many open file descriptors, and have to restart Maya. My point is that I think it should be considered a potential issue, since anyone is capable of writing anything and we all have to use the tools within the same environment. Everyone is at the mercy of everyone else :-/ -- justin On Fri, Jul 18, 2014 at 5:59 AM, Marcus Ottosson <[email protected]> wrote: > Yes, but this isn't unique to Maya. It's similar to having a Python > interpreter running, importing your module and then expecting the > interpreter to know it's been updated. Modules affect global state and can > have a great effect on the behavior of interpreter. Since the interpreter > in Maya is running for as long as Maya is, the only safe option (besides > keeping track of changes and flushing by hand) is to reload Maya. This is > different in Softimage where the interpreter is running as a separate > process to Softimage (at least that's my impression) and is thus restarted > at each execution of scripts. > > The overall workflow for me, and others I think, is to develop separately, > and test in mayapy if you can. Testing in Maya can be a last resort and > shouldn't need as many iterations as can be tested externally. > > I do wish though that Maya did what Softimage does. I really don't see the > benefit of doing it this way, the interpreter should really be a separate > process. > > Off the top of my head though, you might have better luck running your > scripts through subprocess if you really do need more iterations within > Maya. It might act similar to Softimage, but I haven't tested much and > can't say for certain. For one, you'd be dealing with threading issues as > you can't (or shouldn't) call upon maya.cmds from threads other than the > main one. It's something you can work around, but it wouldn't be as > transparent as with Softimage. > > > On 17 July 2014 17:58, Mike Donovan <[email protected]> wrote: > >> the thing I have noticed is that when I updated my UIs and covert them to >> .py modules for import ... I ALWAYS >> need to restart Maya. Even if I have closed all my QT_Dialogs/Widgets >> >> >> >> Sent from my iPhone >> >> On Jul 17, 2014, at 7:51 AM, Marcus Ottosson <[email protected]> >> wrote: >> >> Have you guys tested memory usage on widgets sticking around after >> getting closed? I can't imagine it ever becoming a problem, even in >> long-running sessions of Maya (e.g a whole day). The only issue I've had >> with the persistence of variables in Maya is in debugging and making sure >> you're actually using the latest of your modules as most of them would have >> been reused rather than reloaded; and even if you reload all of them, >> you'll have to do it in the order they are implicitly loaded which isn't >> always possible if you're having cyclical imports. >> >> So, in general, I'd say there isn't any recommended way to clear Qt >> classes or any classes for that matter from Maya's Python, or Python >> overall. The recommended approach for Python in general is to either >> restart the interpreter, which in the case of Maya is to restart Maya, or >> to handle each deletion yourself, which again, I think is of infinitesimal >> importance. >> >> >> On 15 July 2014 21:52, md <[email protected]> wrote: >> >>> Thanks Justin ... >>> >>> Prior to reading this , I thought it was something like this ... I have >>> the following in my Class __init__ >>> >>> self.setAttribute(QtCore.Qt.WA_DeleteOnClose) >>> >>> >>> >>> On Tuesday, July 15, 2014 4:00:15 PM UTC-4, Justin Israel wrote: >>> >>>> There isn't any formal kind of global "flush" for Qt. If you are >>>> leaking memory then you would need to fix that. Since Maya is a persistent >>>> environment for all of the tools you run, tools have to take care to clean >>>> themselves up. >>>> With Qt, even more so. Because if you create widgets with parent to >>>> the main window, they don't get deleted unless you do it. An example is a >>>> dialog window. When you make a dialog and parent it to Maya's main window, >>>> and then close the dialog, you are most likely leaking it if you are just >>>> creating a new one from scratch each time. >>>> >>>> For any widget you have widget.deleteLater() which will delete it once >>>> control gets back to the event loop. >>>> >>>> If you are not keeping a global ref to your dialog to reshow each time, >>>> and your dialog is being parented to Maya, then you can use >>>> QtCore.Qt.WA_DeleteOnClose and set it with dialog.setAttribute() >>>> This will tell the dialog to delete when you close it. All widgets in >>>> the parent child chain will delete. >>>> http://qt-project.org/doc/qt-4.8/qt.html#WidgetAttribute-enum >>>> >>>> This may not be exactly the problem you are having so you might need to >>>> explain the unwanted behavior a bit more >>>> On 16/07/2014 4:22 AM, "md" <[email protected]> wrote: >>>> >>>>> Is there a way to flushing all prior QT instances from memory when >>>>> developing PySide/Qt scripts for Maya? >>>>> >>>>> I am constantly exiting Maya and reloading it when my forms don't seem >>>>> to refresh properly. >>>>> >>>>> Thanks >>>>> >>>>> M >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Python Programming for Autodesk Maya" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To view this discussion on the web visit https://groups.google.com/d/ >>>>> msgid/python_inside_maya/ff0065a9-e32e-4cac-b163- >>>>> d9103c9a1f0f%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/python_inside_maya/ff0065a9-e32e-4cac-b163-d9103c9a1f0f%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Python Programming for Autodesk Maya" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/python_inside_maya/9e20ea8d-4852-489f-a050-84c684f48654%40googlegroups.com >>> <https://groups.google.com/d/msgid/python_inside_maya/9e20ea8d-4852-489f-a050-84c684f48654%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> *Marcus Ottosson* >> [email protected] >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Python Programming for Autodesk Maya" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/python_inside_maya/sNqxa2yDt5s/unsubscribe >> . >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOD1L7yH2E12zioO2iax0pU_MK9eecTBvVRA%2BCMBWJBezw%40mail.gmail.com >> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOD1L7yH2E12zioO2iax0pU_MK9eecTBvVRA%2BCMBWJBezw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Python Programming for Autodesk Maya" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/315E4F7F-F0DD-4130-B336-5DC3C35E7B1C%40mdonovan.com >> <https://groups.google.com/d/msgid/python_inside_maya/315E4F7F-F0DD-4130-B336-5DC3C35E7B1C%40mdonovan.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > *Marcus Ottosson* > [email protected] > > -- > You received this message because you are subscribed to the Google Groups > "Python Programming for Autodesk Maya" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOCtBngEbSTsxdFL9cto74hYq7BCTv9n1d73r7eW3eoGtA%40mail.gmail.com > <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOCtBngEbSTsxdFL9cto74hYq7BCTv9n1d73r7eW3eoGtA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA2VMHqdz1Z4y3QOTRHsbzitBBW7ipUaTTcUB6nr0wqa_w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
