I’m creating a Java application that uses Pulse to simulate a patient. I’ve been working without major issues until I got to get some properties from the Anesthesia Machine that are not numbers. Up to this point, I didn’t have any problem querying the anesthesia machine, an my guess is that it was because I was always querying for numeric values. For example, the following Data Requests work fine:
But, if I want to query for the Connection of the Anesthesia Machine, I would have expected the following Data Request to do the trick:
But the Data Request above gives me the following error message:
[FATAL] : [0.02(s)] Unknown Data Request : Connection
And same thing happens with the OxygenSource property too. I think I can generalize this behavior to properties that are enums.
Am I doing something wrong? Or is this a known limitation in Pulse?
The Connection is actually an enum, so it is currently unsupported as a DataRequest
Data Requests are essentially tied to double values from the engine.
It is possible to add support to have DataRequests associated with enums return an integer value in the double. Off the top of my head, I think it would not be too complicated, but there would probably need to be some additions to the Data Request piping to get this to work.
That being said, enums have a initial value in the engine (Off in the case of the connection) and the only way it can change is by an action you provide it. So in sense, you are asking the engine for a value that you set. Unless you did not, in which its going to be at its default value (Off for a Connection).
The same would apply to substances applied to the right or left chamber. It’s empty until you provide an action putting a substance in it. But there is not currently a way piggyback a thunk of the substance name (that you provided in a previous action) in the chamber over the JNI.
Thank you for your prompt response.
In my case, we have a Pulse Engine running and multiple applications connected to it. So it could be the case that one application changes the connection without the others knowing. My first approach to solve this was to expose that value from Pulse itself, but if that’s not possible, I’ll have to deal with it at the application level (i.e. keep track of all the actions applied to a scenario) and not at the Pulse Engine level.
Thank you again for your time,
Everything in the engine is exposed at the C++ level.
Its really a question of how to thunk it over the JNI.
I have been thinking about supporting a mode in the engine so it keeps track of all incoming messages.
I believe I started it, but I don’t remember where I ended up…so it may be an option to just finish that support…But that would probably be pretty simple to do on your Pulse node as well, before you pass an action along to Pulse.
Another option is to support thunking a whole system over the JNI rather than individual Data Requests. Everything in Pulse is backed by a Protobuf definition, so this would be pretty easy and I think very helpful in general. And you would not have to sort though actions to get the current state.
Yes, I think I can handle this at the application level for now. Having a way to expose the entire state of a system at once would be nice though.
Do you have any thoughts/concerns with Pulse being developed using Java 8?
I have run a build using further Java versions (11/12 I believe) And things built fine, but is there anything for us to keep in mind for moving to a more modern version?
I don’t know about Pulse itself, but the application where I’m including Pulse is using OpenJDK 13 and I haven’t found any issue so far.
I wanted to comment on more modern versions of Java. Building in Java 8 and running in later versions should mostly be ok. Here’s a summary of issues I’ve run into:
- Java strings that contain null characters are no longer supported.
- Split packages (where two different projects/modules contain the same package) are no longer allowed.
- Internal packages/classes (e.g., anything with
native in the name) are no longer accessible. This is unlikely to affect your code, but could affect some of your dependencies. (I had to update UI-related dependencies, although I think all of your UI stuff is in C++).
These are really unusual things to do, but each one affected a small amount of code for a large project that we wanted to use as a dependency in a Java 11 project. The original project is still Java 8, but these updates were needed to work with Java 11 projects (which is different than just running a Java 8 project in a Java 11 JDK/JRE).
The last thing I’ll mention is that, as a java 8 project, you’re not defining
module-info.java in your projects. This is ok – Java will automatically generate a module for older code – but some IDEs (maybe Java itself?) generate warnings about this, since the module name is not “stable”. This hasn’t been an issue for me so far, though, and the warning can be silenced.