David Cournapeau wrote:
> You can use the command line version: svn diff gives exactly what you need.
http://www.sliksvn.com/en/download
is a good source of the command line client for Windows.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R
On Mon, Mar 16, 2009 at 2:43 AM, Sturla Molden wrote:
>
>> Well, that's nearly as good. (Though submitting a single svn diff
>> containing all changes could have been a bit more easy to handle than
>> separate patches for each file. But a small nitpick only.)
>
> The problem is I am really bad at
> Well, that's nearly as good. (Though submitting a single svn diff
> containing all changes could have been a bit more easy to handle than
> separate patches for each file. But a small nitpick only.)
The problem is I am really bad at using these tools. I have TortoiseSVN
installed, but no idea h
Sun, 15 Mar 2009 17:48:51 +0100, Sturla Molden wrote:
>> Mon, 16 Mar 2009 00:33:28 +0900, David Cournapeau wrote:
>>
>> Also, you could post the patch on the http://codereview.appspot.com
>> site. Then it would be easier to both review and to keep track of its
>> revisions
>
> I have posted the f
> Mon, 16 Mar 2009 00:33:28 +0900, David Cournapeau wrote:
>
> Also, you could post the patch on the http://codereview.appspot.com site.
> Then it would be easier to both review and to keep track of its
> revisions
I have posted the files here:
http://projects.scipy.org/numpy/ticket/1055
Sturla
> Would it be possible to make the changes as a patch (svn diff) - this
> makes things easier to review.
I've added diff files to ticket #1055.
> Yes, I would be more comfortable without them (for 1.3). This is
> typically the kind of small changes which can be a PITA to deal with
> just before
Mon, 16 Mar 2009 00:33:28 +0900, David Cournapeau wrote:
> Sturla Molden wrote:
>>
>> There is a version of fftpack_litemodule.c, fftpack.c and fftpack.h
>> that does this attached to ticket #1055. The two important changes are
>> releasing the GIL and using npy_intp for 64 bit support.
>>
>>
Sturla Molden wrote:
>
> There is a version of fftpack_litemodule.c, fftpack.c and fftpack.h that
> does this attached to ticket #1055. The two important changes are
> releasing the GIL and using npy_intp for 64 bit support.
>
Would it be possible to make the changes as a patch (svn diff) - thi
>> 1) I have noticed that fftpack_litemodule.c does not release the GIL
>> around calls to functions in fftpack.c. I cannot se any obvious reason
>> for
>> this. As far as I can tell, the functions in fftpack.c are re-entrant.
>>
>> 2) If fftpack_lite did release the GIL, it would allow functions
On Sun, Mar 15, 2009 at 12:46 PM, Charles R Harris
wrote:
>
>
> As it is easier to read and understand without going to the macro
> definition. Note that David has a quite involved check for the inline
> keyword implementation and I expect he would want to do the same for the
> restrict keyword. I
On Sun, Mar 15, 2009 at 5:16 AM, Sturla Molden wrote:
>
>
> 1) I have noticed that fftpack_litemodule.c does not release the GIL
> around calls to functions in fftpack.c. I cannot se any obvious reason for
> this. As far as I can tell, the functions in fftpack.c are re-entrant.
>
> 2) If fftpack_l
On Sat, Mar 14, 2009 at 10:44 PM, Sturla Molden wrote:
> >
> > I think MSVC uses _inline
>
> No, MSVC uses a double underscore. That is, __restrict for variable names
> and __declspec(restrict) for function return values.
>
Yes, but MSVC uses _inline for inline.
>
> >>#if (__STDC_VERSION__
>
> I think MSVC uses _inline
No, MSVC uses a double underscore. That is, __restrict for variable names
and __declspec(restrict) for function return values.
>>#if (__STDC_VERSION__ >= 199901L)
>>#undef RESTRICT
>>#undef INLINE
>>#define RESTRICT restrict
>>#de
On Sat, Mar 14, 2009 at 8:52 PM, Sturla Molden wrote:
>
> > Ok, but most GNU compilers has a __restrict__ extension for C89 and C++
> > that we could use. And MSVC has a compiler pragma in VS2003 and a
> > __restrict extension in VS2005 later versions. So we could define a
> mscro
> > RESTRICT t
On Sat, Mar 14, 2009 at 8:26 PM, Sturla Molden wrote:
> > On Sat, Mar 14, 2009 at 7:23 PM, Sturla Molden wrote:
>
> > We can't count on C99 at this point. Maybe David will add something so we
> > can use c99 when it is available.
>
> Ok, but most GNU compilers has a __restrict__ extension for C8
> Ok, but most GNU compilers has a __restrict__ extension for C89 and C++
> that we could use. And MSVC has a compiler pragma in VS2003 and a
> __restrict extension in VS2005 later versions. So we could define a mscro
> RESTRICT to be restrict in ISO C99, __restrict__ in GCC 3 and 4,
> __restrict
On Sat, Mar 14, 2009 at 8:26 PM, Sturla Molden wrote:
> > On Sat, Mar 14, 2009 at 7:23 PM, Sturla Molden wrote:
>
> > We can't count on C99 at this point. Maybe David will add something so we
> > can use c99 when it is available.
>
> Ok, but most GNU compilers has a __restrict__ extension for C8
> On Sat, Mar 14, 2009 at 7:23 PM, Sturla Molden wrote:
> We can't count on C99 at this point. Maybe David will add something so we
> can use c99 when it is available.
Ok, but most GNU compilers has a __restrict__ extension for C89 and C++
that we could use. And MSVC has a compiler pragma in VS2
On Sat, Mar 14, 2009 at 7:02 PM, Sturla Molden wrote:
> > On Sat, Mar 14, 2009 at 3:58 PM, Sturla Molden wrote:
>
> > There is also a ticket (#579) to add an implementation of the Bluestein
> > algorithm for doing prime order fft's. This could also be used for zoom
> > type fft's. There is lots
On Sat, Mar 14, 2009 at 7:23 PM, Sturla Molden wrote:
>
> > Give it a shot. Note that the fft transforms also use int instead of
> > intp,
> > which limits the maximum transform size to 32 bits. Fixing that is
> > somewhere
> > on my todo list but I would be happy to leave it to you ;) Although I
> Give it a shot. Note that the fft transforms also use int instead of
> intp,
> which limits the maximum transform size to 32 bits. Fixing that is
> somewhere
> on my todo list but I would be happy to leave it to you ;) Although I
> expect
> transforms > 2GB aren't all that common.
By the way..
> On Sat, Mar 14, 2009 at 3:58 PM, Sturla Molden wrote:
> There is also a ticket (#579) to add an implementation of the Bluestein
> algorithm for doing prime order fft's. This could also be used for zoom
> type fft's. There is lots of fft stuff to be done. I wonder if some of it
> shouldn't go i
On Sat, Mar 14, 2009 at 3:58 PM, Sturla Molden wrote:
> > On Sat, Mar 14, 2009 at 2:24 PM, Charles R Harris
>
> >> Give it a shot. Note that the fft transforms also use int instead of
> >> intp,
> >> which limits the maximum transform size to 32 bits. Fixing that is
> >> somewhere
> >> on my todo
> On Sat, Mar 14, 2009 at 2:24 PM, Charles R Harris
>> Give it a shot. Note that the fft transforms also use int instead of
>> intp,
>> which limits the maximum transform size to 32 bits. Fixing that is
>> somewhere
>> on my todo list but I would be happy to leave it to you ;) Although I
>> expect
On Sat, Mar 14, 2009 at 2:24 PM, Charles R Harris wrote:
>
>
> On Sat, Mar 14, 2009 at 2:16 PM, Sturla Molden wrote:
>
>>
>>
>> 1) I have noticed that fftpack_litemodule.c does not release the GIL
>> around calls to functions in fftpack.c. I cannot se any obvious reason for
>> this. As far as I
On Sat, Mar 14, 2009 at 2:16 PM, Sturla Molden wrote:
>
>
> 1) I have noticed that fftpack_litemodule.c does not release the GIL
> around calls to functions in fftpack.c. I cannot se any obvious reason for
> this. As far as I can tell, the functions in fftpack.c are re-entrant.
>
> 2) If fftpack_
1) I have noticed that fftpack_litemodule.c does not release the GIL
around calls to functions in fftpack.c. I cannot se any obvious reason for
this. As far as I can tell, the functions in fftpack.c are re-entrant.
2) If fftpack_lite did release the GIL, it would allow functions in
numpy.fft to
27 matches
Mail list logo
