[PD] VASP future

[Thomas Grill]

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 ;-)

best,
Thomas


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