[PD] Announce: pdstring v0.08 + locale v0.01

[Hans-Christoph Steiner]

I don't have a strong opinion on this, but I'd say stick to using the  
arrays how they are represented in Pd rather than how they are  
implemented in C.  This will keep the library flexible and  
maintainable.  It seems to me that this should something that is a  
more functionality.  I guess that is Martin Peach's approach with his  
string/blob patch.

And by the way, since I am in middle of rewriting the GUI, let me know  
what I can do to make sure that this stuff is well supported in the  
GUI.  Tcl is fully UTF-8 as far as I know.  It would be nice to have  
pd be UTF-8 as well.  I don't really have a good idea how far pd is  
from being UTF-8.

.hc

On Jan 26, 2009, at 4:59 PM, Bryan Jurish wrote:

> morning all,
>
> As of yesterday, a new version of [pdstring] is available on SVN and
> from me (http://www.ling.uni-potsdam.de/~moocow/projects/pd).   
> Following
> the discussion ensuing from my recent "request for objections", I
> weaseled some wide-character support into the [pdstring]  
> representation
> with new objects ([bytes2wchars], [wchars2bytes]) and abstractions
> ([any2wchars], [wchars2any]).  The old [any2string] and [string2any]  
> are
> now [any2bytes] and [bytes2any], with the old names still working as
> aliases.
>
> In order for the wide character support to do anything useful, you'll
> need to call setlocale(LC_CTYPE,...) to determine how byte strings are
> to be interpreted.  For this, I've written a quick & dirty external
> [locale], which has stunning potential for disaster (see the help file
> for one scenario), but does what it should.
>
> I'm still toying with Miller's suggestion of array-based persistent
> strings, but I haven't found a good solution yet: either we access and
> re-interpret g_array's data vector (safe at runtime, but gets  
> mangled on
> save & reload), or we're limited to 24-bit values which t_float can
> losslessly encode.  The latter is more compatible with other pd tools
> ([tabread], [tabwrite], zexy's [tabset], [tabdump]), but the former
> would make wrapping C functions a lot more comfortable... ideas,  
> anyone?
>
> marmosets,
> 	Bryan
>
> -- 
> Bryan Jurish                           "There is *always* one more  
> bug."
> jurish at ling.uni-potsdam.de      -Lubarsky's Law of Cybernetic  
> Entomology
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list



----------------------------------------------------------------------------

All information should be free.  - the hacker ethic