On Fri, Oct 28, 2016, at 10:29 AM, Jim Craig wrote: > I did some more debugging of Crapahalic last night. So some brief > overview of how it works so far. It uses halcmd show to generate output > that is then parsed through to determine the loaded hal components, the > pins for each component and the signals that are all loaded in the > current configuration. I like this general methodology as it keeps from > having to look up component definitions in the man pages to determine > pins. It also solves the issues that have been brought up about > components generating pins at run time. > > The issue that I am having right now is that the parsing logic is > barfing on the inconsistency of the "Loaded HAL Components:" section of > the halcmd show output. Some lines have a PID value and others don't. > Currently it is splitting each line into 5 variables but sometimes there > are only 4 items in the split due to the missing PID value. This causes > it to barf at the split command. > > Would it make more sense to modify halcmd show, actually the subfunction > print_comp_info to add a placeholder for missing PID values such as a -1 > or a "-" or some other value? Would modifying this output break other > applications? Would it make sense to make additional functions for > halcmd that would be specific for the Crapahalic? Or should I just > update the parsing code to handle each condition separately?
Is crapahalic already using halcmd's "script mode"? Refer to the man page http://linuxcnc.org/docs/html/man/man1/halcmd.1.html If you add -s to the halcmd command line it will produce output that is easier to parse. Changing the script-mode output format should be done with caution (to avoid breaking existing scripts that use it), but at the same time, script-mode output should be designed to be as consistent and parser-friendly as possible. If there are inconsistencies in script-mode output that could be considered a bug. > What is your opinion of this general method of working with a running > HAL configuration? The only drawback that I see at the moment is that it > would make editing a broken configuration with the tool impossible as it > would not load properly and therefore you could not view or edit it with > the tool. I have mixed feelings on the topic. As an electrical engineer who is used to both drawing and reading schematics, I am 100% convinced that NO auto- generated drawing will ever be as readable as a human-created drawing. The layout of components on a good schematic naturally conveys the design intent of the human who drew it as far as signal flows and such. Autogenerated schematics tend to resemble bowls of meaningless spaghetti. So my interest in such tools has always been to "compile" a schematic drawn by a human (me) into a hal file. Going the other way is less interesting. But as has been pointed out, the challenge of components that change their pin-list based on loadrt parameters makes it tough. -- John Kasunich jmkasun...@fastmail.fm ------------------------------------------------------------------------------ The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
