docs: fix grammar mistakes in markdown files (#29743)

* docs: fix grammar mistakes in markdown files

Correct `its`/`it's`, verb-noun agreement, article and number
agreement errors in V-owned documentation.

vlib/x/encoding/asn1/DOCS.md: fix the bulk of the issues, including
`Its` -> `It`/`It is`/`This is`, `two form` -> `two forms`,
`four class` -> `four classes`, `a extra` -> `extra`, and
`you hope an universal type` -> `you need a universal type`.

Other files: single-grammar fixes in chacha20poly1305, ttf,
net/jsonrpc, vpbgen, bench/vectors and examples/templates READMEs.

Vendored thirdparty/ files and historical changelog entries are left
untouched, since the former are external code and the latter are
verbatim commit records.

No behavior change. `./v check-md` passes on all changed files.

* fix review feedback

---------

Co-authored-by: qp <168933756+gabytz777@users.noreply.github.com>
This commit is contained in:
qpandqp authored and GitHub committed 2026-10-08 00:57:06 +03:00
1 parent b69f626f14
commit 99c3b94d33
6 files changed
+34 -32

No files matched your search

+1 -1
View File
@@ -14,7 +14,7 @@ dotnet publish -c Release -r ubuntu.20.04-x64
The generated executable will be in
`/v/vnew/bench/vectors/bin/Release/net7.0/ubuntu.20.04-x64/publish/vectors`
Its size is ~64MB . After stripping, the executable shrinks to just 11MB,
Its size is ~64MB. After stripping, the executable shrinks to just 11MB,
but unfortunately it also stops running after stripping :-| .
## Compiling and running the V program:
+1 -1
View File
@@ -7,7 +7,7 @@
- syntax checking
- embed the template into the binary
Its a very cool way how to do also do e.g. system administration, fill in
It's a very cool way to do things like system administration, fill in
config files, etc...
The example there is also a good demonstration of how to use json on a more
+1 -1
View File
@@ -122,5 +122,5 @@ with `jsonrpc.method_not_found` error
### Interceptors
Both `jsonrpc.Client` and `jsonrpc.Server` support `jsonrpc.Interceptors` - the collection of
on event handlers. There is implementation of all supported interceptors called
on event handlers. There is an implementation of all supported interceptors called
`jsonrpc.LoggingInterceptor`.
+1 -1
View File
@@ -3,7 +3,7 @@
Chacha20Poly1305 Authenticated Encryption with Additional Data (AEAD) module for V Language
This module provides authenticated encryption with additional data (AEAD) algorithm in V Language.
Its backed by experimental `x.crypto.chacha20` symmetric key stream cipher encryption
It's backed by experimental `x.crypto.chacha20` symmetric key stream cipher encryption
module and `x.crypto.poly1305` message authentication code (MAC) module.
> [!Warning]
+29 -27
View File
@@ -12,8 +12,8 @@
This document is intended to serve as documentation (actually as a note) of
internal details of this `asn1` module.
Its describes some parts of the module in the way is implemented,
the lack and also issues or limitation we have found around it.
It describes some parts of the module and how it is implemented,
the lack thereof, and also the issues and limitations we have found around it.
## Table of Contents
@@ -51,7 +51,7 @@ computer networking, and especially in cryptography.
## Encoding of ASN.1
Encoding of ASN.1 is a set of encoding rules that specify how to represent a data structure as
a series of bytes. There are multiple rules available that describes way of serializing
a series of bytes. There are multiple rules available that describe ways of serializing an
ASN.1 object. The standard ASN.1 encoding rules include:
- Basic Encoding Rules (BER)
@@ -91,7 +91,8 @@ mut:
}
```
Where `TagClass` represent class of ASN.1 type. There are four class of ASN.1 type represented in:
Where `TagClass` represents a class of ASN.1 type.
There are four classes of ASN.1 type, represented in:
```codeblocks
enum TagClass {
@@ -104,7 +105,8 @@ enum TagClass {
### Limitation of the Tag in this module.
There are two form how the ASN.1 tag was represented, ie, short form tag for tag number below 31
There are two forms in which the ASN.1 tag can be represented, ie,
a short form tag for tag numbers below 31
and long form tag (multi byte tag) for representing tag number bigger than 31.
This module support both of form, but the size (length) is limited to `max_tag_length` constant,
@@ -220,8 +222,8 @@ generates payload. Its up to specific encoding rules or other constraints.
> implemented required constraints in this module.
### Build custom element payload
Its possible to build payload for complex structure, your own defined struct contains multiples
field of elements with the help of function on this modules. Of course, you can build
It is possible to build a payload for a complex structure: your own defined struct contains
multiple fields of elements with the help of the functions in this module. Of course, you can build
your payload manually, but this `asn1` module has provides helper routine to do that, in the form:
```codeblocks
fn make_payload[T](val T, kd KeyDefault) ![]u8
@@ -231,8 +233,8 @@ fn make_payload[T](val T, kd KeyDefault) ![]u8
> - KeyDefault is map of `field.name` key with some element value
> (only the field has DEFAULT keyword) to setup default value.
Its would produces only element's payload without tag or length bytes included.
When your structures does not contains the fields that
It would produce only the element's payload without tag or length bytes included.
When your structures do not contain the fields that
fulfills interfaces, it would produces and return empty bytes.
### Serializing ASN.1 Element
@@ -247,7 +249,7 @@ fn encode_with_field_options(el Element, fo FieldOptions) ![]u8
All of three's functions produces bytes result on success or error on fails.
The two latest form is serialization routines intended for serializing element
with wrapping, optional or default semantic to existing element,
gives you a extra flexibility to the serialization (deserialization) process.
giving you extra flexibility in the serialization (deserialization) process.
For more information in detail, see [FieldOptions](#element-serialization-with-fieldoptions)
#### Example
@@ -264,7 +266,7 @@ a string option into `encode`, ie:
output := encode_with_options(obj, 'context_specific:5;implicit;inner:19')!
assert output == [u8(0x85), 0x02, 0x68, 0x69]
```
Or when its a explicit tagged element defined as `[5] EXPLICIT PrintableString`
Or when it's an explicit tagged element defined as `[5] EXPLICIT PrintableString`
```codeblocks
output := encode_with_options(obj, 'context_specific:5;explicit;inner:0x13')!
assert output == [u8(0xA5), 0x04, 0x13, 0x02, 0x68, 0x69]
@@ -279,9 +281,9 @@ fn decode_with_options(bytes []u8, opt string) !Element
fn decode_with_field_options(bytes []u8, fo FieldOptions) !Element
```
Technically, the deserialization mechanism is reverse of serialization process.
When you pass an options to decode routine, you should ensure its a same options
used for serialization in `encode` part, or the decode would result in undefined behaviour
if its differs.
When you pass options to a decode routine, you should ensure they are the same options
used for serialization in `encode` part, or the decode would result in undefined behaviour
if they differ.
The `decode` function families, accepts DER serialized bytes, and an options
(if its should be) and return some `Element`, or return error on fails.
@@ -329,7 +331,7 @@ from [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.1.2),
```
This schema required support for other machinery in the form of tagged element
with wrapping semantic, OPTIONAL keyword handling, and DEFAULT keyword handling,
Its supported through the `FieldOptions` structures defined as:
This is supported through the `FieldOptions` structures defined as:
```codeblocks
struct FieldOptions {
mut:
@@ -354,7 +356,7 @@ The main purpose of this options structures is used for:
- handling of element with DEFAULT keyword.
### Wrapping an Element through FieldOptions
There are two constructor for construct a `FieldOptions`, ie
There are two constructors for constructing a `FieldOptions`, ie
```codeblocks
fn FieldOptions.from_string(s string) !FieldOptions
fn FieldOptions.from_attrs(attrs []string) !FieldOptions
@@ -366,8 +368,8 @@ fo := FieldOptions.from_string('context_specific:5;explicit;inner:0x13')!
fo := FieldOptions.from_string('context_specific:5;explicit;inner:0x13;optional')!
```
The second form, is gives more controllable options, and its allowing tag your field of struct
with the supported options,
The second form gives more controllable options, and allows you to tag your field of struct
with the supported options.
Examples :
```codeblocks
struct PersonnelRecord {
@@ -429,10 +431,10 @@ It's currently supports following basic ASN1 type:
- [x] SetOf
## Constructor of Universal ASN.1 Type
Most Universal class of ASN.1 type supported in this modules comes with builtin constructor.
You should use this constructor when you hope an universal type.
Its comes with common signature of the constructor (not at all, but most of them),
see module doc for detail.
The most Universal class of ASN.1 type supported in this module comes with a builtin constructor.
You should use this constructor when you need a universal type.
It comes with a common signature for the constructor (not all of them, but most of them),
see the module docs for details.
```codeblocks
fn T.new(value) !T
fn T.from_string(string) !T // for string-based type
@@ -442,8 +444,8 @@ fn T.from_bigint(bigint) !T // for integer with big.Integer
## Support for non-universal class Element
When your element is non-universal class, this module has a limited support for
this type of element. Its represented in several structures, defined as :
When your element is a non-universal class, this module has limited support for
this type of element. It is represented in several structures, defined as:
```codeblocks
pub struct RawElement {
mut:
@@ -470,16 +472,16 @@ pub struct PrivateELement {
}
```
Intended usage for this non-universal class is for wrapping semantic,
instead create your own non-universal manually. For examples, if you have
instead create your own non-universal type manually. For example, if you have
some element (maybe non-universal), you want create non-universal element from this element,
you can call (for creating private type element) routine :
```codeblocks
fn PrivateELement.from_element(inner Element, tagnum int, mode TaggedMode) !PrivateELement
```
Its currently support nested wrapping, but the unwrapping process should do by your self.
It currently supports nested wrapping, but the unwrapping process should be done by yourself.
> **Warning**
> There are some limitation on this wrapping,
> There are some limitations on this wrapping:
> - You can't wrap into universal class
> - You can't wrap an Optional Element.
+1 -1
View File
@@ -235,7 +235,7 @@ It is possible to modify these parameters to obtain the desired effect on the te
The sokol render use the bitmap render to create the text and the `gg` functions to render
the text to the screen.
It is simpler to use in a `gg app` than the raw bitmap render.
Each single text rendered need its own reder to be declared, after you can modify it.
Each single rendered text needs its own render to be declared, after which you can modify it.
Here a simple example of the usage:
```v oksyntax