Is BlackBox 1.8 incompatible to BlackBox 1.7?

BlackBox for Windows / Linux / OpenBSD / FreeBSD
https://github.com/bbcb/bbcp https://blackbox.oberon.org/download

Is BlackBox 1.8 incompatible to BlackBox 1.7?

Postby Zinn » Fri Apr 16, 2021 8:26 am

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
Zinn
 
Posts: 113
Joined: Mon Nov 24, 2014 10:47 am
Location: Frankfurt am Main

Re: Is BlackBox 1.8 incompatible to BlackBox 1.7?

Postby Ivan Denisov » Sat Apr 17, 2021 4:02 pm

Zinn wrote:Is BlackBox version 1.8-a1.062 the basic of the linux version of BlackBox?

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:Do you need subsystem Cons for integration? Who is using it?

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:Why moved some modules from subsystem Strings to subsystem Unicode and subsystem Utf8?

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.
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.

Zinn wrote:What is the reason to cut the link to Kernel.Hook in several modules?

The same reason — to reduce the dependency from the Kernel. Also

Zinn wrote:I know that is a lot of question. I would like to know the reason of this changes.

Very happy with your questions. Please, ask more.
User avatar
Ivan Denisov
 
Posts: 339
Joined: Tue Sep 17, 2013 12:21 am
Location: Krasnoyarsk, Russia

Re: Is BlackBox 1.8 incompatible to BlackBox 1.7?

Postby Zinn » Sun Apr 18, 2021 9:09 am

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
Zinn
 
Posts: 113
Joined: Mon Nov 24, 2014 10:47 am
Location: Frankfurt am Main

Re: Is BlackBox 1.8 incompatible to BlackBox 1.7?

Postby Ivan Denisov » Sun Apr 18, 2021 1:51 pm

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?

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:Note: Original I had separated module Unicode but Josef moved it to Strings, because he would not like to change to link command.

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.
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)

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?

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.
User avatar
Ivan Denisov
 
Posts: 339
Joined: Tue Sep 17, 2013 12:21 am
Location: Krasnoyarsk, Russia

Re: Is BlackBox 1.8 incompatible to BlackBox 1.7?

Postby Zinn » Wed Apr 21, 2021 6:02 pm

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 57 times
Strings.txt
(17.37 KiB) Downloaded 50 times
Zinn
 
Posts: 113
Joined: Mon Nov 24, 2014 10:47 am
Location: Frankfurt am Main

Re: Is BlackBox 1.8 incompatible to BlackBox 1.7?

Postby Ivan Denisov » Thu Apr 22, 2021 2:52 am

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.
User avatar
Ivan Denisov
 
Posts: 339
Joined: Tue Sep 17, 2013 12:21 am
Location: Krasnoyarsk, Russia

Re: Is BlackBox 1.8 incompatible to BlackBox 1.7?

Postby Zinn » Thu Apr 22, 2021 6:08 am

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.
Zinn
 
Posts: 113
Joined: Mon Nov 24, 2014 10:47 am
Location: Frankfurt am Main

Re: Is BlackBox 1.8 incompatible to BlackBox 1.7?

Postby X512 » Fri Apr 23, 2021 6:16 pm

Maybe add hook interface to Strings module and implement ASCII fallback?
X512
 
Posts: 72
Joined: Sat Feb 07, 2015 2:51 pm

Re: Is BlackBox 1.8 incompatible to BlackBox 1.7?

Postby Ivan Denisov » Sat Apr 24, 2021 8:56 am

X512 wrote:Maybe add hook interface to Strings module and implement ASCII fallback?

I do not think that this will lead to reliable software...

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.
User avatar
Ivan Denisov
 
Posts: 339
Joined: Tue Sep 17, 2013 12:21 am
Location: Krasnoyarsk, Russia

Re: Is BlackBox 1.8 incompatible to BlackBox 1.7?

Postby X512 » Sun Apr 25, 2021 7:39 pm

I do not think that this will lead to reliable software...


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.
X512
 
Posts: 72
Joined: Sat Feb 07, 2015 2:51 pm

Next

Return to BlackBox Cross-Platform

Who is online

Users browsing this forum: No registered users and 1 guest

cron