-
Notifications
You must be signed in to change notification settings - Fork 39
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
New features #3
Comments
This is what I have in my mind but it is open for discussion. The goal of Simple dialoguesDialogues can loaded from a text file (I really like this, I think is one of Pint greatest strengths). We need a syntax which is simple but powerful. (1) Query messages. We have a syntax now that I think is quite clear
(2) Messages without answer.I think we can modify (1) (3) Unknown message.We could provide a typical message when a message is not understood. (4) PropertiesAn easy way to set and get properties, in which values provided by the user are parsed and then stored in an internal dictionary and then
(5) Resourcesan easy way to decouple resource name from dialogue (this is NOT the way it is working now) It would be useful to be able to load the dialogue for a specific resource. Something like:
And also including another file
(6) Configurable end of linesMany instruments have the same dialogues, but with different end of lines depending on the interface used (ethernet vs. serial) Maybe we could provide a magic string We need to discuss:
# Python code example
simulator.load_into('ASRL1::INSTR', my_instrument.txt) Complex dialoguesThis would allow users to build more complex interactions with the simulators, maybe linking to simulated experiments. I suggest we visit this in a second step, but my idea is to provide some kind of base class from which you can derive a state machine. See for example the Simulator in Lantz |
I think this is quite reasonable.
We do need some kind of error reporting which could be quite simple for dialogs (raise ValueError and indicate expected message and received message). I love the idea of defining instrument message properties and separating this from the resource as this would permit to fully simulate an instrument in Lantz (or other libraries). As far as parsing is concerned I am far from being an expert so I will follow you (the @ makes things quite clear and probably easy to parse). One tricky case I foresee is how to declare invalid values in property setting when the syntax is correct but the value is outside of range, and if the range actually depends on another property. I handled that kind of things in my new library Eapii (still WIP) (https://github.com/MatthieuDartiailh/eapii) so I might port some ideas. One thing which should also propose is a default value for properties, which could be overridden in resources. Let me know what you think and where I can start contributing. |
I we can implement simple validation of properties with a syntax like:
where thing after the colon is an expression that returns More complex things show be done by subclassing a SimulatorBase class (a second step). What is already implemented is a way to store dialogues, receive messages and reply (can be one or multiple byte at a time). To do this, messages are stored as list of elements. I use this instead of a bytearray to allow inserting other things like out of band messages. There is also a way to load text files with a syntax for (1), but with a syntax that binds instrument definition to resource_name. There is also another syntax implemented which is a line starting with A few gotchas (which I think they are fine for now):
The file where to contribute is I think we could start by implementing a test suite of what we want to achieve. I created a skeleton to put the tests. We should start by implementing (5), then (2) and (3); and finally move to (4) and (6). Additionally, I think it would be good to implemented The parser is quite simple, nothing fancy ( |
I opening issues for the individual parts to simplify tracking the implementation changes. Advancing with this will help us to get rid of lantz simulators. |
Sounds good ! |
Implemented using YAML, |
You suggested discussing features and implementation. Here seems to be a good place to start.
The text was updated successfully, but these errors were encountered: