Re: [Numpy-discussion] Development workflow

2010-10-11 Thread Joshua Holbrook 
On Mon, Oct 11, 2010 at 9:52 PM, Matthew Brett  wrote:
> Sorry - just re-reading that - it's a bit cryptic.  I mean, yes, I
> agree wholeheartedly that it's a shame to stick to svn workflows when
> using git.  I'm just some guy as well of course.   I suppose we
> just-some-guys should start an just-some-guys interest group or
> something ;)
>

"The Association of We're Just Saying Is All." :)  But yeah, I
understood your meaning.

--Josh

> Best,
>
> Matthew
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Development workflow

2010-10-11 Thread Matthew Brett 
Hi,

>> In my opinion, I've seen a lot of people coming from SVN try to apply
>> SVN-style workflow to git (and presumably other dvcs's), but git and
>> the like (and Github!) allow for much more fine-tuned workflows in my
>> opinion, and I think it's a mistake to ignore that. I'm just some guy,
>> though, so I'm not sure my opinion has much weight.
>
> Ah - yes - I know exactly what you mean ;)

Sorry - just re-reading that - it's a bit cryptic.  I mean, yes, I
agree wholeheartedly that it's a shame to stick to svn workflows when
using git.  I'm just some guy as well of course.   I suppose we
just-some-guys should start an just-some-guys interest group or
something ;)

Best,

Matthew
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Development workflow

2010-10-11 Thread Matthew Brett 
Hi,

> I find having the branch displayed on the command line helpful in avoiding
> mishaps, so I have the following in my .bashrc
>
> export PS1='\[\033[1;31m\]\$\[\033[0m\...@\h \W$(__git_ps1 " (%s)")\\$ '
>
> The \W$(__git_ps1 " (%s)") bit is the important part.

Yes, that one's a lifesaver.  It's part of the truly excellent
git-completion bash utilities too:

http://blog.strug.de/2010/08/how-to-add-git-completion-to-your-terminal/

See you,

Matthew
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Development workflow

2010-10-11 Thread Matthew Brett 
Hi,

> In my opinion, I've seen a lot of people coming from SVN try to apply
> SVN-style workflow to git (and presumably other dvcs's), but git and
> the like (and Github!) allow for much more fine-tuned workflows in my
> opinion, and I think it's a mistake to ignore that. I'm just some guy,
> though, so I'm not sure my opinion has much weight.

Ah - yes - I know exactly what you mean ;)

Best,

Matthew
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Commit rights on github

2010-10-11 Thread David 
On 10/12/2010 11:12 AM, Charles R Harris wrote:
>
>
> On Mon, Oct 11, 2010 at 7:31 PM, David  > wrote:
>
> On 10/12/2010 08:48 AM, Charles R Harris wrote:
>  >
>  >
>  > On Mon, Oct 11, 2010 at 5:09 PM, Pierre GM  
>  > >> wrote:
>  >
>  >
>  > On Oct 12, 2010, at 1:06 AM, Pauli Virtanen wrote:
>  >
>  > > Mon, 11 Oct 2010 23:30:31 +0200, Pierre GM wrote:
>  > >> Would any of you mind giving me commit rights on github? My
>  > handle is
>  > >> pierregm. Thanks a million in advance.
>  > >
>  > > Granted.
>  >
>  > Got it, thanks again!
>  >
>  >
>  > Umm, I think your first commit changed a lot more than you intended.
>
> Indeed. Pierre, please revert this commit, and then commit what you
> intended:
>
> git revert   # will revert
> all your changes
> git cherry-pick -n 61d945bdb5c9b2b3329e1b8468b5c7d0596dd9fc # apply the
> changes introduced by 61d945..., but do not commit
>
> Then, check that you don't add unnecessary files (eclipse files) before
> committing again. A good way to check what you are about to commit is to
> do git diff --stat --cached,
>
>
> I can't quite figure out what commit a14dd542532d383610c1
> 
> did or where it applied. Any hints?

It is a merge commit:

"""
commit a14dd542532d383610c1b01c5698b137dd058fea
Merge: 61d945b 11ee694
Author: pierregm 
Date:   Mon Oct 11 23:02:10 2010 +0200

 merging refs/remotes/origin/master into HEAD
"""

You can see that it has two parents (61d945b and 11ee694). 61d945b is 
another commit by PGM, whereas 11ee694 refers to the last "clean" commit 
by Pauli. For example, you can see this using the --graph option of git log:

*   commit a14dd542532d383610c1b01c5698b137dd058fea
|\  Merge: 61d945b 11ee694
| | Author: pierregm 
| | Date:   Mon Oct 11 23:02:10 2010 +0200
| |
| | merging refs/remotes/origin/master into HEAD
| |
| * commit 11ee694744f2552d77652ed929fdc2b4ccca6843
| | Author: Pauli Virtanen 
| | Date:   Mon Oct 11 00:40:13 2010 +0200
| |

...
| * commit 4510c4a81185eed7e144f75ec5121f80bc924a6e
| | Author: Pauli Virtanen 
| | Date:   Fri Oct 1 11:15:38 2010 +0200
| |
| | sphinxext: fix Other Parameters section parsing in docscrape
| |
* | commit 61d945bdb5c9b2b3329e1b8468b5c7d0596dd9fc
|/  Author: pierregm 
|   Date:   Mon Oct 11 22:24:26 2010 +0200
|
|   Add more tests to test_eq_w_None (bug #1493)


So by doing:

git revert a14dd542532d383610c1b01c5698b137dd058fea -m 2

You are telling git to revert to its second parent (here 11ee6947). I 
don't know exactly what PGM did, maybe he mistakenly "unmerge" all the 
changes made from 61d945 and commit this.

In that case, a way to avoid this mistake is to do the following:

   * make changes on your own git repository clone
   * once you have a set of changesets of commits, first update your 
branch from upstream (a bit like svn up) with git pull: at that point, 
git will try to merge your changes and upstream changes if there are 
divergences. You could also use the --rebase option of git pull, with 
the usual rebase caveats w.r.t. changes

See here for a relatively clear explanation: 
http://yehudakatz.com/2010/05/13/common-git-workflows/, "Updating from 
the remote" section,

cheers,

David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Commit rights on github

2010-10-11 Thread Charles R Harris 
On Mon, Oct 11, 2010 at 7:31 PM, David  wrote:

> On 10/12/2010 08:48 AM, Charles R Harris wrote:
> >
> >
> > On Mon, Oct 11, 2010 at 5:09 PM, Pierre GM  > > wrote:
> >
> >
> > On Oct 12, 2010, at 1:06 AM, Pauli Virtanen wrote:
> >
> >  > Mon, 11 Oct 2010 23:30:31 +0200, Pierre GM wrote:
> >  >> Would any of you mind giving me commit rights on github? My
> > handle is
> >  >> pierregm. Thanks a million in advance.
> >  >
> >  > Granted.
> >
> > Got it, thanks again!
> >
> >
> > Umm, I think your first commit changed a lot more than you intended.
>
> Indeed. Pierre, please revert this commit, and then commit what you
> intended:
>
> git revert a14dd542532d383610c1b01c5698b137dd058fea -m 2 # will revert
> all your changes
> git cherry-pick -n 61d945bdb5c9b2b3329e1b8468b5c7d0596dd9fc # apply the
> changes introduced by 61d945..., but do not commit
>
> Then, check that you don't add unnecessary files (eclipse files) before
> committing again. A good way to check what you are about to commit is to
> do git diff --stat --cached,
>
>
I can't quite figure out what commit
a14dd542532d383610c1did
or where it applied. Any hints?

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Commit rights on github

2010-10-11 Thread David 
On 10/12/2010 08:48 AM, Charles R Harris wrote:
>
>
> On Mon, Oct 11, 2010 at 5:09 PM, Pierre GM  > wrote:
>
>
> On Oct 12, 2010, at 1:06 AM, Pauli Virtanen wrote:
>
>  > Mon, 11 Oct 2010 23:30:31 +0200, Pierre GM wrote:
>  >> Would any of you mind giving me commit rights on github? My
> handle is
>  >> pierregm. Thanks a million in advance.
>  >
>  > Granted.
>
> Got it, thanks again!
>
>
> Umm, I think your first commit changed a lot more than you intended.

Indeed. Pierre, please revert this commit, and then commit what you 
intended:

git revert a14dd542532d383610c1b01c5698b137dd058fea -m 2 # will revert 
all your changes
git cherry-pick -n 61d945bdb5c9b2b3329e1b8468b5c7d0596dd9fc # apply the 
changes introduced by 61d945..., but do not commit

Then, check that you don't add unnecessary files (eclipse files) before 
committing again. A good way to check what you are about to commit is to 
do git diff --stat --cached,

cheers,

David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] equality of empty arrays

2010-10-11 Thread Benjamin Root 
On Mon, Oct 11, 2010 at 7:58 PM, Vincent Davis wrote:

> On Mon, Oct 11, 2010 at 6:06 PM, Ian Goodfellow
>  wrote:
> > The reasoning behind this is that == returns an array that specifies
> > whether each element of the two arrays is equal. It's only defined if
> > the arrays are the same shape (or maybe if they can be broadcasted to
> > the same shape).
>
> >>> m.size==n.size
> True
> >>> m.shape==n.shape
> True
> Not sure about "be broadcasted to the same shape"
> I would kind of expect == to return true, false or some error.
>
> Thanks
> Vincent
>
>
Maybe you are looking for numpy.allclose()?

>>> n = np.array([])
>>> m = np.array([])
>>> np.allclose(n, m)
True


Ben Root
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] inversion of large matrices

2010-10-11 Thread Daniel Elliott 
Sturla Molden  molden.no> writes:

> > Yes, this is what I am computing.  I am computing the pdf of a very high-
> > dimensional multivariate normal.  Is there a specialized method to compute
> > this?
> 
> If you use cho_solve and cho_factor from scipy.linalg, you can proceed
> like this:
> 
>   cx = X - m
>   sqmahal = (cx*cho_solve(cho_factor(S),cx.T).T).sum(axis=1)
> 
> where X is the data (n x p), m is mean (1 x p) and S is the covariance (p
> x p).
> 
> We could do this twice as fast using a hypothetical method tri_solve that
> calls LAPACK subroutine DTRTRS.

Sorry for the laziness of this question...

As a reminder, I am working with high-dimensional data (10K dimensions).  I was 
computing the log of the MVN pdf because the probabilities would almost all go 
to zero.

Do you suppose the method you have shown me will be numerically stable (the 
probabilities will be small but they stay above zero)?

By the way, I would be happy to implement the method you desire in a couple 
months if you are willing to do a little hand-holding.

Thanks for the excellent suggestion.

- dan



___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] equality of empty arrays

2010-10-11 Thread Ian Goodfellow 
If the arrays are the same size or can be broadcasted to the same  
size, it returns true or false on an elementwise basis.
If the arrays are not the same size and can't be broadcasted to the  
same size, it returns False, which was a surprise to me too.

 >>> import numpy as N
 >>> N.asarray([[0,1],[2,3]]) == N.asarray([[1,1],[3,3]])
array([[False,  True],
[False,  True]], dtype=bool)
 >>> N.asarray([[0,1],[2,3]]) == N.asarray([[1,1]])
array([[False,  True],
[False, False]], dtype=bool)
 >>> N.asarray([[0,1],[2,3]]) == N.asarray([[1,1],[3,3],[5,5]])
False


On Oct 11, 2010, at 8:58 PM, Vincent Davis wrote:

> Not sure about "be broadcasted to the same shape"
> I would kind of expect == to return true, false or some error.

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numpy.distutils

2010-10-11 Thread David 
On 10/12/2010 03:39 AM, Charles Doutriaux wrote:
>   Hi David,
>
> The behaviour is there in regular distutils, it is apparently a known
> bug, I'm copy/pasting their answer in there for information.

I saw the discussion, thanks for the update.

cheers,

David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] equality of empty arrays

2010-10-11 Thread Vincent Davis 
On Mon, Oct 11, 2010 at 6:06 PM, Ian Goodfellow
 wrote:
> The reasoning behind this is that == returns an array that specifies
> whether each element of the two arrays is equal. It's only defined if
> the arrays are the same shape (or maybe if they can be broadcasted to
> the same shape).

>>> m.size==n.size
True
>>> m.shape==n.shape
True
Not sure about "be broadcasted to the same shape"
I would kind of expect == to return true, false or some error.

Thanks
Vincent

> The correct way to check if an array is empty is to inspect its .shape
> field.
>
> On Oct 11, 2010, at 8:03 PM, Vincent Davis wrote:
>
>> I assume there is some reasoning behind this
> m = np.array([])
> n = np.array([])
> m==n
>> array([], dtype=bool)
>>
>> I was expecting somthing like.
> m = []
> n = []
> m==n
>> True
>>
>> What is the right way to test if an array is empty?
>>
>> --
>> Thanks
>> Vincent Davis
>> 720-301-3003
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>



-- 
Thanks
Vincent Davis
720-301-3003
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Development workflow

2010-10-11 Thread Charles R Harris 
On Mon, Oct 11, 2010 at 5:56 PM, Joshua Holbrook wrote:

> In projects I've worked on, most people have worked on their own
> repos, continually merging in changes from other repos to keep
> themselves current. I think this is generally a good approach for
> development, if a bit disorganized. In addition, obviously a group of
> people pushing to numpy/numpy is necessary. I would suggest core devs
> keeping numpy/numpy's development branch as "deployed" code, while
> starting new development on their own branches and merging them in as
> they see fit.  Non-core developers can contribute by sending pull
> requests.
>
> In my opinion, I've seen a lot of people coming from SVN try to apply
> SVN-style workflow to git (and presumably other dvcs's), but git and
> the like (and Github!) allow for much more fine-tuned workflows in my
> opinion, and I think it's a mistake to ignore that. I'm just some guy,
> though, so I'm not sure my opinion has much weight.
>
>
I find having the branch displayed on the command line helpful in avoiding
mishaps, so I have the following in my .bashrc

export PS1='\[\033[1;31m\]\$\[\033[0m\...@\h \W$(__git_ps1 " (%s)")\\$ '

The \W$(__git_ps1 " (%s)") bit is the important part.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] equality of empty arrays

2010-10-11 Thread Thomas, Brian (GE Energy) 
I am pretty new user, but I tend to use shape (n.shape) to check empty
array. You can even check n.size to determine if its empty or not.

Regards,
Brian 

-Original Message-
From: numpy-discussion-boun...@scipy.org
[mailto:numpy-discussion-boun...@scipy.org] On Behalf Of Vincent Davis
Sent: Monday, October 11, 2010 8:03 PM
To: Discussion of Numerical Python
Subject: [Numpy-discussion] equality of empty arrays

I assume there is some reasoning behind this
>>> m = np.array([])
>>> n = np.array([])
>>> m==n
array([], dtype=bool)

I was expecting somthing like.
>>> m = []
>>> n = []
>>> m==n
True

What is the right way to test if an array is empty?

--
Thanks
Vincent Davis
720-301-3003
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] equality of empty arrays

2010-10-11 Thread josef . pktd 
On Mon, Oct 11, 2010 at 8:06 PM, Ian Goodfellow
 wrote:
> The reasoning behind this is that == returns an array that specifies
> whether each element of the two arrays is equal. It's only defined if
> the arrays are the same shape (or maybe if they can be broadcasted to
> the same shape).
> The correct way to check if an array is empty is to inspect its .shape
> field.
>
> On Oct 11, 2010, at 8:03 PM, Vincent Davis wrote:
>
>> I assume there is some reasoning behind this
> m = np.array([])
> n = np.array([])
> m==n
>> array([], dtype=bool)
>>
>> I was expecting somthing like.
> m = []
> n = []
> m==n
>> True
>>
>> What is the right way to test if an array is empty?

>>> np.array([]).size
0

Josef
>>
>> --
>> Thanks
>> Vincent Davis
>> 720-301-3003
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] equality of empty arrays

2010-10-11 Thread Ian Goodfellow 
The reasoning behind this is that == returns an array that specifies  
whether each element of the two arrays is equal. It's only defined if  
the arrays are the same shape (or maybe if they can be broadcasted to  
the same shape).
The correct way to check if an array is empty is to inspect its .shape  
field.

On Oct 11, 2010, at 8:03 PM, Vincent Davis wrote:

> I assume there is some reasoning behind this
 m = np.array([])
 n = np.array([])
 m==n
> array([], dtype=bool)
>
> I was expecting somthing like.
 m = []
 n = []
 m==n
> True
>
> What is the right way to test if an array is empty?
>
> -- 
> Thanks
> Vincent Davis
> 720-301-3003
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] equality of empty arrays

2010-10-11 Thread Vincent Davis 
I assume there is some reasoning behind this
>>> m = np.array([])
>>> n = np.array([])
>>> m==n
array([], dtype=bool)

I was expecting somthing like.
>>> m = []
>>> n = []
>>> m==n
True

What is the right way to test if an array is empty?

-- 
Thanks
Vincent Davis
720-301-3003
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Development workflow

2010-10-11 Thread Joshua Holbrook 
In projects I've worked on, most people have worked on their own
repos, continually merging in changes from other repos to keep
themselves current. I think this is generally a good approach for
development, if a bit disorganized. In addition, obviously a group of
people pushing to numpy/numpy is necessary. I would suggest core devs
keeping numpy/numpy's development branch as "deployed" code, while
starting new development on their own branches and merging them in as
they see fit.  Non-core developers can contribute by sending pull
requests.

In my opinion, I've seen a lot of people coming from SVN try to apply
SVN-style workflow to git (and presumably other dvcs's), but git and
the like (and Github!) allow for much more fine-tuned workflows in my
opinion, and I think it's a mistake to ignore that. I'm just some guy,
though, so I'm not sure my opinion has much weight.

--Josh

On Mon, Oct 11, 2010 at 3:47 PM, Matthew Brett  wrote:
> Hi guys,
>
> Am I right in thinking that for the moment at least, the git workflow
> is basically the same as the svn workflow (everyone commiting to
> trunk)?
>
> I realize that this is not going to cheer anyone up, but is this the
> best workflow now?   Who would decide?
>
> Best,
>
> Matthew
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Commit rights on github

2010-10-11 Thread Charles R Harris 
On Mon, Oct 11, 2010 at 5:09 PM, Pierre GM  wrote:

>
> On Oct 12, 2010, at 1:06 AM, Pauli Virtanen wrote:
>
> > Mon, 11 Oct 2010 23:30:31 +0200, Pierre GM wrote:
> >> Would any of you mind giving me commit rights on github? My handle is
> >> pierregm. Thanks a million in advance.
> >
> > Granted.
>
> Got it, thanks again!
>

Umm, I think your first commit changed a lot more than you intended.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Development workflow

2010-10-11 Thread Matthew Brett 
Hi guys,

Am I right in thinking that for the moment at least, the git workflow
is basically the same as the svn workflow (everyone commiting to
trunk)?

I realize that this is not going to cheer anyone up, but is this the
best workflow now?   Who would decide?

Best,

Matthew
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Commit rights on github

2010-10-11 Thread Pierre GM 

On Oct 12, 2010, at 1:06 AM, Pauli Virtanen wrote:

> Mon, 11 Oct 2010 23:30:31 +0200, Pierre GM wrote:
>> Would any of you mind giving me commit rights on github? My handle is
>> pierregm. Thanks a million in advance.
> 
> Granted.

Got it, thanks again!
P.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Commit rights on github

2010-10-11 Thread Pauli Virtanen 
Mon, 11 Oct 2010 23:30:31 +0200, Pierre GM wrote:
> Would any of you mind giving me commit rights on github? My handle is
> pierregm. Thanks a million in advance.

Granted.

Cheers,
Pauli

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Awaiting confirmation before closing tickets

2010-10-11 Thread Pierre GM 
All,
The following tickets could be closed if somebody confirmed everything works OK:
* 1586: fixed in r8714
* 1593: fixed in r8715
* 1591: fixed in r8713
* 1493: fixed a while ago (sorry, I completely forgot to comment on it).
Let me know how it goes and I'll close them. Or not.
Thanks in advance
P.

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Commit rights on github

2010-10-11 Thread Pierre GM 
All,
Would any of you mind giving me commit rights on github? My handle is pierregm. 
Thanks a million in advance.
P.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numpy.distutils

2010-10-11 Thread Charles Doutriaux 
 Hi David,

The behaviour is there in regular distutils, it is apparently a known
bug, I'm copy/pasting their answer in there for information.

thanks,

C.


Answer (from Tarek Ziade):

This is a regression I introduced to fix the fact that the .so are not
rebuilt we you do subtle changes in your project.

We ended up reverting this, and the changes will be done in
Distutils2. see: http://BLOCKEDbugs.python.org/issue8688 for the details.





>


On 10/7/10 9:39 PM, David Cournapeau wrote:
> On Fri, Oct 8, 2010 at 7:40 AM, Charles Doutriaux  wrote:
>
>> Did anybody else noticed this? Anybody know what changed (the fact that
>> it's since Python 2.7 make me think it might be pure distutils related)
> Could you check whether you still see the issue without using
> numpy.distutils ? I actually would be surprised to see it as a
> distutils issue proper, as somebody would have almost certainly
> noticed it already.
>
>> Any insight on how distuils and numpy.distutils are related would be
>> great too!
> numpy.distutils uses distutils, but in an unconvential way, because it
> needs to hook itself to internals. Hence, any non trivial change (and
> even trivial, sometimes) can break numpy.distutils.
>
> cheers,
>
> David
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://BLOCKEDmail.scipy.org/mailman/listinfo/numpy-discussion
>

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] help from OS X 10.5 users wanted

2010-10-11 Thread Vincent Davis 
On Mon, Oct 11, 2010 at 7:34 AM, Ralf Gommers
 wrote:
> Hi Friedrich,
>
> On Mon, Oct 11, 2010 at 2:46 AM, Friedrich Romstedt
>  wrote:
>>
>> 2010/10/9 Vincent Davis :
>> > Did you get any responses on this? I can install 10.5 and help out
>> > with some testing. I have a macbookpro that does not turn of (Hardware
>> > issue) but it is good for testing. I could setup remote access on this
>> > if of interest to you.
>>
>> I can also help with the installer
>
> That would be very helpful, thanks. Please keep me up to date on your
> progress with the 10.5 license, and once you are set up we can coordinate
> building the binaries.
>
>>
>> - I have some (some) experience
>> with building Mac OS X installers using the PackageMaker provided by
>> Apple.  Just lacking a 10.5.  But since I need some anyway (for
>> controlling a 10.5 server), Vincent, if you don't need your 10.5
>> anymore, can we transfer the license in some way from you to me?  I'm
>> serious, one cannot buy 10.5 from Apple anymore, and I need a legal
>> license.  I have 10.6 and a VMware Fusion v3.
>>
>> When anyone can inform me how the installation scheme for numpy
>> binaries is I can then provide the installers, I believe.
>
> The toolchain you need is documented at
> http://projects.scipy.org/numpy/wiki/MakingReleases. If you have all the
> dependencies it's simply a matter of
>   $ paver dmg -p 2.5   (or 2.6/7)
> and a dmg installer is built.

Is there any reason 10.5 server addition would not work for building release ?
Friedrich, you can't just install 10.5 (non server) on vmware. I just
tried, It responds This is not a server addition. There are hacks
but...

I'll try to do a few testes this week., Where does
"numpy-macosx-installer "
http://github.com/cournape/numpy-macosx-installer fit in to running
this command. "paver dmg -p 2.5" or does it? I have installed from
source many times but never built a dmg.
Is there any interest in a current Dev snapshot dmg?
And how about a numpy scipy combo dmg?

A little bit of a separate issue, does the build bot  or so,ething/one
other than developers run numpy.test() to monitor test that may fail
on different systems, as numpy scipy, python get updated. It seems
like a bot could build everything from source weekly and commit a test
log via git/github  to monitor and record the condition and changes in
tests. Maybe there is no point to this, just sound like a neat way to
track test results.

Vincent Davis
720-301-3003


>
>>
>> I strongly
>> support 10.5 support, I believe we should support at least the next to
>> last version.
>>
>> For my own installer for upy, I followed the route: Unpacking the
>> package into some /private/var/tmp directory, and running setup.py
>> install there (since we are root when installing).  upy is pure
>> Python, no compilation.  I see so far three routes for numpy: a) just
>> installing the precompiled binaries using a setup.py file, b)
>> compiling in the background for the user (shouldn't be a problem on
>> Mac OS X, and would give us opportunity to include support for
>> complementary packages in a "binary installer".  Tough it wouldn't be
>> really binary anymore.)  c) Hardcoding the /Frameworks/ directory and
>> simply copying.
>>
> The way it works is (c), so for the binaries the installers from python.org
> are the one we build against. The dmg contains an mpkg plus built docs. Of
> your other options, (a) would be similar only less user-friendly, (b) is a
> very bad idea.
>
> Cheers,
> Ralf
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>



-- 
Thanks
Vincent Davis
720-301-3003
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] help from OS X 10.5 users wanted

2010-10-11 Thread Ralf Gommers 
Hi Friedrich,

On Mon, Oct 11, 2010 at 2:46 AM, Friedrich Romstedt <
friedrichromst...@gmail.com> wrote:

> 2010/10/9 Vincent Davis :
> > Did you get any responses on this? I can install 10.5 and help out
> > with some testing. I have a macbookpro that does not turn of (Hardware
> > issue) but it is good for testing. I could setup remote access on this
> > if of interest to you.
>
> I can also help with the installer


That would be very helpful, thanks. Please keep me up to date on your
progress with the 10.5 license, and once you are set up we can coordinate
building the binaries.


> - I have some (some) experience
> with building Mac OS X installers using the PackageMaker provided by
> Apple.  Just lacking a 10.5.  But since I need some anyway (for
> controlling a 10.5 server), Vincent, if you don't need your 10.5
> anymore, can we transfer the license in some way from you to me?  I'm
> serious, one cannot buy 10.5 from Apple anymore, and I need a legal
> license.  I have 10.6 and a VMware Fusion v3.
>
> When anyone can inform me how the installation scheme for numpy
> binaries is I can then provide the installers, I believe.


The toolchain you need is documented at
http://projects.scipy.org/numpy/wiki/MakingReleases. If you have all the
dependencies it's simply a matter of
  $ paver dmg -p 2.5   (or 2.6/7)
and a dmg installer is built.


> I strongly
> support 10.5 support, I believe we should support at least the next to
> last version.
>

> For my own installer for upy, I followed the route: Unpacking the
> package into some /private/var/tmp directory, and running setup.py
> install there (since we are root when installing).  upy is pure
> Python, no compilation.  I see so far three routes for numpy: a) just
> installing the precompiled binaries using a setup.py file, b)
> compiling in the background for the user (shouldn't be a problem on
> Mac OS X, and would give us opportunity to include support for
> complementary packages in a "binary installer".  Tough it wouldn't be
> really binary anymore.)  c) Hardcoding the /Frameworks/ directory and
> simply copying.
>
> The way it works is (c), so for the binaries the installers from
python.org are the one we build against. The dmg contains an mpkg plus built
docs. Of your other options, (a) would be similar only less user-friendly,
(b) is a very bad idea.

Cheers,
Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] PyArg_ParseTuple

2010-10-11 Thread Pauli Virtanen 
Mon, 11 Oct 2010 13:03:56 +0300, Ioan Ferencik wrote:
> I  would like to aks where can I find more detaile dinfo on
> PyArg_ParseTuple function.

This is off-topic for this list.

See docs.python.org or ask on the Python lists:

http://python.org/community/lists/

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] PyArg_ParseTuple

2010-10-11 Thread Ioan Ferencik 
I  would like to aks where can I find more detaile dinfo on  
PyArg_ParseTuple function.

I find the doc limited on the matter.
Mainly I am curious why the function requires an address of a pointer.

I have issues in the following case:
in python
int jmax = 16

print type(jmax)



which is just all right
  but following C code seems to be working
PyObject *jmax_o = NULL;

if(!PyArg_ParseTuple(args, "i", &jmax_o)){
goto error;
}

but PyInt_Check(jmax_o) fails.

I tried to debug and this is what i could see

Program received signal SIGSEGV, Segmentation fault.
0x767a75bd in fprintf (self=, args=(16,))  
at /usr/include/bits/stdio2.h:98
98return __fprintf_chk (__stream, __USE_FORTIFY_LEVEL - 1, __fmt,

so for some reason the jmax_o can not be converted to int.

I use a x86_64 ubuntu and i suspect it could be because of 64 bits arch.

Cheers







Ioan Ferencik
PhD student
Aalto University
School of Science and Technology
Faculty Of Civil and Env. Engineering
Lahti Center
Tel: +358505122707


___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion