Can you please say how version compare works for UpdateCheck? How Checker determines that version in updates.xml is newer than his version?
For example, my versioning is using formula YEAR/MAJOR.MINOR: 2015/1, 2015/1.1, 2015/1.2, 2015/2, 2016/1 and so on. But I also have specific releases as 2015/1.2-LOK15. How these version numbers will be compared during version check?
Thank you in advance.
install4j transforms the version string into an array of version components. The separators for creating numeric version components are ".", "-" and "_". Each version component has an optional leading text part and a trailing numeric part. The text parts are compared lexically, the version parts are compared numerically.
Version components that start with non-numeric characters, like "LOK15" are generally considered to be pre-cursor versions to the same version component without the text part (like "beta" or "RC"). So 2015/1.2-LOK15 is considered to be lower than 2015/1.2. However 2015/1.2-15LOK would be higher than 2015/1.2.
Related
Not a question but a small contribution, since I was not finding the information anywhere.
The problem appears even with a proper utf8 locale with "older" versions versions of less.
If you cannot update to a version of less correcting the issue, I found a workaround :
export LESSUTFBINFMT=*n%C
this instructs less to process any Unicode code points that were successfully decoded and display them with normal attributes (*n) and as-they-are (%C).
Notes:
I found the %C format by trial-and-error, I didn't find it explicitly documented.
I found this description of the issue : redhat bug 1074489
It mentions a newer version of less solving it in 2014, but I still run into this problem with a less-458-9.el7 from 2018.
(this question is based on that)
Let us consider the following code:
package require Tk 8.6
pack [text .t]
.t insert end "abcdefgh\nабвгґдеє\n一伊依医咿噫欹泆"
puts "[.t index 1.4+1l] [.t index 1.4+2l]"
puts "[.t index 3.4-1l] [.t index 3.4-2l]"
exit 0
Output:
2.2 3.2
2.6 1.8
I would rather expect +1l and -1l to preserve the column if the line is long enough, that is, to print 2.4 3.4 and 2.4 1.4. It looks like the result depends on the number of bytes needed to encode each character.
Should it be this way? Is it documented somewhere?
What font are you using? What exact patch-version of Tk are you using? (It should be reported by doing puts [package require Tk].)
I think the text widget currently uses character widths when working out the actual motions when doing index movement by lines. This has changed between past versions. The problem is that different bits of code want different things: sometimes you want visible motions (e.g., when handling users' cursor motion, especially with tabs set) and sometimes you want character-space motions (which is what you appear to be expecting).
Tk shouldn't ever be doing anything (you can see) with the byte widths of unicode characters. It's really supposed to handle that transparently (at least for any character in the Basic Multilingual Plane; you might find bugs outside that).
Some emoji now combine. For instance, U+1f441 (👁) U+200d (ZWJ) U+1f5e8 (🗨) combine to make 👁🗨 (I am a witness). Rakudo 2016.07.1 on MoarVM 2016.07 says there are two graphemes:
> "\x[1f441]\x[200d]\x[1f5e8]".chars
2
I think that should be 1. It seems to have a similar problem with
> "\x[1f441]\x[fe0f]\x[200d]\x[1f5e8]\x[fe0f]".chars
2
But at least it handles U+fe0f (VS-16, emoji representation) correctly.
Are there plans to fix this in a later version of Perl 6 or am I misunderstanding the intent of the chars method?
The ZWJ sequence you mentioned is only part of Unicode Emoji 4.0 which is still in draft status and planned for release in November 2016. Under this new version, U+1F5E8 has the Grapheme_Cluster_Break property E_Base_GAZ (EBG), so the sequence should indeed form a single grapheme cluster.
I'm sure that Perl 6 will catch up at some point.
I have resource bundle property file with following content:
OwnerImagesController.TerminalContentFormatIsNotAcceptable = \u0424\u0430\u0439\u043b \u0438\u043c\u0435\u0435\u0442 \u043d\u0435\u0434\u043e\u043f\u0443\u0441\u0442\u0438\u043c\u044b\u0439 \u0444\u043e\u0440\u043c\u0430\u0442
In idea configuration following file looks like
To convert my file for resource bundle compatible state I direcly use native2ascii.exe application from jdk.
It is not comfortable.
Please help to facilitate my property file usage
According to the official documentation:
It is possible to encode non-ascii symbols using both upper- and
lower-case hex symbols (e.g. '\u00E3' vs '\u00e3'). Upper case is used
by default. To use lower case, set 'idea.native2ascii.lowercase'
property in the bin/idea.properties file to true.
Source:
https://www.jetbrains.com/idea/help/editing-resource-bundle.html
It seems to be better than editing vmoptions.
You can enable automatic conversion of non-ascii characters to appropriate escape sequences by checking Transparent native-to-ascii conversion in Settings/File Encodings (the section you show in the screenshot).
I also noticed that the the escape sequences in your snippet are lower case (i.e. \u043b instead of \u043B). IntelliJ converts them to uppercase by default. If you want to keep them lowercase to avoid unnecessary VCS changes, add following property to idea.vmoptions:
-Didea.native2ascii.lowercase=true
I'm parsing PHP code using an antlr Grammar and the antlr Ruby Target. One of the source file I have to parse actually contains translation, some of them making heavy use of Unicode character. The grammar seems to hang on one character from the "supplementary plane", namely U+10430.
I had a similar problem in the past due to the fact that the Ruby antlr target is quite old, and was not unicode compliant (well, Ruby was not, at the time). We had to bump RubyTarget.java getMaxCharValue from 0xFF (ascii) to 0xFFFF (unicode) to solve it. Now it seems that even this set is insufficient. Unicode states that characters outside this range may be represented using two UTF-16 characters, but how do antlr manage this ? Would bumping the getMaxCharValue again help (it did once, but I'm no fan of the "try" approach) ?
Thanks !
The reference Java target for ANTLR can only parse characters in the supplementary plane by using a UTF-16 surrogate pair in the grammar and using a UTF-16 encoding for your input stream. Other targets are created by members of the community and may or (as you saw the Ruby target) may not support the same range of characters.
Since there is no way to represent anything past 0xFFFE in the grammar itself, you'll be limited to the UTF-16 encoding even if you modify a target to support characters above 0xFF.