atom feed17 messages in at.iem.pd-dev[PD-dev] Re: symbol tables
FromSent OnAttachments
Krzysztof CzajaMar 24, 2005 7:50 am 
Mathieu BouchardMar 24, 2005 9:20 am 
Frank BarknechtMar 24, 2005 11:03 am 
Krzysztof CzajaMar 24, 2005 1:54 pm 
Mathieu BouchardMar 24, 2005 2:36 pm 
Tim BlechmannMar 25, 2005 1:37 pm 
Krzysztof CzajaMar 25, 2005 2:13 pm 
Tim BlechmannMar 26, 2005 12:31 am 
Mathieu BouchardMar 26, 2005 12:57 am 
Krzysztof CzajaMar 26, 2005 3:40 am 
Frank BarknechtMar 26, 2005 4:03 am 
ix...@replic.netMar 26, 2005 4:20 am 
Krzysztof CzajaMar 26, 2005 1:26 pm 
Tim BlechmannMar 27, 2005 4:52 am 
Tim BlechmannMar 27, 2005 4:57 am 
Mathieu BouchardMar 27, 2005 9:15 pm 
Krzysztof CzajaMar 28, 2005 7:38 am 
Subject:[PD-dev] Re: symbol tables
From:Mathieu Bouchard (mat@sympatico.ca)
Date:Mar 27, 2005 9:15:20 pm
List:at.iem.pd-dev

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?