Found one issue with RC4 (8.5SP1 x86):
from pymel import *
dup = PyNode('my_skinned_mesh')
attrs = dup.listAttr(locked=True)
for attr in attrs:
attr.setLocked(False)
results in:
# Error: argument number 1: Unmatched paren in format
# Traceback (most recent call last):
# File "<maya console>", line 3, in ?
# File "<string>", line 2, in setLocked
# File "C:/Documents and Settings/ijones/My Documents/maya/8.5/
scripts/pymel\core\factories.py", line 2615, in wrappedApiFunc
# File "C:\engserv\rbuild\164\build\wrk\optim\runTime\Python\Lib
\site-packages\maya\OpenMaya.py", line 7921, in setLocked
# SystemError: argument number 1: Unmatched paren in format #
and since you asked:
The new treatment of non-existent objects took me a bit of time to get
used to/port my code. No big deal, and I don't mind the new behavior
at all - it makes sense to me. The bigger problem is that I have to
have all the tools ported and somewhat tested before I can release the
new version of pymel/tools to the studio. I would have much rather had
the feature be depreciated for one release to allow me more time to
transition smoothly. Luckily we have a nice break now to do it
otherwise I would probably would have waited till summer to do so.
Ian
On Feb 23, 4:00 pm, chadrik <[email protected]> wrote:
> Just dropped RC4 which should fix this problem.
>
> Does anyone have any feedback regarding the treatment of non-existent
> objects in the newPyMEL? love it, hate it? check out the docs under
> non-backward compatible changes.
>
> -chad
>
>
>
> > Everytime I importpymelin Maya 8.5sp1, I have the following msg:
>
> > -----------------------
> > # Traceback (most recent call last):
> > # File "/opt/lib/python2.4/logging/__init__.py", line 740, in emit
> > # File "/opt/lib/python2.4/logging/__init__.py", line 718, in flush
> > # AttributeError: 'maya.Output' object has no attribute 'flush'
> > # Warning: The callback " has already been added. #
> > // Warning: The callback " has already been added. //
> > ----------------------------------
>
> > Don't know how to trace this. Any idea?
>
> > - Drake
>
> > On Feb 20, 9:56 am, Drake <[email protected]> wrote:
> >> On Feb 19, 12:34 am, Chad Dombrova <[email protected]> wrote:
>
> >>> sure thing. and if you ever feel the desire to really get your hands
> >>> dirty we can always use the help.
>
> >>> -chad
>
> >> I would like to do some contribution if possible :)
>
> >> - Drake
>
> >>>> Drake
>
> >>>> On Feb 18, 10:56 am, chadrik <[email protected]> wrote:
> >>>>> there's a thread on this forum about it, but it's like this: when
> >>>>> you
> >>>>> use an MMessage to create a callback in the api, swig -- the c++
> >>>>> to
> >>>>> python wrapping mechanism -- thinks there is a memory leak.
> >>>>> disown
> >>>>> tells swig to ignore the swig object and stop trying to detect
> >>>>> leaks.
> >>>>> at least as far as i understand it. there's not actually a
> >>>>> memory
> >>>>> leak, but the warning will be very ominous to users, especially
> >>>>> if it
> >>>>> shows up every time you execute a mel script via python. so we'll
> >>>>> just have to keep this new feature for 2008+
>
> >>>>> -chad
>
> >>>>> On Feb 17, 2009, at 5:11 PM, Drake wrote:
>
> >>>>>> I was wondering what kind of class the "id" is and did a quick
> >>>>>> test by
> >>>>>> following:
>
> >>>>>> ---------------------------
> >>>>>> id = api.MCommandMessage.addCommandOutputCallback
> >>>>>> ( errorCallback, None )
> >>>>>> print type(id)
> >>>>>> print dir(id)
> >>>>>> return
> >>>>>> ---------------------
>
> >>>>>> and I got this:
>
> >>>>>> <type 'PySwigObject'>
> >>>>>> []
> >>>>>> -------------------------
>
> >>>>>> It seems the returned object by "addCommandOutputCallback()" is
> >>>>>> different between 8.5 and 2008~. I am just guessing. BTW, what
> >>>>>> does
> >>>>>> id.disown() do exactly?
>
> >>>>>> - Drake
>
> >>>>>> On Feb 18, 12:10 am, Chad Dombrova <[email protected]> wrote:
> >>>>>>> looks like we have a decision to make: either 8.5 users can
> >>>>>>> deal
> >>>>>>> with
> >>>>>>> annoying but harmless "Callback Memory Leak" warnings or they
> >>>>>>> don't
> >>>>>>> get informative MEL errors with line numbers, etc. the
> >>>>>>> problem is
> >>>>>>> that most users don't realize that these memory leak warnings
> >>>>>>> are, in
> >>>>>>> fact, harmless, so i think i'm going to have to leave the
> >>>>>>> feature
> >>>>>>> out
> >>>>>>> on 8.5...
>
> >>>>>>> thanks for the bug report.
>
> >>>>>>> -chad
>
> >>>>>>> On Feb 17, 2009, at 2:54 AM, Drake wrote:
>
> >>>>>>>> Maya 8.5 SP1 x64
> >>>>>>>> ----------
> >>>>>>>> frompymelimport *
> >>>>>>>>pymel: DEBUG : setting logLevel to default:
> >>>>>>>> # Traceback (most recent call last):
> >>>>>>>> # File "/opt/lib/python2.4/logging/__init__.py", line 740, in
> >>>>>>>> emit
> >>>>>>>> # File "/opt/lib/python2.4/logging/__init__.py", line 718, in
> >>>>>>>> flush
> >>>>>>>> # AttributeError: 'maya.Output' object has no attribute 'flush'
> >>>>>>>> # Error: 'PySwigObject' object has no attribute 'disown'
> >>>>>>>> # Traceback (most recent call last):
> >>>>>>>> # File "<maya console>", line 1, in ?
> >>>>>>>> # File "/tmp/python/pymel/__init__.py", line 1477, in ?
> >>>>>>>> # _installCallbacks()
> >>>>>>>> # File "/tmp/python/pymel/__init__.py", line 1459, in
> >>>>>>>> _installCallbacks
> >>>>>>>> # mel.unloadPlugin( addCallback='''python("importpymel;
> >>>>>>>>pymel._pluginUnloaded('#1')")''' )
> >>>>>>>> # File "/tmp/python/pymel/core/language.py", line 426, in
> >>>>>>>> _call
> >>>>>>>> # return self.eval(cmd)
> >>>>>>>> # File "/tmp/python/pymel/core/language.py", line 528, in
> >>>>>>>> eval
> >>>>>>>> # id.disown()
> >>>>>>>> # AttributeError: 'PySwigObject' object has no attribute
> >>>>>>>> 'disown' #
>
> >>>>>>>> Drake
>
> >>>>>>>> On Feb 14, 5:37 am, chadrik <[email protected]> wrote:
> >>>>>>>>> there was a bug with RC2 related to the pluginLoaded
> >>>>>>>>> callbacks.
> >>>>>>>>> it's
> >>>>>>>>> tough to get these working properly because:
>
> >>>>>>>>> 1 ) loadPlugin causes errors when using python
> >>>>>>>>> callbacks
> >>>>>>>>> 2) unloadPlugin does not even support python callbacks
> >>>>>>>>> 3) unloadPlugin mel command is not passing the
> >>>>>>>>> pluginName
> >>>>>>>>> to the
> >>>>>>>>> function (even when using #1 syntax)
> >>>>>>>>> 4 ) api callbacks for plugin load/unload are not
> >>>>>>>>> supported
> >>>>>>>>> until maya
> >>>>>>>>> 2009
>
> >>>>>>>>> needless to say this is pretty botched on autodesk's end.
>
> >>>>>>>>> but it's working well enough now with RC3.
>
> >>>>>>>>> -chad
>
> >>>>>>>>> On Feb 12, 2009, at 11:00 PM, Chadrik wrote:
>
> >>>>>>>>>> hi all, i posted RC2 tonight adding 8.5 support, as well as
> >>>>>>>>>> fixing
> >>>>>>>>>> Mike's bug and a few others.
>
> >>>>>>>>>> download it here:http://code.google.com/p/pymel/downloads/
> >>>>>>>>>> list
>
> >>>>>>>>>> -chad
>
>
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/python_inside_maya
-~----------~----~----~----~------~----~------~--~---
