matplotlib-devel Mailing List for matplotlib (Page 4)

> On Tue, Feb 22, 2011 at 2:45 PM, Benjamin Root <ben...@ou...> wrote:
> > Hello all,
> >
> > Given some recent -- ahem -- difficulties with matplotlib users where
> > English is not their native language, it has dawned on me that maybe we
> > ought to consider making available translated versions of our
> > documentation.  I have absolutely no experience with such efforts, but I did
> > see that Sphinx does support internationalization:
> >
> > http://sphinx.pocoo.org/latest/intl.html

Hi Ben,

a soft on this -1 from me. At this time, I feel that matplotlib has neither
the user base need, nor the developer / i18n expert bandwidth to make this
happen. As a point of reference, even the Python docs aren't
internationalized, at the moment.

> >
> > and I do believe we have some bilingual developers on this list (or at least
> > are active on the users list).  While I don't think it would be possible to
> > translate the API docs effectively, at the very least we should be able to
> > provide translations of other parts.

which parts? Tutorials? It seems like these sorts of things
self-organize around individuals who write about the software in
their language of choice. Folks searching the web for something
like "python publication quality graphics" in Esperanto or
Klingon will find one another, if there are enough of them, and
if there aren't enough of them, we'd have a very hard time
helping them.

> >
> > What does everyone think?  Could someone who has done internationalization
> > (particularly using sphinx) comment?  What languages would we like the docs
> > to be in?

I think the fact that there isn't a language that automatically
pops into our heads suggests to me that we could expand a lot of
effort to do this without users that actually need it.

Darren Dale, on 2011-02-22 14:52,  wrote:
> If anyone is looking for me, I'll be cowering under my desk.

English being lingua franca ;) is fairly typical in the software
world, but that doesn't mean we should feel free to sprinkle
idioms and confusing cultural references everywhere. I'm guilty
of both of these, as I sometimes try to add "color" to my
comments, which might produce a chuckle for the folks who
understood, but be a source of unneeded confusion for others.

So may I propose an alternative, which I've seen in somewhere
else, but completely blanking on where: add to our FAQ (or some
similar place) comment requesting feedback along these lines:

  All of the documentation is in English: is there a
  <insert-language> translation of matplotlib documentation?
  
  We strive to make matplotlib accessible to everyone, but lack the
  resource to translate and maintain the documentation in several
  languages. Please help us identify and reword confusing portions
  of the documentation (in particular, idiomatic or otherwise
  untranslatable usage of English in docstrings is considered a
  bug which you should report).

best,
-- 
Paul Ivanov
314 address only used for lists,  off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 

On 02/22/2011 09:45 AM, Benjamin Root wrote:
> Hello all,
>
> Given some recent -- ahem -- difficulties with matplotlib users where
> English is not their native language, it has dawned on me that maybe we
> ought to consider making available translated versions of our
> documentation.  I have absolutely no experience with such efforts, but I
> did see that Sphinx does support internationalization:
>
> http://sphinx.pocoo.org/latest/intl.html
>
> and I do believe we have some bilingual developers on this list (or at
> least are active on the users list).  While I don't think it would be
> possible to translate the API docs effectively, at the very least we
> should be able to provide translations of other parts.

I think this is premature.  My sense is that there are other aspects of 
the docs and code that should be cleaned up first, and that having 
translations of the docs will actually make this more difficult--there 
will be more pieces of the system to try to keep up to date.

Eric

>
> What does everyone think?  Could someone who has done
> internationalization (particularly using sphinx) comment?  What
> languages would we like the docs to be in?
>
> Ben Root
>
>
>
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search&  Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Tue, Feb 22, 2011 at 2:45 PM, Benjamin Root <ben...@ou...> wrote:
> Hello all,
>
> Given some recent -- ahem -- difficulties with matplotlib users where
> English is not their native language, it has dawned on me that maybe we
> ought to consider making available translated versions of our
> documentation.  I have absolutely no experience with such efforts, but I did
> see that Sphinx does support internationalization:
>
> http://sphinx.pocoo.org/latest/intl.html
>
> and I do believe we have some bilingual developers on this list (or at least
> are active on the users list).  While I don't think it would be possible to
> translate the API docs effectively, at the very least we should be able to
> provide translations of other parts.
>
> What does everyone think?  Could someone who has done internationalization
> (particularly using sphinx) comment?  What languages would we like the docs
> to be in?

If anyone is looking for me, I'll be cowering under my desk.

Hello all,

Given some recent -- ahem -- difficulties with matplotlib users where
English is not their native language, it has dawned on me that maybe we
ought to consider making available translated versions of our
documentation.  I have absolutely no experience with such efforts, but I did
see that Sphinx does support internationalization:

http://sphinx.pocoo.org/latest/intl.html

and I do believe we have some bilingual developers on this list (or at least
are active on the users list).  While I don't think it would be possible to
translate the API docs effectively, at the very least we should be able to
provide translations of other parts.

What does everyone think?  Could someone who has done internationalization
(particularly using sphinx) comment?  What languages would we like the docs
to be in?

Ben Root

> An associated bug report would be appreciated (mailing list
> discussions are useful for raising awareness, but are more likely to
> be forgotten over time than bug reports): http://bugs.python.org

Just did that; thanks!

-- Hoyt

++++++++++++++++++++++++++++++++++++++++++++++++
+ Hoyt Koepke
+ University of Washington Department of Statistics
+ http://www.stat.washington.edu/~hoytak/
+ ho...@gm...
++++++++++++++++++++++++++++++++++++++++++

On Sat, Feb 19, 2011 at 1:43 PM, Darren Dale <dsd...@gm...> wrote:
> On Sat, Feb 19, 2011 at 1:03 PM, Jarrod Millman <mi...@be...> wrote:
>> On Fri, Feb 18, 2011 at 8:55 PM, Darren Dale wrote:
>>> * Jarrod offered to contribute to the docs to describe the recommended
>>> workflow.
>>
>> I did a first pass at changing the documentation from describing svn
>> to git (including adding gitwash) and generated a pull request:
>>  https://github.com/matplotlib/matplotlib/pull/3
>
> Lets continue discussion at the pull request.

We had some conflicting changes, but Jarrod graciously closed pull
request 3 without merging and reapplied the gitwash docs to the branch
at pull request 2. We could use some more eyes on that branch to
ensure the docs are current. Any help would be appreciated, please
direct feedback to https://github.com/matplotlib/matplotlib/pull/2 .

Thanks,
Darren

On Sun, Feb 20, 2011 at 3:43 PM, Hoyt Koepke <ho...@st...> wrote:
> I'd be happy to provide any more information if needed.  I attached
> example code that reproduces it.  Let me know if I should file a bug
> report (and where to file it -- which is why I haven't yet).

An associated bug report would be appreciated (mailing list
discussions are useful for raising awareness, but are more likely to
be forgotten over time than bug reports): http://bugs.python.org

Cheers,
Nick.

-- 
Nick Coghlan   |   nco...@gm...   |   Brisbane, Australia

Hello,

I've encountered a strange bug that appears to be either in gcc's gomp
implementation or in how python loads extension modules linked against
gomp.  Here's the error:

Using gcc (multiple versions) on linux, I compile an empty c extension
module and pass -lgomp as a linker arg.  If I import it, running a
simple script in matplotlib causes a segfault.  Not passing -lgomp or
not loading the empty module makes the code works fine.  More
specifically, if I compile:

#include "Python.h"
static struct PyMethodDef methods[] = {
  {0, 0, 0, 0}
};
PyMODINIT_FUNC initempty(void) {
  Py_InitModule4("empty", methods, 0, 0, PYTHON_API_VERSION);
}

using ``ext_modules = [Extension("empty", ["empty.c"], extra_link_args
= ["-lgomp"])]``, then


import empty
import matplotlib.pylab as plt

plt.figure()
plt.plot([0,1], [0,1], '-b')
plt.show()


causes the program to segfault (removing ``import empty`` makes it
fine).  Looking at a traceback:

#0  0x00f78bc7 in __cxa_allocate_exception () from /usr/lib/libstdc++.so.6
#1  0x008f51f2 in py_to_agg_transformation_matrix (obj=0x8223f58,
errors=false) at src/agg_py_transforms.cpp:20
#2  0x008fdd73 in _path_module::update_path_extents (this=0x8e45f90,
args=...) at src/path.cpp:378
#3  0x009048bd in
Py::ExtensionModule<_path_module>::invoke_method_varargs (this=<value
optimized out>, method_def=0x8e9ae30, args=...) at
./CXX/Python2/ExtensionModule.hxx:184
#4  0x008f0d96 in method_varargs_call_handler
(_self_and_name_tuple=0x8e6eeac, _args=0x94e683c) at
CXX/Python2/cxx_extensions.cxx:1714
#5  0x080dc0d0 in PyEval_EvalFrameEx ()
#6  0x080dddf2 in PyEval_EvalCodeEx ()

While occurring in some of matplotlib's extension code (and I haven't
found another library that crashes it), the fact that the deciding
factor is whether I link against gomp indicates the it's probably
upstream somewhere.

I encountered this error a year ago and asked about it on the
matplotlib mailing list, but found a quick workaround then, and with
deadline pressure I forgot about it.  However, it's come up again, and
then I was asked to bump it to python-dev, which is why I'm posting it
here.

I can reproduce it on the following systems.  In all cases, matplotlib
is compiled from source on the development branch (r8969) and uses
QT4Agg as the backend, as is numpy, scipy, etc.  If needed, I can
track down more versions.

gcc (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.4, 64bit, Python 2.6.6, ubuntu 10.10
gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3, 64bit, Python 2.6.5, ubuntu 10.04
gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1, 32bit, Python 2.6.4, ubuntu 9.10

gcc 4.5.2 (source build), Python 2.6.5, ubuntu 10.04.  On this build,
the given source example does not produce the result, and I haven't
been able to tweak it so it does.  However, linking to a much larger
extension library that uses many different parts of openmp causes
exactly the same crash.  If I recompile that library without openmp
support, then everything works fine; with openmp support it corrupts
something and matplotlib crashes in exactly the same way.

gcc 4.3.2, Python 2.6.2, ubuntu 9.04 (I don't have access to this
system any more, since it got upgraded, but it had the same problem a
year ago).

I'd be happy to provide any more information if needed.  I attached
example code that reproduces it.  Let me know if I should file a bug
report (and where to file it -- which is why I haven't yet).

Thanks,

--Hoyt

++++++++++++++++++++++++++++++++++++++++++++++++
+ Hoyt Koepke
+ University of Washington Department of Statistics
+ http://www.stat.washington.edu/~hoytak/
+ ho...@gm...
++++++++++++++++++++++++++++++++++++++++++

On Sat, Feb 19, 2011 at 1:03 PM, Jarrod Millman <mi...@be...> wrote:
> On Fri, Feb 18, 2011 at 8:55 PM, Darren Dale wrote:
>> * Jarrod offered to contribute to the docs to describe the recommended
>> workflow.
>
> I did a first pass at changing the documentation from describing svn
> to git (including adding gitwash) and generated a pull request:
>  https://github.com/matplotlib/matplotlib/pull/3

Lets continue discussion at the pull request.

On Fri, Feb 18, 2011 at 8:55 PM, Darren Dale wrote:
> * Jarrod offered to contribute to the docs to describe the recommended
> workflow.

I did a first pass at changing the documentation from describing svn
to git (including adding gitwash) and generated a pull request:
  https://github.com/matplotlib/matplotlib/pull/3

Best,
Jarrod

On Fri, Feb 18, 2011 at 4:53 PM, John Hunter <jd...@gm...> wrote:
> I have removed everyone's commit access to the mpl svn server in
> advance of the github migration, which is underway.  Darren will reply
> when github is live.
>
> svn is dead, long live github!

I just pushed the repositories up to github.com/matplotlib .

A few notes:

* Jarrod offered to contribute to the docs to describe the recommended
workflow. For the impatient:

  - Visit https://github.com/matplotlib/matplotlib and hit the "fork" button
  - clone the resulting repository, eg "git clone
gi...@gi...:username/matplotlib.git"
  - make a new branch (git checkout -b new_feature) and hack away
  - don't merge upstream changes into your feature branch (it makes
the history graph look ugly)
  - when you are ready to have your changes merged upstream, push your
branch to your own repository at github
  - switch to that branch in your github profile, and select the "pull
request" button. This starts the code review process, which also gives
others a chance to inspect the git history graph before it gets merged
into the official mpl repo.

* python-3 support should happen in the matploltib-py3 repo, the
master branch in that repository contains Michael's changes from the
py3k svn branch, but rebased on top of the more recent changes to the
master branch in the main matplotlib repo.

Darren

On Fri, Feb 18, 2011 at 8:16 PM, Jarrod Millman <mi...@be...> wrote:
> On Fri, Feb 18, 2011 at 1:53 PM, John Hunter wrote:
>> I have removed everyone's commit access to the mpl svn server in
>> advance of the github migration, which is underway.  Darren will reply
>> when github is live.
>
> Excellent!  I am glad to see that all the core scipy-related projects
> will soon be on github (scipy will move to github as soon as the 0.9
> release is finalized).
>
> I am sure you know about this; but just as a reminder, Matthew and
> Fernando made a set of generic instruction for using git/github:
>  https://github.com/matthew-brett/gitwash
> The idea being that all the core projects share a standard set of
> procedures for using git/github and adopting similar workflow
> policies.  So far NumPy, IPython, and NIPY all use these instructions:
>
>  https://github.com/numpy/numpy/tree/master/doc/source/dev/gitwash
>  https://github.com/ipython/ipython/tree/master/docs/source/development/gitwash
>  https://github.com/nipy/nipy/tree/master/doc/devel/guidelines/gitwash
>
> If you want I am happy to take care of adding gitwash to the
> matplotlib docs as soon as the move to git/github is done (and
> generating a pull request).

Jarrod, that would be greatly appreciated.

On Fri, Feb 18, 2011 at 1:53 PM, John Hunter wrote:
> I have removed everyone's commit access to the mpl svn server in
> advance of the github migration, which is underway.  Darren will reply
> when github is live.

Excellent!  I am glad to see that all the core scipy-related projects
will soon be on github (scipy will move to github as soon as the 0.9
release is finalized).

I am sure you know about this; but just as a reminder, Matthew and
Fernando made a set of generic instruction for using git/github:
  https://github.com/matthew-brett/gitwash
The idea being that all the core projects share a standard set of
procedures for using git/github and adopting similar workflow
policies.  So far NumPy, IPython, and NIPY all use these instructions:

  https://github.com/numpy/numpy/tree/master/doc/source/dev/gitwash
  https://github.com/ipython/ipython/tree/master/docs/source/development/gitwash
  https://github.com/nipy/nipy/tree/master/doc/devel/guidelines/gitwash

If you want I am happy to take care of adding gitwash to the
matplotlib docs as soon as the move to git/github is done (and
generating a pull request).

Best,
Jarrod

Hi all,


I did not see any voronoi diagram in matplotlib examples so I created a simple one from the available tri.Triangulation function (I hope I did not miss something evident).


Nicolas



#!/usr/bin/env python
# -----------------------------------------------------------------------------
# Voronoi diagram from a list of points
# Copyright (C) 2011  Nicolas P. Rougier
#
# Distributed under the terms of the BSD License.
# -----------------------------------------------------------------------------
import numpy as np
import matplotlib
import matplotlib.pyplot as plt


def circumcircle(P1, P2, P3):
    ''' 
    Return center of the circle containing P1, P2 and P3

    If P1, P2 and P3 are colinear, return None

    Adapted from:
    http://local.wasp.uwa.edu.au/~pbourke/geometry/circlefrom3/Circle.cpp
    '''
    delta_a = P2 - P1
    delta_b = P3 - P2
    if np.abs(delta_a[0]) <= 0.000000001 and np.abs(delta_b[1]) <= 0.000000001:
        center_x = 0.5*(P2[0] + P3[0])
        center_y = 0.5*(P1[1] + P2[1])
    else:
        aSlope = delta_a[1]/delta_a[0]
        bSlope = delta_b[1]/delta_b[0]
        if np.abs(aSlope-bSlope) <= 0.000000001:
            return None
        center_x= (aSlope*bSlope*(P1[1] - P3[1]) + bSlope*(P1[0] + P2 [0]) \
                        - aSlope*(P2[0]+P3[0]))/(2.*(bSlope-aSlope))
        center_y = -(center_x - (P1[0]+P2[0])/2.)/aSlope + (P1[1]+P2[1])/2.
    return center_x, center_y

def voronoi(X,Y):
    ''' Return line segments describing the voronoi diagram of X and Y '''
    P = np.zeros((X.size+4,2))
    P[:X.size,0], P[:Y.size,1] = X, Y
    # We add four points at (pseudo) "infinity"
    m = max(np.abs(X).max(), np.abs(Y).max())*1e5
    P[X.size:,0] = -m, -m, +m, +m
    P[Y.size:,1] = -m, +m, -m, +m
    D = matplotlib.tri.Triangulation(P[:,0],P[:,1])
    T = D.triangles
    n = T.shape[0]
    C = np.zeros((n,2))
    for i in range(n):
        C[i] = circumcircle(P[T[i,0]],P[T[i,1]],P[T[i,2]])
    X,Y = C[:,0], C[:,1]
    segments = []
    for i in range(n):
        for k in D.neighbors[i]:
            if k != -1:
                segments.append([(X[i],Y[i]), (X[k],Y[k])])
    return segments

# -----------------------------------------------------------------------------
if __name__ == '__main__':
    P = np.random.random((2,256))
    X,Y = P[0],P[1]
    fig = plt.figure(figsize=(10,10))
    axes = plt.subplot(1,1,1)
    plt.scatter(X,Y, s=5)
    segments = voronoi(X,Y)
    lines = matplotlib.collections.LineCollection(segments, color='0.75')
    axes.add_collection(lines)
    plt.axis([0,1,0,1])
    plt.show()

I have removed everyone's commit access to the mpl svn server in
advance of the github migration, which is underway.  Darren will reply
when github is live.

svn is dead, long live github!

JDH

On Fri, Feb 18, 2011 at 1:17 PM, Eric Firing <ef...@ha...> wrote:

> On 02/18/2011 08:26 AM, Benjamin Root wrote:
>
>>
>>
>> On Thu, Feb 17, 2011 at 1:36 PM, Benjamin Root <ben...@ou...
>> <mailto:ben...@ou...>> wrote:
>>
>>    On Tue, Feb 15, 2011 at 2:05 PM, Benjamin Root <ben...@ou...
>>    <mailto:ben...@ou...>> wrote:
>>
>>        On Tue, Feb 15, 2011 at 1:41 PM, Benjamin Root <ben...@ou...
>>        <mailto:ben...@ou...>> wrote:
>>
>>
>>
>>            On Tue, Feb 15, 2011 at 1:17 PM, Eric Firing
>>            <ef...@ha... <mailto:ef...@ha...>> wrote:
>>
>>                On 02/15/2011 08:50 AM, Benjamin Root wrote:
>>
>>                    On Tue, Feb 15, 2011 at 12:19 PM, Benjamin Root
>>                    <ben...@ou... <mailto:ben...@ou...>
>>                    <mailto:ben...@ou... <mailto:ben...@ou...>>>
>>
>>                    wrote:
>>
>>                        On Tue, Feb 15, 2011 at 11:54 AM, Eric Firing
>>                    <ef...@ha... <mailto:ef...@ha...>
>>                    <mailto:ef...@ha...
>>
>>                    <mailto:ef...@ha...>>> wrote:
>>
>>                            On 02/15/2011 07:40 AM, Benjamin Root wrote:
>>                     > I have come across a little inconsistency that
>>                    was unexpected
>>                            in the
>>                     > matplotlib API.  The following is perfectly valid:
>>                     >
>>                     > import matplotlib.pyplot as plt
>>                     > plt.plot([], [])
>>                     > plt.show()
>>                     >
>>                     >
>>                     > However, this is not valid:
>>                     >
>>                     > import matplotlib.pyplot as plt
>>                     > plt.scatter([], [])
>>                     > plt.show()
>>                     >
>>                     >
>>                     > The immediate issue that comes up in scatter is
>>                    that it
>>                            attempts to find
>>                     > min/max of the input data for the purpose of
>>                    autoscaling
>>                            (this can
>>                     > probably be done better by just using
>>                    set_xmargin(0.05) and
>>                     > set_ymargin(0.05)).  This can easily be bypassed
>>                    with an if
>>                            statement.
>>                     > However, then we discover that polygon collection
>>                    do not like
>>                            having
>>                     > empty offsets, which leads to a failure in the
>> affine
>>                            transformation.
>>                     >
>>                     > So, the question is, is this a bug or a feature?  I
>>                            personally believe
>>                     > that empty data is a perfectly valid scenario and
>>                    given that
>>                            other
>>                     > matplotlib functions handle it gracefully, we
>>                    should make the
>>                     > collections object more friendly to empty data.
>>
>>                            I agree; a call with empty data should
>>                    simply not plot anything.
>>
>>                            Eric
>>
>>
>>                        Digging further, it appears that the problem is
>>                    in _path.cpp for
>>                        _path_module::affine_transform() which
>>                    explicitly checks for an
>>                        empty vertices array and throws an exception if
>>                    it is empty.
>>
>>                        So, do we want to make _path.cpp empty-friendly
>>                    or should we just
>>                        make empty collections objects just avoid doing
>>                    anything that
>>                        requires doing an affine transform?
>>
>>                        Ben Root
>>
>>
>>
>>                    Ok, some more digging deepens the mystery.  While an
>>                    empty-friendly
>>                    _path.cpp would be nice, it appears that the
>>                    collections and axes
>>                    objects are already doing all it can to avoid doing
>>                    transforms for empty
>>                    collections.
>>
>>                    However, it appears that the supposedly empty
>>                    collection object from
>>                    scatter([], []) is not really empty.  Its
>>                    self._paths member contains a
>>                    list of unit_circle() from Path.  This is also the
>>                    case for
>>                    EllipseCollection.  Meanwhile, LineCollection and
>>                    PatchCollection
>>                    initializes their self._paths in accordance to their
>>                    given data.
>>
>>
>>                One way to solve the problem would be to start each
>>                draw() method with a short-circuit return in case there
>>                is nothing to draw.  It would be needed only for classes
>>                for which empty self._paths is not a valid test.  So for
>>                CircleCollection it would be:
>>
>>                    @allow_rasterization
>>                    def draw(self, renderer):
>>                        # sizes is the area of the circle circumscribing
>>                the polygon
>>                        # in points^2
>>                        if len(self._sizes) == 0:
>>                            return
>>                        self._transforms = [
>>                            transforms.Affine2D().scale(
>>                                (np.sqrt(x) * self.figure.dpi / 72.0) /
>>                np.sqrt(np.pi))
>>                            for x in self._sizes]
>>                        return Collection.draw(self, renderer)
>>
>>                (Collection.draw returns nothing, so there is no
>>                inconsistency in the return value.)
>>
>>                Alternatively, it looks like maybe an empty
>>                self._transforms could be used in a short-circuit test
>>                at the start of Collection.draw.
>>
>>                Eric
>>
>>
>>
>>                    Ben Root
>>
>>
>>
>>            That wouldn't completely solve the problem.  Affine
>>            transforms are being done for get_datalim() as well.  The
>>            other issue (and I see that I mixed this up myself) is the
>>            assumption elsewhere that a non-empty self._path attribute
>>            means that there is something to plot.  This is an
>>            assumption that is made in axes.py on line 1413 and it is an
>>            invalid assumption.
>>
>>            As for your proposed solution in draw(), I prefer
>>            short-circuiting in Collections.draw().  This makes for less
>>            work for new Collection subclasses.
>>
>>            Ben Root
>>
>>
>>
>>        Working from an assumption that we can't possibly find all
>>        bad/broken assumptions in mpl, I decided to go the route of Eric
>>        and make the Collections object as robust as possible.  I have
>>        attached a patch that should enable empty scatter plots in
>>        matplotlib and enable empty Collections as well.
>>
>>        This has not been fully tested yet.  Please be brutal!
>>
>>        Ben Root
>>
>>
>>
>>    Heh, looks like that patch breaks the plotting of errorbars (the
>>    line connecting the center point to the error caps is missing).
>>
>>    I will see about fixing that.
>>
>>    Ben Root
>>
>>
>> Nailed it!
>>
>> After much examination and analysis, I realized that the transforms and
>> the backend renderers are actually quite robust to empty arrays of
>> points, so long as the arrays are shaped Nx2.  It appears that in
>> collections.py, an attempt is made to force that shape, but this is done
>> inconsistently and wasn't technically correct.
>>
>> Consider the following snippet:
>>
>>             offsets = np.asarray(offsets)
>>             if len(offsets.shape) == 1:
>>                 offsets = offsets[np.newaxis,:]  # Make it Nx2.
>>
>> If offsets was [[1, 4], [2, 5], [3, 6]], everything is fine.  If offsets
>> was [1, 4], everything works fine as well. However, if offsets was [1,
>> 2, 3], this would go through, producing a 1x3 array (which isn't what we
>> want and can cause errors later).  If offsets was [], then a (1, 0)
>> array is produced, and this causes problems later in the code when it
>> checks for empty arrays incorrectly.
>>
>> We can make this code better and clearer by shaping the array
>> appropriately like so:
>>
>>              offsets = np.asarray(offsets)
>>              offsets.shape = (-1, 2)
>>
>> There are multiple benefits to this.  First, it explicitly makes it
>> clear our intent and requirement (that offsets needs to be Nx2).
>> Second, it guarantees no copying of the array.  Third, any array that
>> can't fit this shape will throw an error.  Fourth, we eliminate an
>> if-statement!
>>
>> So, with this cleaner enforcement, I applied it to other places in
>> collections.py where it wasn't being done at all.  In addition, checks
>> for empty arrays were being done with a check for len(offsets) > 0,
>> which isn't quite right (a 1x0 array would pass this check, which is
>> incorrect), so I changed it to the clearer and more correct offsets.size
>>  > 0.
>>
>> The attached patch will not only fix the issues in collections.py, but
>> it also slightly changes the implementation of scatter() in axes.py to
>> avoid doing min/max checks (which would fail for empty arrays) and
>> instead will set data margins if they haven't been set already (and if
>> there is data).
>>
>> I have tested the patch with the test suite and it passes.  I also
>> double-checked that all the mplot3d examples (which are not in the test
>> suite) and they all rendered correctly.
>>
>> My only question is: Is it too late to commit to svn?
>>
>
> I don't think so.  Try it. It can't hurt.
>
>
>
>> I hope this enlightens others.
>>
>
> Yes, thank you!
>
> Eric
>
>  Ben Root
>>
>
>
Ah, and so it is still open.  Committed in r8988.

Ben Root

On 02/18/2011 08:26 AM, Benjamin Root wrote:
>
>
> On Thu, Feb 17, 2011 at 1:36 PM, Benjamin Root <ben...@ou...
> <mailto:ben...@ou...>> wrote:
>
>     On Tue, Feb 15, 2011 at 2:05 PM, Benjamin Root <ben...@ou...
>     <mailto:ben...@ou...>> wrote:
>
>         On Tue, Feb 15, 2011 at 1:41 PM, Benjamin Root <ben...@ou...
>         <mailto:ben...@ou...>> wrote:
>
>
>
>             On Tue, Feb 15, 2011 at 1:17 PM, Eric Firing
>             <ef...@ha... <mailto:ef...@ha...>> wrote:
>
>                 On 02/15/2011 08:50 AM, Benjamin Root wrote:
>
>                     On Tue, Feb 15, 2011 at 12:19 PM, Benjamin Root
>                     <ben...@ou... <mailto:ben...@ou...>
>                     <mailto:ben...@ou... <mailto:ben...@ou...>>>
>                     wrote:
>
>                         On Tue, Feb 15, 2011 at 11:54 AM, Eric Firing
>                     <ef...@ha... <mailto:ef...@ha...>
>                     <mailto:ef...@ha...
>                     <mailto:ef...@ha...>>> wrote:
>
>                             On 02/15/2011 07:40 AM, Benjamin Root wrote:
>                      > I have come across a little inconsistency that
>                     was unexpected
>                             in the
>                      > matplotlib API.  The following is perfectly valid:
>                      >
>                      > import matplotlib.pyplot as plt
>                      > plt.plot([], [])
>                      > plt.show()
>                      >
>                      >
>                      > However, this is not valid:
>                      >
>                      > import matplotlib.pyplot as plt
>                      > plt.scatter([], [])
>                      > plt.show()
>                      >
>                      >
>                      > The immediate issue that comes up in scatter is
>                     that it
>                             attempts to find
>                      > min/max of the input data for the purpose of
>                     autoscaling
>                             (this can
>                      > probably be done better by just using
>                     set_xmargin(0.05) and
>                      > set_ymargin(0.05)).  This can easily be bypassed
>                     with an if
>                             statement.
>                      > However, then we discover that polygon collection
>                     do not like
>                             having
>                      > empty offsets, which leads to a failure in the affine
>                             transformation.
>                      >
>                      > So, the question is, is this a bug or a feature?  I
>                             personally believe
>                      > that empty data is a perfectly valid scenario and
>                     given that
>                             other
>                      > matplotlib functions handle it gracefully, we
>                     should make the
>                      > collections object more friendly to empty data.
>
>                             I agree; a call with empty data should
>                     simply not plot anything.
>
>                             Eric
>
>
>                         Digging further, it appears that the problem is
>                     in _path.cpp for
>                         _path_module::affine_transform() which
>                     explicitly checks for an
>                         empty vertices array and throws an exception if
>                     it is empty.
>
>                         So, do we want to make _path.cpp empty-friendly
>                     or should we just
>                         make empty collections objects just avoid doing
>                     anything that
>                         requires doing an affine transform?
>
>                         Ben Root
>
>
>
>                     Ok, some more digging deepens the mystery.  While an
>                     empty-friendly
>                     _path.cpp would be nice, it appears that the
>                     collections and axes
>                     objects are already doing all it can to avoid doing
>                     transforms for empty
>                     collections.
>
>                     However, it appears that the supposedly empty
>                     collection object from
>                     scatter([], []) is not really empty.  Its
>                     self._paths member contains a
>                     list of unit_circle() from Path.  This is also the
>                     case for
>                     EllipseCollection.  Meanwhile, LineCollection and
>                     PatchCollection
>                     initializes their self._paths in accordance to their
>                     given data.
>
>
>                 One way to solve the problem would be to start each
>                 draw() method with a short-circuit return in case there
>                 is nothing to draw.  It would be needed only for classes
>                 for which empty self._paths is not a valid test.  So for
>                 CircleCollection it would be:
>
>                     @allow_rasterization
>                     def draw(self, renderer):
>                         # sizes is the area of the circle circumscribing
>                 the polygon
>                         # in points^2
>                         if len(self._sizes) == 0:
>                             return
>                         self._transforms = [
>                             transforms.Affine2D().scale(
>                                 (np.sqrt(x) * self.figure.dpi / 72.0) /
>                 np.sqrt(np.pi))
>                             for x in self._sizes]
>                         return Collection.draw(self, renderer)
>
>                 (Collection.draw returns nothing, so there is no
>                 inconsistency in the return value.)
>
>                 Alternatively, it looks like maybe an empty
>                 self._transforms could be used in a short-circuit test
>                 at the start of Collection.draw.
>
>                 Eric
>
>
>
>                     Ben Root
>
>
>
>             That wouldn't completely solve the problem.  Affine
>             transforms are being done for get_datalim() as well.  The
>             other issue (and I see that I mixed this up myself) is the
>             assumption elsewhere that a non-empty self._path attribute
>             means that there is something to plot.  This is an
>             assumption that is made in axes.py on line 1413 and it is an
>             invalid assumption.
>
>             As for your proposed solution in draw(), I prefer
>             short-circuiting in Collections.draw().  This makes for less
>             work for new Collection subclasses.
>
>             Ben Root
>
>
>
>         Working from an assumption that we can't possibly find all
>         bad/broken assumptions in mpl, I decided to go the route of Eric
>         and make the Collections object as robust as possible.  I have
>         attached a patch that should enable empty scatter plots in
>         matplotlib and enable empty Collections as well.
>
>         This has not been fully tested yet.  Please be brutal!
>
>         Ben Root
>
>
>
>     Heh, looks like that patch breaks the plotting of errorbars (the
>     line connecting the center point to the error caps is missing).
>
>     I will see about fixing that.
>
>     Ben Root
>
>
> Nailed it!
>
> After much examination and analysis, I realized that the transforms and
> the backend renderers are actually quite robust to empty arrays of
> points, so long as the arrays are shaped Nx2.  It appears that in
> collections.py, an attempt is made to force that shape, but this is done
> inconsistently and wasn't technically correct.
>
> Consider the following snippet:
>
>              offsets = np.asarray(offsets)
>              if len(offsets.shape) == 1:
>                  offsets = offsets[np.newaxis,:]  # Make it Nx2.
>
> If offsets was [[1, 4], [2, 5], [3, 6]], everything is fine.  If offsets
> was [1, 4], everything works fine as well. However, if offsets was [1,
> 2, 3], this would go through, producing a 1x3 array (which isn't what we
> want and can cause errors later).  If offsets was [], then a (1, 0)
> array is produced, and this causes problems later in the code when it
> checks for empty arrays incorrectly.
>
> We can make this code better and clearer by shaping the array
> appropriately like so:
>
>               offsets = np.asarray(offsets)
>               offsets.shape = (-1, 2)
>
> There are multiple benefits to this.  First, it explicitly makes it
> clear our intent and requirement (that offsets needs to be Nx2).
> Second, it guarantees no copying of the array.  Third, any array that
> can't fit this shape will throw an error.  Fourth, we eliminate an
> if-statement!
>
> So, with this cleaner enforcement, I applied it to other places in
> collections.py where it wasn't being done at all.  In addition, checks
> for empty arrays were being done with a check for len(offsets) > 0,
> which isn't quite right (a 1x0 array would pass this check, which is
> incorrect), so I changed it to the clearer and more correct offsets.size
>  > 0.
>
> The attached patch will not only fix the issues in collections.py, but
> it also slightly changes the implementation of scatter() in axes.py to
> avoid doing min/max checks (which would fail for empty arrays) and
> instead will set data margins if they haven't been set already (and if
> there is data).
>
> I have tested the patch with the test suite and it passes.  I also
> double-checked that all the mplot3d examples (which are not in the test
> suite) and they all rendered correctly.
>
> My only question is: Is it too late to commit to svn?

I don't think so.  Try it. It can't hurt.

>
> I hope this enlightens others.

Yes, thank you!

Eric

> Ben Root

On Wed, Feb 16, 2011 at 7:57 PM, Michael Droettboom <md...@st...> wrote:
> On 02/16/2011 03:53 PM, John Hunter wrote:
>> On Wed, Feb 16, 2011 at 2:47 PM, Michael Droettboom<md...@st...>  wrote:
>>> Not sure Sourceforge allows custom hooks in SVN.
>> We have a couple in place already
>>
>>
>> https://sourceforge.net/project/admin/svn.php?group_id=80706
> Yes.  But those aren't custom -- SF only provides a fixed set of scripts
> one can apply.  Notably, I don't think there's one that prevents further
> commits.

If that is the case, then let's just change the permissions for all
the devs to read-only. We can leave the tracker, feature requests, and
so forth enabled until we are ready to disable them at some later
time. Once the website is online at matplotlib.github.com, we can
follow the directions for "project relocation" at
https://sourceforge.net/project/admin/removal.php?group_id=80706 .
SourceForge will keep the project intact as an archive.

Darren

On Tue, Feb 15, 2011 at 2:05 PM, Benjamin Root <ben...@ou...> wrote:

> On Tue, Feb 15, 2011 at 1:41 PM, Benjamin Root <ben...@ou...> wrote:
>
>>
>>
>> On Tue, Feb 15, 2011 at 1:17 PM, Eric Firing <ef...@ha...> wrote:
>>
>>> On 02/15/2011 08:50 AM, Benjamin Root wrote:
>>>
>>>> On Tue, Feb 15, 2011 at 12:19 PM, Benjamin Root <ben...@ou...
>>>> <mailto:ben...@ou...>> wrote:
>>>>
>>>>    On Tue, Feb 15, 2011 at 11:54 AM, Eric Firing <ef...@ha...
>>>>    <mailto:ef...@ha...>> wrote:
>>>>
>>>>        On 02/15/2011 07:40 AM, Benjamin Root wrote:
>>>>         > I have come across a little inconsistency that was unexpected
>>>>        in the
>>>>         > matplotlib API.  The following is perfectly valid:
>>>>         >
>>>>         > import matplotlib.pyplot as plt
>>>>         > plt.plot([], [])
>>>>         > plt.show()
>>>>         >
>>>>         >
>>>>         > However, this is not valid:
>>>>         >
>>>>         > import matplotlib.pyplot as plt
>>>>         > plt.scatter([], [])
>>>>         > plt.show()
>>>>         >
>>>>         >
>>>>         > The immediate issue that comes up in scatter is that it
>>>>        attempts to find
>>>>         > min/max of the input data for the purpose of autoscaling
>>>>        (this can
>>>>         > probably be done better by just using set_xmargin(0.05) and
>>>>         > set_ymargin(0.05)).  This can easily be bypassed with an if
>>>>        statement.
>>>>         > However, then we discover that polygon collection do not like
>>>>        having
>>>>         > empty offsets, which leads to a failure in the affine
>>>>        transformation.
>>>>         >
>>>>         > So, the question is, is this a bug or a feature?  I
>>>>        personally believe
>>>>         > that empty data is a perfectly valid scenario and given that
>>>>        other
>>>>         > matplotlib functions handle it gracefully, we should make the
>>>>         > collections object more friendly to empty data.
>>>>
>>>>        I agree; a call with empty data should simply not plot anything.
>>>>
>>>>        Eric
>>>>
>>>>
>>>>    Digging further, it appears that the problem is in _path.cpp for
>>>>    _path_module::affine_transform() which explicitly checks for an
>>>>    empty vertices array and throws an exception if it is empty.
>>>>
>>>>    So, do we want to make _path.cpp empty-friendly or should we just
>>>>    make empty collections objects just avoid doing anything that
>>>>    requires doing an affine transform?
>>>>
>>>>    Ben Root
>>>>
>>>>
>>>>
>>>> Ok, some more digging deepens the mystery.  While an empty-friendly
>>>> _path.cpp would be nice, it appears that the collections and axes
>>>> objects are already doing all it can to avoid doing transforms for empty
>>>> collections.
>>>>
>>>> However, it appears that the supposedly empty collection object from
>>>> scatter([], []) is not really empty.  Its self._paths member contains a
>>>> list of unit_circle() from Path.  This is also the case for
>>>> EllipseCollection.  Meanwhile, LineCollection and PatchCollection
>>>> initializes their self._paths in accordance to their given data.
>>>>
>>>
>>> One way to solve the problem would be to start each draw() method with a
>>> short-circuit return in case there is nothing to draw.  It would be needed
>>> only for classes for which empty self._paths is not a valid test.  So for
>>> CircleCollection it would be:
>>>
>>>    @allow_rasterization
>>>    def draw(self, renderer):
>>>        # sizes is the area of the circle circumscribing the polygon
>>>        # in points^2
>>>        if len(self._sizes) == 0:
>>>            return
>>>        self._transforms = [
>>>            transforms.Affine2D().scale(
>>>                (np.sqrt(x) * self.figure.dpi / 72.0) / np.sqrt(np.pi))
>>>            for x in self._sizes]
>>>        return Collection.draw(self, renderer)
>>>
>>> (Collection.draw returns nothing, so there is no inconsistency in the
>>> return value.)
>>>
>>> Alternatively, it looks like maybe an empty self._transforms could be
>>> used in a short-circuit test at the start of Collection.draw.
>>>
>>> Eric
>>>
>>>
>>>
>>>> Ben Root
>>>>
>>>>
>>>
>> That wouldn't completely solve the problem.  Affine transforms are being
>> done for get_datalim() as well.  The other issue (and I see that I mixed
>> this up myself) is the assumption elsewhere that a non-empty self._path
>> attribute means that there is something to plot.  This is an assumption that
>> is made in axes.py on line 1413 and it is an invalid assumption.
>>
>> As for your proposed solution in draw(), I prefer short-circuiting in
>> Collections.draw().  This makes for less work for new Collection subclasses.
>>
>> Ben Root
>>
>
>
> Working from an assumption that we can't possibly find all bad/broken
> assumptions in mpl, I decided to go the route of Eric and make the
> Collections object as robust as possible.  I have attached a patch that
> should enable empty scatter plots in matplotlib and enable empty Collections
> as well.
>
> This has not been fully tested yet.  Please be brutal!
>
> Ben Root
>
>
>
Heh, looks like that patch breaks the plotting of errorbars (the line
connecting the center point to the error caps is missing).

I will see about fixing that.

Ben Root

On 02/14/2011 08:32 PM, Benjamin Root wrote:
> On Mon, Feb 14, 2011 at 6:56 PM, Gökhan Sever <gok...@gm... 
> <mailto:gok...@gm...>> wrote:
>
>     python
>     Python 2.7 (r27:82500, Sep 16 2010, 18:02:00)
>     [GCC 4.5.1 20100907 (Red Hat 4.5.1-3)] on linux2
>     Type "help", "copyright", "credits" or "license" for more information.
>     >>> import matplotlib
>     >>> matplotlib.test()
>     Warning: divide by zero encountered in log
>     Warning: divide by zero encountered in log
>     Warning: divide by zero encountered in log
>     /home/gsever/Desktop/python-repo/matplotlib/lib/matplotlib/axes.py:2389:
>     UserWarning: Attempting to set identical left==right results
>     in singular transformations; automatically expanding.
>     left=730139.0, right=730139.0
>       + 'left=%s, right=%s') % (left, right))
>     ======================================================================
>     ERROR: Failure: IOError ([Errno 2] No such file or directory:
>     '/home/gsever/Desktop/python-repo/matplotlib/lib/matplotlib/tests/baseline_images/test_axes/canonical.png')
>     ----------------------------------------------------------------------
>     Traceback (most recent call last):
>       File
>     "/usr/lib/python2.7/site-packages/nose-1.0.0-py2.7.egg/nose/loader.py",
>     line 231, in generate
>         for test in g():
>       File
>     "/home/gsever/Desktop/python-repo/matplotlib/lib/matplotlib/testing/decorators.py",
>     line 91, in compare_images_generator
>         shutil.copyfile(src,dst)
>       File "/usr/lib64/python2.7/shutil.py", line 81, in copyfile
>         with open(src, 'rb') as fsrc:
>     IOError: [Errno 2] No such file or directory:
>     '/home/gsever/Desktop/python-repo/matplotlib/lib/matplotlib/tests/baseline_images/test_axes/canonical.png'
>
This test was added by John Hunter fairly recently.  I'll go ahead and 
commit the test results from my machine -- I assume they are correct 
since there's nothing special about the test.
>
>
>     ======================================================================
>     ERROR: make the basic nearest, bilinear and bicubic interps
>     ----------------------------------------------------------------------
>     Traceback (most recent call last):
>       File
>     "/usr/lib/python2.7/site-packages/nose-1.0.0-py2.7.egg/nose/case.py",
>     line 187, in runTest
>         self.test(*self.arg)
>       File
>     "/home/gsever/Desktop/python-repo/matplotlib/lib/matplotlib/testing/decorators.py",
>     line 32, in failer
>         result = f(*args, **kwargs)
>       File
>     "/home/gsever/Desktop/python-repo/matplotlib/lib/matplotlib/testing/decorators.py",
>     line 126, in decorated_compare_images
>         '(RMS %(rms).3f)'%err)
>     ImageComparisonFailure: images not close:
>     /home/gsever/Desktop/result_images/test_image/image_interps_pdf.png vs.
>     /home/gsever/Desktop/result_images/test_image/expected-image_interps_pdf.png
>     (RMS 281.963)
>
Both the png and svg versions of this test have been updated more 
recently than the pdf, so I suspect it's ok to update it.  I'll go ahead 
and do this.

Mike
>
>
>     ----------------------------------------------------------------------
>     Ran 152 tests in 71.340s
>
>     FAILED (KNOWNFAIL=46, errors=2)
>     False
>
>
>     -- 
>     Gökhan
>
>
> I have reported that first error a few months ago, and nobody has 
> commented on it.  I hope somebody knows what image that is supposed to 
> be for.
>
> The second error has popped up several times before, and we don't seem 
> to address it properly.  The difference between the expected and the 
> resulting images has a definite structure to it, suggesting that 
> something changed.  Either there is something wrong with the original 
> image, or there is something wrong with the current image.  If we 
> figure that the current image is correct, and that there was something 
> wrong with the previous image, then we should update the image in the 
> test suite.
>
> Ben Root
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>    


-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

On 02/16/2011 03:53 PM, John Hunter wrote:
> On Wed, Feb 16, 2011 at 2:47 PM, Michael Droettboom<md...@st...>  wrote:
>> Not sure Sourceforge allows custom hooks in SVN.
> We have a couple in place already
>
>
> https://sourceforge.net/project/admin/svn.php?group_id=80706
Yes.  But those aren't custom -- SF only provides a fixed set of scripts 
one can apply.  Notably, I don't think there's one that prevents further 
commits.

Mike

On Wed, Feb 16, 2011 at 2:47 PM, Michael Droettboom <md...@st...> wrote:
> Not sure Sourceforge allows custom hooks in SVN.

We have a couple in place already


https://sourceforge.net/project/admin/svn.php?group_id=80706

Not sure Sourceforge allows custom hooks in SVN.

Mike

On 02/16/2011 02:45 PM, Benjamin Root wrote:
> On Wed, Feb 16, 2011 at 1:30 PM, Sandro Tosi <mo...@de... 
> <mailto:mo...@de...>> wrote:
>
>     On Wed, Feb 16, 2011 at 19:57, John Hunter <jd...@gm...
>     <mailto:jd...@gm...>> wrote:
>     > On Wed, Feb 16, 2011 at 7:00 AM, Darren Dale <dsd...@gm...
>     <mailto:dsd...@gm...>> wrote:
>     >
>     >> John, could you freeze the svn repo around noon on Friday? I'll
>     >> convert the repositories and push them up to github on
>     Saturday. Is it
>     >> possible to close the sourceforge bugtracker, feature requests,
>     etc to
>     >> new issues as well?
>     >
>     > I did some poking around and do not see an easy way to freeze the
>     > repo.  I can disable it, but then I think it won't be available for
>     > read access.  One thing I could do is remove commit privs for every
>     > developer, making the repo read only going forward.  This seems
>     like a
>     > reasonable approach.
>
>     a pre-commit hook that just "exit 1" ? it prevents commits but not
>     checkouts.
>
>     Just my 2c,
>
>
> Even better, a pre-commit hook that also echos out a message stating 
> where to go.  And maybe a pre-update/pre-checkout hook that does 
> something similar?
>
> Ben Root
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Wed, Feb 16, 2011 at 1:30 PM, Sandro Tosi <mo...@de...> wrote:

> On Wed, Feb 16, 2011 at 19:57, John Hunter <jd...@gm...> wrote:
> > On Wed, Feb 16, 2011 at 7:00 AM, Darren Dale <dsd...@gm...> wrote:
> >
> >> John, could you freeze the svn repo around noon on Friday? I'll
> >> convert the repositories and push them up to github on Saturday. Is it
> >> possible to close the sourceforge bugtracker, feature requests, etc to
> >> new issues as well?
> >
> > I did some poking around and do not see an easy way to freeze the
> > repo.  I can disable it, but then I think it won't be available for
> > read access.  One thing I could do is remove commit privs for every
> > developer, making the repo read only going forward.  This seems like a
> > reasonable approach.
>
> a pre-commit hook that just "exit 1" ? it prevents commits but not
> checkouts.
>
> Just my 2c,
>

Even better, a pre-commit hook that also echos out a message stating where
to go.  And maybe a pre-update/pre-checkout hook that does something
similar?

Ben Root

On Wed, Feb 16, 2011 at 19:57, John Hunter <jd...@gm...> wrote:
> On Wed, Feb 16, 2011 at 7:00 AM, Darren Dale <dsd...@gm...> wrote:
>
>> John, could you freeze the svn repo around noon on Friday? I'll
>> convert the repositories and push them up to github on Saturday. Is it
>> possible to close the sourceforge bugtracker, feature requests, etc to
>> new issues as well?
>
> I did some poking around and do not see an easy way to freeze the
> repo.  I can disable it, but then I think it won't be available for
> read access.  One thing I could do is remove commit privs for every
> developer, making the repo read only going forward.  This seems like a
> reasonable approach.

a pre-commit hook that just "exit 1" ? it prevents commits but not checkouts.

Just my 2c,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi