zeromq / ingescape Goto Github PK

Some methods are not implemented in C#:

• igs_channel_shout_str
• igs_channel_shout_data
• igs_channel_whisper_str
• igs_channel_whisper_data
• igs_peer_add_header
• igs_peer_remove_header

There is an issue with sending DATA type on an output using the python binding.
DATA sent is not read properly using Circle.
Receiving DATA on an input works fine.

The expected behavior is that "the class name should follow the agent name by default". The first igs_agent_set_name sets the class with the same value, the subsequent igs_agent_set_name do not update the class anymore.

Here is a main.c file generated from Circle with assertions showing the bug.

Hi are there plans to add Rust bindings to Ingescape?

I am wanting to use it but I am not sure if Rust support is coming or not and I will need it to work in Rust (or wrap nicely if it does that and anyone has experience doing that with it).

Thanks!!!

The latest PR #39 updated the Node JS binding version number from 3.0.1 to 3.0.2. However, the library current version is 3.2.0.

Either the Node JS binding is out of date and needs to be updated with the latest library features, or the Node JS binding version had not been updated in a while and should be updated to match the library version (at leat for the MAJOR and MINOR version numbers) .

Recent additions about real time APIs need to be implemented in the bindings :

• C#
• Python
• NodeJS

in function "model_write_iop" there is a igsagent_debug call, prepare log_iop_value and free later, but if log level is not debug, the memory still alloc and log_iop_value and prepared for useless.
Will it show down the receive processing ?

As related in #49 : Ingescape uses atof to convert IOP values from string to double and snprintf to convert IOP values from double to string and is locale sensitive.

The fact of having been confronted with Windows local sensitive raise a question : Should a double IOP always be converted with a point as decimal separator in a string ?

Some methods are not implemented in Python:

• igs_service_args_clone
• igs_command_line
• igs_log_no_warning_if_undefined_service

Hello,

I'm trying to use Ingescape with a multi agent program.

I'm working on C++ so I start to create a C++ binding to IGS agent, but I think that it's not a problem.
Conceptually the software architecture it's really simple:

1. Initiallise all my IGS agents
2. Launch IGS execution engine for my platform/program
3. Launch all my agents's processing

I made a small example to show the "problem": https://gist.github.com/Fafou/cd1f87140588b6ed5cd6a8d6d51a3f48
(I build this example with: g++ -std=c++17 -o testAgent testAgents.cpp -lingescape -lczmq -lpthread)

Today it didn't work because I didn't "manage" the internal IGS agent in addition to my agents.
Without setting a name to the internal agent, IGS do not start.
(a small comment in this example, after "igs_start_with_device", explains the cause of the problem)

For me, but I could be wrong, IGS execution engine do not need to create a default agent if user use it's own agents.

If user use default functions like: igs_input_create, in that case, yes he didn't want to manage it's own agent, so IGS can create agent for him, it's the "easy way" to use IGS. But if user want to manage its own agents by using igsagent_input_create, in that case we just need a valid IGS context, without default agent.

do you agree with my analysis? or am I the one who is using this library incorrectly ?

Following issue #40, the Python binding version is currently 3.0.4 while the current library version is 3.2.0.

Either the python binding needs to be updated to include the latest library features, or it's version should be updated to match the library version (at least the MAJOR and MINOR version numbers).