17 messages in at.iem.pd-dev[PD-dev] Re: [PD] VASP future| From | Sent On | Attachments |
|---|---|---|
| Krzysztof Czaja | Mar 24, 2005 7:50 am | |
| Mathieu Bouchard | Mar 24, 2005 9:20 am | |
| Frank Barknecht | Mar 24, 2005 11:03 am | |
| Krzysztof Czaja | Mar 24, 2005 1:54 pm | |
| Mathieu Bouchard | Mar 24, 2005 2:36 pm | |
| Tim Blechmann | Mar 25, 2005 1:37 pm | |
| Krzysztof Czaja | Mar 25, 2005 2:13 pm | |
| Tim Blechmann | Mar 26, 2005 12:31 am | |
| Mathieu Bouchard | Mar 26, 2005 12:57 am | |
| Krzysztof Czaja | Mar 26, 2005 3:40 am | |
| Frank Barknecht | Mar 26, 2005 4:03 am | |
| ix...@replic.net | Mar 26, 2005 4:20 am | |
| Krzysztof Czaja | Mar 26, 2005 1:26 pm | |
| Tim Blechmann | Mar 27, 2005 4:52 am | |
| Tim Blechmann | Mar 27, 2005 4:57 am | |
| Mathieu Bouchard | Mar 27, 2005 9:15 pm | |
| Krzysztof Czaja | Mar 28, 2005 7:38 am |
| Subject: | [PD-dev] Re: [PD] VASP future | |
|---|---|---|
| From: | Krzysztof Czaja (cza...@chopin.edu.pl) | |
| Date: | Mar 24, 2005 7:50:51 am | |
| List: | at.iem.pd-dev | |
Thomas Grill wrote: ...
I have to investigate whether it's feasible with two-level references to also reuse PD symbols for PyObject pointers.
yes, one way to do that might be picking unique global symbols, different for every wrappee. These symbols could be bound to t_pd objects of a class that defines a dummy 'anything' method. In order to deal with accidental alien bindings, the objects would have to be accessed by a pd_findbyclass() call.
The plustot way is different, since it does not pollute the global symbol table. The current version is only experimental. It seems possible to make it robust, although no obvious way to avoid leaking small portions of memory with every new symbol. This is not a very big deal, since for each [+tot] object the number of wrapped tcl objects is small and constant.
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.
some sort of identification will be needed for sure, at least if this is to be a single blob-like type (still a very vague idea for me...)
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
I have missed that one, I am afraid. Is it about keeping $0-symbols in local hash tables, or about introducing a new special syntax? How a local symbol would be prevented from spilling out of local context?
Krzysztof