-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add straightforward endianness implementation; accommodate all allowable string encodings #26
base: main
Are you sure you want to change the base?
Conversation
Note that lxml>=4.8 is needed because that is when support for `Path` objects was added to `parse()`: https://lxml.de/4.8/changes-4.8.0.html
@cgobat This is great work and I want to get these changes in. I think I will do the same thing as your last PR and take these changes and incorporate them into a different changeset that includes tests and omits a few pieces (e.g. I'm still torn on incorporating the lxml dependency and a lot of tests will need to be reworked for that I think). If you're concerned about claiming "credit" for the changes, I can try to teach myself how to continue work on your branch. Is it as simple as me making commits to your fork? The BooleanParameterType was part of PR #24, along with the time parameter types so I think we'll pull those changes out of this PR. On the subject of the ByteOrderList element, the XTCE green book element description is a little unclear on it. I think in XTCE 1.1 there was a ByteOrderList element that literally spelled out the byte significant for every byte in a data encoding. However, it looks like in 1.2 this may have been superseded by the mostSignificantByteFirst and leastSignificantByteFirst attributes that you are using. The explicit element-form of ByteOrderList appears to be still allowed in XTCE 1.2 but seems like an extremely niche use-case now that we have the attribute forms instead. In short, I think your implementation is sufficient. See https://issues.omg.org/issues/XTCE12-400 for a discussion of the byte ordering changes between XTCE 1.1 and 1.2. |
It's not a huge deal to me. It might be nice, but only if it's not too inconvenient for you and your workflow. That said, GitHub does make it pretty easy to continue working on this branch—just
Ah, I had missed that, thanks. I removed the duplicate definition here.
Thanks for the link. That provides some good insight. Cheers! |
Awesome! Thanks for the tip on checking out PR branches from forks. I've always struggled with that. The last piece here is unit test coverage for these new features. Do you want to tackle that? If not, I can start working on it, adding commits to this branch. |
I am pretty tight for time these days. I think it will definitely be ready sooner if you go ahead get started on the tests. |
Ok. I'll take over this PR branch and start working on tests. |
This PR ended up turning into a kind of rollup of several of the changes I've made in my fork to make the module usable. I am opening this as a draft for discussion purposes and as a sort of already-implemented feature(s) request. The major changes here are:
Addition of aBooleanParameterType
classTODO: implement ByteOrderList to inform endianness.
I'm not sure what "ByteOrderList" is a reference to (a name idea for a new/future class?), but the way I've done it here is pretty clean (IMO) and seems to be fully transparent and backwards compatible in my limited testing. Happy to discuss if you had something else in mind for this though.StringDataEncoding
s, plus integration with the aforementioned endianness parsing for the cases where byte order is described by the string encodingChecklist
lxml
dependency, but I will leave that for another PR