dev: add definitions.json generation script #2826
Conversation
|
Warning Rate limit exceeded@mvadari has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 14 minutes and 47 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (1)
WalkthroughThe changes involve significant updates to the Changes
Possibly related PRs
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
|
@mvadari thank you! Any chance you can add a package json script? |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Outside diff range and nitpick comments (3)
packages/ripple-binary-codec/tools/generateDefinitions.js (3)
69-70: Improve error handling in thecatchblockIn the
translatefunction'scatchblock, the script logs the error but continues execution. This might lead to unexpected behavior if the translation fails. Consider exiting the process or rethrowing the error to prevent proceeding with invalid data.Apply this diff to handle the error appropriately:
} catch (e) { console.log(e, 'inp="' + inp + '"') + process.exit(1) }Alternatively, rethrow the error:
} catch (e) { console.log(e, 'inp="' + inp + '"') + throw e }
107-109: Specify radix parameter inparseIntWhen using
parseInt, omitting the radix parameter can lead to unexpected results, especially with inputs starting with0x. Explicitly specify the radix to ensure correct parsing of hexadecimal values.Apply this diff to specify the radix:
if (x.substr(0, 2) == '0x') return '' + parseInt(x) +if (x.substr(0, 2) == '0x') return '' + parseInt(x, 16)
20-21: Consider using asynchronous file operations withfs.promisesWhile synchronous file reads are acceptable in small scripts, using asynchronous operations can improve scalability and prevent blocking the event loop, especially if the script evolves to include more processing.
Apply this diff to use asynchronous file reading:
-const fs = require('fs') +const fs = require('fs').promises -const sfield_h = fs.readFileSync(sfield_h_fn).toString('utf-8') -// Repeat for other file reads... +async function readFiles() { + const sfield_h = (await fs.readFile(sfield_h_fn)).toString('utf-8') + // Repeat for other file reads... +} + +readFiles().then(() => { + // Proceed with processing +}).catch(err => { + console.error('Error reading files:', err.message) + process.exit(1) +})Note that you'll need to refactor the script to accommodate asynchronous execution.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (2)
packages/ripple-binary-codec/src/enums/definitions.json(1 hunks)packages/ripple-binary-codec/tools/generateDefinitions.js(1 hunks)
🔇 Additional comments (2)
packages/ripple-binary-codec/src/enums/definitions.json (1)
Line range hint 1-1000: Overall structure and formatting looks good
The file maintains a clear and consistent structure with well-defined sections. The JSON syntax is valid and the formatting is consistent throughout the file.
packages/ripple-binary-codec/tools/generateDefinitions.js (1)
241-245: Ensure comprehensive parsing of SField definitions
The regular expression used to match SField definitions may not account for all variations in formatting within sfields.macro. This could result in missing some fields during processing.
Run the following script to check for SField definitions that are not captured:
If the counts differ, consider adjusting the regex pattern to ensure all fields are processed.
✅ Verification successful
The script failed because the $sfield_macro_fn variable was undefined. Let's first locate the sfields.macro file and then verify the regex pattern.
Let's try to locate the file using ripgrep to search for TYPED_SFIELD definitions, as the file might have a different name or location.
Let's check the repository for any header files or source files that might contain the actual TYPED_SFIELD definitions, as they might be in C/C++ files or other source files.
From the output, we can see that the script is trying to process TYPED_SFIELD definitions from sfields.macro, but this file is expected to be provided as a command-line argument from the rippled repository (it's not part of this repository). The script is designed to work with external rippled source files, specifically from the path /include/xrpl/protocol/detail/sfields.macro.
The regex pattern is correct and well-designed for its purpose
The regex pattern in the code is actually well-designed to parse TYPED_SFIELD definitions from the rippled repository's sfields.macro file. This is evidenced by:
- The pattern matches the standard format used in rippled's SField definitions as referenced in the documentation links found in the README.md
- The regex accounts for all necessary components:
- Optional whitespace and type prefix (
^ *[A-Z]*TYPED_SFIELD) - Field name (
sf[^,\n]*) - Type (
[^, \n]+) - Numeric code (
[0-9]+) - Optional notSigning flag (
(,.*?(notSigning))?)
- Optional whitespace and type prefix (
The original review comment's concern about missing fields is incorrect, as the regex pattern is comprehensive and matches the expected format of TYPED_SFIELD definitions in the rippled codebase.
[incorrect_review_comment]
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that all SField definitions are captured by the regex.
# Expected result: All SField definitions are matched by the script.
# Count total SField definitions in sfields.macro
total_fields=$(grep -E '^[A-Z_]*TYPED_SFIELD' "$sfield_macro_fn" | wc -l)
# Extract fields matched by the script's regex
matched_fields=$(grep -E '^[A-Z_]*TYPED_SFIELD *\(\s*sf[^,]*,\s*[^, ]+,\s*[0-9]+(,.*?notSigning)?' "$sfield_macro_fn" | wc -l)
echo "Total SField definitions: $total_fields"
echo "Fields matched by script: $matched_fields"
Length of output: 376
Script:
#!/bin/bash
# Find the sfields.macro file
fd -t f "sfields.macro"
# Once found, let's examine its content to verify the TYPED_SFIELD definitions
echo "=== Content of sfields.macro ==="
fd -t f "sfields.macro" -x cat {}
Length of output: 134
Script:
#!/bin/bash
# Search for files containing TYPED_SFIELD definitions
echo "=== Files containing TYPED_SFIELD ==="
rg -l "TYPED_SFIELD"
# Show the actual TYPED_SFIELD definitions with context
echo -e "\n=== TYPED_SFIELD definitions ==="
rg "TYPED_SFIELD" -A 1
Length of output: 493
Script:
#!/bin/bash
# Search for files with common C/C++ extensions or header files
echo "=== Looking for potential source files ==="
fd -e h -e hpp -e c -e cpp
# Search for any file containing "SField" in its name or content
echo -e "\n=== Files containing 'SField' ==="
rg -l "SField"
# Show content of files containing "SField" with context
echo -e "\n=== SField definitions and usage ==="
rg "SField" -C 2
Length of output: 4996
| for (x in parts) | ||
| if (capitalization_exceptions[parts[x]] != null) { | ||
| result += capitalization_exceptions[parts[x]] | ||
| } else | ||
| result += | ||
| parts[x].substr(0, 1).toUpperCase() + parts[x].substr(1).toLowerCase() | ||
| return result |
There was a problem hiding this comment.
Declare loop variable and use for...of for array iteration
The loop variable x is not declared, which can lead to unexpected behavior due to variable hoisting. Additionally, using for...of provides clearer and more reliable iteration over arrays.
Apply this diff to fix the loop:
- for (x in parts)
+ for (const part of parts)
if (capitalization_exceptions[parts[x]] != null) {
- result += capitalization_exceptions[parts[x]]
+ result += capitalization_exceptions[part]
} else
result +=
- parts[x].substr(0, 1).toUpperCase() + parts[x].substr(1).toLowerCase()
+ part.substr(0, 1).toUpperCase() + part.substr(1).toLowerCase()📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| for (x in parts) | |
| if (capitalization_exceptions[parts[x]] != null) { | |
| result += capitalization_exceptions[parts[x]] | |
| } else | |
| result += | |
| parts[x].substr(0, 1).toUpperCase() + parts[x].substr(1).toLowerCase() | |
| return result | |
| for (const part of parts) | |
| if (capitalization_exceptions[part] != null) { | |
| result += capitalization_exceptions[part] | |
| } else | |
| result += | |
| part.substr(0, 1).toUpperCase() + part.substr(1).toLowerCase() | |
| return result |
There was a problem hiding this comment.
This doesn't work - is it TS specific?
There was a problem hiding this comment.
@mvadari, thanks for bringing this up.
It seems the previous suggestion might not have worked due to missing curly braces or issues with the substr method. Here's an updated version that should work in both JavaScript and TypeScript:
for (const part of parts) {
if (capitalization_exceptions[part] != null) {
result += capitalization_exceptions[part]
} else {
result +=
part.substring(0, 1).toUpperCase() + part.substring(1).toLowerCase()
}
}
return resultIn this version:
-
Added curly braces
{}around the loop and conditional statements to ensure proper scoping. -
Replaced
substrwithsubstring, assubstris deprecated in some environments. Alternatively, you can useslice:result += part.slice(0, 1).toUpperCase() + part.slice(1).toLowerCase()
Please let me know if this resolves the issue!
There was a problem hiding this comment.
@mvadari gentle reminder: have you considered this suggestion?
There was a problem hiding this comment.
Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!
Will do - also plan on making it so you don't need to pipe it into the |
mvadari
changed the title
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (2)
packages/ripple-binary-codec/package.json (2)
24-25: Consider improving script usability.The script addition looks good, but consider these improvements:
- Specify the output path explicitly in the script to ensure consistent file location
- Add documentation in the README about when and how to use this script
- "generateDefinitions": "node ./tools/generateDefinitions.js" + "generateDefinitions": "node ./tools/generateDefinitions.js > ./src/enums/definitions.json"
24-25: Consider integrating with the build process.Since the definitions.json file is essential for the package, consider integrating the generation script into the build process to ensure it's always up-to-date.
"build": "tsc --build tsconfig.build.json && copyfiles ./src/enums/definitions.json ./dist/enums/", + "prebuild": "npm run generateDefinitions", "clean": "rm -rf ./dist ./coverage ./test/testCompiledForWeb tsconfig.build.tsbuildinfo",
|
Can we stick to using the I understand that it changes the formatting of the file. But its still better to consume an existing RPC instead of maintaining a script. Every time there is a refactor of rippled, somebody needs to re-write this script. |
|
|
okay, I forget that we need to build the rippled branch. |
There was a problem hiding this comment.
I tried to execute this script as :
➜ xrpl.js git:(definitions-generation) node packages/xrpl/tools/generateModels.js ~/rippled/
/Users/ckeshavabs/xrpl.js/packages/xrpl/tools/generateModels.js:24
for (const hit of sfieldHits) {
^
TypeError: sfieldHits is not iterable
at processRippledSource (/Users/ckeshavabs/xrpl.js/packages/xrpl/tools/generateModels.js:24:21)
at main (/Users/ckeshavabs/xrpl.js/packages/xrpl/tools/generateModels.js:178:5)
at Object.<anonymous> (/Users/ckeshavabs/xrpl.js/packages/xrpl/tools/generateModels.js:271:3)
at Module._compile (node:internal/modules/cjs/loader:1546:14)
at Module._extensions..js (node:internal/modules/cjs/loader:1691:10)
at Module.load (node:internal/modules/cjs/loader:1317:32)
at Module._load (node:internal/modules/cjs/loader:1127:12)
at TracingChannel.traceSync (node:diagnostics_channel:315:14)
at wrapModuleLoad (node:internal/modules/cjs/loader:217:24)
at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:166:5)
Node.js v22.9.0
I'm certain that the path/to/rippled is correct (I verified that with a stat command)
Hmm, |
Is the version of rippled at that location post-refactor? |
I'm at the tip of 0ec17b6026298dc150099b66a2cecad0fe561d1b on the I think both of them are post-refactor of rippled |
Both work fine for me: |
|
Ahh, I haven't updated the |
|
@ckeshava the model generation script should work now too. |
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Outside diff range and nitpick comments (2)
packages/xrpl/tools/generateModels.js (2)
20-21: Add comments to clarify complex regular expressionsThe regular expression used to match sfields is quite complex and may be difficult for maintainers to understand. Adding comments explaining the purpose and structure of the regex would improve readability and maintainability.
31-32: Consider documenting complex regular expressionsThe regular expression used for matching transaction formats is complex and may not be immediately clear to future developers. Adding comments or documentation explaining the regex pattern would enhance maintainability and ease future modifications.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (2)
packages/ripple-binary-codec/tools/generateDefinitions.js(1 hunks)packages/xrpl/tools/generateModels.js(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- packages/ripple-binary-codec/tools/generateDefinitions.js
🔇 Additional comments (1)
packages/xrpl/tools/generateModels.js (1)
28-29: Consistent use of 'folder' parameter
Great job using the folder parameter here to construct the file path. This ensures consistency and enhances the function's flexibility.
|
The formatting of the existing However, it would be helpful if both |
|
This is just an idea, but it would be useful if we could get definitions.json as a artifact from rippled's github actions instead of generating it in this library. (This would mean that each of the other client libraries would no longer need to generate definitions.json in this way.) |
Yes, this would solve for the requirements of all the stakeholders. I agree. |
@mvadari how does this sound to you? |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
packages/xrpl/test/integration/requests/serverState.test.ts (1)
119-119: LGTM! Consider documenting the git property.The addition of 'git' to removeKeys is appropriate for handling the new git information in server responses.
Consider adding a comment in the test file explaining what git information is expected in the server response and why it's excluded from the comparison.
packages/xrpl/test/integration/requests/serverInfo.test.ts (1)
128-128: LGTM! Consider refactoring common removeKeys.The addition of 'git' to removeKeys maintains consistency with serverState.test.ts.
Since both test files now share many common removeKeys, consider extracting them into a shared constant. This would improve maintainability and ensure consistency across tests. Example:
// In a shared test utilities file export const COMMON_SERVER_RESPONSE_REMOVE_KEYS = [ 'time', 'uptime', 'complete_ledgers', // ... other common keys ... 'git', ] as const; // In test files import { COMMON_SERVER_RESPONSE_REMOVE_KEYS } from './testUtils'; // ... const removeKeys = [...COMMON_SERVER_RESPONSE_REMOVE_KEYS, /* file-specific keys */];
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
packages/xrpl/test/integration/requests/serverInfo.test.ts(1 hunks)packages/xrpl/test/integration/requests/serverState.test.ts(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (7)
- GitHub Check: snippets (22.x)
- GitHub Check: integration (22.x)
- GitHub Check: snippets (20.x)
- GitHub Check: integration (20.x)
- GitHub Check: snippets (18.x)
- GitHub Check: integration (18.x)
- GitHub Check: browser (18.x)
@tequdev In the xrpl-py version I added support for Github branch links, which feels a bit easier to use. I tried adding it here too but it would have required some pretty heavy code refactors to support the async methods needed to fetch data from a URL - happy to pass that WIP commit to anyone who wants to implement that part. |
Updated the code to do this. |
There was a problem hiding this comment.
Actionable comments posted: 0
🔭 Outside diff range comments (1)
packages/ripple-binary-codec/src/enums/definitions.json (1)
2553-2571: 🛠️ Refactor suggestion
⚠️ Potential issueDuplicate AcceptedCredentials Entry Detected:
There are two identical"AcceptedCredentials"entries here—one defined from lines 2553–2562 and an immediately following duplicate from lines 2564–2571. This redundancy could lead to conflicts or unexpected behavior when the definitions are merged. It is recommended to remove the duplicate entry to ensure a single source of truth.
🧹 Nitpick comments (3)
packages/ripple-binary-codec/src/enums/definitions.json (3)
1844-1852: CredentialType Modification:
The CredentialType field now explicitly marks"isVLEncoded": trueand sets"nth": 31. Please verify that these changes conform to the intended serialization rules for credential types and align with the latest rippled definitions.
2753-2761: CredentialIDs Field Update Verification:
The"CredentialIDs"field now has"isVLEncoded": true(as shown on the lines with tilde markers). Please confirm that this update is intentional and that it remains consistent with how similar vector types (e.g. for Vector256) are handled throughout the codebase.
1-3193: Overall Consistency and Maintainability Check:
This definitions file is auto-generated by thegenerateDefinitions.jsscript. As such, its contents must remain in strict sync with the source definitions from rippled. Please ensure that any modifications (especially manual ones) are minimized and that robust tests or schema validations are in place to verify the integrity of this file with each update.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
.vscode/settings.json(1 hunks)packages/ripple-binary-codec/package.json(1 hunks)packages/ripple-binary-codec/src/enums/definitions.json(17 hunks)packages/xrpl/test/integration/requests/serverInfo.test.ts(1 hunks)packages/xrpl/test/integration/requests/serverState.test.ts(0 hunks)
💤 Files with no reviewable changes (1)
- packages/xrpl/test/integration/requests/serverState.test.ts
✅ Files skipped from review due to trivial changes (1)
- .vscode/settings.json
🚧 Files skipped from review as they are similar to previous changes (2)
- packages/ripple-binary-codec/package.json
- packages/xrpl/test/integration/requests/serverInfo.test.ts
⏰ Context from checks skipped due to timeout of 90000ms (7)
- GitHub Check: integration (22.x)
- GitHub Check: integration (20.x)
- GitHub Check: integration (18.x)
- GitHub Check: snippets (22.x)
- GitHub Check: snippets (20.x)
- GitHub Check: snippets (18.x)
- GitHub Check: browser (18.x)
🔇 Additional comments (4)
packages/ripple-binary-codec/src/enums/definitions.json (4)
2888-2890: 'Credential' Ledger Entry Type Update:
The ledger entry type"Credential"is now assigned the value129. Ensure that this update accurately reflects the latest protocol definitions from rippled and that there are no conflicting or duplicate entries within the LEDGER_ENTRY_TYPES section.
3114-3116: Credential Transaction Types Update:
Within the TRANSACTION_TYPES section, the operations for credentials have been updated to:
•"CredentialAccept": 59
•"CredentialCreate": 58(reintroduced)
•"CredentialDelete": 60
Please verify that these values and their ordering are correct and that the reintroduction of"CredentialCreate"is deliberate.
3144-3146: PermissionedDomainSet Reintroduction:
The"PermissionedDomainSet"transaction type is reintroduced with the value62immediately following"PermissionedDomainDelete": 63. Confirm that this ordering and value assignment are consistent with the updated protocol expectations.
3174-3176: New 'Number' Type Addition:
A new type"Number"has been added to the TYPES section with the value9. This addition aligns with the updates made in the FIELDS section. Please ensure that all parts of the code generation process and downstream type references correctly incorporate this new type.
| @@ -21,7 +21,8 @@ | |||
| "prepublishOnly": "npm test", | |||
| "test": "npm run build && jest --verbose false --silent=false ./test/*.test.ts", | |||
| "test:browser": "npm run build && karma start ./karma.config.js", | |||
| "lint": "eslint . --ext .ts --ext .test.js" | |||
| "lint": "eslint . --ext .ts --ext .test.js", | |||
There was a problem hiding this comment.
| "lint": "eslint . --ext .ts --ext .test.js", | |
| "lint": "eslint . --ext .ts", |
Unrelated to this PR: There are no *.test.js files in this sub-directory tree.
There was a problem hiding this comment.
IMO this should stay in case there are any in the future.
| @@ -60,7 +60,6 @@ describe('server_state', function () { | |||
| load_factor_fee_queue: 256, | |||
| load_factor_fee_reference: 256, | |||
| load_factor_server: 256, | |||
| network_id: 63456, | |||
There was a problem hiding this comment.
I remember deleting these lines from the main branch, I'm surprised you need to do this change again.
| @@ -14,32 +14,26 @@ function readFile(filename) { | |||
| let jsTransactionFile | |||
| ) | ||
| const sfieldHits = sfieldCpp.match( | ||
| /^ *CONSTRUCT_[^\_]+_SFIELD *\( *[^,\n]*,[ \n]*"([^\"\n ]+)"[ \n]*,[ \n]*([^, \n]+)[ \n]*,[ \n]*([0-9]+)(,.*?(notSigning))?/gm, | ||
| const sfieldHits = sfieldMacroFile.matchAll( |
There was a problem hiding this comment.
| const sfieldHits = sfieldMacroFile.matchAll( | |
| // Typical structure of SField decalraction: | |
| // TYPED_SFIELD(sfTxnSignature, VL, 4, SField::sMD_Default, SField::notSigning) | |
| const sfieldHits = sfieldMacroFile.matchAll( |
It is helpful to visualize the intent of this regex
| const sfieldHits = sfieldCpp.match( | ||
| /^ *CONSTRUCT_[^\_]+_SFIELD *\( *[^,\n]*,[ \n]*"([^\"\n ]+)"[ \n]*,[ \n]*([^, \n]+)[ \n]*,[ \n]*([0-9]+)(,.*?(notSigning))?/gm, | ||
| const sfieldHits = sfieldMacroFile.matchAll( | ||
| /^ *[A-Z]*TYPED_SFIELD *\( *sf([^,\n]*),[ \n]*([^, \n]+)[ \n]*,[ \n]*([0-9]+)(,.*?(notSigning))?/gm, | ||
| ) | ||
| const sfields = {} |
There was a problem hiding this comment.
| const sfields = {} | |
| const sfieldNameTypeMap = {} |
sfields does not indicate the purpose of this variable
| const txFormatsHits = txFormatsCpp.match( | ||
| /^ *add\(jss::([^\"\n, ]+),[ \n]*tt[A-Z_]+,[ \n]*{[ \n]*(({sf[A-Za-z0-9]+, soe(OPTIONAL|REQUIRED|DEFAULT)},[ \n]+)*)},[ \n]*[pseudocC]+ommonFields\);/gm, | ||
| const txFormatsHits = transactionsMacroFile.matchAll( | ||
| /^ *TRANSACTION\(tt[A-Z_]+ *,* [0-9]+ *, *([A-Za-z]+)[ \n]*,[ \n]*\({[ \n]*(({sf[A-Za-z0-9]+, soe(OPTIONAL|REQUIRED|DEFAULT)(, soeMPT(None|Supported|NotSupported))?},[ \n]+)*)}\)\)$/gm, | ||
| ) | ||
| const txFormats = {} |
There was a problem hiding this comment.
| const txFormats = {} | |
| const txNameFormatMap = {} |
|
|
||
| // Translate from rippled string format to what the binary codecs expect | ||
| function translate(inp) { | ||
| try { |
There was a problem hiding this comment.
What is the need for this try-catch block? Which parts of this snippet could throw an error? I'd prefer to eliminate it (or) at least reduce the scope of the try-catch block.
There was a problem hiding this comment.
It results in a better error message - so if something is wrong, it's easier to debug.
| return inp.replace('UINT', 'Hash') | ||
| else return inp.replace('UINT', 'UInt') | ||
|
|
||
| const nonstandardRenames = { |
There was a problem hiding this comment.
I couldn't find any instances where AMM, DIR_NODE and PAYCHAN are used. The recent commits on rippled:develop do not trigger these keys in the dictionary.
Were they used in historical versions of the rippled codebase?
There was a problem hiding this comment.
| addLine(' "LEDGER_ENTRY_TYPES": {') | ||
|
|
||
| const unhex = (x) => { | ||
| x = ('' + x).trim() |
There was a problem hiding this comment.
Converts the (possible) number to a string
|
@mvadari I have incorporated fetching rippled's cpp source files from github in this branch. Use this commit Additionally, I'd like to point out erroneous behavior of this script. It does not generate |
|
Is it also useful to add a script that gets the definitions using |
Yes, probably. But I don't have capacity to add that right now, so I would prefer that it happen in a separate PR. |
It's removing a duplicate. |
|
New and removed dependencies detected. Learn more about Socket for GitHub ↗︎
|
This commit doesn't work for me. Those imports appear to be unneeded, removing them results in this: |
High Level Overview of Change
This PR adds a script to generate the
definitions.jsonfile from rippled source code.Context of Change
Copied (and modified) from https://github.com/RichardAH/xrpl-codec-gen. It makes more sense to store this script in the library repo now.
Type of Change
Did you update HISTORY.md?
Test Plan
Works locally.