Hi Krzysztof, using the PyObject pointers wrapped into t_symbols is really a great idea (i haven't really thought of that in such a direct form). I'm cautious however not to overload the symbol table. The current VASP system is able to use "immediate" vasps [vasp.!], that are buffer fragments independent from PD arrays, with reference counting, also wrapped into symbols - but these are reused if possible, so that the impact on the symbol table is negligible. I have to investigate whether it's feasible with two-level references to also reuse PD symbols for PyObject pointers. In general i think this is the way to go - to be able to have discrete VASP objects without having to duplicate code - a code-wise light system totally based on Python, which is (on par with C++) my favorite language, i admit. many thanks for the hint!
best greetings, Thomas
PS. I wonder how an appropriate t_atom type would look like - it seems like additionally to a void *pointer there should also be some namespace ID (the generator instance of the pointer) - that means a new structure like t_symbol and a respective pointer as a union member into t_atom. PPS. In this respect quite unrelated - i can't really express how i like Mathieu's idea of local symbol tables - i wish someone takes the time to implement a draft into devel_0_38 - to my mind this would be a big leap forwards
Am 23.03.2005 um 14:48 schrieb Krzysztof Czaja:
hi Thomas,
Thomas Grill wrote: ...
I realized in my own work that it's very hard to express complex stuff as PD graphs, and also VASP has the problem of needing to lock arrays while working on them, which still isn't really implemented in PD (it is in the devel branch, but the future of this isn't clear either). The question is now whether i abandon the current PD object implementation of VASP and focus on the Python one, or think about a side-by-side solution of both systems, probably reducing the functionality of the current VASP implementation a bit. There's still
have you been thinking about replacing vasp with "pyobj" (and possibly "pyarr") python externals, which would allow passing references to python objects inside pd messages?
This means wrapping PyObject* and PyArrayObject* inside the t_atom structure. It is generally possible, although, currently, not very elegant, and not 100% robust. In the "plustot" experiment, I found out, that until things change on the t_atom scene, the type best suited for extending is t_symbol. I have faked it into becoming a reference-counted Tcl_Obj wrapper, which is fool-proof in most cases, but may fail, of course, and crash Pd, if someone renames an array to such a faked symbol, etc.
Perhaps, with some discussion and lobbying, we would have an appropriate Pd atom type some day...
Krzysztof
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list