Morten Kromberg wrote:
> On Mar 6, 10:11 am, phil chastney
> <phil.hates.s...@[EMAIL PROTECTED]
> wrote:
>
>> Dyalog have taken the right decision, but instead of simply releasing
>> enhanced Unicode versions without enhanced "classic" versions, it might
>> be better received by their customer base if Dyalog were to announce an
>> end-date for ASCII-only enhancements first
>
> Phil, thanks for the first bit! I am not sure I understand the rest of
> the comment, or what the perceived problem is with the Unicode/Classic
> split - can you elaborate?
>
> The Classic and Unicode versions are built using the same source code
> and are identical in "functionality". They ONLY differ in the way that
> they translate data as it goes in and out of the system, that
> character arrays in the Classic version are restricted to the 256-
> element selection from Unicode known as the "Atomic Vector", and that
> the byte which represents a character in the Classic version is an
> index into "Quad-AV". The arguments and results of monadic upgrade and
> Quad-DR differ from one version to the other.
>
> Note that BOTH versions have a single-byte character data type, but
> that Unicode version will also use 2- and 4-byte internal
> representations if you use code points beyond 255 (the Unicode product
> views characters in the same way as integers, which also come in 1-,
> 2- and 4-byte flavours, depending on the range of the data).
>
> We have NOT set a date for the end of the Classic version because we
> want to give our customers some time to think about the issue and how
> it will impact applications first. Some applications will just load
> and run in the Unicode version, others which use a lot of casting
> ([]DR) and clever tricks when importing and exporting data may need
> work. We do not yet know what would be a "reasonable" deadline.
>
> Actually taking advantage of Unicode in applications (as opposed to
> just being able to run on the Unicode version) may be a massive effort
> involving rewriting all your interfaces, converting all your SQL
> databases and other forms of external media, your applications
> understanding of sorting and searching, etc: We don't expect many of
> our customers to go all the way down that path, but it is very
> important that those who want to CAN do it easily.
>
> Note that the Classic and Unicode versions are fully inter-operable,
> they can share workspaces, component files and TCP socket connections
> - with the "obvious" limitation that a Classic version will choke if
> it encounters a character not in its QuadAV (QuadAV can be defined by
> the user - so Russians can define a different 256-element subset than
> English Dyalog users). The Unicode version can be configured so that
> it knows which subset a Classic "partner system" is working with and
> translate data accordingly.
>
> v12 Unicode can be instructed to continue to write non-Unicode
> component files (on a per file basis) and give an error if this is not
> possible, so that it does not "accidentally" write files that Classic
> (or v10 and v11) cannot read.
>
> Version 12 is carefully designed to avoid big bang conversion events
> and make the transition to Unicode as smooth as possible: We want
> encourage our users to move to Unicode as quickly as possibly but will
> not force anyone to move hastily.
>
> We are NOT setting a deadline at this time. My advice would be to
> install the Unicode version as soon as possible and start up a project
> team to evaluate how hard it will be to move, and how (if) your
> applications can benefit from extending the range of characters
> handled. I would plan to starting a move to the Unicode version with 3
> years and try to complete it in 5. But DON'T PANIC, we do not leave
> people "up the creek": So long as there is any significant use of the
> Classic version it will continue to be supported.
>
> Come to our User Group conference in October to talk to colleagues
> about what they are doing and put pressure on Dyalog to do the right
> thing :-).
>
> Morten
OK, that's fine, if there's no significant overhead in maintaining both
versions, then continue to support both versions
and thanks for the invitation, but I'm sure you get more than enough
pressure as it is, and the pressure that you're getting is probably much
more commercially oriented
best regards . . . /phil
|
