I recorded a very brief video of the performance of Raspberry Pi and Lazarus is quite usable.

Video here:

http://www.getlazarus.org/setup/raspberry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160323/f43c2ed3/attachment.html>

Anthony Walter wrote

I recorded a very brief video of the performance of Raspberry Pi and Lazarus is quite usable.

For a computer priced at ?22, that is incredible value for money! I still have the original RPi - maybe it's time for an upgrade. The work awesome as little micro-servers too. :)

Regards,
- Graeme -

Graeme Geldenhuys wrote

On 2016-03-23 04:56, Anthony Walter wrote:> I recorded a very brief video of the performance of Raspberry Pi and> Lazarus is quite usable. For a computer priced at ?22, that is incredible value for money! Istill have the original RPi - maybe it's time for an upgrade. The workawesome as little micro-servers too. :)

The RPi2 is superior in almost every way. I've got an RPi3 here but won't have time to exercise it for at least a few days.

The Raspberry Pi Zero can, I believe, be run as a USB slave (specifically, USB OTG can be enabled by a kernel patch). That opens the possibility of using it to implement special-purpose input peripherals: has anybody used FPC etc. to play with USB Gadget programming?

http://hackaday.com/2016/03/02/hack-a-ps2-keyboard-onto-your-pi-zero/ http://isticktoit.net/?p=1383

Mark Morgan Lloyd wrote

The RPi2 is superior in almost every way. I've got an RPi3 here but won't have time to exercise it for at least a few days.

My RPi 1 Model B (the original) is still ticking nicely even after so many years of usage. At one stage I used used it as a web server, then as a media player for over two years, running 24/7. Now I use it to test FPC+fpGUI builds for the ARM target.

From what I've read online, the RPi2 and RPi3 have way more memory and

processing speed than mine. So that should be a nice welcome as a lite desktop / development environment.

Regards,
- Graeme -

The RPi1 I've got here wasn't reliable, but it could have been a thermal runaway and I'm supposed to be testing it on a battery.

>From what I've read online, the RPi2 and RPi3 have way more memory and processing speed than mine. So that should be a nice welcome as a lite desktop / development environment.

If we continue this it would be better in -other, but I've got a spare 2 and 3 here and would quite like to explore xdmx as we've already discussed. Potentially, a cluster of those could replace my desktop systems: I think they're entirely adequate for development.

[]

The RPI-2 is superior to what?

Using the RPi-3 is a significantly more pleasant experience than the RPi-2, even just headless when compiling things. Highly recommended. I did have some minor issues with Jessie, with the serial port on the RPi-3, and with gpsd not suto-starting. I detailed those towards the end of this page:

http://www.satsignal.eu/ntp/Raspberry-Pi-quickstart.html

I've not had chance to try Lazarus, though.

But still no "official" 64 bit OS, yet :-(

-Michael

But with "only" 1 GB of memory, 64-bit may be no better than 32-bit. The hardware, though, is 64-bit with the advantages that brings in memory access speeds. I've seen nothing of the Raspberry Pi cards which I use which would benefit from a 64-bit version.

I do know that with X86 the memory efficiency with 64 is a lot worse than with X32 and might result in speed degradation due to worse cache usage. I have no knowledge if this is similar with aarch64.

-Michael

David Taylor wrote

I've not had chance to try Lazarus, though.

You might want to look at my installation script for installing FPC 3.0.0 and Lazarus 1.6 on a bare newly started RPi3 with Raspbian Jessie:
http://blog.boberglund.com/install_laz_pi.sh

Revisions to download are modified in the script configuration at the top. It needs a user response when it is running the install of the seed compiler, otherwise it is unattended.

Bo Berglund wrote

installing FPC 3.0.0 and Lazarus 1.6

A word of caution, there is a major bug in FPC 3.0 regarding floating point values (see the FPC mailing list), so I wouldn't recommend anybody upgrade to FPC 3.0 at this point - at least until 3.0.2 is out. This issue has been fixed in FPC Trunk already though.

Regards,
- Graeme -

Graeme Geldenhuys wrote

A word of caution, there is a major bug in FPC 3.0 regarding floating point values (see the FPC mailing list), so I wouldn't recommend anybody upgrade to FPC 3.0 at this point - at least until 3.0.2 is out. This issue has been fixed in FPC Trunk already though.

They say: "This happens only on Win64 with FPC 3.0 "

-Michael

No, it will also happen on 64-bit arm.

Michael.

Happens on all sorts of things, depending on what selection has been made for certain underlying types. /Specifically/ happens on an RPi2, as discussed in the bug report.

Or 32-bit on an RPi2 (Debian "Jessie" rather than Raspbian etc.).

Hi,

I'm thinking about the thread here
http://forum.lazarus.freepascal.org/index.php/topic,31939.msg206688.html#msg206688 where Bart wrote "... and adding explicit codepage identifiers to sourcecode that has string constants with characters that er not ASCII (or ad -FcUTF8 to your default compiler options to achieve the same) ..."

I think he is right.

Since Lazarus makes per default the switch to UTF-8 encoded strings, it would be good to hint the developer, that they use such encoded strings.

In the most cases the string magic works without a defined {$codepage utf8}, but not if you want to assign a const to a Predefined String or Unicodestring.

I add a project that demonstrate, that the assigning of strings with
{$codepage utf8} works better than without it.

I would prefer to set {$codepage utf8} per default, if a new unit/project is created. I like it more than the general switch -FcUTF8, cause each developer see the current codepage and you can use units with other codepages too (what in reality probably nobody would do).

I add a possible patch, how I think, it could be.

Offtopic: In the added project: Why is a const 'abc' with {$codepage UTF8} a Unicodestring (Windows7, 64bit, Lazarus 1.7 r52077M FPC 3.1.1 i386-win32-win32/win64 on FPC 3.1.1 r33371)?

Regards

Michl

-------------- next part --------------
Index: components/codetools/h2pastool.pas
=================================================================== --- components/codetools/h2pastool.pas (revision 52077) +++ components/codetools/h2pastool.pas (working copy) @@ -2370,6 +2370,7 @@

     W('unit '+SourceName+';');
     W('');
     W('{$mode objfpc}{$H+}');

+ W('{$codepage UTF8}');

     W('');
     W('interface');
     W('');

Index: components/fpcunit/ide/fpcunitlazideintf.pas =================================================================== --- components/fpcunit/ide/fpcunitlazideintf.pas (revision 52077) +++ components/fpcunit/ide/fpcunitlazideintf.pas (working copy) @@ -155,6 +155,7 @@

   NewSource:='program FPCUnitProject1;'+le
     +le
     +'{$mode objfpc}{$H+}'+le

+ +'{$codepage UTF8}'+le
+le
+'uses'+le
+' Interfaces, Forms, GuiTestRunner;'+le
@@ -224,6 +225,7 @@
'unit '+SourceName+';'+LE
+LE
+'{$mode objfpc}{$H+}'+LE
+ +'{$codepage UTF8}'+LE
+LE
+'interface'+LE
+LE
Index: components/fpcunit/ide/fpcunitproject1.inc
=================================================================== --- components/fpcunit/ide/fpcunitproject1.inc (revision 52077) +++ components/fpcunit/ide/fpcunitproject1.inc (working copy) @@ -2,6 +2,7 @@
'program FPCUnitProject1;' + sLineBreak
+ sLineBreak
+ '{$mode objfpc}{$H+}' + sLineBreak
+ + '{$codepage UTF8}' + sLineBreak
+ sLineBreak
+ 'uses' + sLineBreak
+ ' Classes, consoletestrunner;' + sLineBreak
Index: components/fpweb/weblazideintf.pp
=================================================================== --- components/fpweb/weblazideintf.pp (revision 52077) +++ components/fpweb/weblazideintf.pp (working copy) @@ -386,6 +386,7 @@

   NewSource:='program cgiproject1;'+le
     +le
     +'{$mode objfpc}{$H+}'+le

+ +'{$codepage UTF8}'+le
+le
+'uses'+le
+' fpCGI;'+le
@@ -452,6 +453,7 @@

   NewSource:='program cgiproject1;'+le
     +le
     +'{$mode objfpc}{$H+}'+le

+ +'{$codepage UTF8}'+le
+le
+'uses'+le
+' Classes, SysUtils, httpDefs, fpweb,'
@@ -615,6 +617,7 @@

   NewSource:='Library mod_apache1;'+le
     +le
     +'{$mode objfpc}{$H+}'+le

+ +'{$codepage UTF8}'+le
+le
+'Uses'+le
+'{$ifdef unix}'+le
@@ -707,6 +710,7 @@

   NewSource:='program fcgiproject1;'+le
     +le
     +'{$mode objfpc}{$H+}'+le

+ +'{$codepage UTF8}'+le
+le
+'uses'+le
+' Classes,SysUtils,httpDefs,custfcgi;'+le
@@ -790,6 +794,7 @@

   NewSource:='program fcgiproject1;'+le
     +le
     +'{$mode objfpc}{$H+}'+le

+ +'{$codepage UTF8}'+le
+le
+'uses'+le
+' fpFCGI;'+le
@@ -888,6 +893,7 @@

   NewSource:='program httpproject1;'+le
     +le
     +'{$mode objfpc}{$H+}'+le

+ +'{$codepage UTF8}'+le
+le

     +'uses'+le;
   if FReg then

Index: components/ideintf/projectintf.pas
=================================================================== --- components/ideintf/projectintf.pas (revision 52077) +++ components/ideintf/projectintf.pas (working copy) @@ -948,7 +948,8 @@

 function TFileDescPascalUnit.GetUnitDirectives: string;
 begin
-  Result:='{$mode objfpc}{$H+}';
+  Result:='{$mode objfpc}{$H+}'+LineEnding
+    +'{$codepage utf8}';
   if Owner is TLazProject then
     Result:=CompilerOptionsToUnitDirectives(Owner.LazCompilerOptions);
 end;
@@ -985,7 +986,7 @@
 var
   SyntaxMode: String;
 begin
-  Result:='{$mode objfpc}{$H+}';
+  Result:='{$mode objfpc}{$H+}'+LineEnding+'{$codepage UTF8}';
   if CompOpts=nil then exit;
   SyntaxMode:=CompOpts.SyntaxMode;
   if SyntaxMode'' then begin
@@ -992,7 +993,7 @@
     Result:='{$mode '+lowercase(SyntaxMode)+'}';
     if CompOpts.UseAnsiStrings
     and (SysUtils.CompareText(SyntaxMode,'Delphi')0) then
-      Result:=Result+'{$H+}';
+      Result:=Result+'{$H+}'+LineEnding+'{$codepage UTF8}';
   end;
 end;

Index: components/instantfpc/instantfpcregisterlaz.pas =================================================================== --- components/instantfpc/instantfpcregisterlaz.pas (revision 52077) +++ components/instantfpc/instantfpcregisterlaz.pas (working copy) @@ -97,6 +97,7 @@

   NewSource:=TStringList.Create;
   NewSource.Add('#!/usr/bin/env instantfpc');
   NewSource.Add('{$mode objfpc}{$H+}');

+ NewSource.Add('{$codepage UTF8}');

   NewSource.Add('uses');
   NewSource.Add('  Classes, SysUtils;');
   NewSource.Add('');

@@ -144,6 +145,7 @@
begin

   Result:='#!/usr/bin/instantfpc'+LineEnding
     +'{$mode objfpc}{$H+}'+LineEnding

+ +'{$codepage UTF8}'+LineEnding
+LineEnding
+'uses Classes, SysUtils;'+LineEnding
+LineEnding
Index: components/synedit/test/testmarkupifdef.pas =================================================================== --- components/synedit/test/testmarkupifdef.pas (revision 52077) +++ components/synedit/test/testmarkupifdef.pas (working copy) @@ -772,6 +772,7 @@

   AddLine('program project1;');
   AddLine('');
   AddLine('{$mode objfpc}{$H+}');

+ AddLine('{$codepage UTF8}');

   AddLine('');
   // 5
   AddLine('uses {$IFDEF UNIX} {$IFDEF UseCThreads}');

Index: examples/synedit1.pas
=================================================================== --- examples/synedit1.pas (revision 52077)
+++ examples/synedit1.pas (working copy)
@@ -58,6 +58,7 @@
'program synedit1;'+e+
''+e+
'{$mode objfpc}{$H+}'+e+
+ '{$codepage UTF8}'+e+
''+e+
'uses'+e+
' Interfaces, Classes, SysUtils, Forms, Controls, GraphType, Graphics, SynEdit,'+e+ Index: ide/projectdefs.pas
=================================================================== --- ide/projectdefs.pas (revision 52077)
+++ ide/projectdefs.pas (working copy)
@@ -1279,6 +1279,7 @@

   NewSource:='program Project1;'+LineEnding
     +LineEnding
     +'{$mode objfpc}{$H+}'+LineEnding

+ +'{$codepage UTF8}'+LineEnding
+LineEnding
+'uses'+LineEnding
+' {$IFDEF UNIX}{$IFDEF UseCThreads}'+LineEnding
@@ -1396,6 +1397,7 @@

   NewSource:='program Project1;'+LineEnding
     +LineEnding
     +'{$mode objfpc}{$H+}'+LineEnding

+ +'{$codepage UTF8}'+LineEnding
+LineEnding
+'uses'+LineEnding
+' {$IFDEF UNIX}{$IFDEF UseCThreads}'+LineEnding
@@ -1461,6 +1463,7 @@

     NewSource:='program Project1;'+LineEnding
       +LineEnding
       +'{$mode objfpc}{$H+}'+LineEnding

+ +'{$codepage UTF8}'+LineEnding
+LineEnding
+'uses'+LineEnding
+' Classes, SysUtils'+LineEnding
@@ -1553,6 +1556,7 @@

   NewSource.Add('program Project1;');
   NewSource.Add('');
   NewSource.Add('{$mode objfpc}{$H+}');

+ NewSource.Add('{$codepage UTF8}');

   NewSource.Add('');
   NewSource.Add('uses');
   NewSource.Add('  {$IFDEF UNIX}{$IFDEF UseCThreads}');

@@ -1699,6 +1703,7 @@

   NewSource:='library Project1;'+LineEnding
     +LineEnding
     +'{$mode objfpc}{$H+}'+LineEnding

+ +'{$codepage UTF8}'+LineEnding
+LineEnding
+'uses'+LineEnding
+' Classes'+LineEnding
Index: packager/oldcustomcompdlg.pas
=================================================================== --- packager/oldcustomcompdlg.pas (revision 52077) +++ packager/oldcustomcompdlg.pas (working copy)
@@ -348,6 +348,7 @@

     Add('unit CustomIDEComps;');
     Add('');
     Add('{$mode objfpc}{$H+}');

+ Add('{$codepage UTF8}');

     Add('');
     Add('interface');
     Add('');

Index: packager/pkgmanager.pas
=================================================================== --- packager/pkgmanager.pas (revision 52077)
+++ packager/pkgmanager.pas (working copy)
@@ -787,7 +787,7 @@
if (System.Pos(Params.UsedUnitname,UsesLine)<1)
and (Params.UsedUnitname'') then

     UsesLine:=UsesLine+', '+Params.UsedUnitname;

- UnitDirectives:='{$mode objfpc}{$H+}';
+ UnitDirectives:='{$mode objfpc}{$H+}'+LE+'{$codepage UTF8}';

   if Params.Pkgnil then
     UnitDirectives:=TFileDescPascalUnit.CompilerOptionsToUnitDirectives(
                                                     Params.Pkg.CompilerOptions);

-------------- next part --------------
A non-text attachment was scrubbed...
Name: StringAssignTest.zip
Type: application/x-zip-compressed
Size: 7364 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160329/a5941647/attachment.bin>

Sorry, my reply enters the wrong place.

Hi again (hopefully the right place now),

I'm thinking about the thread here
http://forum.lazarus.freepascal.org/index.php/topic,31939.msg206688.html#msg206688 where Bart wrote "... and adding explicit codepage identifiers to sourcecode that has string constants with characters that er not ASCII (or ad -FcUTF8 to your default compiler options to achieve the same) ..."

I think he is right.

Since Lazarus makes per default the switch to UTF-8 encoded strings, it would be good to hint the developer, that they use such encoded strings.

In the most cases the string magic works without a defined {$codepage utf8}, but not if you want to assign a const to a Predefined String or Unicodestring.

I add a project that demonstrate, that the assigning of strings with
{$codepage utf8} works better than without it.

I would prefer to set {$codepage utf8} per default, if a new unit/project is created. I like it more than the general switch -FcUTF8, cause each developer see the current codepage and you can use units with other codepages too (what in reality probably nobody would do).

I add a possible patch, how I think, it could be.

Offtopic: In the added project: Why is a const 'abc' with {$codepage UTF8} a Unicodestring (Windows7, 64bit, Lazarus 1.7 r52077M FPC 3.1.1 i386-win32-win32/win64 on FPC 3.1.1 r33371)?

Regards

Michl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160329/9e7f1115/attachment-0001.html> -------------- next part --------------
Index: components/codetools/h2pastool.pas
=================================================================== --- components/codetools/h2pastool.pas (revision 52077) +++ components/codetools/h2pastool.pas (working copy) @@ -2370,6 +2370,7 @@

     W('unit '+SourceName+';');
     W('');
     W('{$mode objfpc}{$H+}');

+ W('{$codepage UTF8}');

     W('');
     W('interface');
     W('');

Index: components/fpcunit/ide/fpcunitlazideintf.pas =================================================================== --- components/fpcunit/ide/fpcunitlazideintf.pas (revision 52077) +++ components/fpcunit/ide/fpcunitlazideintf.pas (working copy) @@ -155,6 +155,7 @@

   NewSource:='program FPCUnitProject1;'+le
     +le
     +'{$mode objfpc}{$H+}'+le

+ +'{$codepage UTF8}'+le
+le
+'uses'+le
+' Interfaces, Forms, GuiTestRunner;'+le
@@ -224,6 +225,7 @@
'unit '+SourceName+';'+LE
+LE
+'{$mode objfpc}{$H+}'+LE
+ +'{$codepage UTF8}'+LE
+LE
+'interface'+LE
+LE
Index: components/fpcunit/ide/fpcunitproject1.inc
=================================================================== --- components/fpcunit/ide/fpcunitproject1.inc (revision 52077) +++ components/fpcunit/ide/fpcunitproject1.inc (working copy) @@ -2,6 +2,7 @@
'program FPCUnitProject1;' + sLineBreak
+ sLineBreak
+ '{$mode objfpc}{$H+}' + sLineBreak
+ + '{$codepage UTF8}' + sLineBreak
+ sLineBreak
+ 'uses' + sLineBreak
+ ' Classes, consoletestrunner;' + sLineBreak
Index: components/fpweb/weblazideintf.pp
=================================================================== --- components/fpweb/weblazideintf.pp (revision 52077) +++ components/fpweb/weblazideintf.pp (working copy) @@ -386,6 +386,7 @@

   NewSource:='program cgiproject1;'+le
     +le
     +'{$mode objfpc}{$H+}'+le

+ +'{$codepage UTF8}'+le
+le
+'uses'+le
+' fpCGI;'+le
@@ -452,6 +453,7 @@

   NewSource:='program cgiproject1;'+le
     +le
     +'{$mode objfpc}{$H+}'+le

+ +'{$codepage UTF8}'+le
+le
+'uses'+le
+' Classes, SysUtils, httpDefs, fpweb,'
@@ -615,6 +617,7 @@

   NewSource:='Library mod_apache1;'+le
     +le
     +'{$mode objfpc}{$H+}'+le

+ +'{$codepage UTF8}'+le
+le
+'Uses'+le
+'{$ifdef unix}'+le
@@ -707,6 +710,7 @@

   NewSource:='program fcgiproject1;'+le
     +le
     +'{$mode objfpc}{$H+}'+le

+ +'{$codepage UTF8}'+le
+le
+'uses'+le
+' Classes,SysUtils,httpDefs,custfcgi;'+le
@@ -790,6 +794,7 @@

   NewSource:='program fcgiproject1;'+le
     +le
     +'{$mode objfpc}{$H+}'+le

+ +'{$codepage UTF8}'+le
+le
+'uses'+le
+' fpFCGI;'+le
@@ -888,6 +893,7 @@

   NewSource:='program httpproject1;'+le
     +le
     +'{$mode objfpc}{$H+}'+le

+ +'{$codepage UTF8}'+le
+le

     +'uses'+le;
   if FReg then

Index: components/ideintf/projectintf.pas
=================================================================== --- components/ideintf/projectintf.pas (revision 52077) +++ components/ideintf/projectintf.pas (working copy) @@ -948,7 +948,8 @@

 function TFileDescPascalUnit.GetUnitDirectives: string;
 begin
-  Result:='{$mode objfpc}{$H+}';
+  Result:='{$mode objfpc}{$H+}'+LineEnding
+    +'{$codepage utf8}';
   if Owner is TLazProject then
     Result:=CompilerOptionsToUnitDirectives(Owner.LazCompilerOptions);
 end;
@@ -985,7 +986,7 @@
 var
   SyntaxMode: String;
 begin
-  Result:='{$mode objfpc}{$H+}';
+  Result:='{$mode objfpc}{$H+}'+LineEnding+'{$codepage UTF8}';
   if CompOpts=nil then exit;
   SyntaxMode:=CompOpts.SyntaxMode;
   if SyntaxMode'' then begin
@@ -992,7 +993,7 @@
     Result:='{$mode '+lowercase(SyntaxMode)+'}';
     if CompOpts.UseAnsiStrings
     and (SysUtils.CompareText(SyntaxMode,'Delphi')0) then
-      Result:=Result+'{$H+}';
+      Result:=Result+'{$H+}'+LineEnding+'{$codepage UTF8}';
   end;
 end;

Index: components/instantfpc/instantfpcregisterlaz.pas =================================================================== --- components/instantfpc/instantfpcregisterlaz.pas (revision 52077) +++ components/instantfpc/instantfpcregisterlaz.pas (working copy) @@ -97,6 +97,7 @@

   NewSource:=TStringList.Create;
   NewSource.Add('#!/usr/bin/env instantfpc');
   NewSource.Add('{$mode objfpc}{$H+}');

+ NewSource.Add('{$codepage UTF8}');

   NewSource.Add('uses');
   NewSource.Add('  Classes, SysUtils;');
   NewSource.Add('');

@@ -144,6 +145,7 @@
begin

   Result:='#!/usr/bin/instantfpc'+LineEnding
     +'{$mode objfpc}{$H+}'+LineEnding

+ +'{$codepage UTF8}'+LineEnding
+LineEnding
+'uses Classes, SysUtils;'+LineEnding
+LineEnding
Index: components/synedit/test/testmarkupifdef.pas =================================================================== --- components/synedit/test/testmarkupifdef.pas (revision 52077) +++ components/synedit/test/testmarkupifdef.pas (working copy) @@ -772,6 +772,7 @@

   AddLine('program project1;');
   AddLine('');
   AddLine('{$mode objfpc}{$H+}');

+ AddLine('{$codepage UTF8}');

   AddLine('');
   // 5
   AddLine('uses {$IFDEF UNIX} {$IFDEF UseCThreads}');

Index: examples/synedit1.pas
=================================================================== --- examples/synedit1.pas (revision 52077)
+++ examples/synedit1.pas (working copy)
@@ -58,6 +58,7 @@
'program synedit1;'+e+
''+e+
'{$mode objfpc}{$H+}'+e+
+ '{$codepage UTF8}'+e+
''+e+
'uses'+e+
' Interfaces, Classes, SysUtils, Forms, Controls, GraphType, Graphics, SynEdit,'+e+ Index: ide/projectdefs.pas
=================================================================== --- ide/projectdefs.pas (revision 52077)
+++ ide/projectdefs.pas (working copy)
@@ -1279,6 +1279,7 @@

   NewSource:='program Project1;'+LineEnding
     +LineEnding
     +'{$mode objfpc}{$H+}'+LineEnding

+ +'{$codepage UTF8}'+LineEnding
+LineEnding
+'uses'+LineEnding
+' {$IFDEF UNIX}{$IFDEF UseCThreads}'+LineEnding
@@ -1396,6 +1397,7 @@

   NewSource:='program Project1;'+LineEnding
     +LineEnding
     +'{$mode objfpc}{$H+}'+LineEnding

+ +'{$codepage UTF8}'+LineEnding
+LineEnding
+'uses'+LineEnding
+' {$IFDEF UNIX}{$IFDEF UseCThreads}'+LineEnding
@@ -1461,6 +1463,7 @@

     NewSource:='program Project1;'+LineEnding
       +LineEnding
       +'{$mode objfpc}{$H+}'+LineEnding

+ +'{$codepage UTF8}'+LineEnding
+LineEnding
+'uses'+LineEnding
+' Classes, SysUtils'+LineEnding
@@ -1553,6 +1556,7 @@

   NewSource.Add('program Project1;');
   NewSource.Add('');
   NewSource.Add('{$mode objfpc}{$H+}');

+ NewSource.Add('{$codepage UTF8}');

   NewSource.Add('');
   NewSource.Add('uses');
   NewSource.Add('  {$IFDEF UNIX}{$IFDEF UseCThreads}');

@@ -1699,6 +1703,7 @@

   NewSource:='library Project1;'+LineEnding
     +LineEnding
     +'{$mode objfpc}{$H+}'+LineEnding

+ +'{$codepage UTF8}'+LineEnding
+LineEnding
+'uses'+LineEnding
+' Classes'+LineEnding
Index: packager/oldcustomcompdlg.pas
=================================================================== --- packager/oldcustomcompdlg.pas (revision 52077) +++ packager/oldcustomcompdlg.pas (working copy)
@@ -348,6 +348,7 @@

     Add('unit CustomIDEComps;');
     Add('');
     Add('{$mode objfpc}{$H+}');

+ Add('{$codepage UTF8}');

     Add('');
     Add('interface');
     Add('');

Index: packager/pkgmanager.pas
=================================================================== --- packager/pkgmanager.pas (revision 52077)
+++ packager/pkgmanager.pas (working copy)
@@ -787,7 +787,7 @@
if (System.Pos(Params.UsedUnitname,UsesLine)<1)
and (Params.UsedUnitname'') then

     UsesLine:=UsesLine+', '+Params.UsedUnitname;

- UnitDirectives:='{$mode objfpc}{$H+}';
+ UnitDirectives:='{$mode objfpc}{$H+}'+LE+'{$codepage UTF8}';

   if Params.Pkgnil then
     UnitDirectives:=TFileDescPascalUnit.CompilerOptionsToUnitDirectives(
                                                     Params.Pkg.CompilerOptions);

-------------- next part --------------
A non-text attachment was scrubbed...
Name: StringAssignTest.zip
Type: application/x-zip-compressed
Size: 7364 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160329/9e7f1115/attachment-0001.bin>

You have to distinguish between with CP_UTF8 as default and with CP_ACP as default.
Both have cases where some string combinations fail.

LCL applications nowadays use CP_UTF8 as default. We (laz team) tested adding -FcUTF8 and it failed in too many cases. Also it adds some overhead. So we decided to *not* add it by default.

Offtopic: In the added project: Why is a const 'abc' with {$codepage UTF8} a Unicodestring (Windows7, 64bit, Lazarus 1.7 r52077M FPC 3.1.1 i386-win32-win32/win64 on FPC 3.1.1 r33371)?

There is no compile-time flag to tell the compiler what codepage the system is it assumes current Windows codepage. Any string literal not in this codepage is stored as UTF-16.

Mattias

No, originally we had -FcUTF8 set by default but it caused more problems. See:
http://forum.lazarus.freepascal.org/index.php?topic=30022

In the most cases the string magic works without a defined {$codepage utf8}, but not if you want to assign a const to a Predefined String or Unicodestring.

I don't know what is a a Predefined String but assigning a const to Unicodestring can be seen as a special case and then a programmer can take special actions (add {$codepage utf8} himself).

Leaving out {$codepage utf8} is the most backwards compatible way, and the operation is most intuitive.
With Unicodestring we don't need to care about backwards compatibility really because it is so new type.
What more, Unicodestring is not needed often when using our new Unicode system.

Juha

Juha Manninen wrote

With Unicodestring we don't need to care about backwards compatibility really because it is so new type.

Ouch!

WideString has been introduced in Delphi 4 IIRC, FPC had an on all platforms reference counted 16-bit string which worked like current UnicodeString. IIRC it was about version 1.8 when FPC introduced this string type. Kylix WideString (Linux) also was reference counted. Later FPC changed WideString on Windows ( against my strong opposition, well-understood ;-) ) to the not reference counted OLE-string. A little bit later FPC added the on all platforms reference counted UnicodeString again.
So one can say that at the moment when Lazarus became Unicode capable there was a UnicodeString-like stringtype available in FPC. It was very buggy, so probably this was one of the reasons that Lazarus used utf-8 in AnsiString instead.
For MSEgui on the other hand I used WideString/UnicodeString from beginning and wrote FPC bug-reports until FPC WideString became production ready.

What more, Unicodestring is not needed often when using our new Unicode system.

If one wants to handle BMP-chars comfortably and with good performance one has to convert from utf-8 in AnsiString to UnicodeString first.

Martin

Ok, FPC had UnicodeString earlier than I remembered. Currently WideString is often used with WinAPI when UnicodeString should be used, as Marco reminded in another discussion.

Anyway, the problems found by Michael W. Vogel and "malcome" all deal with constants. Assignment between variables always works thanks of their dynamic encoding.
If there is doubt about how a constant is interpreted, it can be first assigned to a "String" type variable which can then be typecasted to a WinAPI's UnicodeString parameter or whatever.
In the worst case scenario an extra "String" variable is needed. Or, if one wants to use UnicodeString constants in a unit, he can add {$codepage utf8}. No big deal.
IMO the problems are exaggerated.

Martin Schreiber wrote

If one wants to handle BMP-chars comfortably and with good performance one has to convert from utf-8 in AnsiString to UnicodeString first.

Maybe, but BMP-chars are not enough for a proper Unicode support. Besides, dealing with codepoints is the easy part regardless of encoding. The associated problems are exaggerated again. The true complexity of Unicode is beyond codepoints.

Juha

Juha Manninen wrote

> If one wants to handle BMP-chars comfortably and with good performance > one has to convert from utf-8 in AnsiString to UnicodeString first. Maybe, but BMP-chars are not enough for a proper Unicode support.

But they are enough to be used in Russian and German pupils homework, utf-8 code units are not enough, please read lazarusformum.de. ;-)

Martin

Mattias Gaertner wrote

You have to distinguish between with CP_UTF8 as default and with CP_ACP as default.

Yes, I know it. What I mean with default:

Go to Project -> New Project ... -> Application

Now a new Application is created. With the added patch {$codepage UTF8} is added and thats right, cause if you save the file to anywhere it is UTF-8 encoded. There is nothing wrong.

Mattias Gaertner wrote

Both have cases where some string combinations fail.

With the hack that the LCL makes and the added {$codepage UTF8} all conversions work like a charm (see added testproject).

If you want to use -dDisableUTF8RTL, you have to know, what you do.
- remove {$codepage UTF8}, better set it to the valid codepage or use -FcCP...
- save all the source files with the wanted encoding/codepage

So IMHO this special case wouldn't be used much. All the puzzled discussions I can see in the forums are about the default applications created with Lazarus (not FPC), that uses the LCL.

Mattias Gaertner wrote

LCL applications nowadays use CP_UTF8 as default. We (laz team) tested adding -FcUTF8 and it failed in too many cases. Also it adds some overhead. So we decided to *not* add it by default.

I also don't want it. I want a added {$codepage UTF8}, if the file is saved as a UTF-8 encoded one.

Thanks for that hint!

Juha Manninen wrote

I don't know what is a a Predefined String

Sorry, I was not clear. I mean a string with a declared codepage http://wiki.freepascal.org/FPC_Unicode_support#Declared_code_page

Mattias Gaertner wrote

LCL applications nowadays use CP_UTF8 as default. We (laz team) tested adding -FcUTF8 and it failed in too many cases. Also it adds some overhead. So we decided to *not* add it by default.

The IDE at least runs fine (in my locale on Windows) with -FcUTF8. (I have it there because I build all my projects with this define, because almost all of them contain some strings with diacritics)

I'm too lazy just yet to insert proper codepage defines in the relevant places.

Curious though: in what scenario's does it fail?

Bart

Michael W. Vogel wrote

With the hack that the LCL makes and the added {$codepage UTF8} all conversions work like a charm (see added testproject).

Conversions in your testproject may work, but you ignored the forum link I gave earlier. There "malcome" gave examples that fail. BTW, the hack is not made by LCL but by LazUtils which can be used also with cmd line / server programs.

The cases fail with UTF-8 file encoding.
All files created by Lazarus IDE are by default saved with UTF-8 encoding, thus you would get {$codepage UTF8} in every file which is the same as -FcUTF8 for the whole project.
Adding -FcUTF8 is already extremely easy. There is a button for it in Project Options -> Custom Options page.

The issue with constant string encodings is more complex than you seem to understand.
It is explained here somehow:
http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus#String_Literals

Juha

Bart wrote

The IDE at least runs fine (in my locale on Windows) with -FcUTF8.

Lazarus IDE does not have string constants beyond 7-bit ASCII. Encoding does not matter obviously.

(I have it there because I build all my projects with this define, because almost all of them contain some strings with diacritics)

Do your files have UTF-8 encoding? It is a necessity for the Unicode system to work.
Any valid UTF-8 string should work, including diacritics.

Curious though: in what scenario's does it fail?

See the forum link I gave earlier.

Juha

Juha Manninen wrote

Conversions in your testproject may work, but you ignored the forum link I gave earlier. There "malcome" gave examples that fail.

I don't ignored it, but I'm not so fast to test the examples there. I'll try the examples there for myself with and without the codepage definition. Thanks for that link.

Juha Manninen wrote

BTW, the hack is not made by LCL but by LazUtils which can be used also with cmd line / server programs.

You are right. I only use LazUtils in combination with the component library, my mistake. Thanks for clearing this.

Juha Manninen wrote

> I also don't want it. I want a added {$codepage UTF8}, if the file is > saved as a UTF-8 encoded one. The cases fail with UTF-8 file encoding.

I don't understand this.

Juha Manninen wrote

The issue with constant string encodings is more complex than you seem to understand.

Thats true and I've made dozens of tests and spend a lot of time and try to help other people with it ...

Juha Manninen wrote

It is explained here somehow: http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus#String_Literals

And the first example there is wrong (or the words "and without" need to be removed). With no defined codepage
const s: string = '???';
has codepoints of a UTF-8 String, the codepage is 0. If you assign it to a string with a declared codepage, you get a corrupted string. See my example.

BTW I've forgotten ShortStrings in my example and maybe PChar. I'll add it (if possible) and try and report later.

Thanks for your attention and time

Kindly regards

Michl

"Juha Manninen" wrote

Ok, FPC had UnicodeString earlier than I remembered. Currently WideString is often used with WinAPI when UnicodeString should be used, as Marco reminded in another discussion.

The WinAPI does not know UnicodeString. It only knows PWideChar or B_STR for COM which is in Pascal handled by WideString.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160330/eb3bb92e/attachment.html>

Michael W. Vogel wrote

> The cases fail with UTF-8 file encoding. I don't understand this.

I meant that some cases fail even when the file encoding is UTF-8. File encoding is not the issue.

I editor the page and separated 2 cases:
  const s = '???';
and
  const s: string = '???';

Please check. In a forum discussion it turned out they behave differently. It may even be a compiler bug.
I cannot test it right now. Could you please edit the page as needed. Anyway, how often do you need to assign a constant to a string that has an explicitly declared codepage?

Juha

Juha Manninen wrote

Do your files have UTF-8 encoding? It is a necessity for the Unicode system to work.

Yes, all my code is either from Lazarus or from my own editor (which is a synedit).

Any valid UTF-8 string should work, including diacritics.

Without the codepage identier?

Quote from http://wiki.freepascal.org/FPC_Unicode_support#String_constants: "Normally, a string constant is interpreted according to the source file codepage. If the source file codepage is CP_ACP, a default is used instead: in that case, during conversions the constant strings are assumed to have code page 28591 (ISO 8859-1 Latin 1; Western European). "
...
"From the above it follows that to ensure predictable interpretation of string constants in your source code, it is best to either include an explicit {$codepage xxx} directive (or use the equivalent -Fc command line option), or to save the source code in UTF-8 with a BOM. "

AFAIK the IDE does not save the file with a BOM, so the compiler may very well decide that my sourcefile has ACP codepage?

Consider this test sourcefile (encoded as UTF8 without BOM):

const
  TestUtf8 = '?A?';
begin
  writeln('DefaultSystemcodePage = ',DefaultSystemcodePage);
  writeln('TestUtf8 = ',StrToHex(TestUtf8));
  s1 := TestUtf8;
  writeln('S1       = ',StrToHex(S1),' [',StringCodePage(S1),']');
  writeln(S1); //will trigger outmatic codepage conversion to
console's codepage when needed
end.

Without {$codepage utf8} it outputs:
DefaultSystemcodePage = 1252
TestUtf8 = $C3 $84 $41 $C3 $84
S1 = $C3 $84 $41 $C3 $84 [0]
?"A?"

The compiler treats my source as if it were written in my system's codepage. With cp1552 S1 now contains garbage (?"A?"). (at least not what I expected it to be)

With the proper {$codepage utf8} inserted it will output: DefaultSystemcodePage = 1252
TestUtf8 = $C3 $84 $41 $C3 $84
S1 = $C3 $84 $41 $C3 $84 [65001]
?A?

I would say that this experiment contradicts the statement in http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus#String_Literals ?

Bart

Bart wrote

[...] I would say that this experiment contradicts the statement in http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus#String_Literals ?

If your "s1" is a plain String then something has changed. IIRC it worked well. I am out of energy for the string encoding issue and I don't even have a proper Windows system to test with.
Could maybe Mattias, you, Michl and whoever take care of the issue please.

Juha

Just thought I would let you know that with or without the {$codepage utf8}, your code works just fine here. Source code is saved in a UTF-8 encoding with no BOM marker.

======================================================== [tmp]$ fpc test.pas
Free Pascal Compiler version 3.0.0 [2015/11/16] for x86_64 Copyright (c) 1993-2015 by Florian Klaempfl and others

[tmp]$ ./test
DefaultSystemcodePage = 0
TestUtf8 = C38441C384
S1 = C38441C384 [0]
?A?

[.... adding $codepage and testing again.....]

[tmp]$ fpc test.pas
Free Pascal Compiler version 3.0.0 [2015/11/16] for x86_64 Copyright (c) 1993-2015 by Florian Klaempfl and others

[tmp]$ ./test
DefaultSystemcodePage = 0
TestUtf8 = C38441C384
S1 = C38441C384 [65001]
?A?
========================================================

Regards,
- Graeme -

I've tested the example too and I got different results with different options. The test was:
- BOM / no BOM at the beginning of the sourcefile
- {$codepage UTF8} or not
- fpc -MObjFPC *-Sh* test.pas (with / without -Sh (use reference counted strings))

The results:

with BOM / with defined codepage / no -Sh,
no BOM / with defined codepage / no -Sh,
no BOM / no defined codepage / no -Sh:

DefaultSystemcodePage = 1252
TestUtf8 = C3 84 41 C3 84
S1 = C4 41 C4 [1252]
?A?

with BOM / with defined codepage / with -Sh,
no BOM / with defined codepage / with -Sh,
no BOM / no defined codepage / with -Sh:

DefaultSystemcodePage = 1252
TestUtf8 = C3 84 41 C3 84
S1 = C3 84 41 C3 84 [65001]
?A?

with BOM / no defined codepage / with -Sh:

DefaultSystemcodePage = 1252
TestUtf8 = C3 84 41 C3 84
S1 = C3 84 41 C3 84 [0]
?"A?"

with BOM / no defined codepage / no -Sh:

DefaultSystemcodePage = 1252
TestUtf8 = C3 84 41 C3 84
S1 = C3 84 41 C3 84 [1252]
??A??

So it is realy more complex as I thought...

As a r?sum? I would say a UTF-8 encoded file with a BOM and not setted
{$codepage UTF8} is a showkiller here (Windows7, FPC 3.1.1, Lazarus 1.7).

If somebody is interested, the testfiles/-results are added.

Regards

Michl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160331/0e983fa2/attachment.html> -------------- next part --------------
A non-text attachment was scrubbed...
Name: testfiles.zip
Type: application/x-zip-compressed
Size: 3808 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160331/0e983fa2/attachment.bin>

Juha Manninen wrote

If your "s1" is a plain String then something has changed. IIRC it worked well.

It is a plain string.
And it behaves like the quote said.
The compiler treats my sourcefile as ACP

I am out of energy for the string encoding issue and I don't even have a proper Windows system to test with. Could maybe Mattias, you, Michl and whoever take care of the issue please.

I think the statement in the wiki that {$codepage utf8} is not needed is wrong.

Bart

DefaultSystemCodePage = 0?

What system are you on (Linux, Windows) and what locale? I'm on Windows with Dutch locale (Windows codepage = cp1252)

Bart

Bart wrote

DefaultSystemCodePage = 0? What system are you on (Linux, Windows) and what locale?

64-bit FreeBSD 10.1 with English (UK) locale. I also used FPC 3.0.0 released compiler installed from the official .tar file.

[~]$ echo $LANG
en_GB.UTF-8

My test program is attached. Compiled with: fpc test.pas

Regards,
- Graeme -

Graeme Geldenhuys wrote

[~]$ echo $LANG en_GB.UTF-8

This is what I hink is happening to your test (Sven can probably explain it better):

Since your locale is UTF8, CP_ACPand CP_UTF8 refer to the same codepage, therefor the contents of S1 in either case is correct.

Without the codepage identifiier on Windows, after the assignement S1 contains a UTF8 byte-sequence, but the compiler treats it as CP_ACP, and therefor on my system as codepage 1252, and now the string has a completely different meaning.

Bart

31.03.2016 1:48, Bart ?????:

Lazarus switches DefaultSystemCodePage to 65001, so your example works OK here without codepage directive (when inserted into LCL dependent project, of course).

Maxim Ganetsky wrote

Lazarus switches DefaultSystemCodePage to 65001, so your example works OK here without codepage directive (when inserted into LCL dependent project, of course).

To me it is unclear wether "your example" refers to Graeme or to me. Either way both of us simply used a plain fpc console application, compiled on commandline with fpc.

I was wondering why DefaultSystemCodepage would return CP_ACP on Graemes FreeBsd with an UTF8 locale?

Bart

Jonas would probably be a better choice. Or the wiki page where the changes are documented (don't know it right now, but Jonas refers to it rather often :) )

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160331/ab9bffd5/attachment.html>

On 3/30/16, Juha Manninen wrote: [...] I think the statement in the wiki that {$codepage utf8} is not needed is wrong.

You can use UTF-8 without the {$codepage utf8}. But there are cases where it is needed. Maybe the wording can be improved.

Mattias

[...] I was wondering why DefaultSystemCodepage would return CP_ACP on Graemes FreeBsd with an UTF8 locale?

The problem only exists on Windows (more exact: OS with system codepageCP_UTF8).

Mattias

The compiler understands -FcUTF8, {$codepage utf8} and BOM. All three sets UTF-8. See here:
http://wiki.freepascal.org/FPC_Unicode_support#Source_file_codepage

BOM has the advantage that it is understood by other text editors as well and the disadvantage that it is hidden, so that people unaware of encodings are easily confused.

-FcUTF8 has the advantage of applying it to all sources in the project/package and it can easily be turned off. You can unset it for a single unit via {$modeswitch systemcodepage}.

- fpc -MObjFPC *-Sh* test.pas (with / without -Sh (use reference counted strings))

And this is where the confusion starts. Mixing multiple string types is asking for troubles. FPC has an impressive (aka frightening) list of string types and consequently a vast net of combinations that only graph theorists can appreciate.

So it is realy more complex as I thought...

Yes.
And you have not yet explored the difficulties in code supporting both FPC 2.6.4 and 3+ and LCL 1.4 and 1.6.

Although Lazarus recommends to "simply" use UTF-8, technically it recommends AnsiString, DefaultSystemCodepage CP_UTF8, no explicit codepage, and the UTF-8 functions in LazUtils. If you need to use other string types in an unit you might want to add an explicit codepage. Maybe a paragraph should be added to the wiki about using non AnsiString with the "Lazarus UTF-8".

Mattias

[...] > Any valid UTF-8 string should work, including diacritics. Without the codepage identier?

Yes, if you use LazUTF8.
If you don't use LazUTF8 and assign a literal to a UnicodeString you need the codepage.

AFAIK this is not entirely correct. The string literals are assumed to be system codepage, which does not need to be code page 28591. I will ask on the fpc list.

Yes and no.
When the compiler assumes ACP, it treats the string special. It does not convert it and stores it as byte copy. At runtime the string has CP_ACP and its codepage is defined by the variable DefaultSystemCodePage. LazUTF8 sets this to CP_UTF8, so the string is treated as UTF-8. Note that it does that without any conversion.

OTOH when you tell the compiler that the source is UTF-8, it converts the literal to UTF-16. At runtime it converts the string back to UTF-8. It does that everytime you assign the literal.

So, with both you get an UTF-8 string, but the latter has a bit more overhead. Also the latter needs special care when typecasting (e.g. PChar).

No contradiction, because this wiki page is about DefaultSystemcodePage = CP_UTF8.

Mattias

So, when my usecase for string constants with diacritics in real life most of the time is just captions for buttons/menu's etc., the extra overhead will not really be something to worry about I guess,and in this scenario adding {$codepage utf8} may be the wise thing to do: it eliminates all confusion about the intended encoding of the string constant.

So, my current intended approach for GUI applications will be:
- declare all strings as just String
- have stringconstants with unicode character all in one file and add {$codepage utf8) to that file, and then don't use -FcUTF8 anymore (which is what I'm doing ATM),

That should be rather safe then I guess.

Will all this mess go away if we would go the Delphi way (String=UnicodeString)? (I know *nix users are going to hate me now)

Bart

Well, I'm not so sure about the "eliminates all confusion" as Rick Cook said:
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to build bigger and better idiots. So far, the universe is winning."

Yes.
If you avoid PChar(Literal), invalid UTF-8 and #0.

Will all this mess go away if we would go the Delphi way (String=UnicodeString)? (I know *nix users are going to hate me now)

Which mess do you mean?
As long as you have to consider codepages, you can get a mess.

Mattias

When you use UnicodeString everywhere and no AnsiString anywhere, then the only confusion left is Endianess,or am I (as one of the Universes idiots) oversimplifying here.

In TP 3.0 I didn't have to deal with all this (but then again the guide that came with it was in Hebrew, which was a bit difficult for me).

Bart

No, you are right. If you somehow(TM) achieve to work only with UnicodeString you avoid the mess. The same if only use UTF-8 strings. Or if you only work in system codepage like in TP 3.0 times.

The problem is that you often has to work with
databases/files/libs/etc in other encodings.
So there is always a little bit of mess.

Mattias

Bart wrote

in this scenario adding {$codepage utf8} may be the wise thing to do: it eliminates all confusion about the intended encoding of the string constant.

How is a conversion to UTF-16 and then back to UTF-8 less confusing than a direct copy without conversions?

When you use UnicodeString everywhere and no AnsiString anywhere, then the only confusion left is Endianess,or am I (as one of the Universes idiots) oversimplifying here.

I doubt you will change every "String" into "UnicodeString" in your code. Somehow you missed the fundamental idea of our new Unicode system. "String" has Unicode and you don't need to care about it, or even about endianess.
Delphi reaches the same goal by mapping String -> UnicodeString. When you need Ansi codepages then you need to pay attention obviously, otherwise not.

Bart, were your earlier results caused by NOT using the new Unicode support? I am surprised if that is the case.
The whole discussion was about the new Unicode support and you have been testing it since the beginning.

Juha

In my fantasy scenario the String would of course have the meaning of UnicodeString.

Bart, were your earlier results caused by NOT using the new Unicode support?

The tests I posted in this thread were plain fpc programs, so no use of LazUtf8. It pointed out that the Lazarus part of the wiki (Better Unicode support) could be interpreted wrong.

The whole discussion was about the new Unicode support and you have been testing it since the beginning.

I have use the "Utf8 in RTL" ever since i swithed to the 3.0 compiler (I have to admit I was to scared to test the 2.7 branch, but I started with the first 3.0 RC), and the number of bugs we had to fix was far, far less than I thought it would be.

Most of my own programs seem to require no main excpetion being my backupprogram, but not beause it stopped correctly accessing filenames with unicode cahracter in their path, but because I used a procedural paramter in it's engine, for which now the signature had changed from plain string to either RawByteString or UnicodeString.
All this was solved (with ifdefs for the 2.6 compiler) quit easily.

And as I pointed out to you earlier in another thread in the forum, the "new UTF8 system" works even better than I thought.

Then again, I do not use databases in any of my programs, so I don't have to deal with that part of the problem.
All my textual data is stored in plain textfiles in UTF8 encoding, probably from the day I started using Lazarus as my main platform (0.9.16).

Anyhow, it's a fascinating issue, and the more I understand about it, the better I am able to fix encoding related problems in our (or user's) code.

Bart

Bart wrote

In my fantasy scenario the String would of course have the meaning of UnicodeString.

That is not anyhow better (or worse) inherently than a UTF-8 based solution. Delphi just happened to implement it so, for various reasons. The surprise is that our system is so Delphi compatible even while having a different encoding.

The tests I posted in this thread were plain fpc programs, so no use of LazUtf8. It pointed out that the Lazarus part of the wiki (Better Unicode support) could be interpreted wrong.

No. You interpreted it wrong for some reason. The page is only about the new Unicode support which is very clearly mentioned there! You don't have to use the UTF-8 mode which is explained in another page : http://wiki.freepascal.org/Lazarus_with_FPC3.0_without_UTF-8_mode

The main message however is that the new mode should be used unless there is a very good reason not to. That's why it was made default when LazUtils / LazUTF8 is used.
For console apps you must add the dependency / unit explicitly but it does not change any facts about the mode.

Anyway, the original issue was about inserting {codepage UTF8} automatically to every unit.
We can conclude it is not a good idea. It does not solve anything when using plain constants with default String type but adds conversion overhead. It breaks things when using constants with ShortString and PChar.

It only improves things with UnicodeString constants which is not necessarily needed at all, but can be used with added {codepage UTF8}. Simple, no hassle!

Besides I feel the problems are exaggerated again. The problems discussed here are only about constants. The automatic conversion between variables works always.

Juha

No, but I don't see fpc moving towards String equals AnsiString(CP_UTF8). It would be hugely Delphi imcompatible.

For me personally Delphi compatibility does not matter at all, I have left Delphi and won't return.
But from the fpc side, breaking compatibility in such a way is probably going to be a big no-no.

But you are rigt, we are getting off-topic more and more. Sorry for that.

Bart

Thank you very much, for your detailed answer!

I'll try to run some more tests, to understand why a BOM for UTF-8 has a other behaviour than a {$codepage UTF8}.

BTW the conversions here has nothing to do with Lazarus, it is only a FPC issue. If I don't find a answer for myself, I'll ask in the FPC mailing list.

Thanks again

Kind regards

Michl

I'm on your side. It was a good thing to ask here, cause it pointed out, that the disadvantages predominate the advantages.

Im clear for myself to that issue and can see the results in my tests too.

Thank you very much

Kind regards

Michl

Graeme Geldenhuys wrote

A word of caution, there is a major bug in FPC 3.0 regarding floating point values (see the FPC mailing list),

You do not happen to know the subject of that thread on the FPC list? I am using GMANE News mirror but I cannot find it without some hint on the actual subject text.
I am working on a project where I will have to process floating point values and do endian conversion and such stuff. So I am really anxious that this could be affected by such a bug.

Bo Berglund wrote

You do not happen to know the subject of that thread on the FPC list?

It seems to be eluding me too. :-) Maybe post a new message and ask for the Mantis bug ID to get more information.

All I remember was that it was a serious bug in currency handling on win64 (and affected other 64-bit targets too), which was a show-stopper for my client upgrading.

Regards,
- Graeme -

[fpc-devel] Bug 29760 on FPC 3.0 Win64

-Michael

Michael Schnell wrote

[fpc-devel] Bug 29760 on FPC 3.0 Win64

OK, so it was on the devel list....
I do not often check that even though it is in GMANE.

Found it now and it looks like it has something to do with operations on variables that are double and currency. Like getting the wrong exponent when multiplying them.

I never ever use currency variables so I guess I am good. :)

Don't guess. You're not that good.