The question arises from my doubt whether everything that follows x- in BCP47 code is a private extension as well. Will Latn be considered as a private extension too in art-x-isv-Latn? On the other hand, the latter looks more reasonable than art-Latn-x-isv, because if you read it:
art-x-isv-Latn: a private extension of the artificial languages group under name "isv" (Interslavic), in Latin script
art-Latn-x-isv: the artificial language in Latin script with the extension "isv" (Interslavic)
Could you help me with figuring out if my interpretation of art-x-isv-Latn and art-Latn-x-isv is correct in terms of BCP47?
I’m the editor of RFC 4645 and 5645 and the main clerical contributor to the BCP 47 Language Subtag Registry.
It is true that in BCP 47, everything following the x singleton is considered a private extension. Therefore, the correct way to write your tag is art-Latn-x-isv.
Variant subtags and especially private extensions can mean almost anything, so there is no one “right” place to put them within a tag that will always make the most sense from a grouping standpoint. Interpreting your tag as “the artificial language in Latin script with the extension ‘isv’ (Interslavic)” is not wrong. The extension refers to the entire preceding tag (“art-Latn”), not just the immediately preceding subtag (“Latn”).
Related
I want to integrate the function shown in the graphic that in turn has several functional dependencies as indicated. Is there a way to define the sub-functions $F(x)$, $G(x)$, $H(x)$ , and $p(x)$ in the input without explicitly writing everything out in one line which would be a hideous mess? All of the other symbols except of course, $x$ are constants.
(I doubt that there's a closed form expression, but I don't want it to be for lack of trying!)
The usual IDEs/editors for MMT (e.g. IntelliJ + MMT plugin or jEdit) feature an autocompletion feature for certain useful Unicode characters. For instance, I can type jle and immediately get suggested jleftrightarrow that, upon autocompletion, is replaced by ↔.
Is there a way to find out the reverse association? E.g. I have the symbol ☞ at hand and would like to know the autocompletion abbreviation starting with j — if it exists. For that hand, I would get juri.
The MMT OnlineTools I developed allow this: https://comfreek.github.io/mmteditor.
See screenshot below: if you already have a string full of Unicode symbols that you don't know how to type, just paste it under "how do I type X?". And if you are looking for a specific abbreviation — by Unicode character or by (parts of its) name — use the "abbreviation search" feature.
Internally, my tools pulls from (a copy of) the same resource file that Dennis linked in his answer.
As far as I know, there currently isn't a good way to look up or search for the ASCII abbreviations, except to go straight for the source — which at least has the advantage that it's guaranteed to be up-to-date.
The IDE plugins all have access to an mmt.jar and load their abbreviations from a specific resource file embedded therein. You can find it here on GitHub: https://github.com/UniFormal/MMT/blob/master/src/mmt-api/resources/unicode/unicode-latex-map.
In the long term, we should consider extending that file with a third "field" that gives a short description, and e.g. have a text field in IntelliJ to search for a specific abbreviation.
I want to search all programs - within a package - that use the statement:
modify itab_xyz from wa_itab_xyz
Preferably, the string should be searched with wild cards like itab*
for a range of itab_(values) like itab_abc, itab_def, itab_ghi
etc..
How do i do this in SAP ABAP?
Below is a screenshot of all programs within a package one can search from.
One possibility would be to use program RS_ABAP_SOURCE_SCAN.
You can restrict the selection by package and you can also enter a specific string to search for in the code.
I use the transaction code_scanner (program is afx_code_scanner).
The biggest problem with this program and the RS_ABAP_SOURCE_SCAN provided above is that they won’t find everything. IMO the most important missing component to them is implicit enhancements. They can be very impactful to system functions, and if you are searching for an error message or hard coded value skipping them could mean not finding something critical.
At the time I looked (about 7 years ago), I was unable to find a delivered tool that would actually scan all the code in the system. I ended up enhancing the code_scanner to look for enhancements, WDA components, BSP code, and forms code.
I don’t know if the open source component above includes those. At first glance it doesn’t seem to, but I don’t have time to really dig into it.
You could use a tool from the Galileo-Open Source library. This program searches ABAP Source, OTR-Texts, Message and Textpools for static Text, wildcard patterns or regex patterns.
ABAP-Coding:
https://github.com/galileo-group/galileo-abap-lib/blob/master/%23gal%23devtools_find_text.prog.abap
Textpool:
https://github.com/galileo-group/galileo-abap-lib/blob/master/%23gal%23devtools_find_text.prog.xml
It refers to some additional classes from the library, so you either need to copy these as well or just use ABAPgit to get the whole library. You can also contact me, so I can send you a transport containing the library.
Additional information (October 1, 2020):
I created a version of the report that you can copy/paste to the ABAP editor. It is too long to include it in the response, but you can find it here.
Do not forget to copy the text elements / selection texts.
Required Text Elements:
-----------------------
B00 Scope
B01 Search pattern
H01 Type
H02 Name
H03 Key
H04 Match
Required Selection Texts:
-------------------------
P_CASE Case-sensitive
P_DEVC Package
P_LANGU Language
P_MESS Messages
P_OTR OTR Texts
P_PATT Pattern
P_REGEX Regular expression
P_SOURCE ABAP sources
P_TPOOL Textpools
P_WILDC Wildcard pattern
This code works:
(3,6...66).contains( 9|21 ).say # OUTPUT: «any(True, True)»
And returns a Junction. It's also tested, but not documented.
The problem is I can't find its implementation anywhere. The Str code, which is also called from Cool, never returns a Junction (it does not take a Junction, either). There are no other methods contain in source.
Since it's autothreaded, it's probably specially defined somewhere. I have no idea where, though. Any help?
TL;DR Junction autothreading is handled by a single central mechanism. I have a go at explaining it below.
(The body of your question starts with you falling into a trap, one I think you documented a year or two back. It seems pretty irrelevant to what you're really asking but I cover that too.)
How junctions get handled
Where is contains( Junction) defined? ... The problem is I can't find [the Junctional] implementation anywhere. ... Since it's autothreaded, it's probably specially defined somewhere.
Yes. There's a generic mechanism that automatically applies autothreading to all P6 routines (methods, operators etc.) that don't have signatures that explicitly control what happens with Junction arguments.
Only a tiny handful of built in routines have these explicit Junction handling signatures -- print is perhaps the most notable. The same is true of user defined routines.
.contains does not have any special handling. So it is handled automatically by the generic mechanism.
Perhaps the section The magic of Junctions of my answer to an earlier SO Filtering elements matching two regexes will be helpful as a high level description of the low level details that follow below. Just substitute your 9|21 for the foo & bar in that SO, and your .contains for the grep, and it hopefully makes sense.
Spelunking the code
I'll focus on methods. Other routines are handled in a similar fashion.
method AUTOTHREAD does the work for full P6 methods.
This is setup in this code that sets up handling for both nqp and full P6 code.
The above linked P6 setup code in turn calls setup_junction_fallback.
When a method call occurs in a user's program, it involves calling find_method (modulo cache hits as explained in the comment above that code; note that the use of the word "fallback" in that comment is about a cache miss -- which is technically unrelated to the other fallback mechanisms evident in this code we're spelunking thru).
The bit of code near the end of this find_method handles (non-cache-miss) fallbacks.
Which arrives at find_method_fallback which starts off with the actual junction handling stuff.
A trap
This code works:
(3,6...66).contains( 9|21 ).say # OUTPUT: «any(True, True)»
It "works" to the degree this does too:
(3,6...66).contains( 2 | '9 1' ).say # OUTPUT: «any(True, True)»
See Lists become strings, so beware .contains() and/or discussion of the underlying issues such as pmichaud's comment.
Routines like print, put, infix ~, and .contains are string routines. That means they coerce their arguments to Str. By default the .Str coercion of a listy value is its elements separated by spaces:
put 3,6...18; # 3 6 9 12 15 18
put (3,6...18).contains: '9 1'; # True
It's also tested
Presumably you mean the two tests with a *.contains argument passed to classify:
my $m := #l.classify: *.contains: any 'a'..'f';
my $s := classify *.contains( any 'a'..'f'), #l;
Routines like classify are list routines. While some list routines do a single operation on their list argument/invocant, eg push, most of them, including classify, iterate over their list doing something with/to each element within the list.
Given a sequence invocant/argument, classify will iterate it and pass each element to the test, in this case a *.contains.
The latter will then coerce individual elements to Str. This is a fundamental difference compared to your example which coerces a sequence to Str in one go.
I set the culture to Hungarian language, and Chr() seems to be broken.
System.Threading.Thread.CurrentThread.CurrentCulture = "hu-US"
System.Threading.Thread.CurrentThread.CurrentUICulture = "hu-US"
Chr(254)
This returns "ţ" when it should be "þ"
However, Asc("ţ") returns 116.
This: Asc(Chr(254)) returns 116.
Why would Asc() and Chr() be different?
I checked and the 'wide' functions do work correctly: ascw(chrw(254)) = 254
Chr(254) interprets the argument in a system dependent way, by looking at the System.Globalization.CultureInfo.CurrentCulture.TextInfo.ANSICodePage property. See the MSDN article about Chr. You can check whether that value is what you expect. "hu-US" (the hungarian locale as used in the US) might do something strange there.
As a side-note, Asc() has no promise about the used codepage in its current documentation (it was there until 3.0).
Generally I would stick to the unicode variants (ending on -W) if at all possible or use the Encoding class to explicitly specify the conversions.
My best guess is that your Windows tries to represent Chr(254)="ţ" as a combined letter, where the first letter is Chr(116)="t" and the second ("¸" or something like that) cannot be returned because Chr() only returns one letter.
Unicode text should not be handled character-by-character.
It sounds like you need to set the code page for the current thread -- the current culture shouldn't have any effect on Asc and Chr.
Both the Chr docs and the Asc docs have this line:
The returned character depends on the code page for the current thread, which is contained in the ANSICodePage property of the TextInfo class. TextInfo.ANSICodePage can be obtained by specifying System.Globalization.CultureInfo.CurrentCulture.TextInfo.ANSICodePage.
I have seen several problems in VBA on the Mac where characters over 127 and some control characters are not treated properly.
This includes paragraph marks (especially in text copied from the internet or scanned), "¥", and "Ω".
They cannot always be searched for, cannot be used in file names - though they could in the past, and when tested, come up as another ascii number. I have had to write algorithms to change these when files open, as they often look like they are the right character, but then crash some of my macros when they act strangely. The character will look and act right when I save the file, but may be changed when it is reopened.
I will eventually try to switch to unicode, but I am not sure if that will help this issue.
This may not be the issue that you are observing, but I would not rule out isolated problems with certain characters like this. I have sent notes to MS about this in the past but have received no joy.
If you cannot find another solution and the character looks correct when you type it in, then I recommend using a macro snippet like the one below, which I run when updating tables. You of course have to setup theRange as the area you are looking at. A whole file can take a while.
For aChar = 1 To theRange.Characters.count
theRange.Characters(aChar).Select
If Asc(Selection.Text) = 95 And Selection.Text <> "_" Then Selection.TypeText "Ω"
Next aChar