morning again all,
On 2009-01-19 15:19:04, Martin Peach appears
to have written:
> Bryan Jurish wrote:
>> well, without wanting to be trite, I have to say that think that "data
>> transmission" and "linguistic processing" are pretty much synonymous.
>
> Pretty much but linguistic processing is h
Bryan Jurish wrote:
> moin all,
>
> well, without wanting to be trite, I have to say that think that "data
> transmission" and "linguistic processing" are pretty much synonymous.
Pretty much but linguistic processing is happening at a higher level
than data transmission, and the 'character' used
moin all,
On 2009-01-18 19:41:06, Roman Haefeli appears to
have written:
> On Sun, 2009-01-18 at 13:46 +0100, IOhannes m zmoelnig wrote:
>> Martin Peach wrote:
>> i always thought that bryan's "pdstrings" was intended for purposes of
>> linguistic processing (unlike a lot of your objects that are
On Jan 17, 2009, at 1:58 PM, Martin Peach wrote:
> Mathieu Bouchard wrote:
>> On Sat, 17 Jan 2009, Bryan Jurish wrote:
>>
>>> OK. I guess I'll make unsigned values the default for [any2string]
>>> then, postponing the issue of name change to [any2bytes] rsp.
>>> [bytes2any] to a hypothetical fut
On Jan 17, 2009, at 5:37 AM, Bryan Jurish wrote:
> morning all,
>
> On 2009-01-15 22:51:14, Hans-Christoph Steiner
> appears to
> have written:
>> As for the simple question of unsigned versus signed for
>> any2string, I
>> have never heard of using negative values for chars, so it makes
>
On Sun, 2009-01-18 at 13:46 +0100, IOhannes m zmoelnig wrote:
> Martin Peach wrote:
> > a string of bytes, for transmission. I think [any2string] is intended
> > for purposes of serialization, to send data through a byte-oriented
> > channel such as a serial port, ethernet, or file.
>
> i always
Martin Peach wrote:
> a string of bytes, for transmission. I think [any2string] is intended
> for purposes of serialization, to send data through a byte-oriented
> channel such as a serial port, ethernet, or file.
i always thought that bryan's "pdstrings" was intended for purposes of
linguistic
Mathieu Bouchard wrote:
> On Sat, 17 Jan 2009, Bryan Jurish wrote:
>
>> OK. I guess I'll make unsigned values the default for [any2string]
>> then, postponing the issue of name change to [any2bytes] rsp.
>> [bytes2any] to a hypothetical future in which the "string" suffix
>> implies unicode or
On Sat, 17 Jan 2009, Bryan Jurish wrote:
OK. I guess I'll make unsigned values the default for [any2string]
then, postponing the issue of name change to [any2bytes] rsp.
[bytes2any] to a hypothetical future in which the "string" suffix
implies unicode or other non-byte-oriented representation
morning all,
On 2009-01-15 22:51:14, Hans-Christoph Steiner appears to
have written:
> As for the simple question of unsigned versus signed for any2string, I
> have never heard of using negative values for chars, so it makes perfect
> sense to me to use 0-255. That'll will give at least the full
moin moin,
On 2009-01-16 15:56:22, Mathieu Bouchard appears to
have written:
> you have to use Pd's lists, and then it's 64 or 128 bits per char.
>
> And then, in theory, Pd could adopt any internal rep, as long as file
> I/O and socket I/O is done the way it needs to be done.
... which (if I u
On Fri, 16 Jan 2009, Bryan Jurish wrote:
UTF-8 also does a pretty good job of compactly representing latin
character sets for natural language data, where non-ASCII characters
tend to be relatively infrequent anyways. UTF-16 and UTF-32 are pretty
wasteful in these cases. (Of course, I'm biting
moin again all,
On 2009-01-15 20:37:12, Mathieu Bouchard appears to
have written:
> On Thu, 15 Jan 2009, IOhannes m zmoelnig wrote:
>
>> so does anybody object to use an "unsigned" type rather than a signed
>> one?
>> expanding "uchar" to "uint" or whatever is no-work on the Pd-side of
>> things
moin Mathieu, moin all,
On 2009-01-15 20:45:13, Mathieu Bouchard appears to
have written:
> On Thu, 15 Jan 2009, Bryan Jurish wrote:
>
>> byte-strings are IMHO the more basic representation (a
>> char* is still a char*, even in this post-unicode world).
>
> What happened is that people switched
Unicode would be great, if someone wants to implement that in Pd, I
would fully support that.
As for the simple question of unsigned versus signed for any2string, I
have never heard of using negative values for chars, so it makes
perfect sense to me to use 0-255. That'll will give at least
On Thu, 15 Jan 2009, Bryan Jurish wrote:
Unicode might be more immediately intuitive to most users, but when it
comes down to it, byte-strings are IMHO the more basic representation (a
char* is still a char*, even in this post-unicode world).
What happened is that people switched to UTF-8 inst
On Thu, 15 Jan 2009, IOhannes m zmoelnig wrote:
so does anybody object to use an "unsigned" type rather than a signed one?
expanding "uchar" to "uint" or whatever is no-work on the Pd-side of things.
It's not that, it's that if you have ΓΌ (u umlaut) taken from a UTF-8 file,
then do you treat
moin Mathieu, moin all,
On 2009-01-15 16:33:03, Mathieu Bouchard appears to
have written:
> On Thu, 15 Jan 2009, Bryan Jurish wrote:
>
>> Would anyone object if the [any2string] semantics were changed so that
>> only "unsigned char" values in the range (0..255) get output, rather
>> than (as is
Mathieu Bouchard wrote:
On Thu, 15 Jan 2009, Bryan Jurish wrote:
Would anyone object if the [any2string] semantics were changed so that
only "unsigned char" values in the range (0..255) get output, rather
than (as is currently the case) "signed char" values in the range
(-128..127)?
I would
On Thu, 15 Jan 2009, Bryan Jurish wrote:
Would anyone object if the [any2string] semantics were changed so that
only "unsigned char" values in the range (0..255) get output, rather
than (as is currently the case) "signed char" values in the range
(-128..127)?
I would object, as I expect to b
morning all,
Would anyone object if the [any2string] semantics were changed so that
only "unsigned char" values in the range (0..255) get output, rather
than (as is currently the case) "signed char" values in the range
(-128..127)?
For reasons to do so other than the purely aesthetic, see Roman's
21 matches
Mail list logo
