Hi Ben, i'm cc'ing to the list, since this might be interesting for others too
I got a pixelTANGO bug report about the new "symbol" type in py. Seems symbols are no longer mapped to strings in python but remain some py type of "symbol" of course the normal string processing methods (not functions) don't work.
right, there's a Python type "Symbol" now, that encapsulates pd t_symbol pointers.
So can I use str() to convert the symbol to a python string? Does py convert a string back to a symbol when PD gets it?
Yes and yes.
Is there any documentation for py now? I seem even more confused with this latest release about types and available methods. (does the symbol type now have special symbol only methods?)
Not really, it can be compared to other symbols and cast to string (and in the cvs version also works as a normal immutable Python sequence.)
I'm finding the included examples less than ideal for learning the API...
Hmmm, you're right. The thing is that i wanted to put out the current state so that i can work on new features. I'm sure i'll find more time soon to work on a real tutorial.
I think Miller would be better to add a "matrix" data type than an image type, somehow to unify vasp, gridflow and iemmatrix so that they can all pass (or at least convert) data to the different forms. Oh and what is the projection for the VASP rewrite?
I'm working on the vasp rewrite now - most of the functionality is covered by numarrays already. As previously stated, vasp will be a Python module (mostly extending numarray functionality) that is used from within py/pyext. py has been extended (in cvs) so that Python object pointers can be passed between several instances of py in the patcher, like [vasp( messages in the old version. I'll give an overview of the new features as soon as the naming/syntax has stabilized.
Concerning PD arrays and matrices i already stated that i'm considering introducing a new type that is based on numarrays. This seems convenient since numarrays can map to existing memory and therefore also be able to interact with Miller's data structures. Numarrays are extremely flexible (multi-dimensional, all relevant types, also non-contiguous) and is seems very likely that they become the basis for a Python core array type. The only basic problem that i see for now is the locking of the Python interpreter state, which could collide with realtime operations in PD. This is not a problem if Python is used only in single-threaded mode, but since scripting isn't too fast this seems like a drawback. Let's see if i can work around this. For numarrays to be really efficient for audio and video application it will also be necessary to optimize the ufuncs which are at the moment implemented too straightforward (auto-generated) without SIMD or MMX... this is a target for the vasp project as well.
best greetings, Thomas