On Mon, 18 Dec 2006, [EMAIL PROTECTED] wrote:
Mathieu Bouchard <[EMAIL PROTECTED]> 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
_______________________________________________
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
