Tags: notJoon/gno-core
Tags
perf: make debug a constant set using a build flag (gnolang#2072) Changing the `debug` flag from a variable to a constant results in increased performance anywhere in the code where the `if debug {` conditional exists. The setting of the debug flag is now facilitated by a `debug` build tag. Here are a few benchmarks showing the performance difference for TypedValue Set and Get operations. The benchmarks suffixed with 'New' are those run with debugging disabled after introducing the build tag. The other benchmarks were run with debugging disabled before introducing the build tag. ``` go test -cpu 1,2,4,8 -benchmem -bench '^BenchmarkTV' -run=^$ goos: darwin goarch: amd64 pkg: github.com/gnolang/gno/gnovm/pkg/gnolang cpu: Intel(R) Core(TM) i5-1038NG7 CPU @ 2.00GHz BenchmarkTVGetBool 616270255 1.919 ns/op 0 B/op 0 allocs/op BenchmarkTVGetBool-2 623206738 1.859 ns/op 0 B/op 0 allocs/op BenchmarkTVGetBool-4 645019149 1.825 ns/op 0 B/op 0 allocs/op BenchmarkTVGetBool-8 628096153 1.897 ns/op 0 B/op 0 allocs/op BenchmarkTVGetBoolNew 1000000000 0.3015 ns/op 0 B/op 0 allocs/op BenchmarkTVGetBoolNew-2 1000000000 0.2997 ns/op 0 B/op 0 allocs/op BenchmarkTVGetBoolNew-4 1000000000 0.3026 ns/op 0 B/op 0 allocs/op BenchmarkTVGetBoolNew-8 1000000000 0.3009 ns/op 0 B/op 0 allocs/op BenchmarkTVSetBool 636429537 1.895 ns/op 0 B/op 0 allocs/op BenchmarkTVSetBool-2 612271684 1.983 ns/op 0 B/op 0 allocs/op BenchmarkTVSetBool-4 583097722 1.923 ns/op 0 B/op 0 allocs/op BenchmarkTVSetBool-8 608042474 1.949 ns/op 0 B/op 0 allocs/op BenchmarkTVSetBoolNew 1000000000 0.3109 ns/op 0 B/op 0 allocs/op BenchmarkTVSetBoolNew-2 1000000000 0.3116 ns/op 0 B/op 0 allocs/op BenchmarkTVSetBoolNew-4 1000000000 0.3101 ns/op 0 B/op 0 allocs/op BenchmarkTVSetBoolNew-8 1000000000 0.3080 ns/op 0 B/op 0 allocs/op BenchmarkTVGetInt 596222908 1.979 ns/op 0 B/op 0 allocs/op BenchmarkTVGetInt-2 565257805 2.024 ns/op 0 B/op 0 allocs/op BenchmarkTVGetInt-4 603462258 1.913 ns/op 0 B/op 0 allocs/op BenchmarkTVGetInt-8 623668717 1.896 ns/op 0 B/op 0 allocs/op BenchmarkTVGetIntNew 1000000000 0.3049 ns/op 0 B/op 0 allocs/op BenchmarkTVGetIntNew-2 1000000000 0.3035 ns/op 0 B/op 0 allocs/op BenchmarkTVGetIntNew-4 1000000000 0.3139 ns/op 0 B/op 0 allocs/op BenchmarkTVGetIntNew-8 1000000000 0.3006 ns/op 0 B/op 0 allocs/op BenchmarkTVSetInt 646375224 1.819 ns/op 0 B/op 0 allocs/op BenchmarkTVSetInt-2 639805758 1.817 ns/op 0 B/op 0 allocs/op BenchmarkTVSetInt-4 641337288 1.840 ns/op 0 B/op 0 allocs/op BenchmarkTVSetInt-8 636959119 1.836 ns/op 0 B/op 0 allocs/op BenchmarkTVSetIntNew 1000000000 0.3011 ns/op 0 B/op 0 allocs/op BenchmarkTVSetIntNew-2 1000000000 0.3017 ns/op 0 B/op 0 allocs/op BenchmarkTVSetIntNew-4 1000000000 0.2984 ns/op 0 B/op 0 allocs/op BenchmarkTVSetIntNew-8 1000000000 0.2909 ns/op 0 B/op 0 allocs/op ``` <details><summary>Contributors' checklist...</summary> - [x] Added new tests, or not needed, or not feasible - [x] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory - [x] Updated the official documentation or not needed - [x] No breaking changes were made, or a `BREAKING CHANGE: xxx` message was included in the description - [x] Added references to related issues and PRs - [x] Provided any useful hints for running manual tests - [x] Added new benchmarks to [generated graphs](https://gnoland.github.io/benchmarks), if any. More info [here](https://github.com/gnolang/gno/blob/master/.benchmarks/README.md). </details>
feat(examples): add simple userbook realm (gnolang#1949) <!-- please provide a detailed description of the changes made in this pull request. --> ## Description This PR arose out of a necessity to have a simple, permissionless realm for demonstration purposes. The idea is that people can sign up once with their address, and the Render function will paginate 50 addresses per page, as well as include a UI to go to the next/previous page. This realm will serve 3 purposes: - Show how to do pagination - Show how to use Render in harmony with `gnoweb` - Exist as a simple entry point for new developers testing out the chain. This realm will be used as an example in the Getting started section in the docs. <details><summary>Contributors' checklist...</summary> - [ ] Added new tests, or not needed, or not feasible - [ ] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory - [ ] Updated the official documentation or not needed - [ ] No breaking changes were made, or a `BREAKING CHANGE: xxx` message was included in the description - [ ] Added references to related issues and PRs - [ ] Provided any useful hints for running manual tests - [ ] Added new benchmarks to [generated graphs](https://gnoland.github.io/benchmarks), if any. More info [here](https://github.com/gnolang/gno/blob/master/.benchmarks/README.md). </details> --------- Co-authored-by: deelawn <dboltz03@gmail.com>
feat: byte slice JSON parser (gnolang#1415) ## Description I implemented a JSON parser using byte slices ### State Machine For JSON Each state transitions to the next when specific conditions are met, representing the process of parsing a JSON structure sequentially. State transitions are defined based on the conditions and actions that occur during the parsing process. The diagram essentially includes the following states (All states are defined at `internal.gno` file): - It starts in the initial state (`__`), returning an error if an unexpected token is encountered. - States for handling string (`ST`), number (`MI`, `ZE`, `IN`), boolean (`T1`, `F1`), and null (`N1`) values. - States for handling the start and end of objects (`co`) and arrays (`bo`) (`ec`, `cc`, `bc`). - States expecting keys (`KE`) and values (`VA`), and for handling commas (`cm`) and colons (`cl`). Each state deals with various scenarios that can occur during JSON parsing, with transitions to the next state determined by the current token and context. Below is a graph depicting how the states transition: ```mermaid stateDiagram-v2 [*] --> __: Start __ --> ST: String __ --> MI: Number __ --> ZE: Zero __ --> IN: Integer __ --> T1: Boolean (true) __ --> F1: Boolean (false) __ --> N1: Null __ --> ec: Empty Object End __ --> cc: Object End __ --> bc: Array End __ --> co: Object Begin __ --> bo: Array Begin __ --> cm: Comma __ --> cl: Colon __ --> OK: Success/End ST --> OK: String Complete MI --> OK: Number Complete ZE --> OK: Zero Complete IN --> OK: Integer Complete T1 --> OK: True Complete F1 --> OK: False Complete N1 --> OK: Null Complete ec --> OK: Empty Object Complete cc --> OK: Object Complete bc --> OK: Array Complete co --> OB: Inside Object bo --> AR: Inside Array cm --> KE: Expecting New Key cm --> VA: Expecting New Value cl --> VA: Expecting Value OB --> ST: String in Object (Key) OB --> ec: Empty Object OB --> cc: End Object AR --> ST: String in Array AR --> bc: End Array KE --> ST: String as Key VA --> ST: String as Value VA --> MI: Number as Value 10000 VA --> T1: True as Value VA --> F1: False as Value VA --> N1: Null as Value OK --> [*]: End ``` ## Walkthrough The JSON Machine Gno is not completely compatible with Go, which means that many functions within the standard library are not fully implemented yet. Therefore, some files are added not directly related to JSON but necessary for functionality implementation. ### Float Value Handler The `strconv` package currently provided by gno has functions injected for parsing basic `int` and `uint` types, but does not have an implementation for parsing floating-point numbers with `ParseFloat`. Therefore, I have brought over the implementation of the `eisel-lemire` algorithm from Go's strconv package (`./p/demo/json/eisel_lemire`).<sup>[1](#footnote_1)</sup> Additionally, since the `FormatFloat` function is also not implemented yet. So, I imported the `ryu64` algorithm <sup>[2](#footnote_2)</sup> to implement this feature (`./p/demo/json/ryu`). Anyway, I plan to add this code to the strconv package if possible, so that the necessary functionality and functions can be completely written in gno. ### Buffer `buffer.gno` manages internal buffer management and interaction with the state machine for JSON parsing. The buffer processes the JSON string sequentially, interpreting the meaning of each character and deciding the next action through the state machine. Here, I'll describe the key functions and how they interact with the state machine. The `/` next to a number is a notation borrowed from Elixir to indicate the number of parameters: - `newBuffer`: This function creates a new buffer instance containing the given data. The initial state is set to `GO`, signifying the start of parsing and preparing for subsequent parsing stages as the state machine's initial state. - `first`: Finds the first meaningful (non-whitespace) character. Although the state machine is not yet activated at this stage, the result of this function plays a crucial role in determining the first step of parsing. - `current`, `next`, `step`: These functions manage the current position within the buffer, reading characters or moving to the next one. `current` returns the character at the current index, `next` returns the next character, and `step` only moves to the next position. These movement functions are necessary to decide what input should be processed when the state machine transitions to the next state. - `getState`: Determines the next state based on the character at the current buffer position. This function evaluates the class (type of character) of the current character and uses a state transition table to decide the next state. This process is central to how the state machine interprets the JSON structure. - `numeric/1`, `string/2`, `word/1`: These functions parse numbers, strings, and specified word tokens, respectively. During parsing, the state machine transitions to the next state based on the current character's type and context, which is essential for accurately interpreting the structure and meaning of JSON data. - `skip`, `skipAny/1`: Functions for skipping characters that meet certain conditions, such as moving the buffer index until a specific character or set of tokens is encountered. These functions are mainly used to manage the current state of the state machine while parsing structural elements (e.g., the end of an object or array). These functions are used to closely interact with the state machine to recognize and interpret the various data types and structures within the JSON string. The current state of the state machine changes based on each character or string the buffer processes, dynamically controlling the parsing process. ### Unescape These functions are designed to process JSON strings, specifically by managing internal buffer interactions and unescaping characters as per JSON standards. This involves translating escape sequences like `\uXXXX` for unicode characters, as well as simpler escapes like `\\`, `\/`, `\b`, `\f`, `\n`, `\r`, and `\t`. Here's some key functions for this file: - `Unescape/2`: This is the primary function that takes an input byte slice (representing a JSON string with escape sequences) and an output byte slice to write the unescaped version of the input. It processes each escape sequence encountered in the input slice and translates it into the corresponding UTF-8 character in the output slice. - `Unquote/2`: This function is designed to remove surrounding quotes from a JSON string and unescape its contents. It's useful for processing JSON string values to their literal representations. ### Node When a JSON string is decoded, the package converts the data into a Node type. ```go type Node struct { prev *Node // prev is the parent node of the current node. next map[string]*Node // next is the child nodes of the current node. key *string // key holds the key of the current node in the parent node. data []byte // byte slice of JSON data value interface{} // value holds the value of the current node. nodeType ValueType // NodeType holds the type of the current node. (Object, Array, String, Number, Boolean, Null) index *int // index holds the index of the current node in the parent array node. borders [2]int // borders stores the start and end index of the current node in the data. modified bool // modified indicates the current node is changed or not. } ``` This node type allows you to fetch and manipulate the specific values from JSON. For example, you can use the `GetKey/1` function to retrieve the value stored at a specific key, and you can use `Delete` to remove the node. By doing so, enabling you to process JSON data. --- <a name="footnote_1">1</a>: The Eisel-Lemire algorithm provides a fast way to parse floating-point numbers from strings. The core idea of this algorithm is to minimize potential errors during the conversion process from strings to numbers, while processing the conversion as quickly as possible. Eisel-Lemire is particularly useful when dealing with large amounts of numerical data, providing much faster and more accurate results than traditional parsing methods. <a name="footnote_2">2</a>: The Ryu algorithm focuses on converting floating-point numbers to strings. Ryu generally converts floating-point numbers to the shortest possible string representation accurately, with excellent performance and precision. A key advantage of the Ryu algorithm is that the converted string maintains the minimum length while precisely representing the original number. This helps save storage space and reduces data transmission times over networks.
chore: `s/use/loadpkg` and `s/example/examples` (gnolang#1690)
docs(readme): add play.gno.land (gnolang#1489) Please feel free to push commits to change the content. closes gnolang#1486. --------- Co-authored-by: Danny <salman.danny03@hotmail.com> Co-authored-by: Morgan <git@howl.moe>
docs: reorg & rename top level docs (gnolang#1455) ## Description This PR introduces a small reorg to the docs structure. Our docs follow the [Diataxis](https://diataxis.fr/) framework, but upon further thought I don't believe that we need to or that we should follow the framework 1:1, as it can be too rigid at times. IMHO it is more understandable to have the "Explanation" category renamed to "Concepts" or "Gno Concepts". While this is a minor change, I believe people who are not aware of Diataxis will find "Concepts" more intuitive. This PR also extracts the "Gno Tooling" out of "Explanation", as the category deserves its own spot in the sidebar. EDIT: This PR also resolves the conflict with and modifies the `docs/reference/standard-library.md` file (merged with [gnolang#859](gnolang#859)). <details><summary>Contributors' checklist...</summary> - [x] Added new tests, or not needed, or not feasible - [x] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory - [x] Updated the official documentation or not needed - [x] No breaking changes were made, or a `BREAKING CHANGE: xxx` message was included in the description - [x] Added references to related issues and PRs - [x] Provided any useful hints for running manual tests - [ ] Added new benchmarks to [generated graphs](https://gnoland.github.io/benchmarks), if any. More info [here](https://github.com/gnolang/gno/blob/master/.benchmarks/README.md). </details>
fix(pkg/gnoland): store skipFailingGenesisTxs in cfg (gnolang#1395) When the flag `--skip-failing-genesis-txs=true` was set, we still have a panic because the flag wasn't send for the config <details><summary>Contributors' checklist...</summary> - [ ] Added new tests, or not needed, or not feasible - [ ] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory - [ ] Updated the official documentation or not needed - [ ] No breaking changes were made, or a `BREAKING CHANGE: xxx` message was included in the description - [ ] Added references to related issues and PRs - [ ] Provided any useful hints for running manual tests - [ ] Added new benchmarks to [generated graphs](https://gnoland.github.io/benchmarks), if any. More info [here](https://github.com/gnolang/gno/blob/master/.benchmarks/README.md). </details>