Skip to content

Feature/mintlayer app#1

Open
OBorce wants to merge 319 commits into
masterfrom
feature/mintlayer-app
Open

Feature/mintlayer app#1
OBorce wants to merge 319 commits into
masterfrom
feature/mintlayer-app

Conversation

@OBorce

@OBorce OBorce commented Sep 30, 2025

Copy link
Copy Markdown
Collaborator

No description provided.

yhql and others added 30 commits June 20, 2023 11:21
use dedicated sections for each device
Update app : features, UI, tests, CI.
@OBorce OBorce force-pushed the feature/mintlayer-app branch from 98949a4 to 5faeaaf Compare December 19, 2025 02:36

@ImplOfAnImpl ImplOfAnImpl left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't have enough time to look through all the code, I'll continue after returning from my vacation.

Comment thread .cargo/config.toml
Comment on lines +11 to +15
# By default, heap size is enforced to 8192 bytes.
# Authorized values are [2048, 4096, 8192, 16384, 24576]
# Uncomment the following lines to set the heap size to 4096 bytes for instance
[env]
HEAP_SIZE = "16384"

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Plz remove the original comment and write our own, explaining why we need this particular heap size

Comment thread Cargo.toml
Comment thread Cargo.toml Outdated
@@ -0,0 +1,44 @@
name: Build and run functional tests using ragger through reusable workflow

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rename the file to build_and_run_functional_tests.yml?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't rename it as it comes from their boilerplate app conventions

Comment thread ledger_app.toml Outdated
Comment thread Cargo.toml Outdated
Comment on lines +27 to +29
[profile.release]
opt-level = 'z'
lto = true

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another thing worth adding here is codegen-units = 1
E.g. I tried building for apex_p. Before:

# llvm-size /app/target/apex_p/release/mintlayer-app
   text	  data	   bss	   dec	   hex	filename
 145080	  1024	 19576	165680	 28730	/app/target/apex_p/release/mintlayer-app

and with codegen-units = 1:

# llvm-size /app/target/apex_p/release/mintlayer-app
   text	  data	   bss	   dec	   hex	filename
 136224	  1024	 19576	156824	 26498	/app/target/apex_p/release/mintlayer-app

I.e. the app will occupy 136224+1024 bytes of flash instead of 145080+1024.

P.S. the BSS section is the amount of RAM that the app's static data will occupy (it will be filled with zeroes at startup). I wonder whether this value is high and, if yes, whether we should look for ways to reduce it. IMO it'd make sense to at least look at other app's binaries (e.g. Ethereum and Bitcoin) and check their BSS sections (will need to build the apps from source for this).
One possible way of trying to reduce it would going through all dependencies and turning off all unneeded default features.

Comment thread messages/src/lib.rs Outdated
Comment thread messages/src/lib.rs Outdated
Comment thread src/main.rs Outdated
Comment thread messages/src/lib.rs Outdated
@OBorce OBorce force-pushed the feature/mintlayer-app branch from bf565b1 to 9ca7570 Compare January 15, 2026 07:30

@ImplOfAnImpl ImplOfAnImpl left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TBF I'm tired from your approach to PRs. From now on I want:

  1. A clear indication of when a PR is ready for review. Normally, after changes have been requested, the PR should be changed to draft and when it comes back to "ready for review", then it's the indication that it is ready. If the PR never went to the draft state, then there should be some other indication, e.g. a comment "ready for review" or something. I will no longer look at PRs without clear indication that they're ready.
  2. The code in a non-draft PR should be of production quality. No forgotten pieces of the original boilerplate app, no unused entities, outdated comments. Also, the usual general best practices should have already been applied - code duplication reduced to minimum, named constants instead of magic numbers etc.
    (Btw, I'm not telling that the code should not have issues at all. But there is a huge difference between missing an issue and not bothering to even check).
  3. To achieve #2 you have to review your own PRs. At least scroll through the diff looking for obvious issues/dirty code. E.g. I do this with my own PRs.
    If you don't bother reviewing your own code, why should I. Doing code review is not pleasant and having to proof-read someones dirty code over and over again sucks all the fun from developer's life.
  4. All review comments should be addressed, which means: applying the comment, initialing its discussion, either on GitHub or Slack, dropping it with a counter-comment, adding TODO to investigate it later, etc. Basically anything will do, except for silently ignoring it.
    Again, accidents can happen, especialy in a large PR, but if they happen too often, then maybe the author of the PR doesn't care enough. And if he doesn't, then why should the reviewer care to write them, right?

Comment thread src/handlers/sign_tx.rs Outdated
Comment thread src/handlers/sign_tx.rs Outdated
Comment on lines +222 to +225
// version
tx_hasher
.update(&[version])
.map_err(|_| StatusWord::TxHashFail)?;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is conceptually wrong - if we ever have Transaction::V2, it may have a completely different structure. So, instead of blindly encoding the version value, we should check if it's 1 and fail if it's not.
Also, the tx version should probably be an enum inside messages, e.g. TransactionVersion.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Made the tx version into an enum in the requests

Comment thread messages/src/lib.rs Outdated
Comment thread messages/src/lib.rs Outdated
Comment thread messages/src/lib.rs Outdated
Comment thread src/handlers/sign_tx.rs Outdated
Comment thread src/handlers/sign_tx.rs Outdated
Comment thread src/main.rs
}

struct Context {
pub data: DataContext,

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

data_context

Though I'm not sure why the word "data" is here, probably the struct should be just Context and the field context.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure about this one, as the outer struct is already named Context

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure about this one, as the outer struct is already named Context

The name of the outer struct has nothing to do with this. The type of data is DataContext, which means "context related to data", so it's a "context", i.e. names like context or data_context would make sense, but data doesn't. But if the type was named ContextData, which would mean "data related to context", then data or context_data would make sense.
Plz decide whether your type is "data context" or "context data" and name both it and the field accordingly.

Comment thread src/handlers/sign_message.rs Outdated
Comment thread tests/application_client/mintlayer_command_sender.py Outdated
ImplOfAnImpl and others added 2 commits April 15, 2026 13:13
…rkflows. Run cargo-fmt. Update ledger_device_sdk version.
Update mintlayer-core-primitives repo revision. Enable disabled CI workflows.
@OBorce OBorce marked this pull request as draft April 20, 2026 10:13
@OBorce OBorce force-pushed the feature/mintlayer-app branch 6 times, most recently from 6b7b7d6 to b1a037f Compare May 27, 2026 07:39
@OBorce OBorce force-pushed the feature/mintlayer-app branch from b1a037f to 54deb76 Compare May 27, 2026 07:48
@OBorce OBorce marked this pull request as ready for review May 27, 2026 08:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.