HAL Python module Examples Fail to Work

[jethornton]

http://linuxcnc.org/docs/stable/html/config/python-hal-interface.html

None of the examples work that start with h.

Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import hal
>>> h = hal.component("passthrough")
>>> h.newpin("in", hal.HAL_FLOAT, hal.HAL_IN)
<hal.Pin object at 0x7f64d4847c10>
>>> h.newpin("out", hal.HAL_FLOAT, hal.HAL_OUT)
<hal.Pin object at 0x7f64d4847c50>
>>> h.ready()
>>> h.in.pin_has_writer()
  File "<stdin>", line 1
    h.in.pin_has_writer()
      ^^
SyntaxError: invalid syntax
>>> h.in.get_name()
  File "<stdin>", line 1
    h.in.get_name()
      ^^
SyntaxError: invalid syntax
>>> hal.h.in.pin_has_writer()
  File "<stdin>", line 1
    hal.h.in.pin_has_writer()
          ^^
SyntaxError: invalid syntax
>>> 

[satiowadahc]

I think I've narrowed it down to: https://github.com/LinuxCNC/linuxcnc/blob/31d3b061d8e00ba7f79b86b40d68e7321a2eeeb0/src/hal/halmodule.cc#L844

It seems its a struct up until this point, after this function it becomes a standard python type.

[satiowadahc]

>>> import hal
>>> h = hal.c
hal.component(           hal.component_exists(    hal.component_is_ready(  hal.connect(             hal.ctypes               
>>> h = hal.component("asdf")
>>> pin = h.newpin("out", hal.HAL_U32, hal.HAL_OUT)
>>> pin.get_dir()
32
>>> pin.get_dir() == hal.HAL_OUT
True
>>> pin.get_dir() == hal.HAL_IN
False
>>> type(h.out)
<class 'int'>
>>> type(pin)
<class 'hal.Pin'>
>>> 

So it seems its not adding the struct but the type of hal component to the main class.

[satiowadahc]

So there is two documentations for this: http://linuxcnc.org/docs/stable/html/config/python-hal-interface.html http://linuxcnc.org/docs/html/hal/halmodule.html

Does it make sense to have both? The first is for import hal.py the second is for _hal.py

[jethornton]

They appear to be the same thing to me

john@cave:~$ python3
Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import _hal
>>> dir(_hal)
['HAL_BIT', 'HAL_FLOAT', 'HAL_IN', 'HAL_IO', 'HAL_OUT', 'HAL_RO', 'HAL_RW', 'HAL_S32', 'HAL_U32', 'MSG_ALL', 'MSG_DBG', 'MSG_ERR', 'MSG_INFO', 'MSG_NONE', 'MSG_WARN', '__doc__', '__file__', '__loader__', '__name__', '__package__', '__spec__', 'component', 'component_exists', 'component_is_ready', 'connect', 'disconnect', 'error', 'get_info_params', 'get_info_pins', 'get_info_signals', 'get_msg_level', 'get_value', 'is_kernelspace', 'is_rt', 'is_sim', 'is_userspace', 'item', 'kernel_version', 'new_sig', 'pin_has_writer', 'sampler_base', 'set_msg_level', 'set_p', 'shm', 'stream', 'streamer_base']
>>> import hal
>>> dir(hal)
['HAL_BIT', 'HAL_FLOAT', 'HAL_IN', 'HAL_IO', 'HAL_OUT', 'HAL_RO', 'HAL_RW', 'HAL_S32', 'HAL_U32', 'MSG_ALL', 'MSG_DBG', 'MSG_ERR', 'MSG_INFO', 'MSG_NONE', 'MSG_WARN', 'Param', 'Pin', '_ItemWrap', '__builtins__', '__cached__', '__doc__', '__file__', '__loader__', '__name__', '__package__', '__spec__', '_hal', 'component', 'component_exists', 'component_is_ready', 'connect', 'disconnect', 'error', 'get_info_params', 'get_info_pins', 'get_info_signals', 'get_msg_level', 'get_value', 'is_kernelspace', 'is_rt', 'is_sim', 'is_userspace', 'item', 'kernel_version', 'new_sig', 'pin_has_writer', 'sampler_base', 'set_msg_level', 'set_p', 'shm', 'stream', 'streamer_base']
>>> 

Nothing every makes any sense to have it in two places. I worked for years on the docs to eliminate that...

[satiowadahc]

One does inherit from the other. But there should at least be a link

[satiowadahc]

Could look at moving functions from hal.py into the boost module. Then it's a single implementation as well?

[andypugh]

Does it make sense to have both? The first is for import hal.py the second is for _hal.py

I think that they are different things. One describes the actual hal module (what you get when you "import hal") the other describes how to write non-realtime components in Python, which tends to use the halmodule library.

[rene-dev]

I have a branch which ports halmodule to pybind11, which eliminates all of this issues, and removes 95% of the code.

[rene-dev]

https://github.com/LinuxCNC/linuxcnc/compare/master...rene-dev:linuxcnc:pybind11

[andypugh]

Are ou suggesting that someone should merge this, or is it presented just for info?

[rene-dev]

I would love to continue working on pybind11, but anything prior to bookworm doesnt have packages for it.

[andypugh]

We have the ability to do our own backports, if that would help.

[havardAasen]

I would love to continue working on pybind11, but anything prior to bookworm doesnt have packages for it.

Which packages is this? I can see that pybind11 goes back to Buster , but the version might be to old?

If I'm reading correctly, we will now how two different ways of creating Python bindings, Boost and pybind11?

Still, a really nice rewrite.