matplotlib-devel Mailing List for matplotlib

John Hunter wrote:
> Andrew, the failure is on the font cache again -- is this the race
> condition you've mentioned in the past?
>
> matplotlib.tests.test_mathtext.test_mathtext_stixsans ... ok
> Failure: IOError ([Errno 2] No such file or directory:
> '/home/mpl-chslave/.matplotlib/fontList.cache') ... ERROR
>
> "/home/mpl-chslave/slave-py24/build_test_py24/build/PYmpl/lib/python2.4/site-packages/matplotlib/font_manager.py",
> line 942, in pickle_dump
> fh = open(filename, 'w')
> IOError: [Errno 2] No such file or directory:
> '/home/mpl-chslave/.matplotlib/fontList.cache'
John, yes, this is the multiprocess race condition. I don't think the
issue is buildbot specific, but I can see that the use case may be rare
in which one process deletes the MPL directory after another had already
determined it is present. Nevertheless, I think it's something that
could happen in other circumstances, and I'm not sure the fontlist cache
file itself is multiprocess safe (I'm not saying it isn't -- I haven't
looked).
It does appear that a locking based solution is possible in a
cross-platform way, as sqlite says they do it in "Can multiple
applications or multiple instances of the same application access a
single database file at the same time?" at http://www.sqlite.org/faq.html .
I could put the builds in different user accounts so that the buildbot
wouldn't unintentionally continue to be hit with this bug. We could also
make a test case that starts multiple processes simultaneously using
subprocess to exercise the bug and mark it as known failing -- that way
we at least don't forget that it's an issue.
All that being said -- I don't mind the occasional buildbot failure
message -- it tells me that the buildbot is running and testing stuff.
One can always quickly re-fire the failed test manually from the
buildbot webpage to determine if this was the problem.
-Andrew

On Thu, Feb 18, 2010 at 11:50 PM, Fernando Perez <fpe...@gm...> wrote:
> I defer to your wisdom here: I had no clue about this, so I went for
> the clumsier API. If you are right, it would also make the
> implementation much simpler, as I had to play some not-totally-obvious
> gymnastics to alter axis creation order based on this parameter.
>
After quickly going through the mpl source (and in my experience), I
think it is quite safe to assume that there is no master-slave
relation among the shared axes.
> One more, related question: is it possible/reasonable to share *both*
> x and y axes?
Yes, it is possible as I often do.
>
> It would be really nice if you were correct. The api could be nicer
> and the implementation simpler.
>
>> Also, how about "subplots" returns a some kind of object so that we
>> may define some methods on it. We can define "__iter__" method so
>> that above syntax also works. As an example,
>>
>> mysubplots = subplots(4,1, sharex=True)
>> mysubplots.label_outer()
>> ax1, ax2, ax3, ax4 = mysubplots
>
> Mmh, more than I have time for right now, I'm afraid (I'm really
> pushing it with these little side-trips already). But if you do have
> a minute to do it, run with it.
>
> I can only commit to finish the basic implementation with the changes
> discussed above, plus any fixes to share* based on clarifying these
> points. A fancier object API would be great to have, so by all means
> go ahead if you have the bandwidth!
I, personally, am more interested in implementing some form of a
general interface (base class) for a set of axes, although I have no
immediate plan. If I have a chance to work on this, I will try to
adjust those to work with well your code.
Regards,
-JJ
>
> Cheers,
>
> f
>