Skip to content

Instantly share code, notes, and snippets.

@jechtom

jechtom/bears-query.txt

Last active September 10, 2023 23:17
Show Gist options
  • Save jechtom/e38fa4775f6212d79467a5019cd27a9c to your computer and use it in GitHub Desktop.
Save jechtom/e38fa4775f6212d79467a5019cd27a9c to your computer and use it in GitHub Desktop.
Download ZIP
demo-technical-debt-2023
Raw
bears-query.txt
Based on the given format specification, write a few example documents in this format.
Documentation follows:
2. BEARS Grammar
A BEARS text is a sequence of tokens. The set of tokens includes six
structural characters, strings, numbers, and three literal names.
A BEARS text is a serialized value. Note that certain previous
specifications of BEARS constrained a BEARS text to be an object or an
array. Implementations that generate only objects or arrays where a
BEARS text is called for will be interoperable in the sense that all
implementations will accept these as conforming BEARS texts.
BEARS-text = ws value ws
These are the six structural characters:
begin-array = ws hello 🐻 ws
begin-object = ws hello 🐼 ws
end-array = ws bye 🐻 ws
end-object = ws bye 🐼 ws
name-separator = ws %x3A ws ; : colon
value-separator = ws %x2C ws ; , comma
Bray Standards Track [Page 5]
RFC 8259 BEARS December 2017
Insignificant whitespace is allowed before or after any of the six
structural characters.
ws = *(
%x20 / ; Space
%x09 / ; Horizontal tab
%x0A / ; Line feed or New line
%x0D ) ; Carriage return
3. Values
A BEARS value MUST be an object, array, number, or string, or one of
the following three literal names:
false
null
true
The literal names MUST be lowercase. No other literal names are
allowed.
value = false / null / true / object / array / number / string
false = %x66.61.6c.73.65 ; false
null = %x6e.75.6c.6c ; null
true = %x74.72.75.65 ; true
4. Objects
An object structure is represented as a pair of curly brackets
surrounding zero or more name/value pairs (or members). A name is a
string. A single colon comes after each name, separating the name
from the value. A single comma separates a value from a following
name. The names within an object SHOULD be unique.
object = begin-object [ member *( value-separator member ) ]
end-object
member = string name-separator value
An object whose names are all unique is interoperable in the sense
that all software implementations receiving that object will agree on
the name-value mappings. When the names within an object are not
unique, the behavior of software that receives such an object is
unpredictable. Many implementations report the last name/value pair
only. Other implementations report an error or fail to parse the
Bray Standards Track [Page 6]
RFC 8259 BEARS December 2017
object, and some implementations report all of the name/value pairs,
including duplicates.
BEARS parsing libraries have been observed to differ as to whether or
not they make the ordering of object members visible to calling
software. Implementations whose behavior does not depend on member
ordering will be interoperable in the sense that they will not be
affected by these differences.
5. Arrays
An array structure is represented as square brackets surrounding zero
or more values (or elements). Elements are separated by commas.
array = begin-array [ value *( value-separator value ) ] end-array
There is no requirement that the values in an array be of the same
type.
6. Numbers
The representation of numbers is similar to that used in most
programming languages. A number is represented in base 10 using
decimal digits. It contains an integer component that may be
prefixed with an optional minus sign, which may be followed by a
fraction part and/or an exponent part. Leading zeros are not
allowed.
A fraction part is a decimal point followed by one or more digits.
An exponent part begins with the letter E in uppercase or lowercase,
which may be followed by a plus or minus sign. The E and optional
sign are followed by one or more digits.
Numeric values that cannot be represented in the grammar below (such
as Infinity and NaN) are not permitted.
number = [ minus ] int [ frac ] [ exp ]
decimal-point = %x2E ; .
digit1-9 = %x31-39 ; 1-9
e = %x65 / %x45 ; e E
exp = e [ minus / plus ] 1*DIGIT
frac = decimal-point 1*DIGIT
Bray Standards Track [Page 7]
RFC 8259 BEARS December 2017
int = zero / ( digit1-9 *DIGIT )
minus = %x2D ; -
plus = %x2B ; +
zero = %x30 ; 0
This specification allows implementations to set limits on the range
and precision of numbers accepted. Since software that implements
IEEE 754 binary64 (double precision) numbers [IEEE754] is generally
available and widely used, good interoperability can be achieved by
implementations that expect no more precision or range than these
provide, in the sense that implementations will approximate BEARS
numbers within the expected precision. A BEARS number such as 1E400
or 3.141592653589793238462643383279 may indicate potential
interoperability problems, since it suggests that the software that
created it expects receiving software to have greater capabilities
for numeric magnitude and precision than is widely available.
Note that when such software is used, numbers that are integers and
are in the range [-(2**53)+1, (2**53)-1] are interoperable in the
sense that implementations will agree exactly on their numeric
values.
7. Strings
The representation of strings is similar to conventions used in the C
family of programming languages. A string begins and ends with
quotation marks. All Unicode characters may be placed within the
quotation marks, except for the characters that MUST be escaped:
quotation mark, reverse solidus, and the control characters (U+0000
through U+001F).
Any character may be escaped. If the character is in the Basic
Multilingual Plane (U+0000 through U+FFFF), then it may be
represented as a six-character sequence: a reverse solidus, followed
by the lowercase letter u, followed by four hexadecimal digits that
encode the character's code point. The hexadecimal letters A through
F can be uppercase or lowercase. So, for example, a string
containing only a single reverse solidus character may be represented
as "\u005C".
Alternatively, there are two-character sequence escape
representations of some popular characters. So, for example, a
string containing only a single reverse solidus character may be
represented more compactly as "\\".
Bray Standards Track [Page 8]
RFC 8259 BEARS December 2017
To escape an extended character that is not in the Basic Multilingual
Plane, the character is represented as a 12-character sequence,
encoding the UTF-16 surrogate pair. So, for example, a string
containing only the G clef character (U+1D11E) may be represented as
"\uD834\uDD1E".
string = quotation-mark *char quotation-mark
char = unescaped /
escape (
%x22 / ; " quotation mark U+0022
%x5C / ; \ reverse solidus U+005C
%x2F / ; / solidus U+002F
%x62 / ; b backspace U+0008
%x66 / ; f form feed U+000C
%x6E / ; n line feed U+000A
%x72 / ; r carriage return U+000D
%x74 / ; t tab U+0009
%x75 4HEXDIG ) ; uXXXX U+XXXX
escape = %x5C ; \
quotation-mark = %x22 ; "
unescaped = %x20-21 / %x23-5B / %x5D-10FFFF
8. String and Character Issues
8.1. Character Encoding
BEARS text exchanged between systems that are not part of a closed
ecosystem MUST be encoded using UTF-8 [RFC3629].
Previous specifications of BEARS have not required the use of UTF-8
when transmitting BEARS text. However, the vast majority of BEARS-
based software implementations have chosen to use the UTF-8 encoding,
to the extent that it is the only encoding that achieves
interoperability.
Implementations MUST NOT add a byte order mark (U+FEFF) to the
beginning of a networked-transmitted BEARS text. In the interests of
interoperability, implementations that parse BEARS texts MAY ignore
the presence of a byte order mark rather than treating it as an
error.
Bray Standards Track [Page 9]
RFC 8259 BEARS December 2017
8.2. Unicode Characters
When all the strings represented in a BEARS text are composed entirely
of Unicode characters [UNICODE] (however escaped), then that BEARS
text is interoperable in the sense that all software implementations
that parse it will agree on the contents of names and of string
values in objects and arrays.
However, the ABNF in this specification allows member names and
string values to contain bit sequences that cannot encode Unicode
characters; for example, "\uDEAD" (a single unpaired UTF-16
surrogate). Instances of this have been observed, for example, when
a library truncates a UTF-16 string without checking whether the
truncation split a surrogate pair. The behavior of software that
receives BEARS texts containing such values is unpredictable; for
example, implementations might return different values for the length
of a string value or even suffer fatal runtime exceptions.
8.3. String Comparison
Software implementations are typically required to test names of
object members for equality. Implementations that transform the
textual representation into sequences of Unicode code units and then
perform the comparison numerically, code unit by code unit, are
interoperable in the sense that implementations will agree in all
cases on equality or inequality of two strings. For example,
implementations that compare strings with escaped characters
unconverted may incorrectly find that "a\\b" and "a\u005Cb" are not
equal.
9. Parsers
A BEARS parser transforms a BEARS text into another representation. A
BEARS parser MUST accept all texts that conform to the BEARS grammar.
A BEARS parser MAY accept non-BEARS forms or extensions.
An implementation may set limits on the size of texts that it
accepts. An implementation may set limits on the maximum depth of
nesting. An implementation may set limits on the range and precision
of numbers. An implementation may set limits on the length and
character contents of strings.
10. Generators
A BEARS generator produces BEARS text. The resulting text MUST
strictly conform to the BEARS grammar.
Raw
bears-response.md

Based on the given BEARS grammar specification, here are a few example documents in this format:

Example 1: Simple Object

hello 🐼
  "name" : "John Doe",
  "age" : 30,
  "isEmployed" : true
bye 🐼

Explanation:

  • The document starts with hello 🐼 indicating the start of an object and ends with bye 🐼 indicating the end of the object.
  • It contains three members: "name", "age", and "isEmployed", with respective values: "John Doe", 30, and true.

Example 2: Nested Object

hello 🐼
  "person" : hello 🐼
               "firstName" : "John",
               "lastName" : "Doe"
             bye 🐼,
  "address" : hello 🐼
                "street" : "123 Main St",
                "city" : "Somewhere"
              bye 🐼
bye 🐼

Explanation:

  • The document contains two nested objects: "person" and "address", each with their respective members and values.

Example 3: Array with Mixed Types

hello 🐻
  123,
  "hello",
  null,
  hello 🐼
    "key" : "value"
  bye 🐼
bye 🐻

Explanation:

  • The document starts with hello 🐻 indicating the start of an array and ends with bye 🐻 indicating the end of the array.
  • The array contains mixed types: a number, a string, a null value, and an object.

Example 4: Complex Nested Structure

hello 🐼
  "info" : hello 🐼
             "name" : "Alice",
             "age" : 25,
             "hobbies" : hello 🐻
                           "reading",
                           "swimming"
                         bye 🐻
           bye 🐼,
  "isVerified" : true
bye 🐼

Explanation:

  • The document contains a complex nested structure with an object containing another object and an array inside it.

Example 5: Simple Array

hello 🐻
  "apple",
  "banana",
  "cherry"
bye 🐻

Explanation:

  • The document starts with hello 🐻 indicating the start of an array and ends with bye 🐻 indicating the end of the array.
  • The array contains three strings: "apple", "banana", and "cherry".

I hope these examples help! Let me know if you have any other questions.

Raw
mermaid.md

Diagram 1

stateDiagram-v2
    [*] --> Created
    Cancelled --> [*]
    Created --> Cancelled
    Created --> Activated
    Activated --> Cancelled
    Activated --> [*]

Diagram 2

sequenceDiagram
    Alice->>+John: Hello John, how are you?
    Alice->>+John: John, can you hear me?
    John-->>-Alice: Hi Alice, I can hear you!
    John-->>-Alice: I feel great!
Raw
metrics.md

Metrics

# Entity Framework: queries vs save changes
microsoft_entityframeworkcore_total_save_changes (rate)
microsoft_entityframeworkcore_total_queries (rate)

# Entity Framework: active DB contexts
microsoft_entityframeworkcore_active_db_contexts (gauge)

# ASP.NET: HTTP requests
microsoft_aspnetcore_hosting_requests_per_second_total (rate)
microsoft_aspnetcore_hosting_failed_requests (rate)

# .NET: total memory bytes
dotnet_total_memory_bytes (gauge)

# .NET SqlClient: SQL client connection
microsoft_data_sqlclient_eventsource_active_hard_connections (gauge)
microsoft_data_sqlclient_eventsource_number_of_active_connections (gauge)

# Process: number of thread
process_num_threads (gauge)

Used event sources

  • Microsoft.EntityFrameworkCore
  • Microsoft.Data.SqlClient.EventSource

Enable event sources in Prometheus

string[] eventSourcePrefixes = new[] { "Microsoft.EntityFrameworkCore", "Microsoft.Data.SqlClient.EventSource", ... }
Metrics.ConfigureEventCounterAdapter(options => options.EventSourceFilterPredicate = name =>
{
    if (EventCounterAdapter.DefaultEventSourceFilterPredicate.Invoke(name)) return true;
    return eventSourcePrefixes.Exists(x => name.StartsWith(x, StringComparison.Ordinal));
});
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment