matplotlib-devel Mailing List for matplotlib

On Sun, Dec 23, 2012 at 2:24 PM, Nathaniel Smith <nj...@po...> wrote:
> On Sun, Dec 23, 2012 at 12:42 AM, Damon McDougall
> <dam...@gm...> wrote:
>> On Mon, Dec 17, 2012 at 8:10 AM, Michael Droettboom <md...@st...> wrote:
>>> On 12/16/2012 03:44 PM, Eric Firing wrote:
>>>> On 2012年12月16日 9:21 AM, Damon McDougall wrote:
>>>>> On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout
>>>>> <jas...@cr...> wrote:
>>>>>> On 12/14/12 10:55 AM, Nathaniel Smith wrote:
>>>>>>> sourceforge's horror of an interface.
>>>>>> I'll second that. Every time I go to Sourceforge, I have to figure out
>>>>>> how in the world to download what I want (and I have to figure out which
>>>>>> things *not* to click on too).
>>>>> Ok sounds like there is a reasonable amount of resistance towards Sourceforge.
>>>>>
>>>>> Eric, when you suggest that NumFocus could 'provide hosting directly',
>>>>> do you mean they would have the physical hardware to host the files,
>>>>> or are you suggesting they provide the finances to seek hosting
>>>>> elsewhere?
>>>> I was thinking that perhaps NumFocus would be running a server that
>>>> could provide the hosting. Funding for an external service is also
>>>> possible, though, and might make more sense.
>>>
>>> I'll definitely walk down the hall and talk to my local Numfocus board
>>> member ;)
>>
>> At the 6th Annual Scientific Software Day here at UT Austin, I met and
>> spoke to Travis Oliphant regarding funding for hosting our binaries.
>> Travis has links with NumFOCUS and was eager to help the matplotlib
>> community host binaries should we choose to not go with sourceforge or
>> another free option.
>>
>> I'll need touch base with him again to get specifics, but I thought
>> I'd just let everyone here know that that's still an option.
>>
>> To be honest with you, I'm thinking that if we only want to link to
>> binaries from the matplotlib web page then sourceforge really doesn't
>> sound like a bad option at all.
>
> Or -- I'll just point this out one more time then leave the dead horse
> alone :-) -- you could just register a project called
> 'matplotlib-downloads' on google code hosting, and have static URLs
> that look like e.g.
> https://apa6e.googlecode.com/files/apa6e-v0.3.zip
> and let Google foot the bill for reliable high-bandwidth CDN hosting.
>
> -n
Thanks for reminding us about the google code option. Since there are
quite a lot of suggestions I've used this opportunity to write a short
summary of the options presented in this thread:
Google Code: Free. Interface is better than sourceforge.
Sourceforge: Free. Ugly. May not need interface if hotlinking to
binaries from the website.
PyPI: Free. Size quota too small. Will link to external files.
S3: Free and not free. We're over the free tier quota. NumFOCUS can
potentially fund the non-free tier (cost is circa 200ドル/mo). I thought
it was 200ドル/yr. IMO 200ドル/mo is very expensive.
gh-pages: We're already over the size limit for this branch.
new gh repo: Free. 1GB of space.
https://help.github.com/articles/what-is-my-disk-quota. Will hold
about 4 releases?
Dropbox: Free 2GB account. Can hotlink to binaries.
-- 
Damon McDougall
http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229

On Wed, Dec 12, 2012 at 11:57 AM, Marcel Oliver <
m.o...@ja...> wrote:
> Paul Hobson writes:
> > On Wed, Dec 12, 2012 at 5:59 AM, Michael Droettboom <md...@st...>
> wrote:
> >
> > http://matplotlib.org/examples/api/clippath_demo.html
> >
> > It's perfectly reasonable code, but seems strange that it's
> > clipped off to the corner which I think makes it less useful as
> > an example.
> >
> > If I understand correctly, you're proposing that that such an
> > example would be deleted after a more practical example was
> > available to replace it?
> >
> > While I'm 100% in favor of "cleaning out the closet", I used this exact
> > example two days ago to clip a depressed groundwater surface to a
> landfill
> > boundary :)
>
> There is one small issue with the example: If one is using imshow on
> random pixel data, there is not reason to use bilinear interpolation
> (which is what imshow defaults to). "nearest" is the only reasonable
> choice.
>
> I know this sounds pedantic, but it irks me as a numerical analyst...
>
> --Marcel
>
Marcel: I agree examples like this should be changed. Actually, I think the
default interpolation should be changed to "nearest", but that's a whole
different can of worms ;)
For those who are interested, I just posted a pull request for this gallery
clean up <https://github.com/matplotlib/matplotlib/pull/1623>. It's
definitely a work in progress. In particular, the section names are less
than ideal, but I think github's PR interface is a better place for that
discussion than the wiki or mailing list. The new section names can be
found below:
https://github.com/matplotlib/matplotlib/pull/1623/files#L0R86
Also, I moved a number of examples to the new sections in order to
demonstrate some of the clean up guidelines. BTW, one of the examples I
cleaned up is the clippath demo discussed earlier in this thread.
Best,
-Tony
Marcel: Sorry for the second email, I forgot to "reply all" the first time.