Skip to content

Use the configured time-context type in time() - #271

Merged
zimri-leisher merged 2 commits into
fprime-community:develfrom
zakariyaghazzol:fpy-time-context-width
Oct 25, 2026
Merged

zimri-leisher merged 2 commits into
fprime-community:develfrom
zakariyaghazzol:fpy-time-context-width

Conversation

@zakariyaghazzol

@zakariyaghazzol zakariyaghazzol commented Oct 16, 2026 •

Copy link
Copy Markdown

Fixes #221.

Summary

  • Use the dictionary-configured time-context type for the time() argument, its zero default, and the returned constant.
  • Keep the existing compiler caching behavior. Clear cached and derived dictionary state in the tests instead of adding production behavior for switching dictionaries.
  • Use explicit U8/U16/U32/U64 test configurations and remove the cache-hit/switching tests.

Regression coverage checks configured types/defaults, exact serialized bytes, integer limits, and compilation for both backends. Runtime cases exercise default, explicit, and maximum contexts on both reference-configured sequencers.

Validation

  • Python 3.12.3: 34 focused tests passed.
  • Full local suite: 1,696 passed, one existing XPASS, zero failures.
  • Black (--check --target-version py310) and git diff --check passed.

Local runtime tests reused the existing real bytecode and Wasm C++ harness binaries after verifying their hashes, harness sources, and submodule revisions; this revision did not rebuild the native harnesses. The previously supplied Wasm harness compatibility patch remains local and is excluded from this PR.

No dependency, workflow, submodule, or runtime-configuration changes are included.

Comment thread src/fpy/state.py Outdated
default_time_base = DEFAULT_TIME_BASE
# TIME and time() are shared by cached scopes. Restore this dictionary's
# context type even when _build_global_scopes returns a cached entry.
_update_time_context_type_from_dict(load_dictionary(dictionary)["type_defs"])

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 seems inconsistent with the rest of the code. instinct is telling me that we shouldn't have this here. my loose understanding is that there's a caching issue due to lru_cache, which causes multiple diff dictionaries loaded in same process to interfere with each other. can't you just reset the cache in the tests instead of this? in reality for the fprime-fpyc we never load two dicts, so it's not an "actual" problem, just one for tests

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.

then you can remove the extra tests for cache hit stuff

Comment thread test/fpy/test_time_context_config.py Outdated


@pytest.fixture
def context_dictionary(tmp_path):

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.

can you please simplify this test code a bit? you're making quite a complex helper here, all you want to test is that for a given dictionary, we configure these various types and macros properly. so just make a couple dictionaries, hard coded is fine, and check that they work as expected

@zakariyaghazzol

Copy link
Copy Markdown
Author

Thanks for the feedback. Updated in cabb756: I removed the production cache-switching behavior and cache-hit tests, The fixture now clears the caches and derived time defaults between tests, so each test starts with independent configuration state.

I also replaced the dictionary factory and its path cache with four explicit U8/U16/U32/U64 configurations. The helper now just copies the reference dictionary and replaces its time-context type.

@zimri-leisher
zimri-leisher merged commit 95d6609 into fprime-community:devel Oct 25, 2026
6 of 7 checks passed
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.

2 participants