David Warde-Farley | 1 May 06:17
Picon
Favicon
Gravatar

Re: Matlab Control System Toolbox for Python / SciPy


On 30-Apr-09, at 12:07 AM, Luke wrote:

> Does anybody know of any projects that aim to implement much of the
> functionality of the control system toolbox in Matlab?  There is a
> control system toolbox for Octave, with what looks like a large amount
> of similar tools, but I haven't really found anything for Python.
>
> Is anybody out there interested in using and/or developing such a  
> set of tools?

This has come up before:

http://mail.scipy.org/pipermail/scipy-dev/2005-April/002948.html
http://mail.scipy.org/pipermail/scipy-user/2008-January/thread.html#15059
http://mail.scipy.org/pipermail/scipy-user/2008-March/thread.html#15729

Cheers,

David
Skipper Seabold | 1 May 06:26
Picon

Re: How to handle code contribution with GSoC students ?

2009/4/29 Stéfan van der Walt <stefan <at> sun.ac.za>:
> 2009/4/29 David Cournapeau <david <at> ar.media.kyoto-u.ac.jp>:
>>    I was wondering about the best way to handle code by students for
>> the upcoming GSoC. The year I participated, I already had write access,
>> so the question did not come up. I think I would prefer starting with
>> code reviews, before giving them svn write access later. Do people have
>> better suggestions ?
>
> It's a good time to learn about distributed revision control :)  So
> yes, let's have review branches.
>
> Cheers
> Stéfan

Then will we need SVN write access at some point I guess.  Also
wondering if I might be given edit rights for the docs wiki to work on
scipy.stats for a start.  My registered user name is jseabold.

Skipper
Gael Varoquaux | 1 May 09:40
Favicon
Gravatar

Re: How to handle code contribution with GSoC students ?

On Fri, May 01, 2009 at 12:26:29AM -0400, Skipper Seabold wrote:
> Also wondering if I might be given edit rights for the docs wiki to
> work on scipy.stats for a start.  My registered user name is jseabold.

Sure thing. Done!

Gaël
Pierre GM | 1 May 10:03
Picon

Re: How to handle code contribution with GSoC students ?


On Apr 29, 2009, at 10:44 AM, Stéfan van der Walt wrote:

> 2009/4/29 David Cournapeau <david <at> ar.media.kyoto-u.ac.jp>:
>>    I was wondering about the best way to handle code by students for
>> the upcoming GSoC. The year I participated, I already had write  
>> access,
>> so the question did not come up. I think I would prefer starting with
>> code reviews, before giving them svn write access later. Do people  
>> have
>> better suggestions ?
>
> It's a good time to learn about distributed revision control :)  So
> yes, let's have review branches.

A whole branch for modifications to only one specific submodule ?  
Isn't it a bit too much (OK, I must admit that I'm not particularly  
familiar with the details of "distributed revision cntrol"). Wouldn't  
it be simpler to have something on git/mercurial/bazaar/whatever-is- 
recommended-by-the-community-at-large ? Which would simplifying  
reviewing and avoid potential mess ?
But once again, I don't know much about versioning...
David Cournapeau | 1 May 10:06
Picon
Picon

Re: How to handle code contribution with GSoC students ?

Pierre GM wrote:
> On Apr 29, 2009, at 10:44 AM, Stéfan van der Walt wrote:
>
>   
>> 2009/4/29 David Cournapeau <david <at> ar.media.kyoto-u.ac.jp>:
>>     
>>>    I was wondering about the best way to handle code by students for
>>> the upcoming GSoC. The year I participated, I already had write  
>>> access,
>>> so the question did not come up. I think I would prefer starting with
>>> code reviews, before giving them svn write access later. Do people  
>>> have
>>> better suggestions ?
>>>       
>> It's a good time to learn about distributed revision control :)  So
>> yes, let's have review branches.
>>     
>
> A whole branch for modifications to only one specific submodule ?
>   

One possibility is to have one sandbox / student, the student would only
commit in the sandbox, and the mentor would be responsible for merging
it into the trunk. The advantage of this technique is that the mentor
can do all the work if desired (updating the branch from the trunk,
merging, etc...).

Using something like git, bzr or hg is easier for the mentor, but this
assumes the student knows how to use them. I am not sure I want to
bother students with new tools if they don't know them - getting
(Continue reading)

Aahz | 1 May 13:10

Python goes Mercurial (was Re: How to handle code contribution with GSoC students?)

On Fri, May 01, 2009, David Cournapeau wrote:
>
> Using something like git, bzr or hg is easier for the mentor, but this
> assumes the student knows how to use them. I am not sure I want to
> bother students with new tools if they don't know them - getting
> familiar with the scipy code, how to build, run and test it is already
> enough as a barrier of entry.

AFAICT from skimming Subject: lines in the archives, it hasn't yet been
mentioned that the Python project itself is switching to Mercurial:

http://www.python.org/dev/peps/pep-0374/

(This isn't particularly relevant to GSoC, but it's something to keep an
eye on if you want to maintain tool compatibility with core Python.)
--

-- 
Aahz (aahz <at> pythoncraft.com)           <*>         http://www.pythoncraft.com/

"Typing is cheap.  Thinking is expensive."  --Roy Smith
josef.pktd | 1 May 15:16
Picon

Re: How to handle code contribution with GSoC students ?

On Fri, May 1, 2009 at 4:06 AM, David Cournapeau
<david <at> ar.media.kyoto-u.ac.jp> wrote:
> Pierre GM wrote:
>> On Apr 29, 2009, at 10:44 AM, Stéfan van der Walt wrote:
>>
>>
>>> 2009/4/29 David Cournapeau <david <at> ar.media.kyoto-u.ac.jp>:
>>>
>>>>    I was wondering about the best way to handle code by students for
>>>> the upcoming GSoC. The year I participated, I already had write
>>>> access,
>>>> so the question did not come up. I think I would prefer starting with
>>>> code reviews, before giving them svn write access later. Do people
>>>> have
>>>> better suggestions ?
>>>>
>>> It's a good time to learn about distributed revision control :)  So
>>> yes, let's have review branches.
>>>
>>
>> A whole branch for modifications to only one specific submodule ?
>>
>
> One possibility is to have one sandbox / student, the student would only
> commit in the sandbox, and the mentor would be responsible for merging
> it into the trunk. The advantage of this technique is that the mentor
> can do all the work if desired (updating the branch from the trunk,
> merging, etc...).
>
> Using something like git, bzr or hg is easier for the mentor, but this
(Continue reading)

Bruce Southey | 1 May 16:01
Picon

Re: How to handle code contribution with GSoC students ?

josef.pktd <at> gmail.com wrote:
> On Fri, May 1, 2009 at 4:06 AM, David Cournapeau
> <david <at> ar.media.kyoto-u.ac.jp> wrote:
>   
>> Pierre GM wrote:
>>     
>>> On Apr 29, 2009, at 10:44 AM, Stéfan van der Walt wrote:
>>>
>>>
>>>       
>>>> 2009/4/29 David Cournapeau <david <at> ar.media.kyoto-u.ac.jp>:
>>>>
>>>>         
>>>>>    I was wondering about the best way to handle code by students for
>>>>> the upcoming GSoC. The year I participated, I already had write
>>>>> access,
>>>>> so the question did not come up. I think I would prefer starting with
>>>>> code reviews, before giving them svn write access later. Do people
>>>>> have
>>>>> better suggestions ?
>>>>>
>>>>>           
>>>> It's a good time to learn about distributed revision control :)  So
>>>> yes, let's have review branches.
>>>>
>>>>         
>>> A whole branch for modifications to only one specific submodule ?
>>>
>>>       
>> One possibility is to have one sandbox / student, the student would only
(Continue reading)

Thouis (Ray) Jones | 1 May 17:13
Picon

Re: Should ndimage.measurements.* should return lists if index is a list?

2009/4/19 Stéfan van der Walt <stefan <at> sun.ac.za>:
> 2009/4/19  <josef.pktd <at> gmail.com>:
>> The long term intention is to rewrite ndimage in cython, but I don't think
>> this will happen anytime soon.
>
> I wish it could, though -- it would save us so much time, and I think
> it is doable in two months by a dedicated student.  Does anyone have
> some free time to spare, or some money to pay for a student?

We may have a student this summer that can work on it as a project.

In the meantime, I rewrote ndimage.measurements in pure python/numpy.
I'm still testing its speed, but I think it will provide a good base
for a cython version.  I've simplified the code quite a bit.
Everything goes through a single labeled_reduce function, which
handles all the label/index interactions without needing any type
conversions.

The changes are available via git at:
http://broad.mit.edu/~thouis/scipy.git ndimage_measurements_rewrite

Ray Jones
josef.pktd | 1 May 18:07
Picon

Re: Should ndimage.measurements.* should return lists if index is a list?

On Fri, May 1, 2009 at 11:13 AM, Thouis (Ray) Jones
<thouis <at> broad.mit.edu> wrote:
> 2009/4/19 Stéfan van der Walt <stefan <at> sun.ac.za>:
>> 2009/4/19  <josef.pktd <at> gmail.com>:
>>> The long term intention is to rewrite ndimage in cython, but I don't think
>>> this will happen anytime soon.
>>
>> I wish it could, though -- it would save us so much time, and I think
>> it is doable in two months by a dedicated student.  Does anyone have
>> some free time to spare, or some money to pay for a student?
>
> We may have a student this summer that can work on it as a project.
>
> In the meantime, I rewrote ndimage.measurements in pure python/numpy.
> I'm still testing its speed, but I think it will provide a good base
> for a cython version.  I've simplified the code quite a bit.
> Everything goes through a single labeled_reduce function, which
> handles all the label/index interactions without needing any type
> conversions.
>
> The changes are available via git at:
> http://broad.mit.edu/~thouis/scipy.git ndimage_measurements_rewrite
>

I cloned your git repository, but how do I find your changes?
`git log` only shows some old svn.scipy commits. And I didn't find any
other branch hiding inside.

(anything tricky with git and I'm lost)

(Continue reading)


Gmane