BlackBox Framework Center

Yes, lets discuss this later after 1.7 final release.

Doug, can you please make the voting for this issue.
I am renaming it now to #19 because Josef push changes to branch issue-#19.

Using a new Issue number #120 or using the old issue number #19?

That is the same problem as: To eat the cake or to have the cake.
1st the argument of Josef is right.
2nd the argument of Ivan is also right.
The problem is from which side we look at this topic.
Josef looks from the side which change beyond to one problem or future. It doesn't matter at what time the change is done.
I call it the developer view.
Ivan looks from the side which change have we done since last time breakpoint. It doesn't matter to which problem it is grouped.
I call it the maintenance view.
This are two different change list.
The question is when we find an error about issue number #19 after release of 1.7 should the new change still use the number #19?
I try both ways and I lost my overview about all the change we have done.

It is time to release 1.7
and discuss after the release how can we continue our work?

Josef says there is no reason to change anything about how to work. Everyting works well.
But I'm not familar with all those tools and I don't know how to use them in the right way.
I have not the windows interface of Git. I have the command interface of Git, because I work with Ubuntu.
I need to work out how to do it, step by step with a simple change example.

Why only 2 (3) persons insert changes into redmine? Because it is too complicated to getting started with all those stuff, Redmine, Git, and so on ...
Two and a half man is a famous American sitcom.
- Helmut

Ivan Denisov wrote:Yes, lets discuss this later after 1.7 final release.

Doug, can you please make the voting for this issue.
I am renaming it now to #19 because Josef push changes to branch issue-#19.

Thanks.

Maybe a short comment on the proposal to use Redmine links for grouping issues.

This would be a tremendous disadvantage and complication because it makes us even more dependent on Redmine.
(Doug, Helmut, et al., this would double your pain in getting productive and it would double my pain in staying productive).
Whenever you want to know all related changes you would need to go to Redmine. This is a nightmare.
It is no longer possible to see related changes directly within the repository.
With the current approach it is possible! All you need is the git repository and, if you need
additional information, the changelist, which is included with BlackBox.

In addition: if you have multiple issues for the same requirement, the changelist would contain multiple entries too.
It would no longer document the changes from the previous (1.6) version, but also contain changes from an intermediate
state of 1.7 to another intermediate state of 1.7.

Any issues observed by external users should be posted to the community forum first.
Our Redmine issue tracker is not a ticket system for customers/users. We are not a call center.
@Helmut: it is the development view that counts.

- Josef

Zinn wrote:Using a new Issue number #120 or using the old issue number #19?

...I call it the developer view.
...I call it the maintenance view.

Why only 2 (3) persons insert changes into redmine? Because it is too complicated to getting started with all those stuff, Redmine, Git, and so on ...
- Helmut

It is the developer view that counts. We are not a call center.

For a target version after 1.7 some things change, of course.
We introduce a new target version in Redmine.
We start with an empty change list because there are no issues with the new target version.
A Redmine issue can have only one target version, so we have to use new issues, I think.
Obviously we cannot reset the issue numbers to start with 1, we have to continue the counting because otherwise the
references to issues would be ambiguous.
In case of revisiting an issue it may be possible to use Redmine links to point to related issues from a previous version
but it is probably better to include an issue reference textually in the issue description, or do both.
Then it would show up in the changelist automatically.

Helmut, the development process is not complicated at all.
It only involves a small set of conventions (see the wiki) and
some standard tools, and such tools have a lot of features that you normally don't need.
This makes the process look complicated. All you need is a handful of git commands on the command line.
There is enough knowledge available now for getting anybody productive in a short time.
You can do experiments easily with git because any repository clone has all the features our github repository has.
Perfect for playing with the process.

- Josef

Has the bug been fixed?
Ivan, have you tested the fix?

DGDanforth wrote:Has the bug been fixed?
Ivan, have you tested the fix?

Yes, I have tested. All is fine now.
http://blackboxframework.org/unstable/i ... c1.604.zip

Also Valeriy Shpkov has tested: http://forum.oberoncore.ru/viewtopic.ph ... 780#p97780

This issue is waiting for voting

Wait a second.
I have found another bug in Strings.Upper that also belongs to issue-#19.

Here is the bug:
Strings.Upper(CHR(255)) # Kernel.Upper(CHR(255)).
The same applies to ToUpper.
Kernel and Strings don't return the same results in one case, viz. ch = CHR(255).

- Josef

fixed by adding one line in the initialization of toUpper: For the diff see http://redmine.blackboxframework.org/pr ... f74af7faae.

- Josef

Josef Templ wrote:fixed by adding one line in the initialization of toUpper:

Code: Select all

toUpper[ORD("ÿ")] := "Ÿ";

Curious that there is an omission in "toUpper", but not in "toLower"!

(I am not claiming this is a bug - I don't follow exactly what is going on.)