Is BlackBox version 1.8-a1.062 the basic of the linux version of BlackBox?
Do you need subsystem Cons for integration? Who is using it?
Why moved some modules from subsystem Strings to subsystem Unicode and subsystem Utf8?
What is the reason to cut the link to Kernel.Hook in several modules?
I know that is a lot of question. I would like to know the reason of this changes.
- Helmut
Is BlackBox 1.8 incompatible to BlackBox 1.7?
- Ivan Denisov
- Posts: 363
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Krasnoyarsk, Russia
Re: Is BlackBox 1.8 incompatible to BlackBox 1.7?
1.8 is the last Alpha development version. That means, that there are will be more changes in the interfaces. However the most changes were already done.Zinn wrote:Is BlackBox version 1.8-a1.062 the basic of the linux version of BlackBox?
Yes, this subsystem is used to produce tools for continuous integration (CI) system (console compiler). And also Cons subsystem allows to make console applications (very natural way of user interface for Linux).Zinn wrote:Do you need subsystem Cons for integration? Who is using it?
This is done to reduce dependency from Utf8 as external format. Basic literal type for Component Pascal is CHAR, and this is not Utf8. There is Unicode cross-platform module, which is not using any third-party libraries.Zinn wrote:Why moved some modules from subsystem Strings to subsystem Unicode and subsystem Utf8?
Also there was the aim to reduce dependencies from the Kernel there it is possible, because Kernel is not platform-independent. And there are also some applications without Kernel, which can utilize Strings, Dates etc. Kernel.Hook had sense for non-opensource software. With current state this is extra complexity. We suggest to try to reduce the complexity of the framework, where it is possible.
The same reason — to reduce the dependency from the Kernel. AlsoZinn wrote:What is the reason to cut the link to Kernel.Hook in several modules?
Very happy with your questions. Please, ask more.Zinn wrote:I know that is a lot of question. I would like to know the reason of this changes.
Re: Is BlackBox 1.8 incompatible to BlackBox 1.7?
OK, I understand there are several problems:
(1)
You would like to rollback the interface of the subsystem Strings to the version of BlackBox 1.6 and add the rest of the interface to the new subsystem called Unicode and Utf.
I agree with this separation. What about the procedure
PROCEDURE Lower (ch: CHAR): CHAR;
PROCEDURE ToLower (in: ARRAY OF CHAR; OUT out: ARRAY OF CHAR);
PROCEDURE ToUpper (in: ARRAY OF CHAR; OUT out: ARRAY OF CHAR);
PROCEDURE Upper (ch: CHAR): CHAR;
Should they left in Strings? Should they move or copy to subsystem Unicode?
Note: Original I had separated module Unicode but Josef moved it to Strings, because he would not like to change to link command.
(2)
Kernel.Hook - This cosmetic change is OK.
(3)
By the way there is another cosmetic change:
Kernel exported the identifier sometimes in string (16 bit CHAR) format and sometimes in utf8 (8 bit CHAR) format. Whenever it is possible the translation between string and utf8 should be done always inside the Kernel. That simplifies further changes of the program. Should I work out this changes?
- Helmut
(1)
You would like to rollback the interface of the subsystem Strings to the version of BlackBox 1.6 and add the rest of the interface to the new subsystem called Unicode and Utf.
I agree with this separation. What about the procedure
PROCEDURE Lower (ch: CHAR): CHAR;
PROCEDURE ToLower (in: ARRAY OF CHAR; OUT out: ARRAY OF CHAR);
PROCEDURE ToUpper (in: ARRAY OF CHAR; OUT out: ARRAY OF CHAR);
PROCEDURE Upper (ch: CHAR): CHAR;
Should they left in Strings? Should they move or copy to subsystem Unicode?
Note: Original I had separated module Unicode but Josef moved it to Strings, because he would not like to change to link command.
(2)
Kernel.Hook - This cosmetic change is OK.
(3)
By the way there is another cosmetic change:
Kernel exported the identifier sometimes in string (16 bit CHAR) format and sometimes in utf8 (8 bit CHAR) format. Whenever it is possible the translation between string and utf8 should be done always inside the Kernel. That simplifies further changes of the program. Should I work out this changes?
- Helmut
- Ivan Denisov
- Posts: 363
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Krasnoyarsk, Russia
Re: Is BlackBox 1.8 incompatible to BlackBox 1.7?
The problem with this procedures, that they worked well with ASCII, however it is expected, that they should work with all Unicode UCS2 range. OberonCore teams wants module Strings be lightweight and also, it would be problem if we change the functionality without changing the interface. After recompiling some user extensions, there can be unexpected behavior. So the better way is to move these procedures to another module — Unicode. This is giving a strong signal that now they will support full UCS2.Zinn wrote:(1)
You would like to rollback the interface of the subsystem Strings to the version of BlackBox 1.6 and add the rest of the interface to the new subsystem called Unicode and Utf.
I agree with this separation. What about the procedure
PROCEDURE Lower (ch: CHAR): CHAR;
PROCEDURE ToLower (in: ARRAY OF CHAR; OUT out: ARRAY OF CHAR);
PROCEDURE ToUpper (in: ARRAY OF CHAR; OUT out: ARRAY OF CHAR);
PROCEDURE Upper (ch: CHAR): CHAR;
Should they left in Strings? Should they move or copy to subsystem Unicode?
Now Unicode is not imported to the Kernel. With Alexander Shiryaev we think, that it should be imported to the Kernel to provide required functionality.Zinn wrote:Note: Original I had separated module Unicode but Josef moved it to Strings, because he would not like to change to link command.
Also I made HostGui module. This module should be linked to each GUI application to provide hook for MessageBox procedure. By the default Kernel writes debug information to the terminal. So for 1.8 compilation list is changing anyway. Evgeny Temirgaleev also provided good solution to read environment variables with common interface for Windows and Linux. Please, see HostEnv module. It is used by HostFiles to read USE parameter (BB_USE_DIR in GNU/Linux)
Many people think, that StringToUtf8 and Utf8ToString should not be exported from the Kernel to reduce using of Kernel. Also Boris said that this is not big deal, if we change identifiers to CHAR in future, so Utf will be only for interaction with BlackBox-outside third-party libraries and text data.Zinn wrote: (3)
By the way there is another cosmetic change:
Kernel exported the identifier sometimes in string (16 bit CHAR) format and sometimes in utf8 (8 bit CHAR) format. Whenever it is possible the translation between string and utf8 should be done always inside the Kernel. That simplifies further changes of the program. Should I work out this changes?
Re: Is BlackBox 1.8 incompatible to BlackBox 1.7?
After I study the discussion about removing the Unicode part from module Strings I create the following solution
- Attachments
-
- Unicode.txt
- (4.65 KiB) Downloaded 710 times
-
- Strings.txt
- (17.37 KiB) Downloaded 686 times
- Ivan Denisov
- Posts: 363
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Krasnoyarsk, Russia
Re: Is BlackBox 1.8 incompatible to BlackBox 1.7?
There are arguments, that Strings should not depend from the Kernel. With your proposed solution, it depends through the Unicode module. Module Unicode can be cross-platform, so there is no reason to bind it with Kernel, which realization by WinApi and libc is differ for some letters.
The second argument that this will change behavior of Strings procedures without changing the interface. This can cause some issues in the existing extensions. Developer should check manually all places in code, there IsUpper IsAlpha etc. are used to be sure, that new functionality will not break something.
The second argument that this will change behavior of Strings procedures without changing the interface. This can cause some issues in the existing extensions. Developer should check manually all places in code, there IsUpper IsAlpha etc. are used to be sure, that new functionality will not break something.
Re: Is BlackBox 1.8 incompatible to BlackBox 1.7?
Of course you can improve this solution. Module Strings depends on module Unicode and module Unicode depends on module Kernel.
You can create your own module e.g. called UnicodeLibrary, where you implement the Unicode translation staff and call them from module Unicode. The first solution is to move the Kernel part to the UnicodeLibrary. The second solution is to remove the WinApi dependency inside module UnicodeLibray and change it as you like.
Divide and conquer that is the solution. You can change and improve the UnicodeLibrary implementation without changing the interface of Strings and Unicode.
You can create your own module e.g. called UnicodeLibrary, where you implement the Unicode translation staff and call them from module Unicode. The first solution is to move the Kernel part to the UnicodeLibrary. The second solution is to remove the WinApi dependency inside module UnicodeLibray and change it as you like.
Divide and conquer that is the solution. You can change and improve the UnicodeLibrary implementation without changing the interface of Strings and Unicode.
Re: Is BlackBox 1.8 incompatible to BlackBox 1.7?
Maybe add hook interface to Strings module and implement ASCII fallback?
- Ivan Denisov
- Posts: 363
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Krasnoyarsk, Russia
Re: Is BlackBox 1.8 incompatible to BlackBox 1.7?
I do not think that this will lead to reliable software...X512 wrote:Maybe add hook interface to Strings module and implement ASCII fallback?
I pushed the problem to the OberonCore board
https://forum.oberoncore.ru/viewtopic.p ... 68#p114468
I think that this is real problem, that Kernel using differ realization of IsUpper etc, however the solution is to import Unicode to the Kernel.
Re: Is BlackBox 1.8 incompatible to BlackBox 1.7?
For many tasks complex Unicode processing is not needed. It is annoying that importing Strings module in simple PE/ELF linked program (to convert int/real to string for example) that don't use runtime will require importing Kernel or heavy Unicode module. Hook will solve this problem.I do not think that this will lead to reliable software...