De: Mathieu Bouchard matju@artengine.ca Date: 2006/12/18 lun. PM 12:11:18 GMT-05:00 À: Martin Peach martin.peach@sympatico.ca Cc: pd-dev@iem.at Objet: Re: [PD-dev] strings
On Sun, 17 Dec 2006, Martin Peach wrote:
You make them work as strings when they can, and You make them work as symbols when they must.
There would be two objects, [stringtosymbol] and [symboltostring] that you could put between string and symbol objects. Of course some strings would get impossibly mangled this way but that's because of the way symbols work.
I have no clue what you're talking about: how mangled would they be? i don't plan any mangling to happen, except for the presence of \0 characters.
Maybe you don't understand what is being proposed. How would you make a symbol containing ASCII NUL and CR LF characters for instance?
Yes, there's no reason not to have 0-length strings. And no reason to trash them when they are unused either, since they don't take up more space than any other object.
They take the space it takes to tell their size and the pointer to the buffer. That's significant, and nearly as much as in the case of a t_symbol, supposing that those t_strings can live independently of the objects that produce them.
Like any other object strings have that overhead, but unlike lists they only have one atom per string. They would be created by string objects and last as long as the string objects. One string per string object. String messages are passed between string manipulator objects. For this purpose symbols are not usable because they can't contain every possible character and lists have too much overhead since each element of a list is an atom.
I'm suggesting that a [string] be like any other object and be deallocated when the patcher is closed.
Ok, that's certainly the string feature that I want. It's too much trouble for the benefit.
Whatever.
Man, that's not n atom type.
No it's not n atoms, it's a single atom that contains a pointer to a list of bytes. That's the main advantage of string over list.
Symbols are difficult to work with because their content gets interpreted,
You say that in answer to my questions on allocation? (That's not an allocation issue and not even any kind of memory layout issue.)
I don't know, did I? It looks to me like an answer to a question about why symbols can't be used to encode arbitrary strings. Maybe I was tired.
for example if I write a comment "MP 20061214" it gets converted into "MP 2.00612e+007"
the contents of a comment box is not a symbol. It's a list of atoms. However, Pd has the same problem you describe when trying to save some symbols. e.g. say you have a symbol with a space in it and you pass it to a messagebox "set $1" which passes it to an empty messagebox, and then you save the patch: then you have that problem with symbols. But the contents of the comment box has that problem while never storing its contents as a symbol.
I wonder how the list of atoms in a comment box gets by without some of those atoms being symbols...
Martin
On Mon, 18 Dec 2006, martin.peach@sympatico.ca wrote:
Mathieu Bouchard matju@artengine.ca wrote:
I have no clue what you're talking about: how mangled would they be? i don't plan any mangling to happen, except for the presence of \0 characters.
Maybe you don't understand what is being proposed. How would you make a symbol containing ASCII NUL and CR LF characters for instance?
Do you realise that the quoting problem can be solved independently of the allocation problem? In that case, you would be able to save any symbol and read it back. This would solve the problem about CR LF and spaces; only the problem with \0 (NUL) would remain.
Do you also realise that symbols can be made to support NUL while being backwards-compatible? Then what happens when a non-NUL-supporting external tries to read a symbol that contains a NUL, it will appear truncated at that point and that's all.
So basically there are three problems that can be dealt with independently. I'd rather not suppose that all three have to come together, monolithically.
For this purpose symbols are not usable because they can't contain every possible character and lists have too much overhead since each element of a list is an atom.
Symbols could be usable, if the problems that can be fixed in symbol without changing the nature of symbols, are fixed. You don't need strings for that.
I'm suggesting that a [string] be like any other object and be deallocated when the patcher is closed.
Ok, that's certainly the string feature that I want. It's too much trouble for the benefit.
Whatever.
Wouldn't you want objects to be able to emit strings in a way as carefree as they are with symbols? I'm talking about not putting the burden of memory management on the emitter of strings.
Man, that's not n atom type.
No it's not n atoms,
It's a typo. It was supposed to be "that's not an atom type", but that isn't so more true. I would've like to say something more like: it would be easier, if strings are more similar to symbols and floats, than to (g)pointers.
Symbols are difficult to work with because their content gets interpreted,
You say that in answer to my questions on allocation? (That's not an allocation issue and not even any kind of memory layout issue.)
I don't know, did I? It looks to me like an answer to a question about why symbols can't be used to encode arbitrary strings. Maybe I was tired.
It was just below two paragraphs that I had written about allocation.
for example if I write a comment "MP 20061214" it gets converted into "MP 2.00612e+007"
the contents of a comment box is not a symbol. It's a list of atoms. However, Pd has the same problem you describe when trying to save some
I wonder how the list of atoms in a comment box gets by without some of those atoms being symbols...
That some of the components are symbols, has nothing to do with the reason 20061214 gets converted to float32. There is never a big symbol containing all of the contents of a comment: it's broken down into atoms (into a t_binbuf) as soon as you click outside of the box, it's just the t_rtext that keeps holding the original string; but the t_savefn only saves the t_binbuf, it doesn't look at the t_rtext, which is why the floats get mangled at save time only.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
-
martin.peach＠sympatico.ca -
Mathieu Bouchard