Retiring halcmd

[machinekoder]

In my opinion it make sense to sooner or later replace halcmd, halrun and so on with the Python HAL APi. The purpose of this thread is to find and write down all missing features in the Python API to fully replace halcmd.

• halrun: could be replaced by the Python interpreter with with the machinekit modules pre-loaded
• script to convert HAL configurations to Python code
• a function similar to halcmd show
• easy access of INI/config parameters -> could work as transistion layer to a persistent distributed config system too

[mhaberler]

I'm all for it, with a twist (I discussed .hal file migration offline with @ArcEye on and off)

However, I would retain the .hal file syntax for a few reasons, and think we should write a proper scanner/parser for halcmd syntax based on PLY (it's trivial anyway).

• I think as an inspection and teaching tool halcmd (as a language, not as the C clunker we have now) has a very low entry bar
• this parser would be the obvious vehicle to also do .hal-> .py conversion (on a fully syntactic, not just regex level)

But those issues are fairly separated from what you suggest. One can do those separately, although having halfile conversion early aids adoption.

I fully agree on the INI transition. We might actually do something like a wrapper which mocks a future API so folks dont start digging the INI file directly.

I think the Cython bindings are almost there, and any stuff needed is easy to add

ps: the reason why I am suggesting PLY is: https://github.com/eliben/pycparser is the strongest candidate for a successor to comp/instcomp (this one actually understands C fully, meaning the transformation is not as limited as comp/instcomp). That would mean just one learning curve for the parser generator.

[ArcEye]

I think the new interface will have to live in parallel with halcmd. There is no need to do away with it.

There are a lot of legacy configs that use halcmd directly through user M codes etc in scripts.

I have several on my machines, setting parameter values like the gain, on a scale component to make it correct for the current spindle pulley for example.

I already have all the information routines from halcmd, adapted to Qt5 in my C++ libraries. If you want to write python versions without disecting halcmd, you are welcome to a copy of the relevant file.

[luminize]

I use halcmd to run scripts for setting pins when tweaking behavior (like ArcEye). I think it's good for what I use it for, keeping HAL syntax. I mirror ArcEye and would not remove it. IMO (or there might be things I don't see) it just works.

On 26 Apr 2015, at 11:17, ArcEye notifications@github.com wrote:

I think the new interface will have to live in parallel with halcmd. There is no need to do away with it.

There are a lot of legacy configs that use halcmd directly through user M codes etc in scripts.

I have several on my machines, setting parameter values like the gain, on a scale component to make it correct for the current spindle pulley for example.

I already have all the information routines from halcmd, adapted to Qt5 in my C++ libraries. If you want to write python versions without disecting halcmd, you are welcome to a copy of the relevant file.

— Reply to this email directly or view it on GitHub.

[RunningLight]

The only fly in the ointment I see if we keep both old and new ways of doing business is the inevitable divergence and subsequent maintenance challenge. I lean naturally toward removing halcmd. It was the first section of emc2 I dug into years ago and I know how convoluted/tricky it is. Not having a portfolio of heavily customized legacy "stuff" I want/have to keep using, though, I'll recuse myself from the decision.

Regards, Kent On Apr 26, 2015 5:32 AM, "Bas de Bruijn" notifications@github.com wrote:

I use halcmd to run scripts for setting pins when tweaking behavior (like ArcEye). I think it's good for what I use it for, keeping HAL syntax. I mirror ArcEye and would not remove it. IMO (or there might be things I don't see) it just works.

On 26 Apr 2015, at 11:17, ArcEye notifications@github.com wrote:

I think the new interface will have to live in parallel with halcmd. There is no need to do away with it.

There are a lot of legacy configs that use halcmd directly through user M codes etc in scripts.

I have several on my machines, setting parameter values like the gain, on a scale component to make it correct for the current spindle pulley for example.

I already have all the information routines from halcmd, adapted to Qt5 in my C++ libraries. If you want to write python versions without disecting halcmd, you are welcome to a copy of the relevant file.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/machinekit/machinekit/issues/590#issuecomment-96353431 .

[machinekoder]

I thought of both ways living side by side too. The way @mhaberler suggests seems fine to me. Creating a halcmd that is based on the new API could work as transistion wrapper and "old way" of doing stuff without the need of maintaining the old halcmd.

I found a slight inconsistency between halcmd and the Python API:

• newsig is now called new_sig: https://github.com/machinekit/machinekit/blob/master/src/hal/cython/machinekit/hal_signal.pyx#L180 I would suggest renaming it to keep the API consistent to halcmd

[machinekoder]

Create a PR for the naming issue: https://github.com/machinekit/machinekit/pull/605