Travis E. Oliphant wrote:
> David M. Cooke wrote:
>> On Jan 4, 2008, at 13:58 , Fernando Perez wrote:
>>
>>
>>> My vote so far is for hg, for performance reasons but also partly
>>> because sage and sympy already use it, two projects I'm likely to
>>> interact a lot with and that are squarely in
David Cournapeau wrote:
>> 4) SVN is very, very, popular. Lots of folks use it, they use it on all
>> common platforms, and there are tons of clients for it. I work with a
>> bunch of folks that really don't like a command line (for programmers, I
>> think that's just plain weird, but there you go)
David Cournapeau wrote:
> On Jan 5, 2008 4:38 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
>> It's worth noting that SVN 1.5 will be tracking such information. But that
>> release is a long ways off.
>>
> My understanding, but I do not follow svn much, is that in 1.5, you
> will only get what svnmer
On Jan 5, 2008 4:38 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> Chris Barker wrote:
> > hmmm. Everyone posting so far seems to be positive on this idea, but I'm
> > not so sure. A few thoughts:
> >
> > 1) change is bad. It may be worth it, but this decision needs to be made
> > very differently th
On Jan 5, 2008 4:21 PM, Chris Barker <[EMAIL PROTECTED]> wrote:
> hmmm. Everyone posting so far seems to be positive on this idea, but I'm
> not so sure. A few thoughts:
>
> 1) change is bad. It may be worth it, but this decision needs to be made
> very differently than if we were starting from scr
Fernando Perez gmail.com> writes:
> Incidentally, the emacs guys seem to be worrying about the same thing:
>
> http://thread.gmane.org/gmane.emacs.devel/85893
>
> If they actually do the work of comparing tools, that work may be
> useful for us. I'm pretty sure that any tool that can handle the
>
Hi Pierre
On Fri, Jan 04, 2008 at 04:30:47PM -0500, Pierre GM wrote:
> Here's a patch to the current version of svn/numpy/branches/maskedarray, that
> corrects several bugs.
Those tests at the end of core.py should be included in the test suite
before we commit (otherwise they won't be ran by nu
Bill Baxter wrote:
> On Jan 6, 2008 8:25 AM, Stefan van der Walt <[EMAIL PROTECTED]> wrote:
>> I recall something you said to David last week, regarding merges with
>> SVN: that a person never knows how to do it until *after* you've done
>> it! We often make branches in scipy and numpy, and stand
On Jan 6, 2008 12:55 AM, Bill Baxter <[EMAIL PROTECTED]> wrote:
> On Jan 6, 2008 8:25 AM, Stefan van der Walt <[EMAIL PROTECTED]> wrote:
> > I recall something you said to David last week, regarding merges with
> > SVN: that a person never knows how to do it until *after* you've done
> > it! We of
On Jan 6, 2008 8:25 AM, Stefan van der Walt <[EMAIL PROTECTED]> wrote:
> I recall something you said to David last week, regarding merges with
> SVN: that a person never knows how to do it until *after* you've done
> it! We often make branches in scipy and numpy, and stand a lot to
> gain from a d
I'd like to briefly provide a different perspective on this question,
which is not a technical one but a more social/process one.
It seems to me (but I could be wrong; this is opinion, not research!)
that a DVCS encourages a more open participation model for newcomers.
Since anyone with a checkout
On Sat, Jan 05, 2008 at 03:00:21PM -0600, Travis E. Oliphant wrote:
> I suspect there are others with serious reservations about jumping off
> of SVN just now (just when a lot of people have finally figured out how
> to use it).
I recall something you said to David last week, regarding merges wi
> This is the behaviour you'd get if the module's __all__ attribute
> lists objects which don't exist in the module. Looks like a regression
> in r4659; fixed in SVN now as r4674.
Thanks!
-steve
___
Numpy-discussion mailing list
Numpy-discussion@scipy.o
David M. Cooke wrote:
> On Jan 4, 2008, at 13:58 , Fernando Perez wrote:
>
>
>> My vote so far is for hg, for performance reasons but also partly
>> because sage and sympy already use it, two projects I'm likely to
>> interact a lot with and that are squarely in line with the
>> ipython/numpy/sc
On Jan 5, 2008 8:15 PM, Fernando Perez <[EMAIL PROTECTED]> wrote:
> On Jan 5, 2008 12:08 PM, David M. Cooke <[EMAIL PROTECTED]> wrote:
> > On Jan 4, 2008, at 13:58 , Fernando Perez wrote:
> >
> > > My vote so far is for hg, for performance reasons but also partly
> > > because sage and sympy alread
On Jan 5, 2008 12:08 PM, David M. Cooke <[EMAIL PROTECTED]> wrote:
> On Jan 4, 2008, at 13:58 , Fernando Perez wrote:
>
> > My vote so far is for hg, for performance reasons but also partly
> > because sage and sympy already use it, two projects I'm likely to
> > interact a lot with and that are sq
On Jan 4, 2008, at 13:58 , Fernando Perez wrote:
> My vote so far is for hg, for performance reasons but also partly
> because sage and sympy already use it, two projects I'm likely to
> interact a lot with and that are squarely in line with the
> ipython/numpy/scipy/matplotlib world. Since they
On Jan 3, 2008, at 18:29 , Steve Lianoglou wrote:
>
> Anyway, somewhere in my codebase (for a long time now) I'm doing:
>
> from numpy.matlib import *
>
> Now, when I try to use this code, or just type that in the
> interpreter, I get this message:
>
> AttributeError: 'module' object has no attribu
> There are two related hierarchies of datatypes: different kinds
> (integer,
> floating point, complex floating point) and different precisions
> within a given
> kind (int8, int16, int32, int64). The term "downcasting" should
> probably be
> reserved for the latter only.
>
> It seems to me
>> I wasn't at all arguing that having complex data chopped and
>> downcast into an int or float container was the right thing to do.
>
> indeed, it is an clearly bad thing to do -- but a bug magnet? I'm not so
> sure, surely, anyone that had any idea at all what they were doing with
> complex numb
20 matches
Mail list logo
