Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #24987 > unrolled thread
| Started by | rwood <rwoodl@nowhere.com> |
|---|---|
| First post | 2016-09-11 15:02 +0800 |
| Last post | 2016-09-12 17:33 +0000 |
| Articles | 13 on this page of 53 — 12 participants |
Back to article view | Back to comp.arch.embedded
XC8 novice question rwood <rwoodl@nowhere.com> - 2016-09-11 15:02 +0800
Re: XC8 novice question Don Y <blockedofcourse@foo.invalid> - 2016-09-11 02:55 -0700
Re: XC8 novice question rwood <rwoodl@nowhere.com> - 2016-09-11 18:25 +0800
Re: XC8 novice question David Brown <david.brown@hesbynett.no> - 2016-09-11 13:35 +0200
Re: XC8 novice question Don Y <blockedofcourse@foo.invalid> - 2016-09-11 07:32 -0700
Re: XC8 novice question David Brown <david.brown@hesbynett.no> - 2016-09-11 16:58 +0200
Re: XC8 novice question Don Y <blockedofcourse@foo.invalid> - 2016-09-11 13:15 -0700
Re: XC8 novice question David Brown <david.brown@hesbynett.no> - 2016-09-12 08:55 +0200
Re: XC8 novice question Don Y <blockedofcourse@foo.invalid> - 2016-09-12 02:41 -0700
Re: XC8 novice question Mike Perkins <spam@spam.com> - 2016-09-12 13:16 +0100
Re: XC8 novice question David Brown <david.brown@hesbynett.no> - 2016-09-12 14:56 +0200
Re: XC8 novice question Mike Perkins <spam@spam.com> - 2016-09-12 14:33 +0100
Re: XC8 novice question David Brown <david.brown@hesbynett.no> - 2016-09-12 16:11 +0200
Re: XC8 novice question Jack <jack4747@gmail.com> - 2016-09-12 07:50 -0700
Re: XC8 novice question David Brown <david.brown@hesbynett.no> - 2016-09-12 22:23 +0200
Re: XC8 novice question Les Cargill <lcargill99@comcast.com> - 2016-09-12 15:34 -0500
Re: XC8 novice question Don Y <blockedofcourse@foo.invalid> - 2016-09-12 08:44 -0700
Re: XC8 novice question David Brown <david.brown@hesbynett.no> - 2016-09-12 14:35 +0200
Re: XC8 novice question Don Y <blockedofcourse@foo.invalid> - 2016-09-12 08:19 -0700
Re: XC8 novice question David Brown <david.brown@hesbynett.no> - 2016-09-12 23:11 +0200
Re: XC8 novice question Dennis <dennis@none.none> - 2016-09-12 17:04 -0500
Re: XC8 novice question Don Y <blockedofcourse@foo.invalid> - 2016-09-12 22:49 -0700
Re: XC8 novice question David Brown <david.brown@hesbynett.no> - 2016-09-13 09:04 +0200
Re: XC8 novice question Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2016-09-13 00:16 +0200
Re: XC8 novice question Don Y <blockedofcourse@foo.invalid> - 2016-09-12 21:22 -0700
Re: XC8 novice question David Brown <david.brown@hesbynett.no> - 2016-09-13 12:25 +0200
Re: XC8 novice question Dennis <dennis@none.none> - 2016-09-13 10:22 -0500
Re: XC8 novice question David Brown <david.brown@hesbynett.no> - 2016-09-13 20:08 +0200
Re: XC8 novice question rwood <rwoodl@nowhere.com> - 2016-09-12 16:50 +0800
Re: XC8 novice question Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-09-11 17:13 +0100
Re: XC8 novice question Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-09-11 17:19 +0100
Re: XC8 novice question David Brown <david.brown@hesbynett.no> - 2016-09-12 09:00 +0200
Re: XC8 novice question Don Y <blockedofcourse@foo.invalid> - 2016-09-11 07:28 -0700
Re: XC8 novice question upsidedown@downunder.com - 2016-09-11 13:56 +0300
Re: XC8 novice question David Brown <david.brown@hesbynett.no> - 2016-09-11 13:28 +0200
Re: XC8 novice question Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2016-09-11 13:36 +0200
Re: XC8 novice question upsidedown@downunder.com - 2016-09-11 16:14 +0300
Re: XC8 novice question Don Y <blockedofcourse@foo.invalid> - 2016-09-11 07:57 -0700
Re: XC8 novice question Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2016-09-12 22:52 +0200
Re: XC8 novice question upsidedown@downunder.com - 2016-09-13 10:11 +0300
Re: XC8 novice question Don Y <blockedofcourse@foo.invalid> - 2016-09-13 01:11 -0700
Re: XC8 novice question upsidedown@downunder.com - 2016-09-13 13:24 +0300
Re: XC8 novice question David Brown <david.brown@hesbynett.no> - 2016-09-13 12:39 +0200
Re: XC8 novice question Don Y <blockedofcourse@foo.invalid> - 2016-09-13 15:41 -0700
Re: XC8 novice question upsidedown@downunder.com - 2016-09-14 09:07 +0300
Re: XC8 novice question Don Y <blockedofcourse@foo.invalid> - 2016-09-13 23:29 -0700
Re: XC8 novice question Don Y <blockedofcourse@foo.invalid> - 2016-09-11 07:50 -0700
Re: XC8 novice question Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2016-09-11 13:42 +0200
Re: XC8 novice question Tim Wescott <tim@seemywebsite.com> - 2016-09-11 20:14 -0500
Re: XC8 novice question rwood <rwoodl@nowhere.com> - 2016-09-12 16:54 +0800
Re: XC8 novice question David Brown <david.brown@hesbynett.no> - 2016-09-12 11:05 +0200
Re: XC8 novice question rwood <rwoodl@nowhere.com> - 2016-09-12 18:48 +0800
Re: XC8 novice question John Temples <usenet@xargs-spam.com> - 2016-09-12 17:33 +0000
Page 3 of 3 — ← Prev page 1 2 [3]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2016-09-13 01:11 -0700 |
| Message-ID | <nr8cak$dt7$1@dont-email.me> |
| In reply to | #25032 |
On 9/13/2016 12:11 AM, upsidedown@downunder.com wrote: > For programming, the most convenient way was to switch the terminal to > US-ASCII, but unfortunately the keyboard layout also changed. > > Digraphs and trigraphs partially solved this problem but was ugly. > > With the introduction of the 8 bit ISO Latin, a large number of > languages and programming could be handled with that single code page, > greatly simplifying data exchange in Europe, Americas, Africa and > Australia. The problem with Unicode is that it makes the problem space bigger. Its relatively easy for a developer to decide on appropriate syntax for file names, etc. with ASCII, Latin1, etc. But, start allowing for all these other code points and suddenly the developer needs to be a *linguist* in order to understand what should/might be an appropriate set of constraints for his particular needs. Also, we *tend* to associate meaning with each of the (e.g.) ASCII code points. So, 16r31 is the *digit* '1'. There's concensus on that interpretation. However, Unicode just tabulates *glyphs* and deprives many of them of any particular semantic value. E.g., if I pick a glyph out of U+[2800,28FF], there's no way a developer would know what my *intent* was in selecting the glyph at that codepoint. It could "mean" many different things (the developer has to IMPOSE a particular meaning -- like deciding that 'A' is not an alphabetic but, rather, a "hexadecimal character" IN THIS CONTEXT)
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2016-09-13 13:24 +0300 |
| Message-ID | <kfjftb5gvv1bgpmth3f2q57akan2b7bi3c@4ax.com> |
| In reply to | #25033 |
On Tue, 13 Sep 2016 01:11:09 -0700, Don Y <blockedofcourse@foo.invalid> wrote: >On 9/13/2016 12:11 AM, upsidedown@downunder.com wrote: >> For programming, the most convenient way was to switch the terminal to >> US-ASCII, but unfortunately the keyboard layout also changed. >> >> Digraphs and trigraphs partially solved this problem but was ugly. >> >> With the introduction of the 8 bit ISO Latin, a large number of >> languages and programming could be handled with that single code page, >> greatly simplifying data exchange in Europe, Americas, Africa and >> Australia. > >The problem with Unicode is that it makes the problem space bigger. >Its relatively easy for a developer to decide on appropriate >syntax for file names, etc. with ASCII, Latin1, etc. But, start >allowing for all these other code points and suddenly the >developer needs to be a *linguist* in order to understand what >should/might be an appropriate set of constraints for his particular >needs. For _file_ names not a problem, stop scanning at next white space (or null in C). Everything in between is the file name, no matter what characters are used. For _path_ specifications, there must be some rules how to separate the node, path, file name, file extension and file version from each other. The separator or other syntactic elements are usually chosen from the original 7 bit ASCII character set. What is between these separators is irrelevant. >Also, we *tend* to associate meaning with each of the (e.g.) ASCII >code points. So, 16r31 is the *digit* '1'. There's concensus on >that interpretation. For _numeric_entry_ fields, including the characters 0-9 requires Arabic numbers fallback mapping. As strange as it sounds, the numbers used in Arabic countries differs from those used in Europe. >However, Unicode just tabulates *glyphs* and deprives many of them >of any particular semantic value. E.g., if I pick a glyph out >of U+[2800,28FF], there's no way a developer would know what my >*intent* was in selecting the glyph at that codepoint. As long as it is just payload data, why should the programmer worry about it ? >It could >"mean" many different things (the developer has to IMPOSE a >particular meaning -- like deciding that 'A' is not an alphabetic >but, rather, a "hexadecimal character" IN THIS CONTEXT) In Unicode, there are code points for hexadecimal 0 to F. Very good idea to separate the dual usage for A to F. Has anyone actually used those code points ?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-13 12:39 +0200 |
| Message-ID | <nr8l0s$8ir$1@dont-email.me> |
| In reply to | #25034 |
On 13/09/16 12:24, upsidedown@downunder.com wrote: > On Tue, 13 Sep 2016 01:11:09 -0700, Don Y > <blockedofcourse@foo.invalid> wrote: > >> On 9/13/2016 12:11 AM, upsidedown@downunder.com wrote: >>> For programming, the most convenient way was to switch the terminal to >>> US-ASCII, but unfortunately the keyboard layout also changed. >>> >>> Digraphs and trigraphs partially solved this problem but was ugly. >>> >>> With the introduction of the 8 bit ISO Latin, a large number of >>> languages and programming could be handled with that single code page, >>> greatly simplifying data exchange in Europe, Americas, Africa and >>> Australia. >> >> The problem with Unicode is that it makes the problem space bigger. >> Its relatively easy for a developer to decide on appropriate >> syntax for file names, etc. with ASCII, Latin1, etc. But, start >> allowing for all these other code points and suddenly the >> developer needs to be a *linguist* in order to understand what >> should/might be an appropriate set of constraints for his particular >> needs. > > For _file_ names not a problem, stop scanning at next white space (or > null in C). Everything in between is the file name, no matter what > characters are used. > That sounds fine - but what is "white space" in unicode? In ASCII, it's space, tab, newline and carriage return characters. In unicode, there are far more. Invisible spaces, non-breaking spaces, spaces of different widths, etc. Did you remember to check for the Ogham space mark, for those Celtic file names? Use UTF-8 and stop on a null character. Just let people put spaces of any sort in their filenames, and you only have to worry about / (or \ and : ) as special characters. > For _path_ specifications, there must be some rules how to separate > the node, path, file name, file extension and file version from each > other. The separator or other syntactic elements are usually chosen > from the original 7 bit ASCII character set. What is between these > separators is irrelevant. > > >> Also, we *tend* to associate meaning with each of the (e.g.) ASCII >> code points. So, 16r31 is the *digit* '1'. There's concensus on >> that interpretation. > > For _numeric_entry_ fields, including the characters 0-9 requires > Arabic numbers fallback mapping. > > As strange as it sounds, the numbers used in Arabic countries differs > from those used in Europe. That's because our "Arabic numerals" came from India, not Arabia - though they were brought over to Europe by an Arabic mathematician. I believe that in Arabic, the term for them translates as "Indian numerals". > >> However, Unicode just tabulates *glyphs* and deprives many of them >> of any particular semantic value. E.g., if I pick a glyph out >> of U+[2800,28FF], there's no way a developer would know what my >> *intent* was in selecting the glyph at that codepoint. > > As long as it is just payload data, why should the programmer worry > about it ? > >> It could >> "mean" many different things (the developer has to IMPOSE a >> particular meaning -- like deciding that 'A' is not an alphabetic >> but, rather, a "hexadecimal character" IN THIS CONTEXT) > > In Unicode, there are code points for hexadecimal 0 to F. Very good > idea to separate the dual usage for A to F. > Has anyone actually used those code points ? > There are lots of cases where the same glyph exists in multiple unicode code points, for different purposes. I have no idea how often they are used.
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2016-09-13 15:41 -0700 |
| Message-ID | <nr9vac$1r6$1@dont-email.me> |
| In reply to | #25034 |
On 9/13/2016 3:24 AM, upsidedown@downunder.com wrote:
> On Tue, 13 Sep 2016 01:11:09 -0700, Don Y
> <blockedofcourse@foo.invalid> wrote:
>
>> On 9/13/2016 12:11 AM, upsidedown@downunder.com wrote:
>>> For programming, the most convenient way was to switch the terminal to
>>> US-ASCII, but unfortunately the keyboard layout also changed.
>>>
>>> Digraphs and trigraphs partially solved this problem but was ugly.
>>>
>>> With the introduction of the 8 bit ISO Latin, a large number of
>>> languages and programming could be handled with that single code page,
>>> greatly simplifying data exchange in Europe, Americas, Africa and
>>> Australia.
>>
>> The problem with Unicode is that it makes the problem space bigger.
>> Its relatively easy for a developer to decide on appropriate
>> syntax for file names, etc. with ASCII, Latin1, etc. But, start
>> allowing for all these other code points and suddenly the
>> developer needs to be a *linguist* in order to understand what
>> should/might be an appropriate set of constraints for his particular
>> needs.
>
> For _file_ names not a problem, stop scanning at next white space (or
> null in C). Everything in between is the file name, no matter what
> characters are used.
The file system code is easy cuz it doesn't have to impart meaning to
any particular "characters". But, a there are typically human beings
involved who *do* impart meaning to certain glyphs (as well as the
OS itself), the developer can't ignore that expected meaning.
I want to use the eight character name "////\\\\". Or, "::::::::".
Or, "><&&&&><".
How do I differentiate between "RSTUV" and "RSTU<roman numeral 5>"?
(i.e., people already have trouble visually disambiguating between
the '0' and 'O' glyphs, '1' and 'l', etc.)
Do you allow control characters in file/pathnames?
Why *not* whitespace"? I have a file called "My To-Do List" and
don't have any problems accessing it, etc.
The developer (not the character set) is responsible for presenting
this information in a form that is useful to the user. E.g., MS
will sort files named "1" through "99" as:
1, 2, ... 10, 11... 20, 21... 99
whereas UNIX will use a L-R alpha sort:
1, 10, 11..., 2, 20, 21... 99
Will the "RSTUV" user above expect to see "RSTU<roman numeral 5>"
immediately following "RSTUU"? And, where would "RSTUV" fit in
that scheme?
> For _path_ specifications, there must be some rules how to separate
> the node, path, file name, file extension and file version from each
> other. The separator or other syntactic elements are usually chosen
> from the original 7 bit ASCII character set. What is between these
> separators is irrelevant.
I parse my namespaces without regard to specific separators.
So, in some objects' identifiers, '/' can be a valid character
while it may have delimited the start of that object name
in the *containing* object. E.g., the single "o/b/j/e/c/t" exists
within the named "container" in the following:
container/o/b/j/e/c/t
>> Also, we *tend* to associate meaning with each of the (e.g.) ASCII
>> code points. So, 16r31 is the *digit* '1'. There's concensus on
>> that interpretation.
>
> For _numeric_entry_ fields, including the characters 0-9 requires
> Arabic numbers fallback mapping.
Why? shouldn't the glyphs for the Thai digits (or Laotian) also be
recognized as numeric? Likewise for the roman numerals, the *fullwidth*
(arabic) digits, etc.?
A particular braille glyph means different things based on how
the application/user interprets it.
For example, the letter 'A' is denoted by a single dot in the upper
left corner of the cell. 'B' adds the dot immediately below while
'C' adds the dot to the immediate right, instead.
Yet, in music braille, the "note" 'A' is denoted by a cell that
is the union of the letters 'B' and 'C' *less* the letter 'A'
A B C
*. *. **
.. *. ..
.. .. ..
Notes:
A B C
.* .* **
*. ** .*
.. .. ..
I.e., the same glyph means different things. Imagine labeling a file
of sound samples with their corresponding "notes"...
> As strange as it sounds, the numbers used in Arabic countries differs
> from those used in Europe.
>
>> However, Unicode just tabulates *glyphs* and deprives many of them
>> of any particular semantic value. E.g., if I pick a glyph out
>> of U+[2800,28FF], there's no way a developer would know what my
>> *intent* was in selecting the glyph at that codepoint.
>
> As long as it is just payload data, why should the programmer worry
> about it ?
Because the programmer has to deal with the glyph's *meaning* to the
user. Otherwise, why not just list file names and content as 4 digit
unicode codepoints and eliminate the hassle of rendering fonts,
imparting meaning, etc.?
>> It could
>> "mean" many different things (the developer has to IMPOSE a
>> particular meaning -- like deciding that 'A' is not an alphabetic
>> but, rather, a "hexadecimal character" IN THIS CONTEXT)
>
> In Unicode, there are code points for hexadecimal 0 to F. Very good
> idea to separate the dual usage for A to F.
> Has anyone actually used those code points ?
The 10 arabic digits that we are accustomed to exist as
U+0030 - U+0039 as well as U+FF10 - U+FF19. Then, there are
the 10 arabic-indic digits, 10 extended arabic-indic digits,
10 mongolian digits, 10 laotian digits, etc.
[We'll ingore dingbat digits, circled digits, super/subscripted
digits, etc.]
Then, stacking glyphs (e.g., the equivalent of diacriticals)...
There's just WAY too much effort involved making sense of Unicode
in a way that your *users* will appreciate and consider intuitive.
When faced with the I18N/L10N issues, I found it MUCH easier to
*punt* (if they don't speak English, that's THEIR problem; or, a
task for someone with more patience/resources than me!)
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2016-09-14 09:07 +0300 |
| Message-ID | <olohtb5gbk84ohclmv9ljqtnf8v1i56uqd@4ax.com> |
| In reply to | #25039 |
On Tue, 13 Sep 2016 15:41:24 -0700, Don Y <blockedofcourse@foo.invalid> wrote: >On 9/13/2016 3:24 AM, upsidedown@downunder.com wrote: >> On Tue, 13 Sep 2016 01:11:09 -0700, Don Y >> <blockedofcourse@foo.invalid> wrote: >> >>> On 9/13/2016 12:11 AM, upsidedown@downunder.com wrote: >>>> For programming, the most convenient way was to switch the terminal to >>>> US-ASCII, but unfortunately the keyboard layout also changed. >>>> >>>> Digraphs and trigraphs partially solved this problem but was ugly. >>>> >>>> With the introduction of the 8 bit ISO Latin, a large number of >>>> languages and programming could be handled with that single code page, >>>> greatly simplifying data exchange in Europe, Americas, Africa and >>>> Australia. >>> >>> The problem with Unicode is that it makes the problem space bigger. >>> Its relatively easy for a developer to decide on appropriate >>> syntax for file names, etc. with ASCII, Latin1, etc. But, start >>> allowing for all these other code points and suddenly the >>> developer needs to be a *linguist* in order to understand what >>> should/might be an appropriate set of constraints for his particular >>> needs. >> >> For _file_ names not a problem, stop scanning at next white space (or >> null in C). Everything in between is the file name, no matter what >> characters are used. > >The file system code is easy cuz it doesn't have to impart meaning to >any particular "characters". But, a there are typically human beings >involved who *do* impart meaning to certain glyphs (as well as the >OS itself), the developer can't ignore that expected meaning. > >I want to use the eight character name "////\\\\". Or, "::::::::". >Or, "><&&&&><". > >How do I differentiate between "RSTUV" and "RSTU<roman numeral 5>"? Depending on usage. For text rendering, either have a slightly modified glyph for U+2165 or use the fallback letter-V (usable as well as for normal text sorting). However, if the numeric value is of interest, a sequence of roman numerals like LXV would be handled as numeric value of 65. >(i.e., people already have trouble visually disambiguating between >the '0' and 'O' glyphs, '1' and 'l', etc.) This is a glyph problem in which similar looking symbols generate different code points. >Do you allow control characters in file/pathnames? Such as null ? Why not, but the usage might be a bit problematic. >Why *not* whitespace"? I have a file called "My To-Do List" and >don't have any problems accessing it, etc. With a purely GUI user interface, not a big problem. However with direct command line entry or scripts will require all kinds of escape mechanisms. > >The developer (not the character set) is responsible for presenting >this information in a form that is useful to the user. E.g., MS >will sort files named "1" through "99" as: > 1, 2, ... 10, 11... 20, 21... 99 >whereas UNIX will use a L-R alpha sort: > 1, 10, 11..., 2, 20, 21... 99 > >Will the "RSTUV" user above expect to see "RSTU<roman numeral 5>" >immediately following "RSTUU"? And, where would "RSTUV" fit in >that scheme? Depending on sorting locale. Since sorting locales are usually different from language to language, you could create your own locale for exactly what you want. >> For _path_ specifications, there must be some rules how to separate >> the node, path, file name, file extension and file version from each >> other. The separator or other syntactic elements are usually chosen >> from the original 7 bit ASCII character set. What is between these >> separators is irrelevant. > >I parse my namespaces without regard to specific separators. >So, in some objects' identifiers, '/' can be a valid character >while it may have delimited the start of that object name >in the *containing* object. E.g., the single "o/b/j/e/c/t" exists >within the named "container" in the following: > container/o/b/j/e/c/t > >>> Also, we *tend* to associate meaning with each of the (e.g.) ASCII >>> code points. So, 16r31 is the *digit* '1'. There's concensus on >>> that interpretation. >> >> For _numeric_entry_ fields, including the characters 0-9 requires >> Arabic numbers fallback mapping. > >Why? shouldn't the glyphs for the Thai digits (or Laotian) also be >recognized as numeric? Likewise for the roman numerals, the *fullwidth* >(arabic) digits, etc.? Yes of course, use fallback character mapping from Thai digit 1 to Arabic digit 1. The Roman numerals are more complex, since they do not use the positional system. > >A particular braille glyph means different things based on how >the application/user interprets it. > >For example, the letter 'A' is denoted by a single dot in the upper >left corner of the cell. 'B' adds the dot immediately below while >'C' adds the dot to the immediate right, instead. > >Yet, in music braille, the "note" 'A' is denoted by a cell that >is the union of the letters 'B' and 'C' *less* the letter 'A' > >A B C >*. *. ** >.. *. .. >.. .. .. > >Notes: >A B C >.* .* ** >*. ** .* >.. .. .. > >I.e., the same glyph means different things. Imagine labeling a file >of sound samples with their corresponding "notes"... > >> As strange as it sounds, the numbers used in Arabic countries differs >> from those used in Europe. >> >>> However, Unicode just tabulates *glyphs* and deprives many of them >>> of any particular semantic value. E.g., if I pick a glyph out >>> of U+[2800,28FF], there's no way a developer would know what my >>> *intent* was in selecting the glyph at that codepoint. >> >> As long as it is just payload data, why should the programmer worry >> about it ? > >Because the programmer has to deal with the glyph's *meaning* to the >user. Otherwise, why not just list file names and content as 4 digit >unicode codepoints and eliminate the hassle of rendering fonts, >imparting meaning, etc.? > >>> It could >>> "mean" many different things (the developer has to IMPOSE a >>> particular meaning -- like deciding that 'A' is not an alphabetic >>> but, rather, a "hexadecimal character" IN THIS CONTEXT) >> >> In Unicode, there are code points for hexadecimal 0 to F. Very good >> idea to separate the dual usage for A to F. >> Has anyone actually used those code points ? > >The 10 arabic digits that we are accustomed to exist as >U+0030 - U+0039 as well as U+FF10 - U+FF19. Then, there are >the 10 arabic-indic digits, 10 extended arabic-indic digits, >10 mongolian digits, 10 laotian digits, etc. Use fallback mapping for numeric entry, use original code points for rendering. >[We'll ingore dingbat digits, circled digits, super/subscripted >digits, etc.] Use foldback mapping. >Then, stacking glyphs (e.g., the equivalent of diacriticals)... > >There's just WAY too much effort involved making sense of Unicode >in a way that your *users* will appreciate and consider intuitive. >When faced with the I18N/L10N issues, I found it MUCH easier to >*punt* (if they don't speak English, that's THEIR problem; or, a >task for someone with more patience/resources than me!) Why would a person have to speak English or even know latin letters to use a computer such as a cell phone ?
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2016-09-13 23:29 -0700 |
| Message-ID | <nraqo1$m6t$1@dont-email.me> |
| In reply to | #25040 |
On 9/13/2016 11:07 PM, upsidedown@downunder.com wrote: >> There's just WAY too much effort involved making sense of Unicode >> in a way that your *users* will appreciate and consider intuitive. >> When faced with the I18N/L10N issues, I found it MUCH easier to >> *punt* (if they don't speak English, that's THEIR problem; or, a >> task for someone with more patience/resources than me!) > > Why would a person have to speak English or even know latin letters to > use a computer such as a cell phone ? I'm not designing a cell phone. And, both parties (user and device) *speak* to each other. Should I also add learning foreign pronunciation algorithms to my list of design issues? :>
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2016-09-11 07:50 -0700 |
| Message-ID | <nr3quv$6k5$1@dont-email.me> |
| In reply to | #24990 |
On 9/11/2016 3:56 AM, upsidedown@downunder.com wrote: > On Sun, 11 Sep 2016 02:55:23 -0700, Don Y > <blockedofcourse@foo.invalid> wrote: > >> On 9/11/2016 12:02 AM, rwood wrote: >>> Novice question using MPLABx + XC8 >>> >>> If i define my_variable using; >>> >>> #define my_variable 0b10000000 >>> >>> And then I use it in a function that expects a 'char'; >>> >>> void my_function(char i); >>> >>> >>> >>> I get a compiler warning; >>> >>> warning: (752) conversion to shorter data type >>> >>> By changing the function prototype to expect an 'int' the warning goes away so >>> I think the defined my_variable is being assigned as an 'int' >>> >>> So my question is how or can I structure my define so the defined my_variable >>> is assigned as a 'char'.. >>> >>> I cannot see anything useful in the mplabx documentation. >> >> Why not explicitly cast the value to a "char" in the define-ition >> (*if* you expect to always use it as such)? >> >> Note that you should decide if you do/don't care about signedness >> of the value (i.e., is this value 128 or -127?) as "char" can vary >>from implementation to implementation. > > Are there still some idiotic systems that are defining char as > _signed_ ???? Apparently so! Regardless (always worth a chuckle to say "irregardless"!), it's a latitude that the compiler has been afforded. You don't want the compiler to make *any* decisions for you regarding the suitability of a particular value (in an assignment, calculation, etc.). > If we really have to use such outdated systems, why aren't we using 6 > bit characters with all upper case (or all lower case) ? In fact why > not use 5 bit Baudot as in Manchester computers ? TDD's and Telex still use 5b codes (well, I dunno if Telex is still around; it's been 30+ years since I worked with it... or TWX for that matter!). [N.B. converting between it and USASCII isn't a "linear mathematical transform"; a lookup table is almost the only effective approach (coupled with a "FIGS/LTRS" state bit). By contrast, USASCII <-> EBCDIC is far more easier to "mathematically transform". Gray codes, OTOH, convert easier one way than the other!]
[toc] | [prev] | [next] | [standalone]
| From | Hans-Bernhard Bröker <HBBroeker@t-online.de> |
|---|---|
| Date | 2016-09-11 13:42 +0200 |
| Message-ID | <e3kuaaF3144U1@mid.dfncis.de> |
| In reply to | #24987 |
Am 11.09.2016 um 09:02 schrieb rwood: > If i define my_variable using; > > #define my_variable 0b10000000 That's a blatant misnomer, because that's not at all a variable. It's a constant-valued macro. The distinction is important, so maybe you should go back to your training materials to learn more. > I get a compiler warning; > > warning: (752) conversion to shorter data type Of course you do. Another subject to look up in the books: what is the type of an integer constant? You'll have to check the compiler manual here, too, because that's non-standard syntax in your constant. > By changing the function prototype to expect an 'int' the warning goes > away so I think the defined my_variable is being assigned as an 'int' It's not assigned at all. Please learn about the difference between the preprocessor and the compiler proper.
[toc] | [prev] | [next] | [standalone]
| From | Tim Wescott <tim@seemywebsite.com> |
|---|---|
| Date | 2016-09-11 20:14 -0500 |
| Message-ID | <YtedncVvMMr9nEvKnZ2dnUU7-UNg4p2d@giganews.com> |
| In reply to | #24987 |
On Sun, 11 Sep 2016 15:02:48 +0800, rwood wrote: > Novice question using MPLABx + XC8 > > > > > If i define my_variable using; > > #define my_variable 0b10000000 > > > And then I use it in a function that expects a 'char'; > > void my_function(char i); > > > > I get a compiler warning; > > warning: (752) conversion to shorter data type > > > > > By changing the function prototype to expect an 'int' the warning goes > away so I think the defined my_variable is being assigned as an 'int' > > > So my question is how or can I structure my define so the defined > my_variable is assigned as a 'char'.. > > > I cannot see anything useful in the mplabx documentation. I assume this is C11 we're talking about, or some vendor-specific C. At any rate, a #define is a preprocessor operation that just does a text substitution. So as far as the compiler itself is concerned, you didn't call my_function(my_variable); you called my_function(0b10000000); Since literal numerical constants default to type 'int' in C, this means that the compiler "sees" an int with a value that _just happens_ to be small enough to fit into a character. Two good ways to get around this are to define my_variable as a const (really, it should be "my_constant"), or to use a cast: static const char my_variable = 0b10000000; OR #define my_variable ((char)(0b10000000)) A halfway decent compiler will see the "static const" business and, unless you take the address of "my_variable" will just quietly turn it into a constant in the background, and optimize out actually putting it somewhere in memory. -- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.com
[toc] | [prev] | [next] | [standalone]
| From | rwood <rwoodl@nowhere.com> |
|---|---|
| Date | 2016-09-12 16:54 +0800 |
| Message-ID | <PMCdnfTd9Mzf8EvKnZ2dnUU7-VWdnZ2d@westnet.com.au> |
| In reply to | #24987 |
On 11-Sep-16 3:02 PM, rwood wrote: > Novice question using MPLABx + XC8 > > > > > If i define my_variable using; > > #define my_variable 0b10000000 > > > And then I use it in a function that expects a 'char'; > > void my_function(char i); > > > > I get a compiler warning; > > warning: (752) conversion to shorter data type > > > > > By changing the function prototype to expect an 'int' the warning goes > away so I think the defined my_variable is being assigned as an 'int' > > > So my question is how or can I structure my define so the defined > my_variable is assigned as a 'char'.. > > > I cannot see anything useful in the mplabx documentation. > > Thanks. > > > Thanks to all who responded to my request for help. I tried a few of the suggestions and ended up increasing the parameter expected by the function to an 'int'. It clears up all the warnings. I'd have preferred to have the constant cast as an 'char' but it seems the compiler won't play ball on doing that. Thanks to all!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-12 11:05 +0200 |
| Message-ID | <nr5r4l$p7t$1@dont-email.me> |
| In reply to | #25010 |
On 12/09/16 10:54, rwood wrote: > On 11-Sep-16 3:02 PM, rwood wrote: >> Novice question using MPLABx + XC8 >> >> >> >> >> If i define my_variable using; >> >> #define my_variable 0b10000000 >> >> >> And then I use it in a function that expects a 'char'; >> >> void my_function(char i); >> >> >> >> I get a compiler warning; >> >> warning: (752) conversion to shorter data type >> >> >> >> >> By changing the function prototype to expect an 'int' the warning goes >> away so I think the defined my_variable is being assigned as an 'int' >> >> >> So my question is how or can I structure my define so the defined >> my_variable is assigned as a 'char'.. >> >> >> I cannot see anything useful in the mplabx documentation. >> >> Thanks. >> >> >> > > > Thanks to all who responded to my request for help. > > I tried a few of the suggestions and ended up increasing the parameter > expected by the function to an 'int'. It clears up all the warnings. I'd > have preferred to have the constant cast as an 'char' but it seems the > compiler won't play ball on doing that. > > Thanks to all! If you learn anything from this thread, it should be that you never use "char" for numbers. Use "uint8_t" or "int8_t" depending on whether you want unsigned or signed types. This is /critical/ to writing good embedded software, especially on 8-bit devices.
[toc] | [prev] | [next] | [standalone]
| From | rwood <rwoodl@nowhere.com> |
|---|---|
| Date | 2016-09-12 18:48 +0800 |
| Message-ID | <e9udnR-Fhv2IFUvKnZ2dnUU7-KednZ2d@westnet.com.au> |
| In reply to | #25011 |
On 12-Sep-16 5:05 PM, David Brown wrote: > On 12/09/16 10:54, rwood wrote: >> On 11-Sep-16 3:02 PM, rwood wrote: >>> Novice question using MPLABx + XC8 >>> >>> >>> >>> >>> If i define my_variable using; >>> >>> #define my_variable 0b10000000 >>> >>> >>> And then I use it in a function that expects a 'char'; >>> >>> void my_function(char i); >>> >>> >>> >>> I get a compiler warning; >>> >>> warning: (752) conversion to shorter data type >>> >>> >>> >>> >>> By changing the function prototype to expect an 'int' the warning goes >>> away so I think the defined my_variable is being assigned as an 'int' >>> >>> >>> So my question is how or can I structure my define so the defined >>> my_variable is assigned as a 'char'.. >>> >>> >>> I cannot see anything useful in the mplabx documentation. >>> >>> Thanks. >>> >>> >>> >> >> >> Thanks to all who responded to my request for help. >> >> I tried a few of the suggestions and ended up increasing the parameter >> expected by the function to an 'int'. It clears up all the warnings. I'd >> have preferred to have the constant cast as an 'char' but it seems the >> compiler won't play ball on doing that. >> >> Thanks to all! > > If you learn anything from this thread, it should be that you never use > "char" for numbers. Use "uint8_t" or "int8_t" depending on whether you > want unsigned or signed types. This is /critical/ to writing good > embedded software, especially on 8-bit devices. > > > I've picked up quite a bit from this thread - as you can probably guess! I'll revisit my code and reassess the data types for all my variables. Thanks David.
[toc] | [prev] | [next] | [standalone]
| From | John Temples <usenet@xargs-spam.com> |
|---|---|
| Date | 2016-09-12 17:33 +0000 |
| Message-ID | <slrnntdpmq.3ls.usenet@xargs-spam.com> |
| In reply to | #24987 |
On 2016-09-11, rwood <rwoodl@nowhere.com> wrote: > Novice question using MPLABx + XC8 > > If i define my_variable using; > > #define my_variable 0b10000000 > > And then I use it in a function that expects a 'char'; > > void my_function(char i); > > I get a compiler warning; > > warning: (752) conversion to shorter data type It's a known issue with the compiler. The support team has logged it, so it may get fixed at some point. If you Google the warning, you will find many threads discussing the issue on the Microchip support forum.
[toc] | [prev] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | comp.arch.embedded
csiph-web