headers
Mike C. Fletcher | 2 May 2005 00:11
Favicon

Bug in gccxmlparser.py, assumes size and align attributes on pointers

At line 143 and 135 in gccxmlparser there's an assumption made that all
pointer types will have a defined size attribute.  Similarly it's
assumed that all pointer types have "align" defined on lines 144 and
136.  This prevents the gl.h header from being converted to a Python
file on Linux.  I just substituted the calls with size = attrs.get(
'size', 0) and align = attrs.get("align",0), but I'm not sure if that's
the correct default value.

Of course, once I get that done, xml2py doesn't produce any *output*,
but that's probably me messing something up in how I'm calling it:

mcfletch <at> raistlin:~/pylive/OpenGLct$ python ../ctypes/wrap/xml2py.py
gl.xml -o gl.py -kf -v
###########################
# Symbols defined:
#
# Variables:              0
# Struct/Unions:          0
# Functions:              0
# Enums:                  0
# Enum values:            0
# Typedefs:               0
# Pointertypes:           0
# Arraytypes:             0
# unknown functions:    478
#
# Total symbols:     0
###########################
needed 1 loop(s)
(Continue reading)

Permalink | Reply | 9 comments |
headers
Andreas Degert | 2 May 2005 00:27
Picon
Favicon

Re: Bug in gccxmlparser.py, assumes size and align attributes on pointers

"Mike C. Fletcher" <mcfletch <at> rogers.com> writes:

> At line 143 and 135 in gccxmlparser there's an assumption made that all
> pointer types will have a defined size attribute.  Similarly it's
> assumed that all pointer types have "align" defined on lines 144 and
> 136.  This prevents the gl.h header from being converted to a Python
> file on Linux.  I just substituted the calls with size = attrs.get(
> 'size', 0) and align = attrs.get("align",0), but I'm not sure if that's
> the correct default value.

for me it seems to work.. are you using the current cvs version of
gccxml?

ciao
Andreas

-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
Permalink | Reply | 3 comments |
headers
Mike C. Fletcher | 2 May 2005 00:40
Favicon

Re: Bug in gccxmlparser.py, assumes size and align attributes on pointers

Andreas Degert wrote:

>"Mike C. Fletcher" <mcfletch <at> rogers.com> writes:
>
>  
>
>>At line 143 and 135 in gccxmlparser there's an assumption made that all
>>pointer types will have a defined size attribute.  Similarly it's
>>assumed that all pointer types have "align" defined on lines 144 and
>>136.  This prevents the gl.h header from being converted to a Python
>>file on Linux.  I just substituted the calls with size = attrs.get(
>>'size', 0) and align = attrs.get("align",0), but I'm not sure if that's
>>the correct default value.
>>    
>>
>
>for me it seems to work.. are you using the current cvs version of
>gccxml?
>  
>
Ah, no.  I'm using the released version via a Gentoo emerge.  Didn't
realise the dependency was on the CVS version.  Guess that might explain
the problem.  Anyway, I've got it producing a Python file with the
current version.  Wondering: is there an option for GCCXML to include
the parameter *names* in the XML so that we could produce a little more
user-friendly wrapper?  I'm thinking I'd want to extend the
auto-generation to produce docstrings instead of the throw-away function
bodies (should make the generated file look a lot more friendly IMO).

Anyway, almost out of time for playing this weekend.  I've mostly been
(Continue reading)

Permalink | Reply | 2 comments |
headers
Andreas Degert | 2 May 2005 01:06
Picon
Favicon

Re: Bug in gccxmlparser.py, assumes size and align attributes on pointers

"Mike C. Fletcher" <mcfletch <at> rogers.com> writes:

> Andreas Degert wrote:
>
>>for me it seems to work.. are you using the current cvs version of
>>gccxml?
>>  
>>
> Ah, no.  I'm using the released version via a Gentoo emerge.  Didn't
> realise the dependency was on the CVS version.  Guess that might explain
> the problem.  Anyway, I've got it producing a Python file with the
> current version.  Wondering: is there an option for GCCXML to include
> the parameter *names* in the XML so that we could produce a little more
> user-friendly wrapper?

The xml generator doesn't get that information from gcc, so its
missing from the xml output. I've appended a patch for gccxml which
changes that (some more testing might also help to get it into the
official gccxml version...)

> I'm thinking I'd want to extend the auto-generation to produce
> docstrings instead of the throw-away function bodies (should make
> the generated file look a lot more friendly IMO).

If you got the names you normally wouldn't need an additional
docstring (just use help on the function). Or did you mean something
else?

ciao
Andreas
(Continue reading)

Permalink | Reply | 1 comment |
headers
Thomas Heller | 2 May 2005 09:53
Favicon

Re: Bug in gccxmlparser.py, assumes size and align attributes on pointers

"Mike C. Fletcher" <mcfletch <at> rogers.com> writes:

> At line 143 and 135 in gccxmlparser there's an assumption made that all
> pointer types will have a defined size attribute.  Similarly it's
> assumed that all pointer types have "align" defined on lines 144 and
> 136.  This prevents the gl.h header from being converted to a Python
> file on Linux.  I just substituted the calls with size = attrs.get(
> 'size', 0) and align = attrs.get("align",0), but I'm not sure if that's
> the correct default value.
>
> Of course, once I get that done, xml2py doesn't produce any *output*,
> but that's probably me messing something up in how I'm calling it:
>
> mcfletch <at> raistlin:~/pylive/OpenGLct$ python ../ctypes/wrap/xml2py.py
> gl.xml -o gl.py -kf -v
> ###########################
> # Symbols defined:
> #
> # Variables:              0
> # Struct/Unions:          0
> # Functions:              0
> # Enums:                  0
> # Enum values:            0
> # Typedefs:               0
> # Pointertypes:           0
> # Arraytypes:             0
> # unknown functions:    478
> #
> # Total symbols:     0
> ###########################
(Continue reading)

Permalink | Reply | 4 comments |
headers
Andreas Degert | 2 May 2005 11:56
Picon
Favicon

Re: Re: Bug in gccxmlparser.py, assumes size and align attributes on pointers

Thomas Heller <theller <at> python.net> writes:

> "Mike C. Fletcher" <mcfletch <at> rogers.com> writes:
[...]
>> Of course, once I get that done, xml2py doesn't produce any *output*,
>> but that's probably me messing something up in how I'm calling it:
[...]
>> $ python ../ctypes/wrap/xml2py.py gl.xml -o gl.py -kf -v
[...]
>> Not sure what an "unknown function" is yet, will keep poking...
>
> Bad naming, probably.  xml2py tries to find functions in the shared libs
> you specify with the -l flag.  'unknown functions' are those functions
> not found in any of the libraries.

The command should read

python ../ctypes/wrap/xml2py.py gl.xml -lGL -o gl.py -kf -v

(note the -lGL)

ciao
Andreas

-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
(Continue reading)

Permalink | Reply | 2 comments |
headers
Mike C. Fletcher | 3 May 2005 05:46
Favicon

Re: Bug in gccxmlparser.py, assumes size and align attributes on pointers

Andreas Degert wrote:
...

>The xml generator doesn't get that information from gcc, so its
>missing from the xml output. I've appended a patch for gccxml which
>changes that (some more testing might also help to get it into the
>official gccxml version...)
>  
>
I'll give the patch a try when I get some significant time to work on
getting gccxml installed from a non-ebuild source.  Thanks.

>>I'm thinking I'd want to extend the auto-generation to produce
>>docstrings instead of the throw-away function bodies (should make
>>the generated file look a lot more friendly IMO).
>>    
>>
>
>If you got the names you normally wouldn't need an additional
>docstring (just use help on the function). Or did you mean something
>else?
>  
>
I'm thinking about including the one-line summaries from the OpenGL docs
into the docstrings (as well as the named and typed parameters), so
something like:

    """glVertexPointer( arrayObject: pointer ) -- define an array of
vertex data"""
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike C. Fletcher | 3 May 2005 05:48
Favicon

Re: Re: Bug in gccxmlparser.py, assumes size and align attributes on pointers

Thomas Heller wrote:
...

>>Not sure what an "unknown function" is yet, will keep poking...
>>    
>>
>
>Bad naming, probably.  xml2py tries to find functions in the shared libs
>you specify with the -l flag.  'unknown functions' are those functions
>not found in any of the libraries.
>  
>
I'd missed that need to do the lookup in the .so's.  Thanks,
Mike

________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com

-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
Permalink | Reply | 0 comments |
headers
Mike C. Fletcher | 3 May 2005 06:44
Favicon

Another general question: releasing the GIL around a function call?

Asking this before I get to the point of actually working on it (likely
this weekend):

    How do I (can I?) specify to ctypes that the GIL should be released
    before calling a given function and then re-acquired afterward?

    Do callbacks automatically re-acquire the GIL before calling back
    into the Python code?

Ideally I'm thinking I'd like to allow the end-programmer to specify
which methods to be thread-friendly, as most functions return instantly,
so releasing the lock would slow them, while others can take huge
amounts of time.  I figure the default would likely be to just have a
dozen or so "obvious" calls be made GIL-free and then let users
add-to/remove-from that set.

Have fun all,
Mike

--

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com

-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
(Continue reading)

Permalink | Reply | 3 comments |
headers
Mike C. Fletcher | 3 May 2005 05:40
Favicon

Re: Re: Bug in gccxmlparser.py, assumes size and align attributes on pointers

Andreas Degert wrote:
...

>The command should read
>
>python ../ctypes/wrap/xml2py.py gl.xml -lGL -o gl.py -kf -v
>
>(note the -lGL)
>  
>
Had to use:

     python ../ctypes/wrap/xml2py.py -llibGL.so -o gl.py -v gl.xml

to get it to work on my machine (Gentoo AMD64 Linux).

Thanks,
Mike

________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com

-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
(Continue reading)

Permalink | Reply | 1 comment |

Gmane