issue-#19 wrong encoding of "module not found" message

Ivan Denisov
Posts: 1700
Joined: Tue Sep 17, 2013 12:21 am
Location: Russia

Re: issue-#57 wrong encoding of "module not found" message

Post by Ivan Denisov »

I agree with Helmut, inside system modules, compiler and essential tools is better to use Kernel. Strings is more for export.
Also everywhere in DevBrowser was Kernel.Utf8ToStrings.

I removed dependency from Strings there:
http://redmine.blackboxframework.org/pr ... 7b8db5a5b5

Testing version:
http://blackboxframework.org/unstable/i ... a1.180.zip
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: issue-#57 wrong encoding of "module not found" message

Post by Josef Templ »

Ivan Denisov wrote:I agree with Helmut, inside system modules, compiler and essential tools is better to use Kernel. Strings is more for export.
Also everywhere in DevBrowser was Kernel.Utf8ToStrings.
Export for what?
It is exported for client modules such as DevBrowser.

It is never better to use an undocumented Kernel function instead of a well-documented exported function
except if you have a very good reason for doing so.
I don't see any reason for DevBrowser.

- Josef
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: issue-#57 wrong encoding of "module not found" message

Post by Josef Templ »

Zinn wrote:
Ivan Denisov wrote:I thought about this, the #19 was the feature, and now it is the bug in the feature implementation, so it is better to make new number.
Without #19 this bug does not exist. The bug is the result of an incomplete implementaion of #19. So the solution beyond to #19.

It make no sense to vote yes for #19 and no for #57, because I won't have an incomplete errornous implementation.
I agree with Helmut that this bug fix belongs to #19.
Only if we assign it to #19 we are able to see all changes that were required for the support of Unicode identifiers
at one place, viz. in the associated revisions in the redmine issue tracker.
This must be assigned to #19 and this rule should be followed from now on
for all similar cases.

I don't agree with Helmut that voting yes for #19 implies voting yes for #57.
I would not vote yes for the current implementation, for example.
It is not only about fixing the bug at all but also about HOW to fix the bug.

- Josef
Ivan Denisov
Posts: 1700
Joined: Tue Sep 17, 2013 12:21 am
Location: Russia

Re: issue-#57 wrong encoding of "module not found" message

Post by Ivan Denisov »

Josef, #issue-19 topic is overloaded by posts, so should I create #issue-19.1 branch? It will be hard to track old numbers.

I do not agree with you, that all Unicode bugs should be referred as #19.

Also, if you will take a look in DevBrowser, the Kernel is used everywhere. The aim of this #issue-57 is only to fix the bug, not to exchange all Kernel entries.
So, please, keep it simple! Do not force with bureaucracy. I think, that I made this issue clean enough for voting. There is the bug, there is the solution.

I do not see the reasons for using Strings in module, which is not dependent of Strings at all. Also about your argument about undocumented Kernel. We should fix this and add the documentation as claimed in issue-#35.
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: issue-#57 wrong encoding of "module not found" message

Post by Josef Templ »

Ivan, it is very simple.

The original discussion thread about issue-#19 is already closed, so it is clear that we need a new discussion thread.
I would simply use the same number but a more specific title e.g.
"issue-#19 wrong encoding ...".
Can we rename the existing thread that way?

The voting is then also entitled "issue-#19 wrong encoding ...".

Thereby you can later easily search for "issue-#19 " in the forum
or for "Refs. #19." in git.

But we don't need another issue in redmine.
This is the simplification!

Note that the list of issues in redmine is the set of issues that constitute the changes from 1.6 to 1.7.
A change inside 1.7 development steps is not required to be documented in the list of issues
that describe the changes from 1.6 to 1.7.
By using the same issue number we group together what belongs together.
It just happens to be split to multiple merges (and votings) because we are not smart enough
to get everything right at the first shot.

Regarding the Kernel versus Strings stuff:
The Utf8/Unicode Kernel operations in DevBrowser have been introduced in issue-#19
and they are inappropriate, so they are now corrected within issue-#19.
See the discussion of HostPackedFiles (http://forum.blackboxframework.org/view ... =250#p2236)
for an example where it is justified to bypass Strings and use Kernel directly.
This must be the exception, not the usual case.
Using Kernel must be avoided if there is an alternative and if there
is no strong argument for justifying an exception.

- Josef
Ivan Denisov
Posts: 1700
Joined: Tue Sep 17, 2013 12:21 am
Location: Russia

Re: issue-#57 wrong encoding of "module not found" message

Post by Ivan Denisov »

How to be with branches? Now the branch #19 already deleted. Should I again create it? The #issue-19 already closed. Should I reopen it?

Josef, I think, that you are wrong about Strings. The current Strings.Utf8ToString realisation is special case! I mean, that it can has different implementation (we discussed this). For any conversion related with Unicode identifiers, Kernel.Utf8ToString and Kernel.StringToUtf8 should be used!
Ivan Denisov
Posts: 1700
Joined: Tue Sep 17, 2013 12:21 am
Location: Russia

Re: issue-#57 wrong encoding of "module not found" message

Post by Ivan Denisov »

Josef Templ wrote:I have committed the latest changes to the issue-#19 branch.
- Utf8-conversion without checking for illegal Unicode characters
http://forum.blackboxframework.org/view ... t=90#p1669

Strings now are inheriting the implementation "without checking for illegal Unicode characters", but this can be changes in future. For example we can use developed LuoWy converter. The comparison was made here.

Code: Select all

Curerent version:
68.0 ms
12.3 ms
Incorrect input:  $FALSE
Truncated:  $TRUE

LuoWy version:
65.7 ms
12.3 ms
Incorrect input:  $TRUE
Truncated:  $TRUE
We should not base identifiers conversion on Strings module, because it can be changed.
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: issue-#57 wrong encoding of "module not found" message

Post by Josef Templ »

Ivan Denisov wrote:How to be with branches? Now the branch #19 already deleted. Should I again create it? The #issue-19 already closed. Should I reopen it?
Sure, you can create a new topic branch named issue-#19.
We have done this before. It's not a problem.

Ivan Denisov wrote:
Josef, I think, that you are wrong about Strings. The current Strings.Utf8ToString realisation is special case! I mean, that it can has different implementation (we discussed this). For any conversion related with Unicode identifiers, Kernel.Utf8ToString and Kernel.StringToUtf8 should be used!
With all respect, Ivan, but this is a complete nonsense. I cannot follow this argumentation.
It looks as if you are desperately searching for things that complicate matters.
Let me give you an example in order to clarify my point of view:
You are not using WinApi functions for accessing files, you use the Files
module. You are not using HostFiles if you can avoid it, you use Files.
In the same way you use Strings functions instead of the lower level
Kernel or WinApi functions.

- Josef
Ivan Denisov
Posts: 1700
Joined: Tue Sep 17, 2013 12:21 am
Location: Russia

Re: issue-#57 wrong encoding of "module not found" message

Post by Ivan Denisov »

In your example, you will not use HostFiles, because it is implementation for current platform and can be changed. Yes? So, you should not use Strings for identifiers for the same reason. The conversion method in Strings module can (and should) be changed, and this shall not touch all identifiers implementations.
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: issue-#57 wrong encoding of "module not found" message

Post by Josef Templ »

Ivan Denisov wrote:In your example, you will not use HostFiles, because it is implementation for current platform and can be changed. Yes? So, you should not use Strings for identifiers for the same reason.
This is very similar with Kernel.
It is the implementation of the runtime system for the current platform and can be changed any time.
Kernel does not have a docu for exactly this reason. It is supposed
to be used internally by (low-level) BB modules only.
You use Kernel at your own risc.
Ivan Denisov wrote:The conversion method in Strings module can (and should) be changed, and this shall not touch all identifiers implementations.
There is no reason to change the Strings implementation.
This is an invented problem that does not exist.
Strings in general is not supposed to be exchanged and the conversion routines
in particular are also not to be changed.
And if you change it, do yourself a favor and don't change the semantics (the 'specification' of the operations).
Otherwise you create a complete mess and you would produce many follow up errors
on many places. But this is the same with any module such as TextModels or Views
that can be replaced by your own modified/extended version.

- Josef
Post Reply