200 feature yellowpages standardized name mapping discovery#208
Conversation
…es-standardized-name-mapping-discovery
This comment was marked as outdated.
This comment was marked as outdated.
…es-standardized-name-mapping-discovery
|
I do not understand why the |
I think it will be fine. I might make some adjustments to the YellowPages, but I believe it is the easiest way to implement it. Basically, I will fetch all the necessary data from several sub-holders instead of the main ones. |
|
OK so I would prefer to hide this internal functions from the API using sr.live.tools.get() |
Ok |
…es-standardized-name-mapping-discovery
|
Hi @gupichon-soleil I tested this PR with SOLEIL II configuration from last workshop and found a few issues: It seems that all CFM are seen as a Arrays by the YellowPages. I am not sure if this is a configuration issue (on SOLEIL conf) or a YellowPage problem: If I check, then I see clearly that this Array just corresponds to the different components of my CFM: There is also an issue with the design control mode, which seems not to be accessible: Why live and not design ? In fact, design mode is not seen by yellow_page._get Somehow this is not working: But this is: Regular expression also don't work as expected: |
…es-standardized-name-mapping-discovery
I'll look to it and add some tests |
|
Would it be possible to have a coherent syntax as in wildcard configuration ? sr.yellow_pages["OH4*"] # fnmatch
sr.yellow_pages["re:^SH1A-C0[12]-H$"] # regexp |
…es-standardized-name-mapping-discovery
That’s a point I wanted to discuss. Which syntax do you prefer? My initial plan was to test this syntax here and, if everyone liked it, implement it everywhere. However, it is quite too complex for the actual needs. I’m changing it to the “classic” syntax used in the wildcard-based configuration. It will also solve the bugs that were observed, as the regex used to parse the query is too complicated anyway. |
|
@GamelinAl, @JeanLucPons sr.yellow_pages["re{OH4*}"]
>>> ['OH10_QCORROCT_112_QT_001',
'OH10_QCORROCT_112_QT_001.octupole',
'OH10_QCORROCT_112_QT_001.quadrupole',
'OH10_QCORROCT_112_QT_001.skewquad',
'OH10_QCORROCT_113_QT_001',
'OH10_QCORROCT_113_QT_001.octupole',
'OH10_QCORROCT_113_QT_001.quadrupole',
'OH10_QCORROCT_113_QT_001.skewquad',
'OH10_QCORROCT_134_QT_001',
...]This is a correct result for the given regex, as it matches elements containing @JeanLucPons, it seems that the CFMs are added as arrays, is that correct? Requesting I’ll commit the modifications this morning. |
…es-standardized-name-mapping-discovery
…ssible. The get method is now public and returns an array of strings. The query syntax has been updated to match the one used in the configuration file. It is also possible to query an array by its name.
|
Everything should be OK now, I update the PR description. |
|
Could you add your new module in apidoc/genapi.py ? if m in ["pyaml.arrays.element_array"]:
# Include special members for operator overloading
file.write(
" :special-members: __add__, __and__, __or__, __sub__ \n"
)Thx |
|
One more remark: |
def __init__(self, accelerator: Any):
self._acc = acceleratorCould accelerator be typed to Accelerator rather than Any ? |
|
OK to what about renaming following function in def get_array(self, name: str):
def get_tool(self, name: str):
def list_tools(self) -> list[str]:
def list_diagnostics(self) -> list[str]:to def _get_array(self, name: str):
def _get_tool(self, name: str):
def _list_tools(self) -> list[str]:
def _list_diagnostics(self) -> list[str]:Thanks |
|
Ok, I believe everything is done now. Could you confirm? |
|
Could you replace "Expected Accelerator interface" by "Accelerator interface" ? 
|
|
It would be nice to have link in the doctring, such as :py:class:`~pyaml.accelerator.Accelerator`when possible. |
|
Small details (I presume) 
|
Wrong copy/paste... |
JeanLucPons
deleted the
200-feature-yellowpages-standardized-name-mapping-discovery
branch
5 participants
Pull Request
Description
This pull request introduces a dynamic YellowPages service for the
Acceleratorobject.The goal is to provide a unified discovery interface for arrays, tuning tools and diagnostics available in an accelerator configuration.
The service scans all
ElementHolderinstances associated with the accelerator controls and simulators and exposes the discovered objects through a simple API.The implementation is fully dynamic:
ElementHolderat runtimeThe service provides a simple identifier lookup API with two complementary behaviors:
If the query exactly matches a discovered array name, the identifiers contained in this array are returned.
The search syntax is intentionally simple:
fnmatchre:prefixThe
get()method always returns alist[str], and__getitem__is an alias to it.The
__repr__representation provides a compact overview of:including:
Example output:
A specific effort was also made to preserve element ordering whenever possible:
Related Issue
Features/issues described there are:
__repr__Changes to existing functionality
The following changes were required to integrate YellowPages into the accelerator architecture:
Added a new module
yellow_pages.pyimplementing the discovery serviceAdded
yellow_pagesproperty to theAcceleratorclassExtended
ElementHolderwith generic accessors:list_arrays()list_tools()list_diagnostics()get_array()get_tool()get_diagnostic()These methods allow YellowPages to dynamically discover objects without knowing their concrete implementation.
Added a structured
__repr__representation showing available objects, types and sizes.Testing
The following tests (compatible with
pytest) were added:ElementHolderhas(),keys(),categories()behaviorget()get(..., mode=...)yellow_pages.BPM)fnmatchre:syntax__repr__output structureVerify that your checklist complies with the project