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
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@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic
Entomology
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
All information should be free. - the hacker ethic
-
Bryan Jurish -
Hans-Christoph Steiner