issue-#44 unicode content of links&targets saving wrong way

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

Re: issue-#44 unicode content of links&targets saving wrong

Post by Ivan Denisov »

Josef Templ wrote:I did not have the time to look into the details of the implementation yet,
so I really don't know what version 0 or 1 or 2 means. Anyway, I am surprised
that this issue has not been fixed in CPC 1.7.

- Josef
The only difference between 0 and 1 is that version 1 is storing "close state" of link. This "close state" (v.close) regulates the behaviour about closing or not closing the document after link is pushed. So using of 1 instead of 0 for leftSide link not only simplify export, but also make the import faster. In case of 0 it should be calculated by analysis of link content, in case of 1 — it is simply read.
Ivan Denisov wrote: 0 - default behaviour: close window if shift is down, never close if link contains ShowTarget (not storing v.close);
1 - unusual behaviour: always close window or never close (storing v.close state);
2 - always storing v.close state and storing v.cmd as widechars;
Zinn
Posts: 476
Joined: Tue Mar 25, 2014 5:56 pm
Location: Frankfurt am Main
Contact:

Re: issue-#44 unicode content of links&targets saving wrong

Post by Zinn »

The question is: Need we state 0 really ?

When the answer is no we can simplify the export by using state 1 and 2 only.

When the answer is yes then our solution is wrong, because we need 4 states:

0 - default behaviour: close window if shift is down, never close if link contains ShowTarget (not storing v.close);
1 - unusual behaviour: always close window or never close (storing v.close state);

2 - always storing v.close state and storing v.cmd as widechars;
3 - same as 0 except storing in widechars
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: issue-#44 unicode content of links&targets saving wrong

Post by Josef Templ »

regarding the version 0 'optimization':
I would follow Chris' suggestion here: make changes only if you solve a problem.

This is a subtle change that needs a lot of thinking in order to verfiy that
it does not change the observable behavior.
Nevertheless, it changes a .odc file even if there is no change in the contents.
This means that git would show a change but a text comparison does not show any changes.
In addition, this is a change that is not related to supporting unicode characers.
It may be true that the change is only a problem for very old BB versions, but is it worth
to spend our time on such optimizations?
A lot more cosmetic changes could be made in this module but what for?

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

Re: issue-#44 unicode content of links&targets saving wrong

Post by Ivan Denisov »

I agree with Josef, that this reduction does not related with bugfix and also will change binary files. So I can roll back after some more discussion.

Nevertheless there is strong desire to make code more simple by cutting rudimentary stuff. This can be done after all known fixes applied. For example old Ctl bindings or this 0 version...
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: issue-#44 unicode content of links&targets saving wrong

Post by Josef Templ »

Zinn wrote:The question is: Need we state 0 really ?

When the answer is no we can simplify the export by using state 1 and 2 only.

When the answer is yes then our solution is wrong, because we need 4 states:

0 - default behaviour: close window if shift is down, never close if link contains ShowTarget (not storing v.close);
1 - unusual behaviour: always close window or never close (storing v.close state);

2 - always storing v.close state and storing v.cmd as widechars;
3 - same as 0 except storing in widechars
For me the answer must be yes.

Is there a difference between 2 and 3 that can be observed by the user?
If no, why do we need them?
If yes, can you give an example?

- Josef
Zinn
Posts: 476
Joined: Tue Mar 25, 2014 5:56 pm
Location: Frankfurt am Main
Contact:

Re: issue-#44 unicode content of links&targets saving wrong

Post by Zinn »

We are running in a circle with this discussion.
So let me start again from the beginning:

The Externalise of Link in BB 1.6 has the following structure:

Code: Select all

IF leftSide THEN
	IF some rules THEN
		version = 0
	ELSE
		version = 1
	END;
ELSE
	version = 0
END;
I change this in the CPC Edition to

Code: Select all

IF leftSide THEN
	IF some rules THEN
		version = 0
	ELSIF ~hasWideChars THEN
		version = 1
	ELSE
		version = 2
	END;
ELSE
	version = 0
END;
Iwan analysed it and said that the CPC solution is wrong. The hasWideChars comparison must be come first:

Code: Select all

IF leftSide TTHEN
	IF hasWideChars THEN
		version = 2
	ELSIF some rules THEN
		version = 0
	ELSE
		version = 1
	END;
ELSE
	version = 0
END;
Now I said when Ivan's argument is right then this can be simplified to

Code: Select all

IF leftSide THEN
	IF hasWideChars THEN
		version = 2
	ELSE
		version = 1
	END;
ELSE
	version = 0
END;
and my question was: Need we the comparison with some rules and version = 0?
If this answer is yes Ivan's solution is wrong too.
User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: issue-#44 unicode content of links&targets saving wrong

Post by Robert »

Helmut
Turing S Spain on my motor bike with a small tablet, so can't really concentrate on this. But isn't the issue the same as the changes we suggested for StdStamps. The new code should be able to read old 8-bit, but always write 16_bit without testing if it needs to?
Zinn
Posts: 476
Joined: Tue Mar 25, 2014 5:56 pm
Location: Frankfurt am Main
Contact:

Re: issue-#44 unicode content of links&targets saving wrong

Post by Zinn »

Robert, yes it is. With your rules the result will be

Code: Select all

IF leftSide THEN
   version = 2
ELSE
   version = 0
END;
Ivan Denisov
Posts: 1700
Joined: Tue Sep 17, 2013 12:21 am
Location: Russia

Re: issue-#44 unicode content of links&targets saving wrong

Post by Ivan Denisov »

Roman found the Oberon/F distribution
ftp://ftp4.gwdg.de/pub/languages/oberon/OberonF
(Mac version also there)

Oberon/F 1.1 beta supports links and can open files from 1.6 version well.
There are no sources available, however I am sure that it uses 0 version.
So we can keep 0 version for back compatibility with Oberon/F 1.1 beta :)
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: issue-#44 unicode content of links&targets saving wrong

Post by Josef Templ »

The rules are simple and follow from the history:
version 0: no close flag stored, Ascii-Cmd
Version 1: close flag added, Ascii-Cmd
Version 2: Unicode-Cmd instead of Ascii-Cmd, close flag REMAINS as in version 1.

The applied strategy in BB1.6 is that although it supports version 1 it stores it as version 0 if possible.
This is for the sake of compatibility. As long as the version 0 behavior is sufficient it is not
used in the storage format and older BB versions can still read the document.
The same principle applies to our current release. It falls back to storing version 1 or even 0
if the new version 2 feature (Unicode) is not needed.

I think Ivan's first version (without the simplifications) is right.
There is no need to introduce another version with Unicode-Cmd but without the close flag.
Why? Because they would behave in the same way. There is no observable difference
and introducing another version code would only complicate things (correct me if I am wrong here).
There is no need to think about backward compatibility in case a Unicode-Cmd is used
because this is incompatible anyway. Having a version 3 would also be
strange in the sense that we would introduce two new versions (2 and 3) at the same time.

If anybody worries about code replication of the HasWideChars procedure:
this could be put into Strings and be reused in StdLinks etc.

- Josef
Post Reply