Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)

2017-05-03 Thread Marcos Douglas B. Santos via Lazarus
On Wed, May 3, 2017 at 6:13 AM, Ondrej Pokorny via Lazarus
 wrote:
> Not if you need pre-unicode Delphi support :)
>
> (Well, Marcos didn't specify what Delphi version he wants to target but he
> stated "If Delphi sources don't use UTF8 [...]", which applies to
> pre-unicode Delphi versions.)

Yeah, sorry. I said that because I didn't know which encoding Delphi
is using nowadays.
But I would like to use only Delphi with Unicode support with
"dot.unit.support".

Marcos Douglas
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)

2017-05-03 Thread Graeme Geldenhuys via Lazarus
On 2017-05-03 20:47, Juha Manninen via Lazarus wrote:
> If you share and edit the sources between Delphi and Lazarus then you
> cannot use the full Unicode. 


Quite comical considering that the FPC team always makes such a big fuss
about "we want Delphi compatibility", and now it seems to be worse than
ever before.

Regards,
  Graeme

-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)

2017-05-03 Thread Sven Barth via Lazarus
On 03.05.2017 21:47, Juha Manninen via Lazarus wrote:
> Why Delphi adds the BOM? Why can't it just read the file and
> understand it is UTF-8?

Probably for the same reason as FPC: the default code page if no BOM is
available and no command line option is set and no $codepage directive
is found is ISO-8859-1.
A BOM does the same as the command line option -FcUTF8 or the directive
{$codepage utf8}, namely switching the source codepage to UTF-8. Only
then string constants that contain UTF-8 characters are converted to
UnicodeString constants.

Regards,
Sven
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)

2017-05-03 Thread Ondrej Pokorny via Lazarus

On 03.05.2017 21:47, Juha Manninen via Lazarus wrote:

How many people are editing their sources in both Delphi and Lazarus?


Me, but I keep the files ASCII-only because I need to target all Delphi 
versions down to D5 :/ My customers really demand it, unfortunately. I'd 
like to kill these dinosaurs, believe me - not the customers but the 
thousand different Delphi versions from ancient eras, during the best 
period even 2 of them in a year :)


I still feel that code should be in English, including comments - and I 
am a patriot, even if it is not popular nowadays :). The utf-8 bom seems 
to be a stupid issue, though.


Ondrej
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)

2017-05-03 Thread Sven Barth via Lazarus
Am 03.05.2017 14:37 schrieb "Tony Whyman via Lazarus" <
lazarus@lists.lazarus-ide.org>:
> On the other hand, AnsiString and UnicodeString are still separate types.
Why? Why should there not be a single unified string type with (e.g.)
ASCII, UTF8 and UTF-16 (or MS Unicode) being just another code page?

Because indexed access to the string data would slow down quite a bit as
the RTL would need to determine whether the string is a 1-Byte, 2-Byte,
4-Byte or multi Byte String. Yes the compiler could do optimizations for
this inside loops, but it would definitely slow down -O- code.

Regards,
Sven
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)

2017-05-03 Thread Sven Barth via Lazarus
Am 03.05.2017 11:34 schrieb "Graeme Geldenhuys via Lazarus" <
lazarus@lists.lazarus-ide.org>:
> For example, take a look at ConEmu for Windows.
>   * Tab support built-in
>   * Resizeable console windows

While not point and click you can resize console windows (and the window
buffer) without problems. And it's even remembered *per shortcut*!

>   * User defined encoding per console window

While not selectable upon start (I think) it can easily be changed with a
command.

>   * Font choice

Supported since at least XP

>   * better mouse & clipboard support

If you use the PowerShell window that experience is already vastly
improved. Could be that this is the case for the default console window in
Windows 10 as well.

>   * User defined "console engine" per window or tab.
> eg: I can have Bash run in one tab and the standard
>  windows console in another.

No one stops you from running a different shell in a command window (e.g. I
often switch to cmd inside PowerShell when some program give me trouble
with the latter).

>   * color customisation

Already supported since at least Windows 7 (can't currently check older
versions).

> I don't know why anybody would still want to run the standard Windows
> console - it is 20 years behind everybody else.

Because it does its job and its part of the OS without the need to install
some 3rd party application.

Regards,
Sven
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)

2017-05-03 Thread Martok via Lazarus
Am 03.05.2017 um 11:03 schrieb Juha Manninen via Lazarus:
> How could this thing be communicated so that people understand?
It would probably help if there weren't three different pages about "Unicode
Support" on the wiki, all saying slightly different and conflicting things
(because they talk about different things, but that's really not obvious unless
you already know) and decidedly *not* saying what a user might want to know...

Maybe split the technical internals from a "simpler" user's guide?


Martok

-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)

2017-05-03 Thread Mattias Gaertner via Lazarus
On Wed, 3 May 2017 13:37:24 +0100
Tony Whyman via Lazarus  wrote:

>[...]
> On the other hand, AnsiString and UnicodeString are still separate 
> types. Why? Why should there not be a single unified string type with 
> (e.g.) ASCII, UTF8 and UTF-16 (or MS Unicode) being just another code page?

Many 8bit string functions work for any 8bit encoding, and so do many
16bit string functions for any 16bit encoding. But almost no string
function works for both.

Mattias
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)

2017-05-03 Thread Tony Whyman via Lazarus

On 03/05/17 09:52, Graeme Geldenhuys via Lazarus wrote:

[rant]
ps:
   Both FPC and Delphi is in such a messed up state when it comes to
   string and character types. It is the laughing stock of programming
   languages at the moment. At least EMBT is heading in the right
   direction with their Linux Delphi compiler - they completely removed
   AnsiString.

   FPC and Delphi can learn a huge lesson from Java and Qt in how to
   handle string and character types.
[/rant]

Regards,
   Graeme

Is Delphi/FPC string handling that much worse than 'C'?

To me, the great thing about AnsiString is that it provides unified 
handling of UTF8 and legacy codepages in a single managed type by 
including the code page id as a dynamic property of the string.


On the other hand, AnsiString and UnicodeString are still separate 
types. Why? Why should there not be a single unified string type with 
(e.g.) ASCII, UTF8 and UTF-16 (or MS Unicode) being just another code page?

--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)

2017-05-03 Thread Marcos Douglas B. Santos via Lazarus
On Wed, May 3, 2017 at 5:59 AM, Graeme Geldenhuys via Lazarus
 wrote:
> On 2017-05-03 01:21, Marcos Douglas B. Santos via Lazarus wrote:
>> Sorry about that. I stopped using Delphi at version 7, that uses ANSI.
>> I thought that Delphi nowadays was using UTF16.
>
> They (Delphi) loves to follow Microsoft. Files are stored in UTF-8 (this
> is the norm), but they use UTF-16 internally.
>
> Lazarus stores files in UTF-8 and uses UTF-8 internally.
>
> Some background info
> 
> UTF-16 was the first encoding implementation for Unicode - at a time
> when they thought 2-bytes will be big enough for everything. They were
> wrong. So then they invented UTF-8 to solve the problem. But by that
> time Microsoft already standardised on UTF-16, so Delphi followed suite.
> Linux, FreeBSD etc saw the light and used UTF-8 instead.

Ok, thank you for these informations.

best regards,
Marcos Douglas
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)

2017-05-03 Thread Mattias Gaertner via Lazarus
On Wed, 3 May 2017 12:03:41 +0300
Juha Manninen via Lazarus  wrote:

>[...]
> Please also look at program LazUnicodeTest in components/lazutils/test/.
> It does advanced Unicode stuff and works in both Delphi and Lazarus.

I tried it:

First it did not compile in Delphi, because of an unsupported inline. I
fix that with an IFDEF FPC.

Then it runs. The output is somewhat hard to interpret as the
Windows console shows many chars as '?' and the writelns do not
explain what it is supposed to show. 
The good news is that it works.

The bad news is, that it only works because Delphi silently altered
the source file and added the BOM.

Back in Lazarus compiling such a file gives the error:
LazUnicodeTest.lpr(28,10) Error: UTF-8 code greater than 65535 found


> It means any code dealing with Unicode can do it.
> 
> How could this thing be communicated so that people understand?
> Why other Lazarus developers don't want to mention it?
> I am puzzled. :(

You are right, that using Unicode with Lazarus only needs a couple of
rules to follow. Sharing code with Delphi adds a few more rules.

Mattias
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)

2017-05-03 Thread Jürgen Hestermann via Lazarus

Am 2017-05-03 um 11:34 schrieb Graeme Geldenhuys via Lazarus:
> I don't know why anybody would still want to run the standard Windows
> console - it is 20 years behind everybody else.

The reason: It is available on every Windows machine.
The alternatives need to be installed first
so scripts designed for them don't work out of the box.

--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)

2017-05-03 Thread Juha Manninen via Lazarus
On Wed, May 3, 2017 at 12:13 PM, Ondrej Pokorny via Lazarus
 wrote:
> Not if you need pre-unicode Delphi support :)

Ok, true. IMO such old Delphi versions should not be used any more for new code.
Maintenance tasks only I think.

Fortunately there is again a free Delphi Starter edition. It means
anybody can use the latest version. Things are surely getting better!

Juha
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)

2017-05-03 Thread Ondrej Pokorny via Lazarus

On 03.05.2017 11:21, Juha Manninen via Lazarus wrote:
Windows already supports Unicode in everything ... except for console 
output! Why is that?


You can start the console with UTF-8 codepage: 
http://stackoverflow.com/questions/14109024/how-to-make-unicode-charset-in-cmd-exe-by-default


Then you have full unicode (utf-8) support.

Ondrej
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)

2017-05-03 Thread Graeme Geldenhuys via Lazarus
On 2017-05-03 10:25, Ondrej Pokorny via Lazarus wrote:
> You can start the console with UTF-8 codepage: 
> http://stackoverflow.com/questions/14109024/how-to-make-unicode-charset-in-cmd-exe-by-default
> 
> Then you have full unicode (utf-8) support.

Or use the much better console alternatives. The Windows platform is
finally catching on to what was been available in X11 environments for
years - multiple choice on consoles.

For example, take a look at ConEmu for Windows.
  * Tab support built-in
  * Resizeable console windows
  * User defined encoding per console window
  * Font choice
  * better mouse & clipboard support
  * User defined "console engine" per window or tab.
eg: I can have Bash run in one tab and the standard
 windows console in another.
  * color customisation
  * transparency support


  https://sourceforge.net/projects/conemu/


I don't know why anybody would still want to run the standard Windows
console - it is 20 years behind everybody else.

Regards,
  Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)

2017-05-03 Thread Juha Manninen via Lazarus
On Wed, May 3, 2017 at 11:52 AM, Graeme Geldenhuys via Lazarus
 wrote:
> At least EMBT is heading in the right direction with their
> Linux Delphi compiler - they completely removed AnsiString.

I must agree with you. I hope it will be removed in (far) future when
nobody uses the old Windows system codepages any more.
Windows already supports Unicode in everything ... except for console
output! Why is that?

Anyway, please let's leave out encoding supremacy issues now.
My point has been that our Unicode solution makes the encoding issues
irrelevent. It is almost compatible at source level despite the
different encodings.
Think how improbable that is, yet it works.
See also the encoding agnostic support provided by LazUnicode.

Encoding does not matter any more, as long as it is Unicode.

Juha
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)

2017-05-03 Thread Ondrej Pokorny via Lazarus

On 03.05.2017 11:03, Juha Manninen via Lazarus wrote:

I am puzzled why there were so many misleading and confusing replies,
also from knowledgeable Lazarus developers.
Remember, the question was about making sources compatible with Delphi.
The person (Marcos Douglas) did not know details of how strings work
in Delphi and Lazarus.
Now we finally have a system that allows (more or less) compatible
code when using Unicode. Why was it not even mentioned by you guys?

For example:

Ondrej Pokorny wrote:

Speaking from my experience, the only approach (not only the best one but
the only one) is not to use characters above #255.

Nonsense. Full Unicode is supported.


Not if you need pre-unicode Delphi support :)

(Well, Marcos didn't specify what Delphi version he wants to target but 
he stated "If Delphi sources don't use UTF8 [...]", which applies to 
pre-unicode Delphi versions.)


Ondrej
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)

2017-05-03 Thread Juha Manninen via Lazarus
Marcos Douglas B. Santos wrote:
> I am develop on Windows. What problems do you mean?

Unicode is recommended also on Windows. No worries. You don't need to
use the old system codepages.
People who need them must convert them explicitly because the Unicode
system of Lazarus does not support them directly.

> Sorry about that. I stopped using Delphi at version 7, that uses ANSI.
> I thought that Delphi nowadays was using UTF16.
> I will install Delphi Tokyo Starter and discover these things.

You confuse separate things now.
The encoding of their "String" is now UTF-16.
Source files are saved as UTF-8.

> But if I put theses constants as resourcestrings, it's Ok as Mattias
> told me, right?

I don't think it makes any difference. You can use the full Unicode in
both cases.

---
I am puzzled why there were so many misleading and confusing replies,
also from knowledgeable Lazarus developers.
Remember, the question was about making sources compatible with Delphi.
The person (Marcos Douglas) did not know details of how strings work
in Delphi and Lazarus.
Now we finally have a system that allows (more or less) compatible
code when using Unicode. Why was it not even mentioned by you guys?

For example:

Ondrej Pokorny wrote:
> Speaking from my experience, the only approach (not only the best one but
> the only one) is not to use characters above #255.

Nonsense. Full Unicode is supported.

Mattias Gaertner wrote:
> Option a) You can use English in sources and load all non ASCII
> constants via resourcestrings or similar. Then the codepage is
> irrelevant.
> Option b) You can store all files as UTF-8 with BOM. Then FPC will
> store all non ASCII string constants as unicodestrings. Be careful when
> using PChar with them. This adds implicit conversions, so it might be
> slower.

That must be very confusing. Why didn't you just tell him to use the
default Unicode support in Lazarus which allows to write Delphi
compatible code, just by remembering couple of rules.

Also Tony's advice to use AnsiString explicitly is quite irresponsible
for a person who looks for Delphi compatibility.
AnsiString is not Delphi compatible any more in our system and it
brings you back to stone-age in Delphi, to the horrors of system
codepages.

Is it possible that people still don't know how Delphi compatible the
Lazarus Unicode system is (unless you need the old system codepages
obviously)?
For example Lazarus developer Werner (wp) didn't know the Ansi...()
string functions, like AnsiCompareStr(), are compatible with Delphi.
 
http://forum.lazarus.freepascal.org/index.php/topic,36664.msg244619.html#msg244619
Yes they are!

Please also look at program LazUnicodeTest in components/lazutils/test/.
It does advanced Unicode stuff and works in both Delphi and Lazarus.
It means any code dealing with Unicode can do it.

How could this thing be communicated so that people understand?
Why other Lazarus developers don't want to mention it?
I am puzzled. :(

Juha
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)

2017-05-03 Thread Graeme Geldenhuys via Lazarus
On 2017-05-02 09:30, Juha Manninen via Lazarus wrote:
> From FPC's point of view our UTF-8 solution is a hack. 

FPC's point of view or Marco's point of view? Just curious - so what is
FPC’s “correct” solution then for using UTF-8 and the preferred
encoding? What's the alternative they offer?


[rant]
ps:
  Both FPC and Delphi is in such a messed up state when it comes to
  string and character types. It is the laughing stock of programming
  languages at the moment. At least EMBT is heading in the right
  direction with their Linux Delphi compiler - they completely removed
  AnsiString.

  FPC and Delphi can learn a huge lesson from Java and Qt in how to
  handle string and character types.
[/rant]

Regards,
  Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus