issue-#158 LowLevel debugging
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
issue-#158 LowLevel debugging
Some low-level debugging tool is required.
There is the prototype by Josef Templ:
https://wiki.blackboxframework.org/inde ... le=Console
With some forward version by LuoWy:
viewtopic.php?f=41&t=602&start=30#p5832
From my point of view it should be located in Win subsystem because it uses WinApi. Appropriate name is WinConsLog.
There is the prototype by Josef Templ:
https://wiki.blackboxframework.org/inde ... le=Console
With some forward version by LuoWy:
viewtopic.php?f=41&t=602&start=30#p5832
From my point of view it should be located in Win subsystem because it uses WinApi. Appropriate name is WinConsLog.
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: issue-#158 LowLevel debugging
I have spent some time now figuring out a useful design for both
issue-#153 and this issue-#158.
Given the requirement of issue-#153 (Console I/O for application programmer)
it is clear that a high level Console module is required that is different from my
Console module introduced for (Kernel) logging.
On the other side, there is common low-level code between both issues and
in this case a separation of the low-level console interface and the high level console
API is quite helpful.
The logging feature is not intended to be a stable, official part of the API, so
it may well be moved into Host, where also the low-level interface for
issue-#153 has been proposed to be implemented.
Host modules have a private interface and are subject to change.
This fits with the 'private' nature of the console logging features.
My proposal merges the low-level part of issue-#153 with the logging feature
into one common module HostConsole. It is still very small, below 2KB code size.
If this module is ported to another platform, it is left to the implementation
if it chooses to support the logging feature or not or it may change the
logging features to whatever the implementation needs.
This is part of the private HostConsole interface.
The only part that is required to be ported is the interface to console I/O as
required for issue-#153.
The main change over the proposal in issue-#153 is that my proposal
does not implement a Console hook but requires that Console imports HostConsole directly.
I have considered also the alternative of decoupling the logging feature from HostConsole
but it either leads to undesired redundancy or undesired dependency.
I also didn't find a good name and a good place for it.
The merged approach is the best compromise I could find so far.
The diffs are here: https://redmine.blackboxframework.org/p ... 0d2224c0fc.
- Josef
issue-#153 and this issue-#158.
Given the requirement of issue-#153 (Console I/O for application programmer)
it is clear that a high level Console module is required that is different from my
Console module introduced for (Kernel) logging.
On the other side, there is common low-level code between both issues and
in this case a separation of the low-level console interface and the high level console
API is quite helpful.
The logging feature is not intended to be a stable, official part of the API, so
it may well be moved into Host, where also the low-level interface for
issue-#153 has been proposed to be implemented.
Host modules have a private interface and are subject to change.
This fits with the 'private' nature of the console logging features.
My proposal merges the low-level part of issue-#153 with the logging feature
into one common module HostConsole. It is still very small, below 2KB code size.
If this module is ported to another platform, it is left to the implementation
if it chooses to support the logging feature or not or it may change the
logging features to whatever the implementation needs.
This is part of the private HostConsole interface.
The only part that is required to be ported is the interface to console I/O as
required for issue-#153.
The main change over the proposal in issue-#153 is that my proposal
does not implement a Console hook but requires that Console imports HostConsole directly.
I have considered also the alternative of decoupling the logging feature from HostConsole
but it either leads to undesired redundancy or undesired dependency.
I also didn't find a good name and a good place for it.
The merged approach is the best compromise I could find so far.
The diffs are here: https://redmine.blackboxframework.org/p ... 0d2224c0fc.
- Josef
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: issue-#158 LowLevel debugging
The name HostConsole already used by another project. If you want Center Windows version be incompatible with Linux/OpenBSD/FreeBSD version, you are welcome. I do not care anymore.
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: issue-#158 LowLevel debugging
I have updated this issue branch with a new Build-Tool after merging issue-#156.
This avoids a merge conflict.
It should be noted that the Console module proposed in issue-#153 fits nicely with this
version of HostConsole. The Console module will even be binary compatible with existing Console modules
in the Linux/OpenBSD/FreeBSD versions. This means that user programs on those platforms will not
need to be recompiled.
From my point of view this issue is ready for voting.
- Josef
This avoids a merge conflict.
It should be noted that the Console module proposed in issue-#153 fits nicely with this
version of HostConsole. The Console module will even be binary compatible with existing Console modules
in the Linux/OpenBSD/FreeBSD versions. This means that user programs on those platforms will not
need to be recompiled.
From my point of view this issue is ready for voting.
- Josef
Re: issue-#158 LowLevel debugging
I am a little confused about the relationship between issues 153 & 158.Josef Templ wrote:From my point of view this issue is ready for voting.
1 - Do we need / want both consoles?
2 - How close to finished is issue 153 - is it nearly ready for a vote?
3 - Should we respond to Ivan's information that the name HostConsole clashes with developments in the Linux world?
4 - Is it satisfactory for the Docu to simply say "Private"? Would it not be better to document the new features while they are fresh in someones mind? Maybe they should be hidden in a fold, like the Kernel documentation, with a notice saying that they are only intended for development, not production use.
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: issue-#158 LowLevel debugging
issue-#153 is about a Console module for console application programming.
This has been proposed by Ivan because there is some console application
programming done in his environment. Such a requirement looks perfectly plausible to me
and therefore I have designed HostConsole such that it can also be used for issue-#153.
issue-#153 is not nearly ready for voting as it depends on the low-level console interface
shared with issue-#158 and it has a merge conflict via the Build-Tool.
But it is trivial to add it after issue-#158.
Since both Console and HostConsole are not doing any harm to BlackBox
(in my design they are not even loaded unless they are really used)
I would suggest to add both issues but to start with issue-#158.
Adding both also shows to Ivan that we do care about his requirements.
The difference is only in the details of the implementation.
Adding more docu do Host/Docu/Console in the 'Kernel style' can of course be done.
Currently there are some header comments in the source code of the logging features of HostConsole.
If there is a clear preference I can change it.
- Josef
This has been proposed by Ivan because there is some console application
programming done in his environment. Such a requirement looks perfectly plausible to me
and therefore I have designed HostConsole such that it can also be used for issue-#153.
issue-#153 is not nearly ready for voting as it depends on the low-level console interface
shared with issue-#158 and it has a merge conflict via the Build-Tool.
But it is trivial to add it after issue-#158.
Since both Console and HostConsole are not doing any harm to BlackBox
(in my design they are not even loaded unless they are really used)
I would suggest to add both issues but to start with issue-#158.
Adding both also shows to Ivan that we do care about his requirements.
The difference is only in the details of the implementation.
Adding more docu do Host/Docu/Console in the 'Kernel style' can of course be done.
Currently there are some header comments in the source code of the logging features of HostConsole.
If there is a clear preference I can change it.
- Josef
Re: issue-#158 LowLevel debugging
I would prefer that - although it can be a separate issue "Improving HostConsole documentation" or something.Josef Templ wrote:Adding more docu do Host/Docu/Console in the 'Kernel style' can of course be done.
Currently there are some header comments in the source code of the logging features of HostConsole.
If there is a clear preference I can change it.
In an ideal world there would be less modules that say "This module has a private interface, it is only used internally."; I think we should not add any more.
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: issue-#158 LowLevel debugging
we can also add resp. move the docu in issue-#153.
- Josef
- Josef
Re: issue-#158 LowLevel debugging
I have merged this feature to master (build 867).
It does not appear in the list of changes, which is unhelpful, I think.
The issue has no "Description" in Redmine, which may explain this?
It does not appear in the list of changes, which is unhelpful, I think.
The issue has no "Description" in Redmine, which may explain this?
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: issue-#158 LowLevel debugging
There was no target version specified in the issue.
I have set it to 1.7.1.
In addition, I have added a description.
- Josef
I have set it to 1.7.1.
In addition, I have added a description.
- Josef