Skip to content

Conversation

@grooviegermanikus
Copy link
Contributor

@grooviegermanikus grooviegermanikus commented Jan 13, 2026

Addresses this issue

Test with filtered-pipeline

pub inner: Vec<InstructionUpdate>,
/// The index of this instruction within the transaction.
/// always set after parsing.
pub ix_path: Option<IxPath>,
Copy link
Collaborator

Choose a reason for hiding this comment

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

ig we can call is ix_index , wyt @kespinola

Suggested change
pub ix_path: Option<IxPath>,
pub ix_index: Option<IxIndex>,

Copy link
Contributor Author

@grooviegermanikus grooviegermanikus Jan 15, 2026

Choose a reason for hiding this comment

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

IxIndex sounds nice but does it imply that the thing is multiple levels deep? I'm good with ix_index nevertheless

Copy link
Collaborator

Choose a reason for hiding this comment

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

Path is good with me I'd just call the field path though since its on an instruction update object already.

.map(|i| Self::parse_one(Arc::clone(&shared), i))
.collect::<Result<Vec<_>, _>>()?;

for (index_outer, outer_instr) in outer.iter_mut().enumerate() {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
for (index_outer, outer_instr) in outer.iter_mut().enumerate() {
for (index_outer, outer_ix) in outer.iter_mut().enumerate() {


Self::parse_inner(&shared, inner_instructions, &mut outer)?;

for outer_instr in &outer {
Copy link
Collaborator

Choose a reason for hiding this comment

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

same comment as above

pub inner: Vec<InstructionUpdate>,
/// The index of this instruction within the transaction.
/// always set after parsing.
pub ix_path: Option<IxPath>,
Copy link
Collaborator

Choose a reason for hiding this comment

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

any reason this is optional ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

my approach visits the tree after it got constructed and updates the path

Copy link
Collaborator

Choose a reason for hiding this comment

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

Is there anyway to compute it when the InstructionUpdate is being formed so its not an option?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

hm thought a bit about that but it that's not possible without modifying the traversal strategy

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I can try to change parse_inner to do traversal before the actual mapping (parse_one_inner)

Copy link
Contributor Author

@grooviegermanikus grooviegermanikus Jan 15, 2026

Choose a reason for hiding this comment

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

ig I found an easy way to derive the path from the stack height array

one more question: should we log the path in the places where errors/logs in vixen are referring to an instruction?

Comment on lines +132 to +134
pub struct IxIndex(Vec<u32>);

impl IxIndex {
Copy link
Collaborator

Choose a reason for hiding this comment

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

You are already in instruction module so call perhaps call it path so its instruction::Path

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.

3 participants