On Wed, Mar 26, 2014 at 12:03 PM, Fraser Gordon wrote:
> On 26 Mar 2014, at 15:37, Geoff Canyon wrote:
>
> >
> > "somebody, somewhere, might be depending on the fact that it interprets
> the
> > number modulo 256"
>
> We've already had a bug report against 7.0 because it wasn't doing that in
> ce
On 26 Mar 2014, at 15:37, Geoff Canyon wrote:
>
> "somebody, somewhere, might be depending on the fact that it interprets the
> number modulo 256"
We've already had a bug report against 7.0 because it wasn't doing that in
certain cases.
The problem with making non-compatible changes to exist
Sorry for the delayed response. My point wasn't to start an Apple vs. MS
war, it was simply to illustrate a clear ill that plagues MS non-stop:
overwhelming backwards compatibility. Specifically:
"somebody, somewhere, might be depending on the fact that it interprets the
number modulo 256"
My poi
On Fri, Mar 21, 2014 at 8:12 AM, Bob Sneidar wrote:
> But Apple of late has not blown my skirt up either. Soldering memory to
> the motherboard?? And why??? Well they will cite cost of production, but
> how curious that we can no longer take advantage of the price match
> guarantee on a memory up
Fraser wrote:
That's the reason behind most of the functions we've marked as deprecated
in 7.0 - upgrading them to support Unicode would break existing stacks in
subtle ways
Geoff wrote:
That's the Microsoft way to handle this. The Apple way would simply
be to do the right thing -- if you wan
Apple vs Microsoft anyone? I’m not a huge Microsoft fan, but I have to
work with it everyday as part of my job, so I’ve learned to live with it. But
Apple of late has not blown my skirt up either. Soldering memory to the
motherboard?? And why??? Well they will cite cost of production, but how
On Fri, Mar 21, 2014 at 6:56 AM, Fraser Gordon wrote:
> That's the reason behind most of the functions we've marked as deprecated
> in 7.0 - upgrading them to support Unicode would break existing stacks in
> subtle ways (e.g. numToChar - somebody, somewhere, might be depending on
> the fact that i
On 21 Mar 2014, at 01:36, Mark Wieder wrote:
>
> Thanks. Most of that makes sense, but why not alias the deprecated
> uni* functions to text* functions rather than just having them return
> the wrong thing?
UniEncode would alias to textDecode and uniDecode to textEncode as the closest
equivale
Fraser-
Thursday, March 20, 2014, 10:50:28 AM, you wrote:
> One annoyance is that the unicodeText of a field is not, in fact,
> unicode text in the 7.0 engine - it is binary data. Similarly, the
> uniEncode and uniDecode functions convert between two different
> forms of binary data rather than b
Ben
On 21 Mar 2014, at 02:40, Ben Rubinstein wrote:
> That probably means in fact that all the characters are in ISO-8859-1 (I
> think that the one-byte characters in UTF8 approximately correspond to
> ISO-8859-1, but I'm prepared to be corrected).
UTF-8 only has 128 one-byte characters (0 - 1
On 20/03/2014 15:37, Geoff Canyon wrote:
I have a field that has been populated by setting the unicodetext. Some
lines actually need unicode -- umlauts, enye, etc. -- and others are plain
ascii.
What's the most efficient way to count how many lines are plain and how
many actually need unicode?
On 20 Mar 2014, at 17:39, Mark Wieder wrote:
> put unidecode("hello bucko")
>
> converts the text to 敨汬Ɐ戠捵潫.
Thinking about this a bit more, I ought to write something up about how text
and binary work in the 7.0 engine and how this relates to the existing ways of
doing things.
The short ve
Colin Holgate writes:
>
> When I try that I get 敨汬畢正
>
> On Mar 20, 2014, at 1:39 PM, Mark Wieder ahsoftware.net> wrote:
>
> >
> > put unidecode("hello bucko")
> >
> > converts the text to 敨汬Ɐ戠捵潫.
Ah. Right. So do I. I had a comma after the hello originally, and it didn't
make it into the
On 20 Mar 2014, at 17:28, Mark Wieder wrote:
>
> In that case, shouldn't the setUnicode value be "true" rather than false?
> And does it make sense to have that property settable any more?
All the previous Unicode functionality has been left as-is in order to avoid
breaking existing stacks. Ho
When I try that I get 敨汬畢正
On Mar 20, 2014, at 1:39 PM, Mark Wieder wrote:
>
> put unidecode("hello bucko")
>
> converts the text to 敨汬Ɐ戠捵潫.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe
Fraser Gordon writes:
> In LiveCode 7.0, all text is Unicode and there is no such thing as
"non-Unicode text". There are ways to
> convert text to and from legacy 8-bit encodings (like MacRoman) when doing
I/O to
> files/sockets/processes/etc but (in the engine at least) all text is Unicode.
Um.
Get the styledText of a field and check it for any "unicodeText"
elements. (Or will that be meaningless in 7.0 when everything is Unicode?)
Phil
On 3/20/14, 8:37 AM, Geoff Canyon wrote:
I have a field that has been populated by setting the unicodetext. Some
lines actually need unicode -- umla
Fraser Gordon writes:
> In LiveCode 7.0, all text is Unicode and there is no such thing as
"non-Unicode text".
In that case, shouldn't the setUnicode value be "true" rather than false?
And does it make sense to have that property settable any more?
--
Mark Wieder
ahsoftw...@gmail.com
_
On Thu, Mar 20, 2014 at 11:47 AM, Fraser Gordon wrote:
> Out of interest - why are you trying to do this? I ask because trying to
> do so may not be useful in future versions of LiveCode.
I'm preparing data for use through an API. The API doesn't support unicode,
so any entries I create that inc
On 20 Mar 2014, at 15:37, Geoff Canyon wrote:
> What's the most efficient way to count how many lines are plain and how
> many actually need unicode?
Out of interest - why are you trying to do this? I ask because trying to do so
may not be useful in future versions of LiveCode.
In LiveCode 7.
I have a field that has been populated by setting the unicodetext. Some
lines actually need unicode -- umlauts, enye, etc. -- and others are plain
ascii.
What's the most efficient way to count how many lines are plain and how
many actually need unicode?
The best thing I've come up with so far is
21 matches
Mail list logo
