SF.net SVN: harbour-project:[18799] trunk/harbour

[vsza...@users.sourceforge.net]

Revision: 18799
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=18799&view=rev
Author: vszakats
Date: 2013-01-30 14:32:36 +0000 (Wed, 30 Jan 2013)
Log Message:
-----------
2013-01-30 15:31 UTC+0100 Viktor Szakats (harbour syenar.net)
- src/codepage/l_ua.c
+ src/codepage/l_uk.c
* src/codepage/cpua1125.c
* src/codepage/cpua1251.c
* src/codepage/cpuakoi8.c
! renamed to be in sync with ISO language code
and src/lang/uk.c filename

Modified Paths:
--------------
trunk/harbour/ChangeLog.txt
trunk/harbour/src/codepage/cpua1125.c
trunk/harbour/src/codepage/cpua1251.c
trunk/harbour/src/codepage/cpuakoi8.c

Added Paths:
-----------
trunk/harbour/src/codepage/l_uk.c

Removed Paths:
-------------
trunk/harbour/src/codepage/l_ua.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

[Alain Aupeix]

Hi,

I have the same behaviour than Marco Bra when compiling under Linux.

With 18795, I have this error:

Unrecoverable error 9994: Harbour CP (SVISO) initialization failure
make[1]: [install] Erreur 1 (ignorée)
./bin/linux/gcc/hbmk2 ./config/postinst.hb install

With 18799, I have this error:

Unrecoverable error 9994: Harbour CP (FRISO) initialization failure
make[1]: [install] Erreur 1 (ignorée)
./bin/linux/gcc/hbmk2 ./config/postinst.hb install

As you can notice, between the two rv, the codepage has changed, and I have read the TROUBLESHOOTING section, and I confirm that :

- I always use 'make clean'
- I have a  also the same error with 'make clean'.

A+

--

---

Alain Aupeix
http://jujuland.pagesperso-orange.fr/
http://pissobi-lacassagne.pagesperso-orange.fr/

---

U.buntu 12.04 | G.ramps 3.5.0-0.SVN20055 | H.arbour 3.2.0dev (Rev 18782) | HbIDE (Rev.148)

---

[vszakats]

Maybe you read TROUBLESHOOTING, but then I 

have to say to read it _wholly_, meaning beyond point 1 and 2.

-- Viktor

[Alain Aupeix]

Le 30/01/2013 18:39, vszakats a écrit :

Maybe you read TROUBLESHOOTING, but then I 

have to say to read it _wholly_, meaning beyond point 1 and 2.

Yes, I have read all the points.

As there is an error doing make clean, I have removesd all the local harbour svn folder, all the installed folders (/usr/local/bin, ...)
No more traces of harbour ...

I build then using this command:

make clean
make
sudo make install

and I have this error:

! Installing ../../bin/linux/gcc/hbi18n on /usr/local/bin
../bin/linux/gcc/hbmk2 ../contrib/make.hb install

Unrecoverable error 9994: Harbour CP (SVISO) initialization failure
make[1]: [install] Erreur 1 (ignorée)
./bin/linux/gcc/hbmk2 ./config/postinst.hb install

Unrecoverable error 9994: Harbour CP (SVISO) initialization failure

make: *** [install] Erreur 1

Where do I fail ?
I don't understand, as harbour builds and works on my computer since a few years.

[vszakats]

! Installing ../../bin/linux/gcc/hbi18n on /usr/local/bin
../bin/linux/gcc/hbmk2 ../contrib/make.hb install

Unrecoverable error 9994: Harbour CP (SVISO) initialization failure
make[1]: [install] Erreur 1 (ignorée)
./bin/linux/gcc/hbmk2 ./config/postinst.hb install

Unrecoverable error 9994: Harbour CP (SVISO) initialization failure
make: *** [install] Erreur 1

Where do I fail ?
I don't understand, as harbour builds and works on my computer since a few years.

See the meme where Harbour users install development 

versions to system locations and then forget about the whole 

thing and can't clean off Harbour from those system locations.

I've told about 100 times, NOT TO INSTALL Harbour into 

system locations, but if you prefer to, you're on your own.

-- Viktor

[Przemyslaw Czerpak]

On Wed, 30 Jan 2013, vszakats wrote:

Hi Viktor,

> > *! Installing ../../bin/linux/gcc/hbi18n on /usr/local/bin

> > ../bin/linux/gcc/hbmk2 ../contrib/make.hb install
> >
> > Unrecoverable error 9994: Harbour CP (SVISO) initialization failure
> > make[1]: [install] Erreur 1 (ignorée)
> > ./bin/linux/gcc/hbmk2 ./config/postinst.hb install
> >
> > Unrecoverable error 9994: Harbour CP (SVISO) initialization failure
> > make: *** [install] Erreur 1

> > *

> > Where do I fail ?
> > I don't understand, as harbour builds and works on my computer since a few
> > years.
> >
> See the meme where Harbour users install development
> versions to system locations and then forget about the whole
> thing and can't clean off Harbour from those system locations.
> I've told about 100 times, NOT TO INSTALL Harbour into
> system locations, but if you prefer to, you're on your own.

I know that in the past we have to read many times messages from
people who didn't make clean build anyhow this time it's not the
source of problem.
For nearly whole day is not possible to cleanly compile Harbour
due to problems with new CPs definitions. SVISO is definitely wrong
and it has to break all clean build.
Just try to execute:
make clean
make

recent modification broke UA866 CP though it's not detected yet by
cdpapi.c during registration. I'll fix it later.

best regards,
Przemek

[vszakats]

Hi Przemek,

On Wednesday, January 30, 2013 8:33:50 PM UTC+1, druzus wrote:

On Wed, 30 Jan 2013, vszakats wrote:
> > 
> See the meme where Harbour users install development
> versions to system locations and then forget about the whole
> thing and can't clean off Harbour from those system locations.
> I've told about 100 times, NOT TO INSTALL Harbour into
> system locations, but if you prefer to, you're on your own.

I know that in the past we have to read many times messages from
people who didn't make clean build anyhow this time it's not the
source of problem.
For nearly whole day is not possible to cleanly compile Harbour
due to problems with new CPs definitions. SVISO is definitely wrong
and it has to break all clean build.
Just try to execute:
   make clean
   make

Thanks for breaking the stream of unusable/untrusted 

error reports.

Now I see I forgot to change SVISO to ISO-8859-15.

I hope Klas see this okay. It was wrong all along BTW, 

it just didn't surface.

recent modification broke UA866 CP though it's not detected yet by
cdpapi.c during registration. I'll fix it later.

If you say it's different problem, I have no idea. But 

I see that U+0490 and U+0491 are missing from CP-866 :(

If it's that and it's possible, I'd prefer if the RTL would drop 

any UPPER/LOWER char pair in case any of them cannot 

be represented in the target CP. Or, replace the missing 

char from the pair with a space, as it's done in some 

collations manually. This way it'd be possible to keep the 

same uniform collation source for any target CPs.

If not, simply UA866 needs to be restored along with a 

NOTE explaining the reason of the difference.

-- Viktor

[Klas Engwall]

Hi Viktor,

> Now I see I forgot to change SVISO to ISO-8859-15.
>
> I hope Klas see this okay. It was wrong all along BTW,
> it just didn't surface.

If it is OK with you, I will do some thinking over the weekend and
report back after that. As you mentioned in one of the commit messages,
the offending characters in ISO-8859-15 that do not exist in 8859-1 are
not a part of the Swedish alphabet "of old". When I built the original
collation strings for xHB, the idea was to include "everything including
the kitchen sink" because the Swedish population now includes so many
people from all corners of the globe, and they want to spell their names
as they would in their original languages, and as a result of that the
alphabet in actual use has been extended. So for example, I packed all
available variants of "Y" that exist in Windows-1252 together between
"X" and "Z" even though some of them are very seldom used.

The general rule in the book "Swedish Writing Rules" that I referred to
in my comments to the SV437C codepage says that all available variants
of a certain letter should have the same value, and from there it is
just a matter of cramming as many letters as possible, that exist in
each codepage, into the collation strings. So there is no fixed rule
that says that an Y with umlauts has to be included in the language, I
included it in the collation string for SVWIN because it was available
in that codepage.

I did not even notice when SVISO was added that there was really an
unhandled conflict with SVWIN. So far I still use
set(_SET_DBCODEPAGE,'SV437C') everywhere while my VM codepage is SVISO.
And I suspect that besides me there are zero developers using Swedish
codpages (sadly...), so the short term problem is limited as long as
Harbour can be built for everyone.

The idea, in general, of calling the Swedish codepage 8859-15 and not
8859-1 gives me a slightly strange feeling, so I will contemplate
whether this is the way to go or if the offending characters should be
removed. It is mostly a philosophical question.

Regards,
Klas

[Viktor Szakáts]

Hi Klas,

Perfect with me. Though as i added in last commit, old svwin and sviso were bit by bit identical as far as the collation went. Only that they referenced different CP, so they worked differently in fe. a hb_translate(). Otherwise svwin collation worked wrongly, not as any valid ISO cp. So with latest rev, to me it seems it's sorted. Well, you'll decide.

--
You received this message because you are subscribed to the Google Groups "Harbour Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-deve...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Viktor

[Klas Engwall]

Hi Viktor,

Sorry for the delay, I had to focus on other things for a while.

I have tested the latest SVWIN and SVISO collations, and all seems to be
fine. Thank you.

As I mentioned last week, the philosophy behind the extended collation
strings in (my original) SVWIN (originally for xHB) was to allow *all*
alphabetical characters provided by the codepage, including those not
normally used in Swedish words and names, to be sorted according to
their alphabetical context rather than an arbitrary asc() value - as
suggested by the Swedish Language Council.

When I look at the collation strings again I see that there are four
characters, that are available in Windows-1252, that I for some reason
forgot to include at that time. Those are SsZz with caron, and they also
exist in ISO-8859-15 but not in ISO-8859-1 (as shown in the included
excerpt from the Wikipedia page for ISO-8859-15). As with all the other
"extra" characters they are never used in "old" Swedish, but our
neighbours on the other side of the Baltic Sea do use them.

We already have one INCOMPATIBLE tag since last week's overhaul, so I
think that if we are ever going to include those remaining characters in
the SV* codepages, now is the time to do it. The correct sequences, for
this purpose, would be:

... S <tilde> S-with-caron T ...
... Z <tilde> Z-with-caron � ...
... s <tilde> s-with-caron t ...
... z <tilde> t-with-caron � ...

And they would work for both SVWIN and the updated 8859-15 based SVISO
with your new deduplication strategy.

What do you think?

If you agree, would you please make the modifications for me? I suspect
that if I do them you would have to clean up after me anyway :-)

Regards,
Klas

[vszakats]

Hi Klas,

On Thursday, February 7, 2013 2:27:31 PM UTC+1, Klas Engwall wrote:

Hi Viktor,

Sorry for the delay, I had to focus on other things for a while.

I have tested the latest SVWIN and SVISO collations, and all seems to be
fine. Thank you.

As I mentioned last week, the philosophy behind the extended collation
strings in (my original) SVWIN (originally for xHB) was to allow *all*
alphabetical characters provided by the codepage, including those not
normally used in Swedish words and names, to be sorted according to
their alphabetical context rather than an arbitrary asc() value  -  as
suggested by the Swedish Language Council.

When I look at the collation strings again I see that there are four
characters, that are available in Windows-1252, that I for some reason
forgot to include at that time. Those are SsZz with caron, and they also
exist in ISO-8859-15 but not in ISO-8859-1 (as shown in the included
excerpt from the Wikipedia page for ISO-8859-15). As with all the other
"extra" characters they are never used in "old" Swedish, but our
neighbours on the other side of the Baltic Sea do use them.

We already have one INCOMPATIBLE tag since last week's overhaul, so I
think that if we are ever going to include those remaining characters in
the SV* codepages, now is the time to do it. The correct sequences, for
this purpose, would be:

...   S   <tilde>   S-with-caron   T   ...

...   Z   <tilde>   Z-with-caron   �   ...

...   s   <tilde>   s-with-caron   t   ...

...   z   <tilde>   t-with-caron   �   ...

And they would work for both SVWIN and the updated 8859-15 based SVISO
with your new deduplication strategy.

What do you think?

If you agree, would you please make the modifications for me? I suspect
that if I do them you would have to clean up after me anyway :-)

I agree absolutely. I don't think you'd make a mess,

but it's no problem for me to do it. Am I assuming 

right that the new chars should be sorted after normal 

S and Z chars respectively?

-- Viktor

[Klas Engwall]

Hi Viktor,

> I agree absolutely. I don't think you'd make a mess,

Who knows? :-)

> but it's no problem for me to do it. Am I assuming
> right that the new chars should be sorted after normal
> S and Z chars respectively?

Yes, and with a tilde between them like with all the other "variant"
letters.

Regards,
Klas

[vszakats]

Hi Klas,

Thanks, and there goes the commit in a few mins.

-- Viktor