[PD-dev] strings

[Mathieu Bouchard]

On Mon, 18 Dec 2006, martin.peach at sympatico.ca wrote:
> Mathieu Bouchard <matju at 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