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
On Thu, 24 Mar 2005, Krzysztof Czaja wrote:
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?
The global symbol-table would deal with: 1. the unique numbering of symbols based on string comparison 2. the holding of global variables (array names / receive-symbols)
A "local" symbol-table would deal with: 1. the holding of "local" variables 2. that's all
The $-prefixes would really become scope indicators. $0-hello would access the local table $0 using the t_symbol "hello". This would *not* create a t_symbol "1000-hello" anymore.
A "local" symbol-table would belong to an abstraction instance (and so, in OOP vocabulary, would rather be called instance symbol-table, or object symbol-table). It would be destroyed whenever the abstraction instance is destroyed.
_____________________________________________________________________ Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
The $-prefixes would really become scope indicators. $0-hello would access the local table $0 using the t_symbol "hello". This would *not* create a t_symbol "1000-hello" anymore.
Am I right to assume that this would still keep "passing $0" as abstraction argument a viable operation? I use this idiom immensly often to let abstractions access data local to their parents.
Ciao
On Thu, 24 Mar 2005, Frank Barknecht wrote:
The $-prefixes would really become scope indicators. $0-hello would access the local table $0 using the t_symbol "hello". This would *not* create a t_symbol "1000-hello" anymore.
Am I right to assume that this would still keep "passing $0" as abstraction argument a viable operation? I use this idiom immensly often to let abstractions access data local to their parents.
Yes, $1-hello will work as expected. In fact, everything will feel the same as now, except that all "1000-"-prefixed symbols will be deleted when the abstr.instance #1000 gets deleted. Then it's faster and cleaner to achieve that effect by using two levels of hashes instead of one, because else you have to scan *all* of the *big* table every time an abstr.instance is deleted (!).
(with two levels, deleting n abstr.instances takes O(n) instead of O(n*n)).
_____________________________________________________________________ Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
Mathieu Bouchard wrote: ...
The $-prefixes would really become scope indicators. $0-hello would access the local table $0 using the t_symbol "hello". This would *not* create a t_symbol "1000-hello" anymore.
A "local" symbol-table would belong to an abstraction instance (and so, in OOP vocabulary, would rather be called instance symbol-table, or object symbol-table). It would be destroyed whenever the abstraction instance is destroyed.
so what would [s globalsymbol] do upon receiving $0-hello?
Krzysztof
On Thu, 24 Mar 2005, Krzysztof Czaja wrote:
A "local" symbol-table would belong to an abstraction instance (and so, in OOP vocabulary, would rather be called instance symbol-table, or object symbol-table). It would be destroyed whenever the abstraction instance is destroyed.
so what would [s globalsymbol] do upon receiving $0-hello?
It would not receive $0-hello because that's an A_DOLLSYM atom, which never leaves a messagebox or objectbox. Is that right?
However the way A_DOLLSYM works will have to be changed, because there's no way to make a t_word hold more than either t_int or t_symbol*, whereas now we need to have both. The solution is to use the high-bits of t_atom's t_atomtype a_type, to store the $-prefix (which is usually 0 but is also often 1 and sometimes more).
In short:
an A_SYMBOL is independent of scope. "foo" in N instances is the same "foo".
an A_DOLLSYM is dependent of scope, and its evaluation causes a lookup for the given symbol in the table indicated by the $-prefix.
_____________________________________________________________________ Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
The global symbol-table would deal with:
- the unique numbering of symbols based on string comparison
- the holding of global variables (array names / receive-symbols)
A "local" symbol-table would deal with:
- the holding of "local" variables
- that's all
The $-prefixes would really become scope indicators. $0-hello would access the local table $0 using the t_symbol "hello". This would *not* create a t_symbol "1000-hello" anymore.
i was thinking about this ... from my point of view, there are 2 different ways to implement this:
1. rewrite the $X resolving: at the moment it'd not known, if a symbol starts with $0, $2 or 1234 ... the resolving is done when the object is being created... this could be changed by using $X as kind of namespaces with a symbol table for every parent canvas ... i think this would be the most elegant solution...
2. hack gensym: if the string begins with a number, use the corresponding symbol table ... still, this would be an ugly hack ...
i'd prefer the first solution, although it would change most of pd's $X handling ... it's cleaner, though ...
any other possible solutions?
cheers ... tim
On Fri, 25 Mar 2005 23:14:01 +0100 Krzysztof Czaja czaja@chopin.edu.pl wrote:
Tim Blechmann wrote: ...
i was thinking about this ... from my point of view, there are 2
sorry for being so dumb, but for me it is still not clear what would happen to a $0-symbol when it is sent globally or through an outlet?
i don't see this as a problem ... the if a symbol starts with $X and there is a symbol table for this namespace, it will be put in this specific symbol table ... but this symbol table can be accessed from everywhere in the patch ...
still, there is one problem ... what happens, if a symbol is sent through an outlet, is used somewhere else in the patch and the parent canvas with the specific $0 symbol table is deleted ... the symbol pointer would point into nowhere :-( ... will have to think about this ...
cheers ... tim
Tim Blechmann wrote: ...
still, there is one problem ... what happens, if a symbol is sent through an outlet, is used somewhere else in the patch and the parent canvas with the specific $0 symbol table is deleted ... the symbol pointer would point into nowhere :-( ... will have to think about this
Tim, Mathieu,
this is not just a minor implementation detail. You are talking about introducing a completely different semantics for $0-symbols. Global symbol atoms, as they are defined currently, are immutable entities. Any Pd object may transparently store them, retrieve, etc.
Krzysztof
Hallo, Krzysztof Czaja hat gesagt: // Krzysztof Czaja wrote:
this is not just a minor implementation detail. You are talking about introducing a completely different semantics for $0-symbols. Global symbol atoms, as they are defined currently, are immutable entities. Any Pd object may transparently store them, retrieve, etc.
"Passing $0" around through send/receives, in- and outlets and abstraction arguments is a very important idiom in Pd. It is crucial for reusability of abstractions. I admit, that I don't really understand how the proposed change works and what consequences it will have, but if it would make accessing the $0 of some remote abstraction through above mechanisms impossible, it would not only break patches, it would break a way of thinking in Pd.
Ciao
this is not just a minor implementation detail. You are
for reusability of abstractions. I admit, that I don't really know
same, not exactly sure what this change means , or if breakage was ever proposed...however matju's other proposals sound nice, as if they would solve the problem of using too many symbols at the source:
* to use multielement lists of varying/unknown length as 'atoms' (currently via l2s/s2l symbol hack) * as 'string'-esque buffers between object
whatever u do, im sure you wont break the 'rradical' communication paradigm ...i'm using the same scheme for my OSC sequencer and sure hope it deosnt break any time soon!...
Frank Barknecht wrote: ...
for reusability of abstractions. I admit, that I don't really understand how the proposed change works and what consequences it will
neither do I, hence my query. Otherwise, I think Mathieu is right about Pd's current type system being inadequate for many applications.
Krzysztof
frank ...
i think it is clear, that there won't be any changes that imply your concerns ... compatibility is the concern no. 1, efficiency the concern no. 2
i don't think that _anyone_ thought of breaking pd! if you have any concerns, please have a look at what the changes are actually about...
t
Tim, Mathieu,
this is not just a minor implementation detail. You are talking about introducing a completely different semantics for $0-symbols. Global symbol atoms, as they are defined currently, are immutable entities. Any Pd object may transparently store them, retrieve, etc.
that's exactly, what concerns me most ... on the other hand, a $0-symbol that's $0 is connected with a canvas that doesn't exist any more can't be seen as valid any more ... the question is how to handle this ...
cheers ... tim
On Sat, 26 Mar 2005, Tim Blechmann wrote:
still, there is one problem ... what happens, if a symbol is sent through an outlet, is used somewhere else in the patch and the parent canvas with the specific $0 symbol table is deleted ... the symbol pointer would point into nowhere :-( ... will have to think about this
Ok, I reviewed all my stuff again, and I can say that there is currently no way to do what I want with the local symbols, because:
1. There is no way to store an instance number inside of the a_type field of an atom, because externals discard the atom and keep just the t_symbol*.
2. There is no way to store an instance number inside of a t_symbol* while keeping compatibility with the current code, because externals do dereference that pointer themselves instead of using an API, which means that the t_symbol* could not be replaced by (t_symbol*)(symbol_number*10000+canvas_number) for example.
3. There is no way to reference-count the t_symbols because the externals don't indicate their reference usage to pd.
4. There is no way to garbage-collect the t_symbols because the externals don't indicate to pd where are their t_symbol pointer variables located.
5. Integrating the $ number into the symbol and resolving it upon use (instead of upon declaration) makes no sense, as it breaks the feature of sending the name of a local name to some abstraction instance, by replacing it by a behaviour that is very difficult to use ($1's from completely different abstractions would get confused for each other...)
Which means that instead the road to be taken should be to create a new mechanism and slowly migrate everything to it, while keeping hackwards compatibility with the current way.
The new way I am now proposing (for the first time) would introduce a new atom type, a "pointer to variable", which would contain both a t_symbol* and an instance number.
Am I missing anything now?
_____________________________________________________________________ Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
Mathieu Bouchard wrote: ...
The new way I am now proposing (for the first time) would introduce a new atom type, a "pointer to variable", which would contain both a t_symbol* and an instance number.
exactly -- local symbols require introducing a new atom type...
so, it would be great, if we started a discussion about extending Pd type system, and the more generic level it starts on, the better. Ideally, the abstract mechanism yet to be proposed, would allow deriving special cases like gpointers, python object wrappers, etc.
What bothers me, though, is whether we are not going to find ourselves hitting the same wall that Miller had good reasons not to go through, many years ago...
Krzysztof
-
Frank Barknecht -
ix＠replic.net -
Krzysztof Czaja -
Mathieu Bouchard -
Tim Blechmann