[PD-dev] Pd Strings

[Bryan Jurish]

morning all,

One (potential) problem with strings-as-arrays (as has been pointed out
before) is a gross waste of space: for IEEE-754 floats, sizeof(float)=4,
which is 3 bytes wasted for a single 8-bit character.  We could do some
devious byte-packing and pointer-casting in one or more externals to
attenuate the problems, but that gets very cryptic very quickly (I
actually tried this with [pdstring] (which wastes even *more* memory by
using one atom per character), but decided against it in the interests
of clarity and flexibility)... I think it's definitely worth a go however...

marmosets,
	Bryan

On 2007-11-14 08:13:03, Hans-Christoph Steiner <hans at eds.org> appears to
have written:
> Using arrays as strings is an interesting idea.  I don't think non- 
> ascii charsets should be too big a deal, they are decently supported  
> right now, without even trying :).  The Pd floats should store UTF-16  
> fine, which really covers basically everything.  By the time UTF-32  
> is used much, Pd will be using 64-bit floats.
> 
> .hc
> 
> On Nov 14, 2007, at 12:43 AM, Miller Puckette wrote:
> 
>> HI all,
>>
>> I don't have answers to all these, but I'm sure that adding a  
>> string ytpe
>> to Pd isn't the roght way to handle these problems.  But specifically:
>>
>> 1.  spaces in symbols are a parsing/formatting problem, not a data  
>> type
>> problem; 2. use arrays as strings as I proposed; 3.  I have to  
>> think about
>> that one some more (!) and 4. one thing is dealing with non-ascii  
>> character
>> sets, although there are likely to be many more problems to adress.
>>
>>
>> On Tue, Nov 13, 2007 at 11:57:06PM -0500, Chris McCormick wrote:
>>> Hi,
>>>
>>> I have deleted Miller's reply where he said that he's not that  
>>> interested
>>> in adding a string type to Pd, but I'd like to ask him a couple of
>>> questions regarding that response, if that's ok.
>>>
>>> 1. How do you propose to solve the 'spaces in file path' issue  
>>> without a
>>> string type? Or are you content with that restriction?
>>>
>>> 2. How do you suggest that people deal with the symbol table  
>>> pollution
>>> issue mentioned before on this list, when they are doing operations
>>> processing lots and lots of symbol-strings in Pd? Let me know if you
>>> want more information about this issue.
>>>
>>> 3. Will a [symbol2list] ever make it into Pd canonical so that people
>>> can split long symbols on a character, like the zexy external that  
>>> does
>>> this? It seems strange that you can concatenate symbols, but not  
>>> split
>>> them apart again.
>>>
>>> 4. Can anyone else help me with a concise summary of other string/Pd
>>> issues I haven't thought of?
>>>
>>> Thanks for taking the time to read and reply.
>>>
>>> Best,
>>>
>>> Chris.

-- 
Bryan Jurish                           "There is *always* one more bug."
jurish at ling.uni-potsdam.de      -Lubarsky's Law of Cybernetic Entomology