BlackBox Framework Center

In new version aliases

There is the minimal demonstration. If you select Views and choose in pop up menu Interface, the interface for TextViews will be oppended.
If same to do about Журнал, there will be an error message.

Ivan Denisov wrote:In new version aliases

There is the minimal demonstration.

Code: Select all

MODULE Test;

	IMPORT Журнал := StdLog, Views := TextViews;

END Test.

If you select Views and choose in pop up menu Interface, the interface for TextViews will be oppended.
If same to do about Журнал, there will be an error message.

Definitely a bug.
It will probably be quite a while before we track down all of the consequences of allowing Unicode identifiers.

here is a proposal for a fix: http://redmine.blackboxframework.org/pr ... f86480202f.

A Unicode string was compared with a utf-8 string (mod) in CheckModName.
The utf-8 string mod is now converted to Unicode first (modStr).

- Josef

Ivan, this is not a new issue.
It is issue-#19.

Josef, thanks for the bug fix!

Josef Templ wrote:Ivan, this is not a new issue.
It is issue-#19.

I do not like this idea, because issue-#19 was a feature and here is the bug after this feature was adopted. So this numbers limitations makes total mess in the board. Also I do not like, that we have several issues-#100 and issue-49 now. It is now hard to distinguish who found the bug, what was the test example, who suggested the fix and so on. This rule of number economy has many disadvantages when advantages is not obvious.

Ivan, this a technical question not a question of I like it or not.
You must understand what an 'issue' is.

An issue a single separate requirement, either for a bug fix or a feature.
Whatever changes are required to fulfill that requirement MUST be grouped together.
The simplest way to get this grouping is to use the same issue number.
Otherwise you would have to group together different issues by providing links from one issue to another,
and it is really complicated to figure out what belongs together.

Now, what is the GROUPING needed for?
It is needed for having a chance to find out which changes have been done in order to fulfill which requirement.
This makes it possible, for example, to undo the changes for a particular requirement.
Let me give you an example:
If it turns out that issue-#38 (report passing receiver parameter IN to VAR)
leads to too many problems for the users we can easily undo that change because we know
what changes have been made for that issue. It is completely irrelevant if the merge to master
has been split over several pull requests. It is one and the same requirement, and the requirement
groups the changes.

"The interface is not showing for aliases" issue is NOT a new requirement.
It is a bug fix in the changes we have done for issue-#19.
Without issue-#19, that new bug fix would not be required.
It belongs together.
It should have been reviewed more carefully, OK, but in general
it is not always possible to avoid all errors, as you probably know from experience.

So far, I have not seen any problem related to this strategy and therefore it must not be changed.

- Josef

You explained why issues relations and grouping are important. I am understanding you idea now.
I am suggesting the alternative, which has less disadvantages.
For issues relations I switch on such feature in the Redmine tracker.
There is now Related issues in the description:
http://redmine.blackboxframework.org/issues/120

The problem of the strategy you described is that it is not possible sometimes to know "is the bug related to some another feature?". So reporter can not know which number to use. This makes extremely hard to report an issue. So if it is not possible to know before submission we should not use submission number for classification. Redmine is allowing to classify issues latter then there is more information.

The problems with reusing the number will graw as a snow ball. We should discuss this now with more Center members.

At creation, an issue should list files belonging to the issue.
If one does not know what files are relevant then the list is empty.
As the issue is worked on files may be added to the issue BUT
EVERY ISSUE MUST BE DISJOINT FROM EVERY OTHER ISSUE.
Only after an issue is closed may a file of it be included in another issue
(again subject to the disjoint condition). Hence two issues that share
1 or more files CAN NOT SIMULTANEOUSLY BE OPEN.

What do we do if a file is found not to be relevant to an issue, after all?
We should be able to remove it from the list BUT this means we need to
keep a history of the issue such that the file list can grow and shrink over time.

Looking at a file one should also be able to determine what issue(s) modified it
(scan through the history of all issues).

Not trivial.
-Doug

We really do need unbounded issue numbers.

Can we please finish 1.7 with the process as it is now.
It is the simplest possible way I can think of.
Too much effort goes into pointless process discussions.
The effort should be invested into reviewing changes and testing the release.
It is really time now to finish 1.7.

- Josef