issue-#153 Basic in/out console functionality

[Zinn]

Dear Ivan,
there is a big misunderstanding.

I know there are several subsystem Console in Russian. They are good, but they have a different aim, a different task and they are not usable for Josef's purpose.

There are two different things with the same name Console.
On one side a remote control program and on the other side a very small debug output program.
Maybe that is the reason of the misunderstanding.

Lets start again from the beginning:
- I report a problem with BlackBox.
- In low level BlackBox procedures you can't insert StdLog for control outputs.
- Josef shares a small procedure Console for this task.

Josef's Console program is not a subsystem. It is a very small module for debugging where the service of Log and StdLog can't be use. In my opinion this is a useful debug tool, which should be add unmodified.

You can publish you Console program as its own module outside BlackBox in the same way as a lot of other subsystems.
Inside BlackBox we have StdLog and we don't need another big Console Output via Hook program.

Please don't worry.
- Helmut

[Ivan Denisov]

I am strongly against putting anything platform-dependent in the System directory. Also this name is crossing with existed published module from Freenix version.

So I understand your aim and suggest better solution which is fit the aim of the center to run BlackBox on multiple platforms in future.

I use your initial idea, but my suggestion is not just to serve this debugging needs. But to make a big step forward in right direction in general.

With that tool you can use debugging where it is necessary, and many people will have ability to develop cross-platform console applications. Any of app utilizing Console today is possible to run in Linux OpenBSD and FreeBSD. That is a bit depressing for me, that you do not understand these great abilities and prefer some crutch temporary solution which can make BlackBox more platform-dependent.

No WinApi in the System folder!
WinApi place in Host and Win directories!

[Josef Templ]

I am strongly against putting anything platform-dependent in the System directory. Also this name is crossing with existed published module from Freenix version.

The Freenix version is not normative. If you put something in System,
you do this at your own risc. You should use a subsystem for your own modules.

So I understand your aim and suggest better solution which is fit the aim of the center to run BlackBox on multiple platforms in future.

I use your initial idea, but my suggestion is not just to serve this debugging needs. But to make a big step forward in right direction in general.

With that tool you can use debugging where it is necessary, and many people will have ability to develop cross-platform console applications. Any of app utilizing Console today is possible to run in Linux OpenBSD and FreeBSD. That is a bit depressing for me, that you do not understand these great abilities and prefer some crutch temporary solution which can make BlackBox more platform-dependent.

Ivan, what you effectively do is you are 'hijacking' my module and taking away important features.
Unfortunately you ignore all the details.

It is better if you describe your NEEDS, not your solution.
I have asked you several times to tell me what features you need for
the Console module that are not yet available in my Console module.
I am always open for suggestions to make the Console module more
general purpose.
Why do you refrain from answering this question?
Instead you point us to a YouTube video in Russian. This is not helpful.
Please describe your needs here, in english.

- Josef

[Ivan Denisov]

My job is to develop cross-platform console applications. I run BlackBox in multiple platforms for scientific issues.

Josef, please, make your module consist of two modules: abstract interface and the realization.
And do not put any WinApi dependencies in any folders except Win and Host.
Anyway, if your module have only debugging perpouse, it should not be included in System. It should be included to Dev subsystem.
So I suggest you to make module DevConsDebug, which will utilize suggested simple Console interface for line nubmering etc.
This DevConsDebug in that case will be platform independent and can be used also for debugging Kernel in Linux.

I am strongly against putting anything platform-dependent in the System directory. Also this name is crossing with existed published module from Freenix version.

The Freenix version is not normative. If you put something in System, you do this at your own risc. You should use a subsystem for your own modules.

Console is not "my own module". It is the part of the project of cross-platform version of BlackBox we are developing with Alexander Shiryaev and Igor Dehtyarenko. I hope that you will respect our activity if some of your project will cross with Linux/OpenBSD/FreeBSD world. Igor also made very nice Decoder with fixups: http://oberoncore.ru/bbcc/subs/dev/decoder I think, that you can improve your decoder in future.

Ivan, what you effectively do is you are 'hijacking' my module...

Josef, this module in Freenix published more than two years ago. Nobody is hijacking your module. That is calumny.
Maybe Alexander used some work of OpenBUGS and previous realizations.
Ivan Goryachev published his WinConsole 10 years ago, Evgenii Temirgaleev published his version of WinConsole 7 years ago.

... and taking away important features.

Some features like Int & Bool output done in ConsLog module, that sets hook for Log module. Did you watch this module when I posted it previous time?
https://gitlab.molpit.org/blackbox/free ... od/Log.odc

[Zinn]

- STOP -
We have a name clash. One word with to different meaning.
In German we say it is a "Teekessel" word, e.g. Bank.
First meaning: The house where you can get money.
Second meaning: A chair in the park where you can sit down.

Let us split this discussion into
1. Module Console for the low level debugging
2. Subsystem Console for the Linux port of BlackBox

About Console (low level debugging)
I don't accept the name DevConsDebug.
It should be called Console or WinConsole.

About Console (Linux port)
Why need the Linux port another I/O system called Console? We have StdLog.
Which interface need you for this task?

- Helmut

[Ivan Denisov]

Helmut, Console is the module name, not the subsystem name. Please, look at the diff page:
https://redmine.blackboxframework.org/p ... 09ddc6ad20

Console is the interface module in the System folder that provides basic read/write operation for the command line (terminal) routings.

Code: Select all

DEFINITION Console;

	PROCEDURE ReadLn (OUT text: ARRAY OF CHAR);
	PROCEDURE SetConsole (c: Console);
	PROCEDURE WriteChar (c: CHAR);
	PROCEDURE WriteLn;
	PROCEDURE WriteStr (IN text: ARRAY OF CHAR);

END Console.

This module is not for Linux. It is independent from OS. And have realization for Windows and for Linux/OpenBSD/FreeBSD. Realization is done with HostConsole module. That is like Fonts and HostFonts. Files and HostFiles etc.

[Josef Templ]

My job is to develop cross-platform console applications. I run BlackBox in multiple platforms for scientific issues.

I am sorry but I still cannot understand why an App based on a Console module consisting
of 2 modules is more portable than an App based on a Console
module consisting of a single module.
You can develop all your Console apps either way.
To me there is no technical reason for a split.
It only creates inconveniences and problems as you can see
by the IMPORT anomaly that I have shown.

Technical hint: If you can handle the differences in Kernel
you can also handle the differences in Console.
Technically, this is the same problem.
If you go to a different CPU architecture you would also
have the same problem with Math and SMath (and you would need
a recompile).

- Josef

[Ivan Denisov]

Josef, please give the honest answer. Do you understand why Fonts and HostFonts are split?

[Josef Templ]

Josef, please give the honest answer. Do you understand why Fonts and HostFonts are split?

Please don't answer with a question.
Give us your technical arguments.

- Josef

[Ivan Denisov]

Josef, please give the honest answer. Do you understand why Fonts and HostFonts are split?

Please don't answer with a question.
Give us your technical arguments.

We should split abstract interface and it's realization for preventing platform-specific code come to System. Why platform specific code is bad? Platform specific code in the System makes harder to run BlackBox in multiple platforms. The process of this splitting is called "hermetization of abstraction layer". If you put any platform dependent code in the abstraction layer this is called "leaking of the abstraction layer".

These modules Math and SMath, which Josef like to use as an example, are not platform-dependent. They are architecture-dependent. So I do not need to recompile them if I switch from Windows to Linux and vice-versa in same x86 and x86-64 architectures. So I can run my software in Linux/OpenBSD/FreeBSD/Windows without recompiling it.

That is why Fonts is separated from HostFonts and Files are separated from HostFiles. That is why it is wiser to make basic console functions with good architecture and then modify Josef's module using this basic functionality. Debugging module will become cross platform. And the BlackBox will have some good basic interface for console read/write functions for further issues.