[PD] VASP future

[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,
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 at iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://iem.at/cgi-bin/mailman/listinfo/pd-list
>