Initial Enablement of Program Mapper Component

[kylanerace]

Proposed changes

• Initial Commit Enabling the Program Mapper component
• Added Program Mapper to pre-commit source path

Types of changes

What types of changes does your code introduce to the Encrypted Computing SDK project?
Put an x in the boxes that apply

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update (if none of the other choices apply)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating
the PR. If you are unsure about any of them, do not hesitate to ask. We are
here to help! This is simply a reminder of what we are going to look for before
merging your code.

• I have read the CONTRIBUTING agreement
• Current formatting and unit tests / base functionality passes locally with my changes
• I have added tests that prove my fix is effective or that my feature works (if appropriate)
• I have added necessary documentation (if appropriate)
• Any dependent changes have been merged and published in downstream modules

Further comments

N/A

[joserochh]

For the format action failing we can add an installation step for cpplint

- name: Install cpplint if C++ changed
  if: steps.cpp_check.outputs.cpp_changed == 'true'
  run: pip install cpplint

Or perhaps we can have a requirements-dev.txt in the root with pytest, pylint and cpplint, which are not setup by the pre-commit-config.yml. And then reference this on CONTRIBUTING.md.

So requirements-dev.txt can be something like:

# Pre-commit framework
pre-commit>=3.5.0

# Testing
pytest>=7.4.0

# Python development tools
pylint>=3.0.0

# Optional: For IDE integration and manual use (pre-commit handles these automatically)
# black==25.1.0
# mypy==1.16.0

# C++ linting
cpplint>=1.6.0

[kylanerace]

For the format action failing we can add an installation step for cpplint

- name: Install cpplint if C++ changed
  if: steps.cpp_check.outputs.cpp_changed == 'true'
  run: pip install cpplint

Or perhaps we can have a requirements-dev.txt in the root with pytest, pylint and cpplint, which are not setup by the pre-commit-config.yml. And then reference this on CONTRIBUTING.md.

So requirements-dev.txt can be something like:

# Pre-commit framework
pre-commit>=3.5.0

# Testing
pytest>=7.4.0

# Python development tools
pylint>=3.0.0

# Optional: For IDE integration and manual use (pre-commit handles these automatically)
# black==25.1.0
# mypy==1.16.0

# C++ linting
cpplint>=1.6.0

I lean towards the latter. Other folks contributing will need those dependencies on their own system to do so anyway, and it avoids needing to edit the workflow every time a new dep pops up. Want to update the requirements as part of this PR or a separate one?

[kylanerace]

Apparently as of v4, you can only have one "run" trigger per label unless you make the run itself a step... modifying to fix now

[faberga]

@kylanerace , @joserochh and @christopherngutierrez
Awesome that this PR has been raised !

[joserochh]

LGTM, initial commit of the Program Mapper.

[faberga]

If for this commit we are gonna stick with Ubuntu 22.04 then we need to change .github/workflows/format.yml line 13 to say runs-on: ubuntu-22.04

I'm ok with sticking with 22.04 for this initial enablement.

[kylanerace]

If for this commit we are gonna stick with Ubuntu 22.04 then we need to change .github/workflows/format.yml line 13 to say runs-on: ubuntu-22.04

I'm ok with sticking with 22.04 for this initial enablement.

We set it to 24.04 because we were already effectively running it by using the default "ubuntu-latest" (actions pulls 24.04). So this change is purely to be more explicit, and to avoid GitHub actions updating to pull a different version potentially causing issues in the future.

We've run code on both 22.04 and 24.04, though minimum required version is still assumed to be 22.04 by various components.

[christopherngutierrez]

LGTM, tested locally.

[faberga]

If we are already testing with 24.04, then let's change the README.md to reflect that. I will review that with a suggestion, and you can choose to accept.

[kylanerace]

If we are already testing with 24.04, then let's change the README.md to reflect that. I will review that with a suggestion, and you can choose to accept.

I'd want to avoid putting the latest version as 1. it's still not the primary system that we all use for development and 2. It will cause people to think they HAVE to update. I could see updating the README to say something to the effect of: Ubuntu 22.04+.

But let's do general README documentation/updates in a separate PR, as there are a decent amount of other updates to do there anyway (only functional_modeler and program_mapper even mention OS-version requirements, probably will want a top-level README for p-isa to clarify build guidance, etc.)

[faberga]

@kylanerace, that is good with me.
I will resolve the conversation and approve the PR.