HAL Python module Examples Fail to Work about linuxcnc HOT 13 OPEN

I think I've narrowed it down to:

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

from linuxcnc.

>>> 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.

from linuxcnc.

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

from linuxcnc.

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...

from linuxcnc.

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

from linuxcnc.

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

from linuxcnc.

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.

from linuxcnc.

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

from linuxcnc.

master...rene-dev:linuxcnc:pybind11

from linuxcnc.

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

from linuxcnc.

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

from linuxcnc.

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

from linuxcnc.