Enhancement: Python client cannot read a parameter's bound expression (`in power = powerPort.power;`); only constant values are exposed
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
- #1981 di @devin-ai-integration — chiusa senza merge
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 42/100
Direzione di ricerca
Start with the attached repro.py and model to reproduce the missing binding in the Python client, then trace how Symbol facts and attribute_facts() expose parameter values. The requested API should report the binding expression, default status, and referenced features for feature chains while retaining folded constants. Also investigate why reflection returns an empty targetFeature.qualifiedName; done means the reproduced bindings and target feature are accessible through the relevant APIs.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
This issue was written with AI help. The model, the reproduction script and its output are
attached and were run against the version below.This is mainly a feature request. The issue form points feature requests to Discussions, but
Discussions are not enabled on this repository, so it is filed as an issue.
What happened, and what you expected instead
An action performed by a part binds its input parameter to a feature of the part's port:
part def Motor {
port powerPort : PowerPort;
perform action consume : Consume {
in power = powerPort.power; // bound to a feature chain
in gain = 0.5; // literal
}
action boost : Consume {
in power = powerPort.power * 2.0; // operator expression
}
}
A client walking the model (to generate an interface table, a simulation wiring, or code) needs
to know what each parameter is bound to. From Python:
| Route | consume::power = powerPort.power |
consume::gain = 0.5 |
boost::power = powerPort.power * 2.0 |
|---|---|---|---|
parameter Symbol (metadata, type_facts) |
direction in, type Real; no value |
same | same |
owner's attribute_facts() value |
None |
0.5 ✔ |
None |
model.query |
no property carries a value | same | same |
reflection, ….metadata.ownedRelationship (the FeatureValue) |
UnsupportedValueError: metaobject of an element with no qualified name |
same | same |
| api-json | FeatureValue → FeatureChainExpression, targetFeature = PowerPort::power ✔ |
FeatureValue → LiteralRational 0.5 ✔ |
FeatureValue → OperatorExpression '*' ✔ |
So a value is exposed only when it folds to a model-level constant (AttributeFacts.value is
documented that way: "Default value, when it is a model-level constant"). An expression that
refers to another feature, which is the normal way to wire a parameter, is invisible: there is
no text, no referenced feature, and no indication that the parameter is bound at all. The only
route to it is exporting the whole model as api-json and following
ownedRelationship → FeatureValue.value → the expression tree.
Requested: the Symbol API reports a feature's value binding when there is one. At minimum
that means the expression's source text and whether it is a default (isDefault/isInitial).
For a feature-chain expression it should also give the referenced features
(powerPort → PowerPort::power), so a client can follow the binding without parsing text.
AttributeFacts.value could stay as the folded constant beside it.
One reflection defect found on the way: even when navigating straight through the anonymous
elements, last(…::consume::power.metadata).ownedRelationship.value.targetFeature.qualifiedName
returns []. KerML v1.1 §8.3.4.8.4 derives FeatureChainExpression::targetFeature, and
api-json writes it as PowerPort::power. The anonymous-element limitation of reflection
(UnsupportedValueError) is the same one described in #1957.
Reproduction
$ python repro.py # loads model.sysml with opensysml.loads() over sysml-grpc
## consume::power = powerPort.power
[OK ] consume::power: Symbol reports direction and type
observed: {'metadata': {'visibility': 'default', 'direction': 'in'}, 'type_facts.primitive': 'Real'}
[INFO] consume::power: owner's attribute_facts() value
observed: None
[BUG ] consume::power: the Symbol API exposes the value or expression
observed: {'facts': {'metadata': {'visibility': 'default', 'direction': 'in'}, 'type_facts.primitive': 'Real'}, 'value': None}
expected: 'the expression `powerPort.power` (text, and for a chain the referenced feature)'
[INFO] consume::power: reflection ownedRelationship (the FeatureValue)
observed: UnsupportedValueError('unsupported: metaobject of an element with no qualified name')
[OK ] consume::power: api-json has FeatureValue -> FeatureChainExpression
observed: {'@type': 'FeatureChainExpression', 'targetFeature': {'@id': 'ParameterValues__PowerPort__power'}}
## consume::gain = 0.5
[INFO] consume::gain: owner's attribute_facts() value
observed: 0.5
## Reflection: FeatureChainExpression::targetFeature of consume::power
[BUG ] consume::power: ownedRelationship.value.targetFeature is PowerPort::power
observed: []
expected: ['ParameterValues::PowerPort::power']
model.sysml:
package ParameterValues {
port def PowerPort {
out attribute power : ScalarValues::Real;
}
action def Consume {
in power : ScalarValues::Real;
in gain : ScalarValues::Real;
}
part def Motor {
port powerPort : PowerPort;
perform action consume : Consume {
in power = powerPort.power; // bound to a feature chain -> not exposed
in gain = 0.5; // literal (for comparison) -> exposed as a value
}
action boost : Consume {
in power = powerPort.power * 2.0; // operator expression -> not exposed
}
}
}
Reproduction files (attached)
| File | Contents |
|---|---|
model.sysml.txt |
the model above (GitHub does not accept .sysml uploads): rename it to model.sysml next to repro.py |
repro.py |
loads model.sysml with opensysml.loads() and, for each parameter, checks the Symbol facts, the owner's attribute_facts(), the query API, reflection and the api-json export. Each check prints OK, BUG or INFO, and the script exits 1 while any BUG reproduces. |
_common.py |
shared helper the script imports: starts the sysml-grpc named by $OPENSYSML_BINARY, prints the server and client versions, and formats the checks |
output.txt |
the full output of the run reported here |
To run it, put _common.py in the parent directory of the folder holding repro.py and the model,
install the client (pip install -e client/python from an OpenSysML checkout), and point
OPENSYSML_BINARY at a sysml-grpc build:
$ OPENSYSML_BINARY=/path/to/OpenSysML/bin/sysml-grpc python repro.py
Without OPENSYSML_BINARY, _common.py assumes an OpenSysML checkout next to the directory
that holds _common.py, with bin/sysml-grpc built by make build-grpc.
Version
sysml-grpc v0.12.0-262-gc86932321 (develop at c86932321), opensysml Python client 0.12.0, Python 3.13.15
Surface
Python client (opensysml)
- Lingua principale
- Go
- Stelle
- 56
- Fork
- 17
- Merge medio
- 12h 31m
- PR unite (30g)
- 909
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di Open-MBEE/OpenSysML
-
dependencies
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
Open-MBEE/OpenSysML#1951 · 3 commenti · 1 reazione ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
I maintainer di solito rispondono entro 1 giorno
-
bug enhancement spec compliance
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
Open-MBEE/OpenSysML#2009 · 3 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
bug spec compliance
Difficoltà 4/5 3-5 giorni Idoneità per principianti 52/100
Open-MBEE/OpenSysML#2008 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
Open-MBEE/OpenSysML#2007 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di Open-MBEE/OpenSysML
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
multica-ai/multica#10081 ·
I maintainer di solito rispondono entro 1 giorno
-
csp-probe needs efqdn to probe CSP domainsForse già presa @unknownhackerworld l’ha presa 1 giorno fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
projectdiscovery/httpx#2725 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
stefanpejcic/OpenPanel#1321 ·
I maintainer di solito rispondono entro 1 giorno
-
bug triage/pending
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
I maintainer di solito rispondono entro 1 giorno