SicroAtGit
commented
5 years ago manage STOUT and STDERR output
A few days ago I extended the logger module with the DeviceType #DeviceType_StandardProgramOutput and reduced code redundancies with macros.
I uploaded the new code now: 8e2f3238ddff1df04f34e1f5674888c0b7d309c5
tajmone
Ciao @SicroAtGit,
Since the beginning of the "modularizaion process", I've spent more time carrying out local tests and searching issues than actually publishing code.
The reasons for this are due to some complications that I can't seem to find a solution for when it come to create modules that would work with both CLI (or PB IDE run apps) and GUI tools, for GUI tools might need more complicate ways to handle messages logging and errors.
I propose that I go ahead and work on implementing a CLI or IDE-Executable version of the tools first, for these are easier to implement and have already done most of the required testing. They are simpler to work on because ultimately the logger only needs to be setup once at startup and told were to output messages, errors and debug info — whereas a GUI tool might have different gadgets to handle these, and would require many subsettings.
I believe that once we have a set of working CLI tools it would be then easier to look into how to create a GUI CPanel for the project too (which is indeed needed). Chances are that for GUI tools we'll need separate dedicated modules, which might reuse some code from the CLI modules but also add some different procedures to handle Gadgets, etc.
If I keep pushing on creating straight away modules that would work on any scenerario, the risk is that it might take too long, and it's better to have only some CLI tools that work, tomorrow, than to have more tools but in the far future.
Also, if I focus on CLI tools it's easier to implement the basic logger and errors management modules, and then to insert the cache system into them (I've already tested the cache system, it's going to be much easier than I thought, and most code is ready in local tests I've carried out).
Furthermore, right now there are still many aspects to work out about sanitation checks for resources: currently I only have your old tools as references, but the new system is now a bit different and we should first get straight how the Resources module should determine if a resource is ready for inclusion or if it needs fixing (missing keys, malformed values, etc.).
Once we get this right, we can then move on to look into GUI tools. In these days I've taken some time to look into design patterns to handle modularization of functions that should be used by different tools, and there are different ways to go about them; but right now it might still be better to leave some choices open, and to make some decisions later on, based on real-case needs that emerge during tests and actual usage.
In the immediate future I'm going to focus on the following:
Once these tasks are done, we'll finally have at least one working tool which is capable of checking the intergrity of the CodeArchiv and build all HTML pages (if integrity check passed). It might not be much of an interactive tool, but it would be a good starting point.