hal: Add halfileupdate to convert HAL configuration files - #4499
hal: Add halfileupdate to convert HAL configuration files#4499grandixximo wants to merge 1 commit into
Conversation
d8e1890 to
3d52570
Compare
That is good. Both conv_s32_s64, conv_s64_s32, conv_u32_u64 and conv_u64_u32 are superfluous now.
I'm still working on them. The abs_s32 and abs_s64 will collapse into abs_sint. Anything else I find will also need to be added. Also working on changing the components to replace si32/ui32 with sint/uint where ever possible. |
| tcl = path.endswith('.tcl') | ||
| if tcl and re.search(r'(?m)^\s*(proc|for|foreach|while|if)\b', text): | ||
| self.rep.at(path) | ||
| self.rep.note("haltcl file that builds HAL names in code; the " | ||
| "plain commands are converted, a name a proc or a " | ||
| "loop builds is not, and has to be converted by " | ||
| "hand") |
There was a problem hiding this comment.
This makes me wonder... Why should we continue to support Tcl based hal files? Is there a (very) pressing case for having them?
There was a problem hiding this comment.
TCL other than innumerable parentheses, allows you to have multi model machines swappable configs with few INI changes per model, meaning a manufacturer could manage a single TCL, and have model only INI files, I am actually work in progress on moving my configs to TCL, but I'm too comfortable in Hal, and I find TCL less readable, Hal is easier to debug and hack new features on, so I'm conflicted about it, unfortunately I don't see other scripting languages coming to the rescue here...
Why wouldn't you want a way to script your Hal? I think is a valuable construct, just a painful language.
The biggest gripe is not being able to search a specific pin directly in the TCL file because it has been created from a variable, which is not listed anywhere, is that reason enough to drop the "scripted Hal" construct all together?
There was a problem hiding this comment.
Sure, I get it why it is there ;-)
That said, not being able to grep your way to a pin is (very) annoying.
Anyway, there has been a continual push to move from Tcl to Python. That is my point... The Tcl support libraries are withering and Python would be the better choice in that light. Also seen in the light of our own updating of the python modules.
FWIW, I see a version 3 where TP is non-RT and all Tcl has been retired (rtai killed too; python modules in a namespace,...).
There was a problem hiding this comment.
I think that some of the shared files in the sample configs are Tcl HAL.
To be honest I didn't support that change, I think that all the sample configs should be flat files, to be easy to modify and for new users to comprehend. Yes that leads to a lot of redundancy, but so what?
There was a problem hiding this comment.
There already is a huge copy/paste redundancy in the sample configs. It is no problem as long as they are maintained. But that is the hard problem.
There was a problem hiding this comment.
Having default TCL configs in tree is IMO quite user unfriendly, TCL configs IMO should be something a more advanced user reaches for, rather than being forced in the introductory configs, although that is how I learned they exist in the first place, but then again if we are going all Python... This feels like a larger topic for the agenda...
|
Do you also update the |
|
Why is this needed in addition to the existing update_ini script? |
Factoring this out is a good thing because you may not hit all .hal files in the ini upgrade. There can be files located many places and a user may need to do some things more manually. There is no problem of calling this from the ini update script to automate the 1.1->1.2 version upgrade. But when that fails, for whatever reason, you still want to offer some kind of automation for the hal files. |
Removing the 32-bit HAL types renames components, pins and parameters whose name spells a type that is gone (conv_s32_float -> conv_sint_real, mux-gen.00.in-s32-00 -> mux-gen.00.in-sint-00), so a configuration using those names fails to start. halfileupdate rewrites them. A name is rewritten only when it resolves to an instance of a component that a loadrt in the files being read created, which covers count= and names= instances and components whose HAL prefix is not the module name without guessing; a name that does not resolve is left alone and reported. Given an INI file, the HAL files it names are converted in the order LinuxCNC runs them, which is what makes a configuration convertible: its loadrt and its pin uses are regularly in different files. Keys of a user interface's own and keys outside [HAL] count, an INI value continued with a backslash is one command, and in haltcl the Tcl form 'hal setp name value' is understood as well. Signal names, aliases, comments and names built with a substitution are never rewritten, though the type word on a newsig line is converted, and a linkpp line is reported since halcmd no longer has the command. By default a diff is printed and nothing is written; --in-place rewrites atomically and keeps a .bak. The renames are tables in the tool itself, following the 64-bit only work: the eleven conv_* converters, the mux_generic and demux_generic pins, demux sel-u32 and the reset pins. They are regenerated if that set changes. No part of HAL knows the old names, and both the tool and its tables are a migration aid for one release transition, not a permanent part of HAL. The test therefore checks that the old names are gone and that what replaces them is consistent everywhere, not how any one name is spelled.
|
Both done.
Tables get regenerated when |
3d52570 to
30c1d5a
Compare
|
Draft till the renaming is settled... |
3 participants
@BsAtHome This is the .hal side of what we discussed in #4256, as a separate binary:
halfileupdate.It should be safe because it does not match strings. It reads the
loadrtlines, works out which instances exist, and converts only names that resolve to one of those instances.count=,names=(the instance name is the user's, only theloadrtline changes) and components whose HAL prefix is not the module name,mux-genand friends, all fall out of that instead of being special cases. Anything that does not resolve is left alone and reported.Given an INI file it walks the
[HAL]files in the order LinuxCNC runs them and followssource, which is the part that matters in practice: in stock configs theloadrtand the pins that use it are regularly in different files,sim_vmc.halloadsconv_float_s32 count=3andtoolchange_gray.halusesconv-float-s32.2.in. It also picks up HAL files behind a GUI's own key such asCUSTOM_HALFILE, and rewritesHALCMDlines in the INI itself. On a single .hal file it converts what that file loads and says to run the INI for the rest.Signals, aliases and comments are never rewritten, though a comment still naming something that changed is reported. Names built with a substitution or in a haltcl loop are reported rather than guessed at. Library files are skipped. Diff by default,
-ikeeps a .bak.Per your last comment: no table in
hal_lib, no hooks on the halcmd error paths, no CI mode. The renames are plain tables in the tool, taken from yourwip_hal-types-and-isolationbranch: the elevenconv_*converters, themux_genericanddemux_genericpins,demuxsel-u32and theresetpins. The four converters whose two sides collapse to one type,conv_s32_s64and friends, are gone with no replacement there, so their uses are reported instead of rewritten. I leftabs_s32,scaled_s32_sumsand the tristate pair alone since you have not renamed them; if that changes the tables get regenerated.I have not written a removal release into it, since 2.12 or 3.0 is not settled; it needs remembering at some point.
Testing: all 326 stock config INI files dry-run clean, 65 lines changed, no false positives. The test asserts that the old names are gone and that the replacements are consistent, not how they are spelled, so regenerating the tables will not invalidate it.