On 12-07-02 03:05 PM, Chris Barker wrote:
> (this seems to have gone off-list -- putting it back on)
>
> On Mon, Jul 2, 2012 at 11:37 AM, Gordon Wrigley
> <gordon.wrigley@...> wrote:
>> A bunch of these functions have a pointer argument and an old and new style
>> of use, old style you pass a pointer to the data, new style you pass an
>> integer index into preloaded data. The current API turns an integer argument
>> into a one element list, which is rather awkward for new style use.
> OK -- so is the proposal that the "pass an integer index into
> preloaded data" be translated into python as passing an python integer
> as an index into preloaded data, then yes, this sure seems the obvious
> thing to so. I thought the integer would be interpreted as the value
> of a reference, not as an index. My mis-understanding, I guess.
The current behaviour looks like this (using an OpenGL.arrays.vbo.VBO):
glVertexAttribPointer(
self.Vertex_normal_loc,
3, GL_FLOAT,False, stride, self.coords+(5*4)
)
where coords is a VBO. the VBO +(5*4) creates a thing that produces a
GLvoidp( 0 + 5*4). You easily *can* create the GLvoidp( 0 + 5*4 )
yourself, of course, but nothing in any C opengl doc will tell you do
so, as in C you don't need to do the cast yourself. If you happen to be
following a C document, you likely *also* won't be using the VBO class
(which hides these details).
The issue comes with some (generally pretty old) APIs where e.g. you
want to be able to pass in one or many items (I'm actually struggling to
think of one off the top of my head, though I do recall that *something*
broke with PyOpenGL-ctypes when I didn't have it). They were odd bits
of code here and there that used the C-level idea that a reference to an
array of 1 item is just a reference to that item. Again, really only
seen when you're following along with a C tutorial, but that's a *lot*
of what people do with PyOpenGL. The old behaviour has been around a
*long* time (I believe from back when PyOpenGL was hand-coded C IIRC),
likely from before there were any APIs that did the offset-as-pointer
trick, and I'm really feeling like we could drop the behaviour.
> I guess I need an example or two to understand.
>
> Perhpas I'm also confused by the term "array" in python, there is:
>
> a list
> a tuple
> an array.array
> a numpy ndarray
>
> ... and who knows what else.
In PyOpenGL, the OpenGL.arrays package is what defines it (or any plugin
you load into that package). Basically:
* None
* bytes (str)
* ctypes
o arrays
o parameters
o pointers
* lists/tuples
* numbers
o int
o float
o long
* Numeric Python (deprecated)
* Numpy
o arrays
o scalars (with the appropriate flag set)
* vbo
o VBO
o VBOOffset
each of those things has a plug-in that allows that type to be used as
an array data-type within PyOpenGL. Some of the types have extra
features that allow them to be used as output data-types as well.
(Note: we don't currently have a built-in-array-module plugin).
The numbers plugin is what would be altered, so that instead of doing a
ctypes byref( int ) it would create a GLvoidp( int ), and would likely
drop the float types.
Hope that helps,
Mike
--
________________________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://www.vrplumber.comhttp://blog.vrplumber.com

(this seems to have gone off-list -- putting it back on)
On Mon, Jul 2, 2012 at 11:37 AM, Gordon Wrigley
<gordon.wrigley@...> wrote:
> A bunch of these functions have a pointer argument and an old and new style
> of use, old style you pass a pointer to the data, new style you pass an
> integer index into preloaded data. The current API turns an integer argument
> into a one element list, which is rather awkward for new style use.
OK -- so is the proposal that the "pass an integer index into
preloaded data" be translated into python as passing an python integer
as an index into preloaded data, then yes, this sure seems the obvious
thing to so. I thought the integer would be interpreted as the value
of a reference, not as an index. My mis-understanding, I guess.
I guess I need an example or two to understand.
Perhpas I'm also confused by the term "array" in python, there is:
a list
a tuple
an array.array
a numpy ndarray
... and who knows what else.
They are all different things. Which were we talking about with:
"""
eliminate the interpretation of numbers as arrays
"""
-CHB
> On Jul 2, 2012 6:41 PM, "Chris Barker" <chris.barker@...> wrote:
>>
>> On Sat, Jun 30, 2012 at 7:34 PM, Mike C. Fletcher
>> <mcfletch@...> wrote:
>> > * eliminate the interpretation of numbers as arrays, that is, if you
>> > pass 3 to a function expecting an array of integers you will get a
>> > pointer to address 3, rather than a pointer to an array with a
>> > single value of 3
>>
>> So a Python integer gets interpreted as a pointer? That feels prone to
>> error to me, though probably an error that would show itself pretty
>> quickly.
>>
>> Maybe it's to wordy, but what about a "pointer" of "address" object,
>> so ratehr than passing in an integer, you'd pass in:
>>
>> pointer(an_integer)
>>
>> (or you could use a numpy scalar:
>>
>> Then passing in a string integer could either wrap an array around it,
>> or raise an error.
>>
>> And what about passing a float?
>>
>> > o this will make the Python and C APIs look a lot closer
>>
>> sure, but Python doesn't have pointers -- so being explicit about that
>> would make more sense to me.
>>
>> > eliminate a common class of issues where someone can't see how
>> > to pass offsets to modern array functions
>>
>> with this method -- where would the address value come from anyway? I
>> guess in my case, I'd tend to want to use a numpy array, and an offset
>> could be expressed as a slice.
>>
>> By the way, Cython does this pretty naturally, you can do:
>>
>> cdef np.ndarray[double, ndim=1, mode="c"] an_array
>>
>> call_a_function_that_takes_a_pointer( &input[i] )
>>
>> which makes it very easy to do an offset.
>>
>> Thanks for moving PyOpenGL forward.
>>
>> -Chris
>>
>>
>>
>> --
>>
>> Christopher Barker, Ph.D.
>> Oceanographer
>>
>> Emergency Response Division
>> NOAA/NOS/OR&R (206) 526-6959 voice
>> 7600 Sand Point Way NE (206) 526-6329 fax
>> Seattle, WA 98115 (206) 526-6317 main reception
>>
>> Chris.Barker@...
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> PyOpenGL Homepage
>> http://pyopengl.sourceforge.net
>> _______________________________________________
>> PyOpenGL-Users mailing list
>> PyOpenGL-Users@...
>> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@...

On Sat, Jun 30, 2012 at 7:34 PM, Mike C. Fletcher
<mcfletch@...> wrote:
> * eliminate the interpretation of numbers as arrays, that is, if you
> pass 3 to a function expecting an array of integers you will get a
> pointer to address 3, rather than a pointer to an array with a
> single value of 3
So a Python integer gets interpreted as a pointer? That feels prone to
error to me, though probably an error that would show itself pretty
quickly.
Maybe it's to wordy, but what about a "pointer" of "address" object,
so ratehr than passing in an integer, you'd pass in:
pointer(an_integer)
(or you could use a numpy scalar:
Then passing in a string integer could either wrap an array around it,
or raise an error.
And what about passing a float?
> o this will make the Python and C APIs look a lot closer
sure, but Python doesn't have pointers -- so being explicit about that
would make more sense to me.
> eliminate a common class of issues where someone can't see how
> to pass offsets to modern array functions
with this method -- where would the address value come from anyway? I
guess in my case, I'd tend to want to use a numpy array, and an offset
could be expressed as a slice.
By the way, Cython does this pretty naturally, you can do:
cdef np.ndarray[double, ndim=1, mode="c"] an_array
call_a_function_that_takes_a_pointer( &input[i] )
which makes it very easy to do an offset.
Thanks for moving PyOpenGL forward.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@...

A few backwards-incompatible things I'm thinking of for PyOpenGL 3.0.3+:
* eliminate the interpretation of numbers as arrays, that is, if you
pass 3 to a function expecting an array of integers you will get a
pointer to address 3, rather than a pointer to an array with a
single value of 3
o this will make the Python and C APIs look a lot closer, and
eliminate a common class of issues where someone can't see how
to pass offsets to modern array functions
* drop support for Python 2.5 and below
o to make it easier to do Python 3.x support, e.g. by using except
Exception as var: syntax throughout
I don't expect either of those is *too* controversial, but I wanted to
let people know and have a chance to raise issues before I go about
implementing them (again, post 3.0.2 release).
Have fun,
Mike
--
________________________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://www.vrplumber.comhttp://blog.vrplumber.com