You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
blark will continue to support the current input formats - just without pytmc as a required dependency.
I'm hoping to make file loading more easily customizable, with the option to load arbitrary file formats so long as you can provide an adapter (or a JSON-ified code block).
This is more of a TODO list at the moment - more details on the way soon.
Most of the following are at least somewhat done in the WIP branch wip_standalone_solution_parser:
Load .sln from TwinCAT
Iterate through tsproject files and PLCs
Find source code files
Make a blark-specific container for holding PLC source code of any format
Make an adapter to take the loaded solution source code into the blark-specific containers
Map source code file lines onto "blark lines" (lines which will be fed into the grammar)
Use source code file lines in linter output
Allow blark to write files back to TwinCAT formats without significantly changing the contents
Drop pytmc requirement; add lxml requirement
Remove all pytmc references
Clean it all up and document it
Make sure the test suite still runs
Update dependency store code to support this loader
Remove dependency on deprecated distutils version parsing
Tweak blark CLI blark parse to work better with the generalized source code containers
Rework blark CLI tool blark format entirely to either dump formatted code or rewrite in place
Consider the ability to convert any input type to any output type
Ensure all TwinCAT source code files support rewriting (property and others are still a TODO)
The text was updated successfully, but these errors were encountered:
@engineerjoe440, as part of this refactor, I'm going to be changing the command-line interface of blark parse pretty significantly. The blark.parse*() methods will also be getting reworked.
Will this get in the way of your usage? If it does, will it be an issue to adapt your use case?
I don't think this should be too much of an issue. I suspect that I'll still be able to rework my tooling to derive from the refactoring changes you make. As long as the fundamental parsing is still possible, interface changes or function renames should not be a real issue. 👍
I'm excited to see how this all comes together, too! The tooling I've been working on is largely a linter for CODESYS-based systems, consuming the ST material from XML files, so there's some data-munging and manipulation that I have to do to get it correctly formatted for blark as it stands (nothing terrible, mind you!), so I'm excited to see what you're working on, specifically related to this remark:
Use source code file lines in linter output
Thank you, again, @klauer! I'm very excited about all of this!
blark will continue to support the current input formats - just without pytmc as a required dependency.
I'm hoping to make file loading more easily customizable, with the option to load arbitrary file formats so long as you can provide an adapter (or a JSON-ified code block).
This is more of a TODO list at the moment - more details on the way soon.
Most of the following are at least somewhat done in the WIP branch
wip_standalone_solution_parser
:.sln
from TwinCATlxml
requirementblark parse
to work better with the generalized source code containersblark format
entirely to either dump formatted code or rewrite in placeThe text was updated successfully, but these errors were encountered: