[PD] VASP future
gr at grrrr.org
Thu Mar 24 00:44:19 CET 2005
Oh well, somehow preempting Mathieu - i'm sure gridflow does it in a
similar way - i'm sure he can elaborate on this quite a bit.
Does it make sense to have two systems potentially providing the same
features, only coming from two different directions?
Ok, it would be interesting to do some benchmarks then ;-)
Am 23.03.2005 um 23:48 schrieb Thomas Grill:
> 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,
> 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
>>> 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
>> 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...
>> PD-list at iem.at mailing list
>> UNSUBSCRIBE and account-management ->
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
More information about the Pd-list