expected identifier before numeric constant

[Wkerzendorf]

Hello,

I'm trying to wrap some c code. Trying to compile it gives me this
error:

---------------------------------------------------------------------------
mithrandir:pysextractor wkerzend$ python setup.py build_extrunning
build_ext
building 'makeback_wrap' extension
gcc-4.2 -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -
Os -Wall -Wstrict-prototypes -DENABLE_DTRACE -arch i386 -arch ppc -
arch x86_64 -pipe -I/Library/Python/2.6/site-packages/numpy/core/
include -I/System/Library/Frameworks/Python.framework/Versions/2.6/
include/python2.6 -c makeback_wrap.c -o build/temp.macosx-10.6-
universal-2.6/makeback_wrap.o
In file included from src/types.h:20,
from cmakeback_wrap.c:3,
from makeback_wrap.c:160:
src/fits/fitscat.h:70: error: expected identifier before numeric
constant
In file included from makeback_wrap.c:160:
cmakeback_wrap.c:19: warning: function declaration isn’t a prototype
cmakeback_wrap.c: In function ‘main’:
cmakeback_wrap.c:22: warning: unused variable ‘filename’
In file included from src/types.h:20,
from cmakeback_wrap.c:3,
from makeback_wrap.c:160:
src/fits/fitscat.h:70: error: expected identifier before numeric
constant
In file included from makeback_wrap.c:160:
cmakeback_wrap.c:19: warning: function declaration isn’t a prototype
cmakeback_wrap.c: In function ‘main’:
cmakeback_wrap.c:22: warning: unused variable ‘filename’
In file included from src/types.h:20,
from cmakeback_wrap.c:3,
from makeback_wrap.c:160:
src/fits/fitscat.h:70: error: expected identifier before numeric
constant
In file included from makeback_wrap.c:160:
cmakeback_wrap.c:19: warning: function declaration isn’t a prototype
cmakeback_wrap.c: In function ‘main’:
cmakeback_wrap.c:22: warning: unused variable ‘filename’
lipo: can't open input file: /var/folders/q-/q-6J7C5cFJuOCEieqIry8k++
+TI/-Tmp-//ccOQ0qs8.out (No such file or directory)
error: command 'gcc-4.2' failed with exit status 1
---------------------------------------------------------------------------

The line that seems to upset the code fitscat.h:70:

typedef enum {T_BYTE, T_SHORT, T_LONG, T_FLOAT, T_DOUBLE, T_STRING}
t_type; /* Type of data */

Any ideas?

Cheers
Wolfgang

[Lisandro Dalcin]

On 9 March 2010 11:21, Wkerzendorf <wkerz...@googlemail.com> wrote:
>
> The line that seems to upset the code fitscat.h:70:
>
> typedef enum            {T_BYTE, T_SHORT, T_LONG, T_FLOAT, T_DOUBLE, T_STRING}
>                                t_type;         /* Type of data */
>

Do this enumeration comes from your own code? In such case, these
names conflict with Python's structmember.h stuff ... You know,
namespaces are one honking great idea, but not for Python's C-API ;-)
Unfortunately, you will have to change the names of the enumeration
items to avoid the conflict.

--
Lisandro Dalcin
---------------
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594

[Dag Sverre Seljebotn]

Lisandro Dalcin wrote:
> On 9 March 2010 11:21, Wkerzendorf <wkerz...@googlemail.com> wrote:
>
>> The line that seems to upset the code fitscat.h:70:
>>
>> typedef enum {T_BYTE, T_SHORT, T_LONG, T_FLOAT, T_DOUBLE, T_STRING}
>> t_type; /* Type of data */
>>
>>
>
> Do this enumeration comes from your own code? In such case, these
> names conflict with Python's structmember.h stuff ... You know,
> namespaces are one honking great idea, but not for Python's C-API ;-)
> Unfortunately, you will have to change the names of the enumeration
> items to avoid the conflict.
>

Or perhaps, if this is a library, create a wrapper firstcat_cython.h
like this:

#undef T_BYTE
#define T_BYTE CYTHON_T_BYTE
/* repeat for other types */
#include "fitscat.h"
#undef T_BYTE

/* here, copy and paste the definition of T_BYTE from structmember.h */

Then, in pxd/pyx files, use CYTHON_T_BYTE.

Dag Sverre

[Lisandro Dalcin]

Or... Change Cython to get rid of structmember.h ... Why not use the
transform+property machinery for implementing this? IIRC, I suggested
this long ago...

[Dag Sverre Seljebotn]

And I subsequently implemented it long ago, but as it resulted in longer
generated C code for no apparent benefit it was reverted...

Dag Sverre

[Lisandro Dalcin]

You are right, looking at it right now (BTW, it seems that 'readonly'
is not handled?)...

> but as it resulted in longer
> generated C code for no apparent benefit it was reverted...
>

Perhaps the benefit is now more clear? structmember.h is a somewhat
private header, some definitions are not properly Py_-prefixed, then
they can cause trouble. Additionally, as a matter of consistency, I
would prefer cdef public/readonly members to use Cython's own
conversion machinery.

[Dag Sverre Seljebotn]

Sounds right, I remember that there was some deficiency which also made
it easier to revert than fix. So don't push it without making sure
there's proper tests!

I'm +1.

Dag Sverre

[Dag Sverre Seljebotn]

BTW it was Robert opposing it last time, so he should probably chime in
here before anything is done...

Dag Svere

[Robert Bradshaw]

I don't remember what my reasoning was, but IIRC the code as it was
had issues.

Another con is that it makes our .c and .so files much more verbose,
so IMHO we should have good justification for doing so.

- Robert

[Wkerzendorf]

Dear all,

So what do I need to do? I'm wrapping a c code which I don't really
want to change as it is not mine. And I thought when doing typedef
enum. I'm basically creating a "drop down menu", where a variable can
have any of the above values T_BYTE, T_SHORT, T_LONG, T_FLOAT,
T_DOUBLE, T_STRING which are defined through the enum type. There
doesnt seem to be a consensus by you guys what to do?
Anyway thanks for the help
Wolfgang

On Mar 10, 4:43 am, Robert Bradshaw <rober...@math.washington.edu>
wrote:

> On Mar 9, 2010, at 9:01 AM, Dag Sverre Seljebotn wrote:
>
>
>
>
>
> > Dag Sverre Seljebotn wrote:
> >> Lisandro Dalcin wrote:
> >>> On 9 March 2010 13:38, Dag Sverre Seljebotn <da...@student.matnat.uio.no
> >>> > wrote:
>
> >>>> Lisandro Dalcin wrote:
>
> >>>>> On 9 March 2010 13:23, Dag Sverre Seljebotn <da...@student.matnat.uio.no
>
> >>>>> wrote:
>
> >>>>>> Lisandro Dalcin wrote:
>
> >>>>>>> On 9 March 2010 11:21, Wkerzendorf  

[Stefan Behnel]

Wkerzendorf, 10.03.2010 12:26:

> So what do I need to do? I'm wrapping a c code which I don't really
> want to change as it is not mine. And I thought when doing typedef
> enum. I'm basically creating a "drop down menu", where a variable can
> have any of the above values T_BYTE, T_SHORT, T_LONG, T_FLOAT,
> T_DOUBLE, T_STRING which are defined through the enum type. There
> doesnt seem to be a consensus by you guys what to do?

The discussion has moved on to the cython-dev mailing list (where it
belongs) and (soon) the bug tracker. A proposed fix has been implemented
and will be considered for Cython 0.13.

The problem for now is that there is a naming collision between the CPython
structmember.h header file (which Cython includes automatically), and the
header file that you use in your source. Dag provided a work-around for
this, which is not beautiful, but which should solve this issue for the
time being.

Stefan

[Lisandro Dalcin]

On 10 March 2010 08:35, Stefan Behnel <stef...@behnel.de> wrote:
> Wkerzendorf, 10.03.2010 12:26:

>>
> The discussion has moved on to the cython-dev mailing list (where it
> belongs) and (soon) the bug tracker. A proposed fix has been implemented and
> will be considered for Cython 0.13.
>

http://trac.cython.org/cython_trac/ticket/517

[Lisandro Dalcin]

On 10 March 2010 11:52, Lisandro Dalcin <dal...@gmail.com> wrote:
> On 10 March 2010 08:35, Stefan Behnel <stef...@behnel.de> wrote:
>> Wkerzendorf, 10.03.2010 12:26:
>>>
>> The discussion has moved on to the cython-dev mailing list (where it
>> belongs) and (soon) the bug tracker. A proposed fix has been implemented and
>> will be considered for Cython 0.13.
>>
>
> http://trac.cython.org/cython_trac/ticket/517
>

http://hg.cython.org/cython-devel/rev/1a2e04bc1395

[Wkerzendorf]

Dear all,

I am trying to wrap some c functions of a c program. I wrote a c file
that has a function that I want to wrap with python. this c function
in turn accesses the program I want to wrap and has all the necessary
includes. One of these includes is a file that has the above mentioned
CTYPES. But this is an include from the c file not from the cython
file. I dont know if that makes sense: I would like to keep the cython
completely separate from the rest of the c libraries and just want to
wrap my own c function that includes the c library.

I hope that is kind of understandable.

Thanks again for the help

Wolfgang

On Mar 12, 7:24 am, Lisandro Dalcin <dalc...@gmail.com> wrote:
> On 10 March 2010 11:52, Lisandro Dalcin <dalc...@gmail.com> wrote:

[Lisandro Dalcin]

On 18 March 2010 11:12, Wkerzendorf <wkerz...@googlemail.com> wrote:
>
> I hope that is kind of understandable.
>

Sorry, this is still related to the issue you posted (i.e. the
name-clashing of T_BYTE, T_SHORT, T_LONG, etc. from your
"src/fits/fitscat.h" include file??)

[Wkerzendorf]

Yes that is still related; I only want my c code to do the includes
(which contains the T_BYTE,T_SHORT) and I dont want cython to see any
of that.

Cheers
Wolfgang

On Mar 19, 3:58 am, Lisandro Dalcin <dalc...@gmail.com> wrote:

[Dag Sverre Seljebotn]

Please don't top-post, we keep loosing track of the discussion...

Wkerzendorf wrote:
> Yes that is still related; I only want my c code to do the includes
> (which contains the T_BYTE,T_SHORT) and I dont want cython to see any
> of that.

If I understand correctly, you should make a new header file (.h file)
for your C code which do NOT include "fitscat.h", which Cython then uses.

Only your C file needs to use fitscat.h.

That way, the Cython-generated C source never sees fitscat.h.

Dag Sverre