Re: Re: [PD-dev] strings
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
Re: Re: [PD-dev] strings
On Mon, 18 Dec 2006, [EMAIL PROTECTED] wrote: If ascii values from 0 - 31 can be part of symbols that would be nice. How do you specify a symbol containing ascii values 1 2 and 3? Do they have names? Do it the way most languages have borrowed from C : use backslash followed by an octal or hex code, like \033 or \0x1b. It's easy to make it compatible with C/C++/Java/Perl/Python/Tcl/Ruby/PHP, all at the same time. 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. You still have the problem of the symbol table that grows by one each time the symbol changes. Well, you can solve that problem separately. There's no point to clump all issues into one ball. 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. A string library could have functions similar to getbytes(), resizebytes() and freebytes() Yes, that's putting the burden of memory management on the emitter. I mean, what I call the burden of memory management isn't about writing your own malloc() from scratch, no, I'm not talking about that, I'm talking about having to decide when to copy and when to deallocate. _ _ __ ___ _ _ _ ... | 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
Re: Re: [PD-dev] strings
Mathieu Bouchard [EMAIL PROTECTED] wrote: 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. If ascii values from 0 - 31 can be part of symbols that would be nice. How do you specify a symbol containing ascii values 1 2 and 3? Do they have names? 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. You still have the problem of the symbol table that grows by one each time the symbol changes. If I want to parse a book one word at a time, for example, it would only take one string for the input buffer, but it would take as many symbols as there are different words in the book. 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. A string library could have functions similar to getbytes(), resizebytes() and freebytes() for changing the length of strings that could be called by any other external in the library. Or pd could have the same functions that could be called by any external. Either way... Martin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: Re: [PD-dev] strings
De: Hans-Christoph Steiner [EMAIL PROTECTED] Date: 2006/12/18 lun. AM 09:45:26 GMT-05:00 À: carmen [EMAIL PROTECTED] Cc: pd-dev@iem.at Objet: Re: [PD-dev] strings On Dec 18, 2006, at 1:23 AM, carmen wrote: Automatic type conversion sounds like a really bad idea if the language only partially supports it. Pd is strongly typed is it? it mainly has numbers that occasionally look like symbols, and symbols that more than occasionally look like lists and/or strings.. There are set rules which defined what is a float, symbol, or pointer. You cannot change that type, often even with a special method. Ever tried to turn a float into a symbol? Doesn't really work, only partially. Along the lines of pd_defaultlist() in m_class.c, which handles list messages for objects that don't have list methods, one could add a pd_defaultstring(), which attempts to convert strings into symbols/floats/lists, instead of calling pd_defaultanything(), which would print no method for string. But it needs to be understood that it might not do it correctly, which is Not A Good Thing, but no worse than comments getting mangled. Maybe a [string unpack] object would be better: it could attempt to unpack a string into specified types, so the user could decide if a string like 123 is meant to represent a float or a symbol. Martin .hc , so what Martin says is definitely appropriate. Perl is the opposite, everything can be automatically cast, so there it makes sense. it is definitely a design decision which way to go. could PD flexibly support both at once? or does there need to be an OCaml edition, and a Perl edition? ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev Mistrust authority - promote decentralization. - the hacker ethic ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: Re: [PD-dev] strings
De: Mathieu Bouchard [EMAIL PROTECTED] Date: 2006/12/18 lun. PM 12:11:18 GMT-05:00 À: Martin Peach [EMAIL PROTECTED] 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 ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
