headers
Shalom Rav | 1 Aug 2011 03:23
Picon

Re: Help Calling C functions with 1d & 2d arrays?

Thanks Robert.

On Jul 30, 2:46 am, Robert Bradshaw <rober... <at> math.washington.edu>
wrote:
> On Fri, Jul 29, 2011 at 7:32 AM, Shalom Rav <csharpplusproj... <at> gmail.com> wrote:
> > Blair,
>
> > Thank your for your detailed response.
>
> > I am just curious, were you able to compile my examples using the
> > `c99` standard (gcc -std=c99 myFile.c -o myFile) ?
>
> > Also, is there a provide a python wrapper for the matrix prototype,
> > just using a 2d numpy array and without using malloc etc?
>
> > Can this work, or will this cause issues:
>
> > def SumMatrixPython( numpy.ndarray[numpy.float32_t, ndim = 2]
> > incomingArray ):
> >    # invoke the c function
> >    return SumMatrix(incomingArray.shape[0], incomingArray.shape[1],
> > <float**≥ incomingArray.data )
>
> That won't work--data in a NumPy array is always 1-dimensional with
> stride and dimension metadata used to index into it into a
> multi-dimensional manner. Casting incomingArray.data to a float** will
> be the same result as ((float*) (float value))[index]--probably a
> segfault and certainly not what you want.
>
> Another way at getting at the rows is &incomingArray[i,0]--let Cython
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christopher Barker | 1 Aug 2011 18:57
Picon
Favicon

Re: [POLL] Can we drop support for CPython 2.3? (and maybe even 2.4?)

On 7/30/11 2:54 AM, Yosef Meller wrote:
>     would anyone mind dropping support for CPython 2.3?
>
>
> Not me :)
>
>     What about 2.4? Is that still actively used?
>
> It's the default Python in RHEL 5.4, which I had to use recently. I had
> permissions to install 2.6 along the default python, but it's very
> time-consuming and error-prone to maintain the two sets of packages for
> different versions of Python.

sure, but it's also error-prone to update Python packages that RH may 
depend on. I haven't used RedHat in years, but back in the day, I found 
it was best to leave the system python install alone, and install a 
separate one for all of my code -- that way I could control what 
packages I used, and didn't  have to worry about breaking any system 
utilities.

 From that perspective, it's actually nice that RedHat uses an older 
Python -- you can do your own work with a newer one, and not worry about 
clashes with the system Python.

So it's really only one extra package to maintain -- python itself -- 
the extra python packages you need can build on that, and you'd have to 
do that anyway.

Though it's all still a bit of a mystery to me why someone would 
recently decide to upgrade to a pretty old Python! If you're going to
(Continue reading)

Permalink | Reply | 3 comments |
headers
Lisandro Dalcin | 2 Aug 2011 04:47
Picon
Gravatar

Re: [POLL] Can we drop support for CPython 2.3? (and maybe even 2.4?)

On 1 August 2011 13:57, Christopher Barker <Chris.Barker <at> noaa.gov> wrote:
>
> Though it's all still a bit of a mystery to me why someone would recently
> decide to upgrade to a pretty old Python! If you're going to make a change,
> why not go to 2.7?
>

You know, there are companies out there selling you new shiny versions
of their products, just to discover a few day after you buy that you
became a beta-tester of the next new shiny version, and so on...

--

-- 
Lisandro Dalcin
---------------
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
3000 Santa Fe, Argentina
Tel: +54-342-4511594 (ext 1011)
Tel/Fax: +54-342-4511169
Permalink | Reply | 1 comment |
headers
Stefan Behnel | 2 Aug 2011 07:57
Picon
Favicon

Re: [POLL] Can we drop support for CPython 2.3? (and maybe even 2.4?)

Lisandro Dalcin, 02.08.2011 04:47:
> On 1 August 2011 13:57, Christopher Barker wrote:
>>
>> Though it's all still a bit of a mystery to me why someone would recently
>> decide to upgrade to a pretty old Python! If you're going to make a change,
>> why not go to 2.7?
>
> You know, there are companies out there selling you new shiny versions
> of their products, just to discover a few day after you buy that you
> became a beta-tester of the next new shiny version, and so on...

That seriously does not apply to 2.7. I can see no reason at all not to 
switch to that directly, instead of considering a resting parrot like 2.5 
or something full-of-quickly-assembled-cruft like 2.6. Basically, 2.7 has 
all the applicable goodies of 3.1 (and a half) including all the cleanup 
that 2.6 didn't receive anymore, but with full backwards compatibility to 
the 2.x series.

Stefan
Permalink | Reply | 0 comments |
headers
Yosef Meller | 2 Aug 2011 08:17
Picon
Picon

Re: [POLL] Can we drop support for CPython 2.3? (and maybe even 2.4?)

On יום שני 01 אוגוסט 2011 19:57:33 Christopher Barker wrote:
> On 7/30/11 2:54 AM, Yosef Meller wrote:
> >     What about 2.4? Is that still actively used?
> > 
> > It's the default Python in RHEL 5.4, which I had to use recently. I had
> > permissions to install 2.6 along the default python, but it's very
> > time-consuming and error-prone to maintain the two sets of packages for
> > different versions of Python.
> 
> sure, but it's also error-prone to update Python packages that RH may
> depend on. I haven't used RedHat in years, but back in the day, I found
> it was best to leave the system python install alone, and install a
> separate one for all of my code -- that way I could control what
> packages I used, and didn't  have to worry about breaking any system
> utilities.

That's why I chose a side-by-side install.

> So it's really only one extra package to maintain -- python itself --
> the extra python packages you need can build on that, and you'd have to
> do that anyway.

Not so - there are many "general programming" packages that I don't require 
their latest version to get productive with  - GUI tools, databases, etc. - 
all useful in large complex simulations. These tools are already packaged for 
Python 2.4 and in the main RHEL repositories.

What I'm saying is that some people would not have the ability or time to do 
the side-by-side thing and have to stick to the system Python.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Denis Bilenko | 2 Aug 2011 09:49
Picon

cython and preprocessor

Hi,

I've been using Cython for gevent (http://gevent.org) for 2 years now
and love it. Thanks to all the authors and the contributors!

One problem that I have to work around is lack of preprocessor support.

I've been using this hack:

    cdef void emit_ifdef "#if defined(_WIN32) //" ()
    cdef void emit_else  "#else //" ()
    cdef void emit_endif "#endif //" ()

but that's very very limited, as it only can be used in the executable
code and not in declarations (also results in compiler warnings).

So I've made another hack: https://github.com/denik/cython-ifdef

It uses unifdef to process the source multiple times for all possible
configurations of symbols definitions and then runs cython on all
those sources and then merges the resulting .c files into one.

For example, if test.pyx looks like this:

cdef class A:
    cdef object member
#ifdef _WIN32
    cdef object windows_only_member
#endif
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dag Sverre Seljebotn | 2 Aug 2011 11:15
Picon
Picon
Gravatar

Re: cython and preprocessor

On 08/02/2011 09:49 AM, Denis Bilenko wrote:
> Hi,
>
> I've been using Cython for gevent (http://gevent.org) for 2 years now
> and love it. Thanks to all the authors and the contributors!
>
> One problem that I have to work around is lack of preprocessor support.
>
> I've been using this hack:
>
>      cdef void emit_ifdef "#if defined(_WIN32) //" ()
>      cdef void emit_else  "#else //" ()
>      cdef void emit_endif "#endif //" ()
>
> but that's very very limited, as it only can be used in the executable
> code and not in declarations (also results in compiler warnings).
>
> So I've made another hack: https://github.com/denik/cython-ifdef
>
> It uses unifdef to process the source multiple times for all possible
> configurations of symbols definitions and then runs cython on all
> those sources and then merges the resulting .c files into one.

Nice trick!

IMO it would be nice to have this integrated into Cython itself at some 
point, building on Cython syntax, e.g.:

cdef class A:
     with cython.ifdef('_WIN32'):
(Continue reading)

Permalink | Reply | 12 comments |
headers
Dag Sverre Seljebotn | 2 Aug 2011 11:18
Picon
Picon
Gravatar

Re: cython and preprocessor

On 08/02/2011 11:15 AM, Dag Sverre Seljebotn wrote:
> On 08/02/2011 09:49 AM, Denis Bilenko wrote:
>> Hi,
>>
>> I've been using Cython for gevent (http://gevent.org) for 2 years now
>> and love it. Thanks to all the authors and the contributors!
>>
>> One problem that I have to work around is lack of preprocessor support.
>>
>> I've been using this hack:
>>
>> cdef void emit_ifdef "#if defined(_WIN32) //" ()
>> cdef void emit_else "#else //" ()
>> cdef void emit_endif "#endif //" ()
>>
>> but that's very very limited, as it only can be used in the executable
>> code and not in declarations (also results in compiler warnings).
>>
>> So I've made another hack: https://github.com/denik/cython-ifdef
>>
>> It uses unifdef to process the source multiple times for all possible
>> configurations of symbols definitions and then runs cython on all
>> those sources and then merges the resulting .c files into one.
>
> Nice trick!
>
> IMO it would be nice to have this integrated into Cython itself at some
> point, building on Cython syntax, e.g.:
>
> cdef class A:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sturla Molden | 2 Aug 2011 18:11
Picon
Favicon

Re: cython and preprocessor

Den 02.08.2011 11:15, skrev Dag Sverre Seljebotn:
>
> What do others think?
>

What does Cython's DEF, IF, ELIF, ELSE (with capital letters) do then? I 
thought it invoked the C preprocessor, but I might be mistaken.

Sturla
Permalink | Reply | 7 comments |
headers
mark florisson | 2 Aug 2011 18:48
Picon
Gravatar

Re: cython and preprocessor

On 2 August 2011 18:11, Sturla Molden <sturlamolden <at> yahoo.no> wrote:
> Den 02.08.2011 11:15, skrev Dag Sverre Seljebotn:
>>
>> What do others think?
>>
>
> What does Cython's DEF, IF, ELIF, ELSE (with capital letters) do then? I
> thought it invoked the C preprocessor, but I might be mistaken.
>
> Sturla
>
>
>
>

Unfortunately it doesn't, it only works for cython constants you
defined with DEF. The use case for that has always eluded me. I'd
prefer that syntax with preprocessor support though, the problem with
the 'with' statement is that it doesn't support elif and else clauses.
Permalink | Reply | 6 comments |

Gmane