librelist archives

« back to archive

Cannot create a consistent method resolution order (MRO) for bases Exception, JoblibException

Cannot create a consistent method resolution order (MRO) for bases Exception, JoblibException

From:
Gustavo Goretkin
Date:
2011-08-01 @ 21:10
Hey All,

I'm having a hard time finding out what this exception means:

TypeError: Cannot create a consistent method resolution order (MRO) for
bases Exception, JoblibException

I've appended the full stacktrace below.  Note that the stacktrace only
happens after the jobs have finished executing.

Thanks,
Gustavo

...
[Parallel(n_jobs=-1)]: Done  17 out of  18  |elapsed:   20.9s remaining:
1.2s
[Parallel(n_jobs=-1)]: Done  18 out of  18  |elapsed:   22.2s remaining:
0.0s
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)

/afs/athena.mit.edu/user/g/o/goretkin/py/lis/learn_model.py in <module>()
     96     return r
     97
---> 98 r = Parallel(n_jobs=-1, verbose=1)(delayed(jobfit)(train_size) for
train_size in train_sizes*repetition)
     99 train_errors = r
    100

/afs/

athena.mit.edu/user/g/o/goretkin/py/lis_env/lib/python2.6/site-packages/joblib-0.5.3.dev-py2.6.egg/joblib/parallel.pycin
__call__(self, iterable)
    420                 self.dispatch(function, args, kwargs)
    421
--> 422             self.retrieve()
    423         finally:
    424             if n_jobs > 1:

/afs/

athena.mit.edu/user/g/o/goretkin/py/lis_env/lib/python2.6/site-packages/joblib-0.5.3.dev-py2.6.egg/joblib/parallel.pycin
retrieve(self)
    379                         )
    380                     # Convert this to a JoblibException

--> 381                     exception_type =
_mk_exception(exception.etype)[0]
    382                     raise exception_type(report)
    383                 raise exception

/afs/

athena.mit.edu/user/g/o/goretkin/py/lis_env/lib/python2.6/site-packages/joblib-0.5.3.dev-py2.6.egg/joblib/my_exceptions.pycin
_mk_exception(exception, name)
     58         this_exception = type(this_name, (exception,
JoblibException),
     59                     dict(__repr__=JoblibException.__repr__,
---> 60                          __str__=JoblibException.__str__),
     61                     )
     62         _exception_mapping[this_name] = this_exception

TypeError: Cannot create a consistent method resolution
order (MRO) for bases Exception, JoblibException

Re: [joblib] Cannot create a consistent method resolution order (MRO) for bases Exception, JoblibException

From:
Gael Varoquaux
Date:
2011-08-01 @ 21:13
On Mon, Aug 01, 2011 at 05:10:02PM -0400, Gustavo Goretkin wrote:
>    I'm having a hard time finding out what this exception means:

>    TypeError: Cannot create a consistent method resolution order (MRO) for
>    bases Exception, JoblibException

Wow, that's pretty cool. I've never seen such an exception before. Could
you send me some code to reproduce it, please.

>    I've appended the full stacktrace below.  Note that the stacktrace only
>    happens after the jobs have finished executing.

Yes, unfortunately with the parallel computing code in joblib the
exception is raise after the parallel code finishes running.

Re: [joblib] Cannot create a consistent method resolution order (MRO) for bases Exception, JoblibException

From:
Gustavo Goretkin
Date:
2011-08-01 @ 21:35
I am glad to send the code. I'm sorry that I can't make a more elegant test
case.

The code loads data from an hdf5 file using h5py. Again, sorry I didn't
figure out how to narrow the test case.

The files are here: http://mit.edu/goretkin/Public/joblib_testcase/

Regarding the line "DO_CRASH = True #toggle me", when I set it to False, it
doesn't crash for me.

Thanks!
Gustavo

On Mon, Aug 1, 2011 at 5:13 PM, Gael Varoquaux <
gael.varoquaux@normalesup.org> wrote:

> On Mon, Aug 01, 2011 at 05:10:02PM -0400, Gustavo Goretkin wrote:
> >    I'm having a hard time finding out what this exception means:
>
> >    TypeError: Cannot create a consistent method resolution order (MRO)
> for
> >    bases Exception, JoblibException
>
> Wow, that's pretty cool. I've never seen such an exception before. Could
> you send me some code to reproduce it, please.
>
> >    I've appended the full stacktrace below.  Note that the stacktrace
> only
> >    happens after the jobs have finished executing.
>
> Yes, unfortunately with the parallel computing code in joblib the
> exception is raise after the parallel code finishes running.
>

Re: [joblib] Cannot create a consistent method resolution order (MRO) for bases Exception, JoblibException

From:
Gustavo Goretkin
Date:
2011-08-01 @ 22:21
Another way to make it *not* crash is to change

 gps = [gaussian_process.GaussianProcess(thetaL=1e-2,thetaU=1e2) for i in
range(m)]


to


gps = [gaussian_process.GaussianProcess() for i in range(m)]


This eliminates an optimization step inside of GaussianProcess, which is
giving me trouble separate from joblib. (I posted about it on scipy-user)


On Mon, Aug 1, 2011 at 5:35 PM, Gustavo Goretkin <gustavo.goretkin@gmail.com
> wrote:

> I am glad to send the code. I'm sorry that I can't make a more elegant test
> case.
>
> The code loads data from an hdf5 file using h5py. Again, sorry I didn't
> figure out how to narrow the test case.
>
> The files are here: http://mit.edu/goretkin/Public/joblib_testcase/
>
> Regarding the line "DO_CRASH = True #toggle me", when I set it to False, it
> doesn't crash for me.
>
> Thanks!
> Gustavo
>
>
> On Mon, Aug 1, 2011 at 5:13 PM, Gael Varoquaux <
> gael.varoquaux@normalesup.org> wrote:
>
>> On Mon, Aug 01, 2011 at 05:10:02PM -0400, Gustavo Goretkin wrote:
>> >    I'm having a hard time finding out what this exception means:
>>
>> >    TypeError: Cannot create a consistent method resolution order (MRO)
>> for
>> >    bases Exception, JoblibException
>>
>> Wow, that's pretty cool. I've never seen such an exception before. Could
>> you send me some code to reproduce it, please.
>>
>> >    I've appended the full stacktrace below.  Note that the stacktrace
>> only
>> >    happens after the jobs have finished executing.
>>
>> Yes, unfortunately with the parallel computing code in joblib the
>> exception is raise after the parallel code finishes running.
>>
>
>